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,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
|
||||
Reference in New Issue
Block a user