Spec-Driven Working Memory
Spec-Driven Working Memory
Active execution layer: goal tracking, scope definition, architecture strategy, formal requirements, and verifiable checklists.
PLAN πΊοΈ Execution Roadmap
Active goal tracking, high-level task roadmaps, and sub-step checkpoints.
Structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| # Active Plan: <plan-name>
**Goal**: <one-sentence objective>
**Status**: π’ Active / π‘ Paused / π΄ Blocked / β
Complete
**Created**: YYYY-MM-DD
**Target**: YYYY-MM-DD
**Owner**: hermes-agent / subagent-<id>
## Roadmap
| Phase | Checkpoint | Status | Target | Notes |
|-------|------------|--------|--------|-------|
| 1 | <milestone> | β
/π‘/β¬ | YYYY-MM-DD | |
| 2 | <milestone> | β¬ | YYYY-MM-DD | |
## Sub-Steps (Current Phase)
- [ ] <atomic step 1>
- [ ] <atomic step 2>
- [ ] <atomic step 3>
## Blockers
- <blocker description> β <mitigation>
## Decisions Log
| Date | Decision | Rationale |
|------|----------|-----------|
| YYYY-MM-DD | <choice> | <why> |
|
Current Active Plans
| Plan | Goal | Phase | Status |
|---|
llm-wiki-revamp | Full architecture implementation | 2/4 | π’ Active |
omp-suite-audit | Complete ROUTA diff documentation | 1/2 | π‘ Paused |
dashboard-fetch-fix | Resolve Svelte fetch hang bug | 1/1 | β
Complete |
Plan Lifecycle
1
2
3
4
5
6
7
| stateDiagram-v2
[*] --> Draft: Create PROJECT_BRIEF
Draft --> Active: DEVELOPMENT_PLAN approved
Active --> Paused: Blocker / priority shift
Paused --> Active: Blocker resolved
Active --> Complete: All requirements β
Complete --> Archived: Move to SESSION_LOG
|
PROJECT_BRIEF π― Scope Definition
Top-level product spec and requirements synthesized during brainstorming.
Template
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| # Project Brief: <name>
## Vision
<One paragraph: what this becomes when done>
## Success Criteria
- [ ] <measurable outcome 1>
- [ ] <measurable outcome 2>
- [ ] <measurable outcome 3>
## Scope
### In Scope
- <feature 1>
- <feature 2>
### Out of Scope
- <explicit exclusion 1>
- <explicit exclusion 2>
## Constraints
| Constraint | Detail |
|------------|--------|
| Technical | <stack, platform, performance> |
| Timeline | <deadline or cadence> |
| Resources | <compute, budget, human> |
| Compliance | <privacy, security, legal> |
## Stakeholders
| Role | Name | Input Required |
|------|------|----------------|
| Owner | @ππ | Final approval |
| Operator | hermes-agent | Execution |
| Reviewer | <subagent> | Verification |
## Risks
| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| <risk> | High/Med/Low | High/Med/Low | <action> |
|
DEVELOPMENT_PLAN ποΈ Architecture Strategy
Implementation priorities, risks, and phase grouping generated from the brief.
Structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| # Development Plan: <project-name>
## Phases
### Phase 1: Foundation (Week 1-2)
**Priority**: Critical
**Risk**: Low
**Deliverables**:
- [ ] <core component 1>
- [ ] <core component 2>
### Phase 2: Core Features (Week 3-4)
**Priority**: High
**Risk**: Medium
**Deliverables**:
- [ ] <feature 1>
- [ ] <feature 2>
### Phase 3: Polish & Deploy (Week 5)
**Priority**: Medium
**Risk**: Low
**Deliverables**:
- [ ] <integration>
- [ ] <documentation>
- [ ] <deploy>
## Architecture Decisions
| Decision | Options Considered | Chosen | Rationale |
|----------|-------------------|--------|-----------|
| <topic> | A, B, C | B | <why> |
## Technical Debt Budget
- **Allocated**: 20% of phase time
- **Tracking**: FEEDBACK-LOG entries tagged `tech-debt`
|
Structured user goals and strict ACCEPTANCE CRITERIA for spec-driven TDD.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| # REQ-<id>: <title>
**As a** <role>
**I want** <capability>
**So that** <benefit>
## Acceptance Criteria
### Scenario: <happy path>
Given <precondition>
When <action>
Then <observable outcome>
And <another outcome>
### Scenario: <edge case>
Given <precondition>
When <action>
Then <error handling>
|
Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| # REQ-001: LLM Wiki Architecture Pages
**As a** system architect
**I want** comprehensive architecture documentation in the wiki
**So that** the system is self-describing and onboards new agents
## Acceptance Criteria
### Scenario: All 7 layers documented
Given the wiki is deployed
When I navigate to /architecture/
Then I see all 7 layer pages
And each page has cross-references
And navigation works
### Scenario: Live site reflects changes
Given I edit a content file
When deploy runs
Then https://llm-wiki.0rk.de/architecture/ shows updates
|
Requirements Registry
| ID | Title | Status | Linked Tasks |
|---|
| REQ-001 | Architecture documentation | β
Done | TASK-001..007 |
| REQ-002 | Identity Anchors implementation | π‘ In Progress | TASK-010..016 |
| REQ-003 | Mutable Memory automation | β¬ Planned | TASK-020..025 |
| REQ-004 | Spec-driven workflow enforcement | β¬ Planned | TASK-030..035 |
tasks β
Verifiable Checklist
Highly granular, numbered checklist of actionable technical implementations linked to requirements.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| # Tasks: <project-name>
## TASK-001: Create architecture/_index.md
**Requirement**: REQ-001
**Status**: β
Complete
**Verification**: `ls content/architecture/_index.md`
**Handle**: File created at content/architecture/_index.md
## TASK-002: Create identity-anchors section
**Requirement**: REQ-001
**Status**: π‘ In Progress
**Verification**: `ls content/architecture/identity-anchors/`
**Handle**: Dir exists with 7 component pages
## TASK-003: Update config.toml menu
**Requirement**: REQ-001
**Status**: β¬ Pending
**Verification**: `grep -A20 "menu.main" config.toml | grep Architecture`
**Handle**: Menu entry added
|
Task States
| State | Icon | Meaning |
|---|
| Pending | β¬ | Not started |
| In Progress | π‘ | Actively working (ONE at a time) |
| Complete | β
| Done + verified |
| Cancelled | β | Abandoned, reason logged |
| Blocked | π΄ | Waiting on dependency |
Verification Protocol
Every task MUST have:
- Verification command β executable check
- Handle β verifiable artifact (file, URL, HTTP status, DB row)
- Requirement link β traceability to REQ-XXX
1
2
3
4
5
6
7
8
9
10
11
12
13
| def verify_task(task):
# Run verification command
result = subprocess.run(task.verification, shell=True, capture_output=True)
assert result.returncode == 0, f"Verification failed: {result.stderr}"
# Verify handle exists
if task.handle.startswith("File:"):
assert os.path.exists(task.handle[5:]), "File handle missing"
elif task.handle.startswith("URL:"):
assert requests.get(task.handle[4:]).status_code == 200, "URL handle dead"
elif task.handle.startswith("HTTP:"):
# Already verified above
pass
|
Cross-References
- Identity Anchors β SOUL constrains PROJECT_BRIEF scope
- Orchestration β guidelines govern task updates
- Autonomic β HEARTBEAT audits task completion
- Swarm Alignment β THESIS aligns PROJECT_BRIEF
Spec-Driven Working Memory is the execution layer β it turns architecture into delivered software with proof.