# Spec Review

## Summary
Reviewed 29 specs. 17 current, 2 partially outdated, 1 outdated (header only), 6 aspirational, 3 partially aspirational.

## Outdated Specs

### specs/codex-provider.md
**Status:** Outdated (header only)
**Issues:**
| Claim | Location in Spec | Actual State |
|-------|-----------------|--------------|
| Header says "Aspirational - not implemented yet" | Top of file | Full 652-line CodexProvider exists at `src/gza/providers/codex.py` with Docker config, pricing, event parsing |

**Action:** Update spec header to mark as "Implemented."

---

### specs/review-improve-loop.md
**Status:** Partially outdated
**Issues:**
| Claim | Location in Spec | Actual State |
|-------|-----------------|--------------|
| `_run_with_auto_review()` function | Loop execution design | Not found in runner.py; uses TaskCycle/TaskCycleIteration pattern instead |

**Correct claims:** `max_review_cycles` config, `task_cycles`/`task_cycle_iterations` tables, `cycle_id`/`cycle_role` fields on Task all exist. Schema is current; execution approach diverged from spec.

---

### specs/shared-task-state.md
**Status:** Partially outdated
**Issues:**
| Claim | Location in Spec | Actual State |
|-------|-----------------|--------------|
| TaskStore Protocol interface for DB abstraction | Architecture section | Only `SqliteTaskStore` exists; no Protocol base class. PostgresTaskStore path not abstracted |

**Correct claims:** Database location, SqliteTaskStore class, `claim_next_pending_task()`, `mark_in_progress`, `complete_task` methods all exist.

## Aspirational Specs (No Action Needed)

| Spec | Summary | Last Modified |
|------|---------|---------------|
| specs/async-human-in-the-loop.md | Question markers, `waiting_input` status, `gza answer` command — none implemented | f723203 |
| specs/beads-integration.md | Correctly marked aspirational; no bead_ids or bridge workflow | 8fd8b11 |
| specs/dspy-integration.md | Marked "Proposed"; no DSPy dependency, modules, or `gza optimize-prompts` command | ff48743 |
| specs/llm-judgment-points.md | `src/gza/llm.py` module not implemented; basic `review_verdict.py` regex exists but not full LLM judgment system | 4f22ca4 |
| specs/tmux-attach.md | No `gza attach`, no `src/gza/tmux_proxy.py`, no tmux infrastructure | 5725327 |
| specs/watch-loop.md | No `gza watch` command; `gza advance` exists but continuous watch wrapping does not | db7400a |

## Partially Aspirational Specs

| Spec | Current Parts | Aspirational Parts |
|------|--------------|-------------------|
| specs/task-workflow-orchestration.md | Phase 2: `gza advance` with `--all`, `--max`, `--dry-run` fully implemented | Phase 1: `gza dashboard`/`gza summary` commands not implemented. Phase 3: `gza changelog` not implemented. Phase 4: `gza ps --detail`, stall detection not implemented. Phase 5: `gza daemon` not implemented |
| specs/rich-console-output.md | `src/gza/console.py` exists with rich integration, shared console instance | Some helper functions described in spec may not all be implemented |
| specs/pypi-publishing.md | PyPI publishing fully set up with hatchling, hatch-vcs, GitHub Actions | Package name is `gza-agent` not `gza` as spec originally suggested |

## Current Specs

| Spec | Key Claims Verified |
|------|-------------------|
| specs/branch-naming-strategies.md | `BranchStrategy` dataclass, pattern variables `{project}/{task_id}/{slug}/{type}`, `task_type_hint` field, presets |
| specs/concurrent-work.md | `gza ps`, `gza stop`, worker registry, background execution, zombie cleanup, `--poll` |
| specs/docker-testing.md | `etc/Dockerfile.test` exists, build/run commands match |
| specs/failure-reason-tracking.md | `failure_reason` field, `KNOWN_FAILURE_REASONS` set, `[GZA_FAILURE:...]` marker regex, `extract_failure_reason()`, migration |
| specs/improve-task-type.md | `improve` task type, `cmd_improve()`, `depends_on`/`based_on`/`same_branch` fields, review context injection |
| specs/learning-accumulation.md | Phases 1-3 complete: `.gza/learnings.md` injection, `--no-learnings`, `gza learnings show/update`, regex extraction, auto-regeneration, `learn` task type |
| specs/max-steps-abstraction-spec.md | `max_steps` config, `max_turns` backward compat, provider step mapping, `num_steps_reported`/`num_steps_computed` columns, `MAX_STEPS` failure reason |
| specs/merge-status-tracking.md | `merge_status` column, valid values, index, migration, `set_merge_status()`, display in `gza unmerged`/`history`/`show` |
| specs/message-step-logging.md | `run_steps`/`run_substeps` tables, all fields, indexes, legacy compatibility fields, dataclasses |
| specs/plan-persistence.md | `output_content` column, `_get_task_output()` helper, cross-worktree access |
| specs/pr-code-review.md | `pr_number` field, migration, `get_pr_number()`/`add_pr_comment()` in GitHub class, auto-posting, `--no-pr`/`--pr` flags |
| specs/rebase-resolve.md | `--resolve` flag, `invoke_provider_resolve()`, `/gza-rebase --auto` invocation, abort on failure |
| specs/replace-sqlite3-with-python-api.md | `get_task()`, `get_task_log_path()`, `get_task_report_path()`, `get_baseline_stats()` functions, skills updated |
| specs/task-chaining.md | `group`, `depends_on`, `create_review`, `same_branch` fields, migration, `gza groups`, dependency-aware `get_next_pending()` with recursive CTE |
| specs/task-import.md | `gza import`, `--dry-run`, `--force`, YAML parsing, validation, dependency resolution |
| specs/task-provider-routing.md | `task_providers` config, resolution precedence, valid task types |
| specs/task-resume.md | `session_id` field, migration, `cmd_resume()`, provider `resume_session_id` parameter, session capture |

## Recommendations
1. **Update codex-provider.md header** — mark as "Implemented" since the full provider exists
2. **Update review-improve-loop.md** — describe the TaskCycle pattern that was actually implemented instead of the `_run_with_auto_review()` approach
3. **Update task-workflow-orchestration.md** — Phase 2 (advance) is implemented; update the spec to reflect what's done vs planned
4. **Update shared-task-state.md** — remove the Protocol abstraction claims or mark them as aspirational, since the concrete SqliteTaskStore approach was chosen
