Rendered from the repository — the file stays the source of truth.
Session C7 — Scope implementation status (2026-08-18)
Goal
product/scope.md becomes telling at a glance (roadmap C7): every CF-nn and
SF-nn item carries a dated implementation-status badge for the current
deployed version, plus a summary table near the top — without altering a
word of the adopted scope text. Precondition B3 (#36) merged was verified
before starting (the session initially stopped because #36 was still open;
it proceeded after the merge landed at 14:03 UTC).
What was done
- Summary table (
product/scope.md, inserted directly after the provenance blockquote): all 22 CF + 14 SF items, one row each — ID, name, status icon, evidence (PR links, or “cut list”/“phase n” where nothing shipped) — dated 2026-08-18, with the rule stated above it: the scope text below is the adopted target; the annotations track shipped reality through B3 (#36). - Per-item badges: one blockquote directly under each CF/SF heading, vocabulary exactly four: ✅ In current version · 🔶 Partial (one clause on exists vs missing) · ⏳ Planned (phase n) · ❌ Cut for v1. Statuses were sourced from the merged PRs’ scope and E2E evidence (#6, #10, #15, #24, #27, #29, #36), not from code reading.
- Non-functional note (before §7): a single blockquote saying NF
sections are not badge-tracked per item and pointing to the living NF
record — the security register (
product/security.md, repo-only), feasibility (D-1…D-10), and the architecture views. - Insert-only mechanics: the annotations were generated by a script
that only inserts lines;
git diffconfirms 125 insertions, 0 deletions — the adopted text is byte-identical.
Status summary
✅ CF-01, CF-03, CF-05, CF-06, CF-07, SF-02 · 🔶 CF-02, CF-04, CF-08, CF-10, CF-12, SF-01, SF-08, SF-09, SF-10, SF-11 · ⏳ CF-16, CF-17, CF-18, CF-21, CF-22, SF-03, SF-14 · ❌ CF-09, CF-11, CF-13, CF-14, CF-15, CF-19, CF-20, SF-04, SF-05, SF-06, SF-07, SF-12, SF-13.
Judgment calls (also in the PR description)
- CF-03 ✅ not 🔶: “reprocessing after source changes” is moot in v1 — sources are immutable (no linked external sources; SF-04 cut), and “image association where applicable” has no applicable shipped source class. The shipped pipeline (#15) plus hybrid retrieval (#24) covers the rest of the list.
- CF-04 🔶: viewer + removal + cited-passage navigation shipped (#15/#29), but no auto-generated source summary (Source Guide) and the viewer is dialog-only — enough missing to withhold ✅.
- CF-09 ❌: not literally on the roadmap cut list, but nothing shipped and nothing scheduled; ❌ (“no chat configuration shipped”) describes reality better than ⏳ with an invented phase.
- SF-06/SF-12 ❌: SF-06 falls under the sharing & collaboration cut; SF-12 is conditional on commercialisation, which is out of v1 scope. SF-07 ❌ cites scope §9 (out-of-scope candidates) rather than the cut list.
- SF-10 🔶 not ❌: “multi-language output” is on the cut list, but D2 (#27) did ship a selectable output language for Audio Overview (de/en) — a flat ❌ would contradict the shipped product.
- SF-14 ⏳ with “no phase assigned yet”: not shipped, not cut, and not in any §8 phase — named as such instead of inventing a phase number.
- Link forms: PR links are absolute GitHub URLs (work on GitHub and the
docs site alike); doc cross-references use repo-relative links that the
docs app’s canonical-links plugin rewrites (
roadmap.md→/roadmap/,feasibility.md→/decisions/,architecture/index.md→/architecture/);product/security.mdis named but deliberately not linked — it has no docs route.
Verification
git diffonproduct/scope.md: insertions only (125+, 0−).apps/docs: zero source changes;bun run buildpasses (40 pages).- Rendered
/product/scope/checked in the built output: all 36 badges present, blockquotes render as styled callouts under their headings, the summary table renders with working PR links, and the three rewritten doc links point at their site routes (screenshot-verified via headless Chromium against the builtdist/).
Open points
- The annotations are a dated snapshot. When later sessions ship or cut items, the badges and table must be updated in the same change (correct-the-record convention) — otherwise this page becomes exactly the stale claim it exists to prevent.
- If per-NF tracking is ever wanted, the security register model (one row per finding, dated updates) is the better home than badges here.