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

PlanGoalPhaseStatus
llm-wiki-revampFull architecture implementation2/4🟒 Active
omp-suite-auditComplete ROUTA diff documentation1/2🟑 Paused
dashboard-fetch-fixResolve Svelte fetch hang bug1/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`

requirements πŸ“ Formal User Stories

Structured user goals and strict ACCEPTANCE CRITERIA for spec-driven TDD.

Format (Gherkin-style)

 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

IDTitleStatusLinked Tasks
REQ-001Architecture documentationβœ… DoneTASK-001..007
REQ-002Identity Anchors implementation🟑 In ProgressTASK-010..016
REQ-003Mutable Memory automation⬜ PlannedTASK-020..025
REQ-004Spec-driven workflow enforcement⬜ PlannedTASK-030..035

tasks βœ… Verifiable Checklist

Highly granular, numbered checklist of actionable technical implementations linked to requirements.

Format

 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

StateIconMeaning
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:

  1. Verification command β€” executable check
  2. Handle β€” verifiable artifact (file, URL, HTTP status, DB row)
  3. 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


Spec-Driven Working Memory is the execution layer β€” it turns architecture into delivered software with proof.