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,80 @@
|
||||
# Behavioral Guidelines Store — Spec
|
||||
|
||||
## Guideline Entity
|
||||
|
||||
```typescript
|
||||
interface GuidelineContent {
|
||||
condition: string; // When...
|
||||
action: string | null; // Then...
|
||||
description: string | null;
|
||||
}
|
||||
|
||||
interface Guideline {
|
||||
id: string;
|
||||
creationUtc: string;
|
||||
content: GuidelineContent;
|
||||
enabled: boolean;
|
||||
tags: string[];
|
||||
labels: string[];
|
||||
metadata: Record<string, unknown>;
|
||||
criticality: "low" | "medium" | "high";
|
||||
title: string | null;
|
||||
priority: number;
|
||||
}
|
||||
```
|
||||
|
||||
## GuidelineDocumentStore
|
||||
|
||||
File-based JSON store at `.boo/guidelines/`. Versioned with migration support.
|
||||
|
||||
Methods:
|
||||
- `createGuideline(condition, action?, description?, ...) → Guideline`
|
||||
- `listGuidelines(tags?, labels?) → Guideline[]`
|
||||
- `readGuideline(id) → Guideline`
|
||||
- `updateGuideline(id, params) → Guideline`
|
||||
- `deleteGuideline(id) → void`
|
||||
- `findGuideline(content: {condition, action?}) → Guideline`
|
||||
|
||||
Version migration chain (port from Parlant v0.1.0 → v0.11.0):
|
||||
- v0.1.0 → v0.2.0: add enabled field
|
||||
- v0.2.0 → v0.3.0: remove guideline_set (migration script only)
|
||||
- v0.3.0 → v0.4.0: add optional action, description, metadata
|
||||
- v0.4.0 → v0.5.0: description as optional
|
||||
- v0.5.0 → v0.6.0: add criticality (default "medium")
|
||||
- v0.6.0 → v0.7.0: add composition_mode (optional)
|
||||
- v0.7.0 → v0.8.0: add track (default true)
|
||||
- v0.8.0 → v0.9.0: add labels (default empty)
|
||||
- v0.9.0 → v0.10.0: add priority (default 0)
|
||||
- v0.10.0 → v0.11.0: add title (default null)
|
||||
|
||||
## Tag & Label Filtering
|
||||
|
||||
- `listGuidelines({tags: ["tag1"]})` → guidelines with ANY of the specified tags
|
||||
- `listGuidelines({labels: ["label1"]})` → guidelines with ALL specified labels (subset match)
|
||||
- Combined: both filters apply (intersection)
|
||||
|
||||
## Journey → Guideline Projection
|
||||
|
||||
Port of Parlant's `JourneyGuidelineProjection.project_journey_to_guidelines()`:
|
||||
|
||||
- DFS traversal of Journey nodes from root
|
||||
- Each (edge, node) pair → one Guideline
|
||||
- Edge condition becomes guideline condition
|
||||
- Node action becomes guideline action
|
||||
- Edge/node metadata merged into guideline metadata with journey_node key
|
||||
- follow_ups list populated with downstream guideline IDs
|
||||
- BFS queue avoids infinite loops via visited set
|
||||
|
||||
## Journey Backtrack Detection
|
||||
|
||||
```typescript
|
||||
interface BacktrackCheck {
|
||||
journeyId: string;
|
||||
currentNodeId: string;
|
||||
previousNodeId: string;
|
||||
isBacktrack: boolean;
|
||||
recommendation: string | null;
|
||||
}
|
||||
```
|
||||
|
||||
Scans the edge list for source→target relationships. If the agent's current step has an edge back to a previously visited node (and that node is not in a forward path from current), it's flagged as a backtrack regression.
|
||||
@@ -0,0 +1,88 @@
|
||||
# Session Lifecycle Commands — Spec
|
||||
|
||||
## Overview
|
||||
|
||||
Four agent-invocable commands that manage audit session lifecycle. Each command is a skill markdown file loaded by the agent on invocation.
|
||||
|
||||
## /start
|
||||
|
||||
```
|
||||
/start "task description"
|
||||
```
|
||||
|
||||
Creates a named audit session:
|
||||
|
||||
1. Generate `session_id = adhoc_YYYYMMDD_HHMM`
|
||||
2. `mkdir -p .boo/runs/{session_id}`
|
||||
3. Write `session.json`:
|
||||
```json
|
||||
{
|
||||
"session_id": "adhoc_20260320_1400",
|
||||
"task": "task description",
|
||||
"start_time": "2026-03-20T14:00:00Z",
|
||||
"status": "in_progress",
|
||||
"expected_record_types": ["data", "change", "conversation"]
|
||||
}
|
||||
```
|
||||
4. Write `.boo/runs/.current_session` containing session_id (handshake for hooks)
|
||||
5. Run context recovery:
|
||||
- L0: read `index.json` → last 5 entries
|
||||
- L2: scan recent audit_trail.jsonl for `user_correction` records
|
||||
6. Output recovery summary: recent activity, corrections, priorities
|
||||
7. Check for unfinished sessions: scan for `status: "in_progress"` sessions, prompt user
|
||||
|
||||
## /end
|
||||
|
||||
```
|
||||
/end
|
||||
```
|
||||
|
||||
Ends the current audit session:
|
||||
|
||||
1. Read `.current_session` → get session_id
|
||||
2. Collect remaining buffer data from `audit_buffer.jsonl` + `audit_pending.jsonl`
|
||||
3. Append to `audit_trail.jsonl`
|
||||
4. Clear buffer files
|
||||
5. Extract `user_correction` records from audit_trail
|
||||
6. Run integrity checks:
|
||||
- Has records? (>0 audit_trail lines)
|
||||
- All files covered? (changes in audit_trail match modified files)
|
||||
- Corrections persisted? (persisted_to is non-empty)
|
||||
7. Generate `session_summary.md`
|
||||
8. Update `session.json` status=completed, end_time
|
||||
9. Clear `.current_session`
|
||||
|
||||
## /recover
|
||||
|
||||
```
|
||||
/recover # L0+L1+L2
|
||||
/recover full # L3 (full audit_trail)
|
||||
/recover {session_id} # load specific session
|
||||
```
|
||||
|
||||
Graded context loading:
|
||||
|
||||
- L0 (~200t): index.json → last 5 entries (id, task, status)
|
||||
- L1 (~500t): .current_session + session.json + last 3 audit_trail entries
|
||||
- L2 (~1000t): scan all audit_trails for user_correction records + conclusions + daily report §4+§6
|
||||
- L3 (~3000t): full audit_trail.jsonl + audit_pending.jsonl
|
||||
|
||||
## /report-daily
|
||||
|
||||
```
|
||||
/report-daily # today
|
||||
/report-daily 20260319 # specific date
|
||||
/report-daily review # + morning self-review
|
||||
```
|
||||
|
||||
7-section report:
|
||||
|
||||
1. Task overview (from index.json)
|
||||
2. Operation stats (tool counts)
|
||||
3. Change records (file modifications)
|
||||
4. User feedback & corrections
|
||||
5. Anomaly alerts
|
||||
6. Backlog tracking
|
||||
7. Integrity summary
|
||||
|
||||
`review` variant: adds morning self-review with trend analysis and recommended priorities.
|
||||
@@ -0,0 +1,42 @@
|
||||
# User Correction Tracking — Spec
|
||||
|
||||
## Record Schema
|
||||
|
||||
```typescript
|
||||
interface UserCorrectionRecord {
|
||||
record_type: "conversation";
|
||||
action_type: "user_correction";
|
||||
priority: "critical_for_recovery";
|
||||
timestamp: string; // ISO 8601
|
||||
original_claim: string; // what the agent said that was wrong
|
||||
correction: string; // what the user corrected it to
|
||||
principle_extracted: string; // general principle derived from this correction
|
||||
persisted_to: string[]; // files where this correction was documented
|
||||
}
|
||||
```
|
||||
|
||||
## Storage
|
||||
|
||||
User correction records are stored inline in `audit_trail.jsonl` as regular entries. They are extracted during `/end` and surfaced during `/recover` L2 loading.
|
||||
|
||||
## Detection
|
||||
|
||||
During `/end`, scan the session's `audit_trail.jsonl` for entries matching:
|
||||
- `action_type === "user_correction"`
|
||||
|
||||
Also scan `audit_pending.jsonl` for any pending correction records not yet flushed.
|
||||
|
||||
## persisted_to Field
|
||||
|
||||
When a correction is written to CLAUDE.md, coding standards, or other documentation, the file paths are recorded in `persisted_to[]`. This is populated manually by the agent when it persists the correction.
|
||||
|
||||
## Correction-as-Precedent
|
||||
|
||||
When an agent considers an action that contradicts a known `user_correction` record, it is flagged with a warning. The agent should:
|
||||
|
||||
1. Identify the contradiction (which rule is being violated)
|
||||
2. Surface the relevant correction record (with timestamp and original context)
|
||||
3. Propose an alternative that respects the correction
|
||||
4. If the contradiction is intentional, document why as a new correction
|
||||
|
||||
Detection logic: before each significant action, the agent scans loaded user_correction records from the current recovery context and checks if the proposed action matches any known `original_claim` pattern.
|
||||
Reference in New Issue
Block a user