chore(openspec): drop 9 superseded proposals + 11 stub archive files
Drop 9 batch proposals that are superseded by the boocode-lift-analysis (boocontext-audit, conductor upgrades, self-healing/verify-gate skills): add-3tier-memory, import-llm-evaluator, import-pregel-engine, plugin-platform, conductor-evolution, code-intelligence-upgrade, dev-workflow, ui-overhaul, agent-reliability. Delete 11 stub archive files (49-66B each, 'Status: Shipped. Archived.' only) that provide zero documentation value over the existing CHANGELOG.md + git tags.
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-06-07
|
||||
76
openspec/changes/audit-harness-integration/design.md
Normal file
76
openspec/changes/audit-harness-integration/design.md
Normal file
@@ -0,0 +1,76 @@
|
||||
## Context
|
||||
|
||||
boocontext (TypeScript code scanner, MCP server) and codecontext (Go code graph engine, MCP server) currently lack persistent audit trails for their operations. When a scan or graph analysis is interrupted, context is lost — tool calls have no recoverable log, session state disappears, and there's no mechanism to detect repeated mistakes or anomalies across runs.
|
||||
|
||||
The audit-harness repo provides a production-tested 3-layer audit enforcement system. Its hooks (PostToolUse, Stop, UserPromptSubmit) intercept every tool call, buffer to JSONL, flush to session trails, and inject session context on every user turn. Its Python core library (AuditContext, 600 lines) provides environment snapshots, SHA256 verification, configurable anomaly detection, and unified index management.
|
||||
|
||||
This design ports the **hook audit pipeline** into both tools as MCP server middleware, and the **session lifecycle** as boocode commands.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- Port PostToolUse pattern as MCP middleware → auto-log every tool call to JSONL buffer
|
||||
- Port Stop pattern as MCP middleware → flush buffer to session trail + update index on completion
|
||||
- Port UserPromptSubmit pattern as MCP middleware → inject session context + CRITICAL alerts on each request
|
||||
- Port /start, /end, /recover, /report-daily as boocode commands
|
||||
- Port AuditContext's unified index schema for cross-session tracking
|
||||
- All patterns opt-in via configuration, zero breaking changes
|
||||
|
||||
**Non-Goals:**
|
||||
- Full AuditContext Python class port (environment snapshots, anomaly lambdas) — Phase 2
|
||||
- Parlant's relationship resolver (ARQ) — separate change
|
||||
- Codex/Claude-specific hook formats — only MCP middleware abstraction
|
||||
|
||||
## Decisions
|
||||
|
||||
### Decision 1: MCP Middleware over Hook Scripts
|
||||
**Choice**: Implement audit as MCP server middleware (TypeScript for boocontext, Go for codecontext), not shell hooks.
|
||||
**Rationale**: Shell hooks (like audit-harness uses) are platform-specific (Claude Code vs Codex). MCP middleware is framework-agnostic — any MCP client automatically gets audit trails. Both boocontext and codecontext already have MCP servers.
|
||||
**Alternatives considered**: Shell hooks (rejected — platform-specific), Python subprocess (rejected — dependency overhead).
|
||||
|
||||
### Decision 2: JSONL Buffer + File Rotation
|
||||
**Choice**: Port audit-harness's JSONL buffer pattern exactly — append-only JSONL with size-limited rotation (1MB per buffer file).
|
||||
**Rationale**: JSONL is grep-able, pipeable, compressible, and append-only. The 1MB limit prevents unbounded memory growth. This is the most battle-tested pattern in audit-harness.
|
||||
**Alternatives considered**: SQLite (rejected — adds DB dependency for a log), structured logging (rejected — not designed for session replay).
|
||||
|
||||
### Decision 3: Session Handoff via Pointer File
|
||||
**Choice**: Port the `.current_session` handshake file pattern — a single file containing the current session ID, read by all hooks.
|
||||
**Rationale**: This is the simplest reliable inter-process coordination. No locks, no DB, no race conditions (atomic writes). Works across MCP middleware invocations.
|
||||
**Alternatives considered**: Environment variable (rejected — not persistent across MCP calls), in-memory state (rejected — lost on restart).
|
||||
|
||||
### Decision 4: Unified Index Schema (JSON)
|
||||
**Choice**: Port the index.json schema with `schema_version`, `entries[]` containing `{id, type, task, created, status, record_count}`.
|
||||
**Rationale**: audit-harness's index schema is proven across 4 skills + 3 hooks writing to the same file. JSON with version field allows forward-compatible schema evolution.
|
||||
**Alternatives considered**: SQLite (rejected — overkill for metadata index), binary format (rejected — not human-readable).
|
||||
|
||||
### Decision 5: Graded Context Recovery (L0-L4)
|
||||
**Choice**: Port the tiered loading system — Level 0 (index, ~200t) → Level 1 (task state, ~500t) → Level 2 (corrections, ~1000t) → Level 3 (full, ~3000t) → Level 4 (cross-day, ~5000t+).
|
||||
**Rationale**: Loading all context every time wastes tokens. Graded loading lets the agent fetch exactly what it needs. The token budgets are tuned to avoid context window exhaustion.
|
||||
**Alternatives considered**: Load-all (rejected — token waste), agent-decides (rejected — inconsistent).
|
||||
|
||||
### Decision 6: Opt-in Configuration
|
||||
**Choice**: All audit features disabled by default. Enabled via `audit.enabled: true` in the MCP server config.
|
||||
**Rationale**: Zero behavioral change for existing users. Audit is valuable but has file I/O overhead.
|
||||
**Alternatives considered**: Always-on (rejected — breaking change), env-var-only (rejected — less discoverable).
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- **[Risk]** JSONL buffer write contention under high concurrency → **Mitigation**: Append-only writes are atomic on most filesystems for lines under PIPE_BUF. Use flock() for safety on NFS.
|
||||
- **[Risk]** Disk space from unbounded audit trails → **Mitigation**: Configurable `audit.maxRetentionDays` (default 30), auto-cleanup on session end.
|
||||
- **[Risk]** Performance overhead from every tool call being logged → **Mitigation**: Buffer writes are async (fire-and-forget). Benchmarked at <0.5ms per write in audit-harness.
|
||||
- **[Trade-off]** File-based audit is simple but doesn't scale to distributed deployments → Acceptable for single-node code analysis tools. Cluster deployments would need a DB-backed backend in Phase 2.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. **Phase 1a**: Add +audit middleware to boocontext's MCP server (PostToolUse + Stop patterns, JSONL buffer to session dirs)
|
||||
2. **Phase 1b**: Add audit middleware to codecontext's MCP server (same patterns, Go implementation)
|
||||
3. **Phase 1c**: Add `/start`, `/end`, `/recover`, `/report-daily` commands to boocode
|
||||
4. **Phase 2a**: Port AuditContext Python class to TypeScript (environment snapshots, hash verification, anomaly detection)
|
||||
5. **Phase 2b**: Add CRITICAL anomaly alert injection (UserPromptSubmit pattern)
|
||||
6. **Rollback**: Remove `audit.enabled: true` from config → zero residual effects. Delete `.audit/` directory to purge all data.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should the buffer flush be synchronous (blocking response until written) or async (fire-and-forget, could lose last N records on crash)? audit-harness uses sync flush on Stop hook — recommend same for consistency.
|
||||
- Index.json merge strategy when two processes write simultaneously? audit-harness uses atomic file replace (write .tmp → os.replace) — adequate for single-process MCP server.
|
||||
- Token budget for context injection on UserPromptSubmit? audit-harness uses ~50 tokens for the context prefix. Recommend same default with `audit.maxContextTokens` config.
|
||||
38
openspec/changes/audit-harness-integration/proposal.md
Normal file
38
openspec/changes/audit-harness-integration/proposal.md
Normal file
@@ -0,0 +1,38 @@
|
||||
## Why
|
||||
|
||||
The audit-harness repo provides a production-tested 3-layer audit enforcement system for LLM agents — hooks (PostToolUse, Stop, UserPromptSubmit), skills (/start, /end, /recover, /report-daily), and a Python core library (AuditContext). This system solves the #1 pain point for agent-based code analysis tools: context window loss and lack of traceability. Integrating these patterns into boocontext (code scanner) and codecontext (code graph engine) will provide persistent audit trails, context recovery across sessions, and structured operation logs.
|
||||
|
||||
The total effort to port the high-value subset is approximately **25-30 person-days**, with the highest ROI being the buffer/flush pipeline and unified index schema for codecontext.
|
||||
|
||||
## What Changes
|
||||
|
||||
### New Capabilities
|
||||
- **context-recovery**: Port audit-harness's graded context loading system (L0-L4) into boocontext for LLM context window persistence across code analysis sessions. Each analysis step is recorded to a JSONL buffer, flushed to session trails on completion, and recoverable on session resume.
|
||||
|
||||
- **hook-audit-pipeline**: Port the 3 audit hooks (PostToolUse → buffer, Stop → flush to trail, UserPromptSubmit → context injection) into codecontext as MCP server middleware. Every tool call in codecontext's MCP server is automatically logged to an audit trail with timestamps, summaries, and session IDs.
|
||||
|
||||
- **session-lifecycle**: Port the /start → /end → /recover → /report-daily skill flow into boocode's command system. /start creates named analysis sessions with context recovery, /end performs integrity checks and generates summaries, /recovers restores lost context through graded loading, /report-daily generates structured work reports from audit data.
|
||||
|
||||
### Modified Capabilities
|
||||
- boocontext's `MCP server` → Add audit middleware layer for automatic tool-call capture
|
||||
- codecontext's `graph index` → Adopt audit-harness's unified index.json schema for cross-session state tracking
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `context-recovery`: Graded context loading (L0-L4) from persistent audit trails. On session start or `/recover`, loads index summary (~200t), task state (~500t), user corrections (~1000t), or full context (~3000t) depending on need. Prevents rework of already-corrected mistakes.
|
||||
|
||||
- `hook-audit-pipeline`: Three MCP middleware hooks: PostToolUse captures tool calls (tool_name, session_id, summary) to audit_buffer.jsonl; Stop flushes buffer + pending to session trail + updates unified index; UserPromptSubmit injects current session context and CRITICAL alerts into every user turn.
|
||||
|
||||
- `session-lifecycle`: Named analysis sessions with lifecycle: /start creates session.json + .current_session; /end integrity-checks all records, generates session_summary.md; /recover loads context in increasing detail; /report-daily generates 7-section work reports with operation stats, anomalies, user feedback, backlog.
|
||||
|
||||
### Modified Capabilities
|
||||
- `mcp-server` (boocontext): Add optional audit middleware that intercepts tool calls for logging
|
||||
- `graph-index` (codecontext): Extend index schema to include audit-compatible session tracking
|
||||
|
||||
## Impact
|
||||
|
||||
- **boocontext**: Adds ~500 lines of Go/TS for buffer management and hook middleware. No breaking changes — audit is opt-in via configuration.
|
||||
- **codecontext**: Adds ~300 lines of TypeScript for the unified index schema extension. Backward compatible.
|
||||
- **boocode**: Adds 4 new commands (/start, /end, /recover, /report-daily), ~400 lines of skill definitions. No existing command breakage.
|
||||
- **Dependencies**: Python 3.10+ for the audit_context.py core (boocontext already uses Python for tree-sitter); bash for hooks (existing shell tooling). No new external services.
|
||||
@@ -0,0 +1,42 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Graded context recovery from audit trails
|
||||
The system SHALL support context recovery at 5 graded levels (L0-L4), each returning progressively more detailed context from persistent audit trail files.
|
||||
|
||||
#### Scenario: L0 recovery loads index summary
|
||||
- **WHEN** user invokes `/recover` with no arguments
|
||||
- **THEN** system reads `index.json` and returns the last 5 index entries (id + task + status) at approximately 200 tokens
|
||||
|
||||
#### Scenario: L1 recovery loads current task state
|
||||
- **WHEN** user invokes `/recover` with `level: 1`
|
||||
- **THEN** system reads `.current_session` for session ID, then reads `{session_id}/session.json` for task + start_time, then reads the last 3 audit_trail.jsonl records
|
||||
|
||||
#### Scenario: L2 recovery loads user corrections
|
||||
- **WHEN** user invokes `/recover` with `level: 2`
|
||||
- **THEN** system searches all `audit_trail.jsonl` files for `user_correction` records and returns them alongside L1 context at approximately 1000 tokens
|
||||
|
||||
#### Scenario: L3 recovery loads full session
|
||||
- **WHEN** user invokes `/recover` with `level: 3` or `/recover full`
|
||||
- **THEN** system returns complete `audit_trail.jsonl` and `audit_pending.jsonl` at approximately 3000 tokens
|
||||
|
||||
#### Scenario: L4 recovery loads cross-day history
|
||||
- **WHEN** user invokes `/recover` with `level: 4`
|
||||
- **THEN** system returns cross-day comparison of manifests and historical daily reports at approximately 5000+ tokens
|
||||
|
||||
#### Scenario: Session start auto-recovery
|
||||
- **WHEN** `/start` creates a new session and historical audit data exists
|
||||
- **THEN** system SHALL load L0 + L2 context automatically (index summary + user corrections) before the new session begins
|
||||
|
||||
### Requirement: User correction priority in context loading
|
||||
The system SHALL mark `user_correction` records with highest priority in all context recovery operations. Corrections SHALL always be loaded before task state or any other context.
|
||||
|
||||
#### Scenario: Corrections surfaced first on recovery
|
||||
- **WHEN** `/recover` loads context
|
||||
- **THEN** any `user_correction` records in the audit trail SHALL appear before task summaries and SHALL be clearly labeled as "User Corrections — Review These First"
|
||||
|
||||
### Requirement: Structured recovery report
|
||||
The system SHALL output a structured recovery report containing: current task, user corrections found, key conclusions from context, unresolved issues, and recent actions.
|
||||
|
||||
#### Scenario: Recovery report includes all sections
|
||||
- **WHEN** context recovery completes
|
||||
- **THEN** output SHALL contain: `**Current Task**`, `**User Corrections**`, `**Conclusions**`, `**Open Issues**`, `**Recent Activity**`
|
||||
@@ -0,0 +1,56 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: MCP middleware captures tool calls to buffer
|
||||
The MCP server SHALL provide injectable middleware that intercepts every tool call response and appends a structured record to `audit_buffer.jsonl` in the configured audit directory.
|
||||
|
||||
#### Scenario: PostToolUse captures tool name and summary
|
||||
- **WHEN** any MCP tool completes execution
|
||||
- **THEN** middleware SHALL write a JSONL record with `{timestamp, tool, session, summary}` to `audit_buffer.jsonl`
|
||||
- **THEN** `tool` SHALL be the MCP tool name
|
||||
- **THEN** `summary` for Bash tools SHALL be the first non-comment command line (truncated to 200 chars)
|
||||
- **THEN** `summary` for Write/Edit tools SHALL be the file path
|
||||
|
||||
#### Scenario: Buffer is size-limited
|
||||
- **WHEN** tool call output exceeds 1MB
|
||||
- **THEN** middleware SHALL truncate input to 1MB via `head -c 1048576` before processing
|
||||
|
||||
#### Scenario: Buffer directory is auto-created
|
||||
- **WHEN** first tool call is captured
|
||||
- **THEN** middleware SHALL create the audit runs directory with `mkdir -p`
|
||||
|
||||
#### Scenario: Failures do not block tool execution
|
||||
- **WHEN** buffer write fails (disk full, permission denied)
|
||||
- **THEN** middleware SHALL silently skip logging and allow the tool response to proceed
|
||||
|
||||
### Requirement: Session flush archives buffer to trail
|
||||
The MCP middleware SHALL provide a flush mechanism that moves buffered records into session-specific audit trail files.
|
||||
|
||||
#### Scenario: Flush moves buffer to session trail
|
||||
- **WHEN** middleware flush is triggered (on session end or explicit flush call)
|
||||
- **THEN** system SHALL read `audit_buffer.jsonl` + `audit_pending.jsonl`
|
||||
- **THEN** system SHALL concatenate them into `{session_id}/audit_trail.jsonl`
|
||||
- **THEN** system SHALL clear both buffer files
|
||||
|
||||
#### Scenario: Auto-session for unstarted sessions
|
||||
- **WHEN** no active session exists and flush is triggered
|
||||
- **THEN** system SHALL auto-generate session ID `auto_{YYYYMMDD_HHMM}` and continue
|
||||
|
||||
#### Scenario: Session ID via handshake file
|
||||
- **WHEN** a session is active via `/start`
|
||||
- **THEN** `{auditDir}/.current_session` SHALL contain the session ID
|
||||
- **THEN** flush SHALL read this file to determine the target session directory
|
||||
|
||||
### Requirement: Context injection on each request
|
||||
The MCP middleware SHALL inject current session context into every incoming request's metadata.
|
||||
|
||||
#### Scenario: Session context injected at request start
|
||||
- **WHEN** any MCP request arrives
|
||||
- **THEN** middleware SHALL add `{audit.session_id, audit.record_count, audit.status}` to the request context
|
||||
|
||||
#### Scenario: CRITICAL alerts injected
|
||||
- **WHEN** `index.json` contains entries with `max_anomaly_level: "CRITICAL"`
|
||||
- **THEN** middleware SHALL append CRITICAL alert details to the injected context
|
||||
|
||||
#### Scenario: Context injection is configurable
|
||||
- **WHEN** `audit.contextInjection` is set to `false`
|
||||
- **THEN** middleware SHALL skip context injection entirely
|
||||
@@ -0,0 +1,76 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: /start creates named audit session
|
||||
The system SHALL provide a `/start` command that creates a named audit session with task description, start time, and persistent session ID.
|
||||
|
||||
#### Scenario: /start creates session directory
|
||||
- **WHEN** user runs `/start "fix auth bug"`
|
||||
- **THEN** system SHALL generate session ID `adhoc_{YYYYMMDD_HHMM}`
|
||||
- **THEN** system SHALL create `{auditDir}/{session_id}/` directory
|
||||
- **THEN** system SHALL write `session.json` with `{session_id, task, start_time, status: "in_progress"}`
|
||||
- **THEN** system SHALL write `{auditDir}/.current_session` with the session ID
|
||||
|
||||
#### Scenario: /start recovers context from history
|
||||
- **WHEN** user runs `/start` and historical audit data exists
|
||||
- **THEN** system SHALL load Level 0 (index summary) and Level 2 (user corrections) automatically
|
||||
|
||||
#### Scenario: /start outputs recovery summary
|
||||
- **WHEN** `/start` completes
|
||||
- **THEN** system SHALL output: started session ID, recovery summary with any corrections found, current session directory path
|
||||
|
||||
### Requirement: /end finalizes session with integrity check
|
||||
The system SHALL provide an `/end` command that collects remaining data, validates completeness, generates a summary, and marks the session as completed.
|
||||
|
||||
#### Scenario: /end collects and archives remaining data
|
||||
- **WHEN** user runs `/end`
|
||||
- **THEN** system SHALL flush audit buffer + pending to session trail
|
||||
- **THEN** system SHALL extract all `user_correction` records from the session trail
|
||||
|
||||
#### Scenario: /end runs integrity checks
|
||||
- **WHEN** `/end` runs integrity checks
|
||||
- **THEN** system SHALL verify: records exist, critical files are covered by audit, prompt changes are validated, corrections are persisted
|
||||
- **THEN** system SHALL record any failed checks as anomalies in `anomalies.json`
|
||||
|
||||
#### Scenario: /end generates session summary
|
||||
- **WHEN** `/end` completes
|
||||
- **THEN** system SHALL generate `session_summary.md` with operation count, files touched, corrections made, anomalies detected
|
||||
- **THEN** system SHALL update `session.json` status to `completed`
|
||||
- **THEN** system SHALL clear `.current_session`
|
||||
|
||||
### Requirement: /recover restores lost context
|
||||
The system SHALL provide a `/recover` command that restores LLM context from audit trails at multiple detail levels.
|
||||
|
||||
#### Scenario: /recover with no args loads L1 context
|
||||
- **WHEN** user runs `/recover`
|
||||
- **THEN** system SHALL load Level 1 context (current task state, last 3 actions)
|
||||
|
||||
#### Scenario: /recover full loads L3 context
|
||||
- **WHEN** user runs `/recover full`
|
||||
- **THEN** system SHALL load Level 3 context (full session trail)
|
||||
|
||||
#### Scenario: /recover {session_id} loads specific session
|
||||
- **WHEN** user runs `/recover 20260607_1200`
|
||||
- **THEN** system SHALL load context from session `20260607_1200`
|
||||
|
||||
### Requirement: /report-daily generates structured work report
|
||||
The system SHALL provide `/report-daily` that aggregates all session data into a structured daily report with traceable metrics.
|
||||
|
||||
#### Scenario: /report-daily generates 7-section report
|
||||
- **WHEN** user runs `/report-daily`
|
||||
- **THEN** system SHALL generate a report with: task overview, operation statistics, file/resource changes, anomaly summary, user feedback, backlog items, data integrity status
|
||||
- **THEN** every number in the report SHALL be sourced from `{auditDir}/` files — no inferred or remembered data
|
||||
|
||||
#### Scenario: /report-daily for specific date
|
||||
- **WHEN** user runs `/report-daily 20260607`
|
||||
- **THEN** system SHALL generate report for June 7, 2026 only
|
||||
|
||||
#### Scenario: /report-daily review mode
|
||||
- **WHEN** user runs `/report-daily review`
|
||||
- **THEN** system SHALL include morning self-review section with trend analysis and anomaly comparisons
|
||||
|
||||
### Requirement: Session lifecycle is opt-in
|
||||
All session lifecycle commands SHALL be opt-in via configuration. Systems without audit enabled SHALL have no session lifecycle commands available.
|
||||
|
||||
#### Scenario: Commands hidden when audit disabled
|
||||
- **WHEN** `audit.enabled` is `false` or unset
|
||||
- **THEN** `/start`, `/end`, `/recover`, `/report-daily` SHALL NOT be registered as commands
|
||||
57
openspec/changes/audit-harness-integration/tasks.md
Normal file
57
openspec/changes/audit-harness-integration/tasks.md
Normal file
@@ -0,0 +1,57 @@
|
||||
## 1. Data Directory Convention (cross-cutting)
|
||||
|
||||
- [ ] 1.1 Define `.boo/runs/` directory structure — runs_dir/buffer/session dirs/.current_session/index.json
|
||||
- [ ] 1.2 Implement `.boo/runs/` directory auto-creation with `.gitignore`
|
||||
- [ ] 1.3 Add `AUDIT_DOT_DIR` environment variable support for platform-specific directory naming
|
||||
- [ ] 1.4 Implement `find_runs_dir()` — walk up from CWD looking for {AUDIT_DOT_DIR}/runs
|
||||
|
||||
## 2. Buffer + Flush Pipeline (MCP middleware)
|
||||
|
||||
- [ ] 2.1 Implement PostToolUse middleware: capture tool_name + summary → append to `audit_buffer.jsonl`
|
||||
- [ ] 2.2 Implement Stop middleware: read `.current_session`, flush buffer+pending to session trail
|
||||
- [ ] 2.3 Implement atomic session.json update preserving existing fields
|
||||
- [ ] 2.4 Implement `.current_session` handshake protocol (create/read/clear)
|
||||
- [ ] 2.5 Add safe input truncation (1MB cap) for large tool payloads
|
||||
- [ ] 2.6 Implement UserPromptSubmit middleware: inject session context + CRITICAL alerts
|
||||
- [ ] 2.7 Register all middleware with opt-in gate (`audit.enabled: true`)
|
||||
|
||||
## 3. Unified Index Schema
|
||||
|
||||
- [ ] 3.1 Define `INDEX_ENTRY_REQUIRED` and `INDEX_ENTRY_OPTIONAL` field schemas
|
||||
- [ ] 3.2 Implement `update_index_entry()` with idempotent upsert and atomic `.tmp` + rename
|
||||
- [ ] 3.3 Implement `schema_version=1.1` tracking in index.json
|
||||
- [ ] 3.4 Add CLI entry point for hooks to call `update-index --runs-dir X --id Y ...`
|
||||
|
||||
## 4. Graded Context Recovery
|
||||
|
||||
- [ ] 4.1 Implement L0 recovery: read last 5 index.json entries (~200 tokens)
|
||||
- [ ] 4.2 Implement L1 recovery: read session.json + last 3 audit_trail entries (~500 tokens)
|
||||
- [ ] 4.3 Implement L2 recovery: scan all audit trails for user_correction records (~1000 tokens)
|
||||
- [ ] 4.4 Implement L3 recovery: full audit_trail + all pending records (~3000 tokens)
|
||||
- [ ] 4.5 Implement recovery report output format: current task, corrections, conclusions, open issues, recent activity
|
||||
- [ ] 4.6 Implement priority loading: user_correction records always loaded first
|
||||
|
||||
## 5. Session Lifecycle Commands
|
||||
|
||||
- [ ] 5.1 Implement `/start` command: generate session ID, write session.json + .current_session, auto-recover L0+L2
|
||||
- [ ] 5.2 Implement `/end` command: flush buffers, run integrity checks, generate session_summary.md, update index
|
||||
- [ ] 5.3 Implement `/recover` command: graded context loading (L0-L3), support for specific session IDs
|
||||
- [ ] 5.4 Implement `/report-daily` command: aggregate index + audit trails, 7-section report with task overview, ops stats, changes, anomalies, feedback, backlog, integrity
|
||||
- [ ] 5.5 Implement `/report-daily review` mode: add morning self-review with trend analysis
|
||||
- [ ] 5.6 Implement unfinished session detection + continue prompt
|
||||
- [ ] 5.7 Register all commands behind `audit.enabled` gate
|
||||
|
||||
## 6. Ambient Context via AsyncLocalStorage
|
||||
|
||||
- [ ] 6.1 Implement `AmbientContext` class wrapping Node.js `AsyncLocalStorage` with `run()`/`get()`/`set()`
|
||||
- [ ] 6.2 Define `AmbientState` interface: sessionId, sessionDir, runsDir, agentId, toolCall
|
||||
- [ ] 6.3 Wire context set at MCP handler/command entry point, clear on session end
|
||||
- [ ] 6.4 Replace explicit parameter threading in audit pipeline with ambient context reads
|
||||
|
||||
## 7. Testing & Verification
|
||||
|
||||
- [ ] 7.1 Unit tests for buffer write, flush, index update
|
||||
- [ ] 7.2 Unit tests for context recovery at all 4 levels
|
||||
- [ ] 7.3 Integration test: full session lifecycle (/start → tool calls → /end)
|
||||
- [ ] 7.4 Integration test: context recovery after mid-session interruption
|
||||
- [ ] 7.5 Verify zero behavioral change when `audit.enabled` is false
|
||||
Reference in New Issue
Block a user