Serial Studio — /ss-implement (phase 4 of 4)

Execute the approved tasks.md one task at a time, verifying as you go. This is the only phase that writes code. See doc/claude/spec-driven.md.

Preconditions

• doc/claude/specs/NNNN-slug/tasks.md exists and its status: is approved.
• Read spec.md, plan.md, and tasks.md in full before touching code.
• Set spec.md status: in-progress.

Per-task loop

For each task in order:

1. Read before writing. Read the target files in full this session — hotpath files (FrameBuilder, CircularBuffer, FrameReader, Dashboard) and existing signal/slot wiring are mandatory full reads (CLAUDE.md). Invoke ss-hotpath on any hotpath task, ss-cpp-modern when shaping non-trivial new C++.
2. Name the binding invariants before the first Edit: restate in chat, in your own words, the invariant(s) the task's Does line carries (plus any the read surfaced). A constraint steers the edit only when named at the point of action, not when it sits in a doc you read earlier (doc/claude/j-space.md).
3. Make the change with targeted Edit calls — edit, don't rewrite. Follow code-style.md: header ordering, [[nodiscard]], no in-header init, Q_EMIT, no in-body comments, 100-col, ASCII-only in source.
4. Verify the task: python scripts/code-verify.py --check <changed files>. Resolve new errors before moving on (advisories are baseline debt, but new code clears them). Run the task's stated check (a tests/scripts/ JS unit you can run, or a read-back).
5. Mark it done — tick the task's box in tasks.md so the file stays a live record.

Stay strictly inside the plan's file list. If a needed change falls outside it, stop and name it in chat ("the plan didn't cover X — add it?") rather than widening the diff. Never touch, revert, or restore a working-tree file you did not edit this session.

Finish

When every task is done, run the Definition of Done in tasks.md:

1. Static review: invoke qt-cpp-review on the C++ diff; address or note findings.
2. Hotpath: if touched, confirm the --benchmark-hotpath plan with the maintainer (you cannot run it — you don't build the app).
3. Self-review the diff, counterfactually: is this what was asked, and only that? Then answer out loud: "which rule does this diff most risk violating, and what is the concrete evidence it doesn't?" Name the rule and the evidence — not a generic pass (doc/claude/j-space.md, counterfactual self-check). If either answer is weak, say so before claiming completion.
4. Sanitize: run python scripts/sanitize-commit.py (it sanitizes only — never commits).
5. Land the spec first. When the maintainer asks for a commit, spec.md/plan.md/tasks.md go in their own docs(spec): NNNN <slug> commit before any implementation commit. scripts/commit-shape.py, run by the commit hook, refuses a commit that creates a spec alongside code, a security-sensitive surface staged with other paths, more than 60 paths without a Mechanical: trailer, or a fix(ci) without the failing run's URL.
6. Identify the pytest targets from plan.md for the maintainer to run (the app must be up with the API server enabled).
7. Set spec.md status: done.

Rules

• Never build or run the app, and never commit or push without explicit per-turn permission — earlier authorizations do not carry over.
• The spec is the contract: every acceptance criterion must end up satisfied and checked off in spec.md. If reality diverges from the plan mid-build, stop and amend plan.md/tasks.md (re-confirm) rather than silently improvising.
• Keep tasks.md honest as you go — a half-finished feature should be resumable by reading the three spec files alone.