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,21 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: PostToolUse audit logging
|
||||
- **WHEN** a tool is used
|
||||
- **THEN** the tool name, input summary, and timestamp are appended to the JSONL audit buffer
|
||||
|
||||
### Requirement: Stop hook flush
|
||||
- **WHEN** a response completes
|
||||
- **THEN** the audit buffer is flushed to the session audit trail and index is updated
|
||||
|
||||
### Requirement: UserPromptSubmit context injection
|
||||
- **WHEN** a user message is submitted
|
||||
- **THEN** session context (session ID, record count, critical alerts) is injected into the prompt
|
||||
|
||||
### Requirement: Anomaly detection
|
||||
- **WHEN** audit records are checked against alert rules
|
||||
- **THEN** anomalies at CRITICAL level are injected into the context
|
||||
|
||||
#### Scenario: Full audit trail
|
||||
- **WHEN** an agent runs 10 tool calls across 3 turns
|
||||
- **THEN** the audit trail contains 10 JSONL records, a session summary, and an updated index
|
||||
@@ -0,0 +1,25 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: L0 recovery (index summary)
|
||||
- **WHEN** /recover is called without arguments
|
||||
- **THEN** the last 5 index entries are loaded (~200 tokens)
|
||||
|
||||
### Requirement: L1 recovery (session state)
|
||||
- **WHEN** /recover L1 is called
|
||||
- **THEN** current session.json + last 3 audit trail entries are loaded (~500 tokens)
|
||||
|
||||
### Requirement: L2 recovery (user corrections)
|
||||
- **WHEN** /recover L2 is called
|
||||
- **THEN** ALL user_correction records across all sessions are loaded (~1000 tokens)
|
||||
|
||||
### Requirement: L3 recovery (full context)
|
||||
- **WHEN** /recover L3 is called
|
||||
- **THEN** full audit trail + all pending records are loaded (~3000 tokens)
|
||||
|
||||
### Requirement: Priority loading
|
||||
- **WHEN** recovering context
|
||||
- **THEN** user_correction records are loaded first (highest priority)
|
||||
|
||||
#### Scenario: Session crash recovery
|
||||
- **WHEN** an agent session crashes and restarts with /recover
|
||||
- **THEN** the agent gets the index summary, last session state, and all user corrections
|
||||
@@ -0,0 +1,17 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Guideline creation
|
||||
- **WHEN** creating a guideline with condition, action, and criticality
|
||||
- **THEN** it is stored with unique ID and metadata
|
||||
|
||||
### Requirement: Guideline evaluation
|
||||
- **WHEN** an agent action triggers guideline evaluation
|
||||
- **THEN** matching guidelines are activated with score and rationale
|
||||
|
||||
### Requirement: Criticality levels
|
||||
- **WHEN** evaluating guidelines
|
||||
- **THEN** guidelines are filtered by criticality (low/medium/high/critical) with higher-criticality taking precedence
|
||||
|
||||
#### Scenario: Security policy enforcement
|
||||
- **WHEN** an agent attempts to edit a file matching a security guideline condition
|
||||
- **THEN** the guideline matcher returns the relevant rule with CRITICAL severity
|
||||
@@ -0,0 +1,17 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Six batch types
|
||||
- **WHEN** guidelines are evaluated
|
||||
- **THEN** they are processed through: Observational, Actionable, PreviouslyApplied, Disambiguation, ResponseAnalysis, and LowCriticality batches
|
||||
|
||||
### Requirement: Parallel batch execution
|
||||
- **WHEN** independent batches are ready
|
||||
- **THEN** they execute in parallel (observational + actionable run concurrently)
|
||||
|
||||
### Requirement: Structured LLM output per batch
|
||||
- **WHEN** a batch calls the LLM
|
||||
- **THEN** it uses a structured schema specific to the batch type (e.g., applies: boolean for actionable, was_followed: boolean for response analysis)
|
||||
|
||||
#### Scenario: Multi-rule evaluation
|
||||
- **WHEN** an agent action matches 3 guidelines across different criticalities
|
||||
- **THEN** the matcher returns all applicable matches with scores, with CRITICAL matches flagged
|
||||
@@ -0,0 +1,21 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: DEPENDS_ON resolution
|
||||
- **WHEN** guideline A depends on guideline B
|
||||
- **THEN** B is activated if A is activated
|
||||
|
||||
### Requirement: PRIORITIZES resolution
|
||||
- **WHEN** guideline A prioritizes over guideline B
|
||||
- **THEN** B is filtered out if both match
|
||||
|
||||
### Requirement: ENTAILS resolution
|
||||
- **WHEN** guideline A entails guideline B
|
||||
- **THEN** B is automatically activated when A is activated
|
||||
|
||||
### Requirement: Iterative convergence
|
||||
- **WHEN** resolving relationships
|
||||
- **THEN** the resolver iterates (max 100 iterations) until no more changes or stable state
|
||||
|
||||
#### Scenario: Conflicting guideline resolution
|
||||
- **WHEN** a HIGH priority guideline matches and a LOW priority guideline also matches
|
||||
- **THEN** the LOW priority guideline is filtered out via numerical priority resolution
|
||||
Reference in New Issue
Block a user