task-view — PLAN

task-view — PLAN

Status: DRAFT (ID-20.5, kh-prod-readiness-S60). Authored by a FRESH task-planner instance per Q-PLANNER-2 (NOT the 20.3 PRODUCT or 20.4 TECH Planner). Decomposes the ratified PRODUCT.md (55 invariants) + TECH.md (1297 lines, §1-§7 + parallelization sketch) into eight implementation Subtasks (20.6 through 20.13) plus this PLAN Subtask (20.5). Sibling-only dependency constraint honoured throughout (no cross-Task deps emitted; escalation tripwire was not hit).

Companion specs

• PRODUCT spec (ratified S57): ./PRODUCT.md — 55 numbered Behaviour invariants across 11 subsections (tool identity, ledger detection, three per-mode view spec sets, free-text + structured + array edit affordances, save discipline + concurrency, external regen, invocation + routing, cross-project consistency, edge cases, accessibility).
• TECH spec (ratified S58): ./TECH.md — §0 name resolution (ledger-mirror placeholder → task-view final), Context (Plannotator v0.19.18 inventory + KH patch-surface integration), §1 fork plan + strip ledger, §2 routing + schema detection, §3 mirror generator, §4 viewer rendering, §5 patch server, §6 plugin + CLI dual-invocation, §7 cross-project packaging, Testing-and-validation table (one-to-one invariant-to-test mapping), End-to-end Mermaid flow, Risks, Parallelization, Follow-ups, three Liam-ratified OQs (OQ-T1 distribution / OQ-T2 vendoring trigger / OQ-T3 logging policy).
• Research (background): docs/research/per-task-file-mirror-design.md (ID-20.1) + docs/research/per-task-render-surface.md (ID-20.2).

Decomposition principles applied

1. Vertical slicing. Each Subtask delivers a vertical capability slice that leaves the tool in a working state (or, for early slices, a working stub that subsequent slices can attach to). Horizontal slicing (do all the database, then all the UI) is explicitly avoided.
2. Sibling-only Subtask dependencies (§3.3 / A6 forcing function). Every implementation Subtask depends only on other Subtasks of ID-20. PRODUCT inv 46 explicitly de-couples this Task from ID-22 (ledger relocation), so no cross-Task dep surfaces. ID-19.x (worktree isolation hooks) is referenced in TECH §5.6 but only as a non-coupling note — the hooks are already shipped and require no co-edit from ID-20 Subtasks.
3. ≤2-3h per Subtask. Aligned with the workflow rule “max 2h per Executor dispatch” — most Subtasks sit at ~2h; the larger ones (20.6 fork+strip, 20.9 viewer read-mode) are tight at ~2-3h and could be split further by an Executor mid-flight if scope blows up. Subtask 20.6 in particular is bounded by the strip+rename mechanical nature of the work — not all hours are intellectually deep.
4. Dependency-graph foundations first. Slice 1 (fork prep + vendored schemas) precedes Slice 2 (mirror generator needs schemas); Slice 3 (patch server) needs Slice 2 (apply schema to validate patches); Slice 4 read-mode needs Slice 2 (mirror shape); Slice 4 edit-mode needs Slice 3 (patch endpoint) AND Slice 4 read-mode (DOM hooks); CLI/plugin (Slice 5) needs the full server functional.
5. Parallelization-friendly per TECH §Parallelization. Slices 3 and 4a can run in worktree-isolated parallel after Slices 1+2 merge; Slice 6 (KH-side glue) is independent and can run any time after --check ships.
6. Coverage transitivity, not invariant-per-Subtask 1:1. TECH’s Testing-and-validation table already maps each PRODUCT invariant to a concrete test colocated with the TECH §. Each Subtask below cites the invariant range and TECH § it implements; coverage of all 55 invariants verified by transitive sum.
7. Cross-project repo boundary respected. Subtasks 20.6-20.11 work inside the task-view external repository (a new GitHub repo, separate from knowledge-hub). Only Subtasks 20.12 + 20.13 touch KH directly (KH-side CI glue + KH acceptance verification). PRODUCT inv 1, 3, 45, 46 + TECH §7 enforce this boundary; each Subtask’s details field names which repo it’s working in.

Subtask dependency graph

20.5 PLAN (this Subtask, in_progress at dispatch)
 │
 ├── 20.6 Fork prep + strip + rename + vendor schemas (Slice 1)
 │     ├── §1.1 repo creation
 │     ├── §1.2 strip ledger (14 apps + 7 packages stripped)
 │     ├── §1.3 retained surface
 │     ├── §1.4 rename map
 │     └── §1.5 schema vendoring strategy
 │
 ├── 20.7 Schema detection + path/CWD resolution + mirror generator (Slice 2)
 │     ├── depends on 20.6 (vendored schemas)
 │     ├── §2 routing + detectSchema + record-level path resolution + CWD inference
 │     ├── §3.1 mirror layout, §3.2 record-id filename rule
 │     ├── §3.3 per-mode mirror content shape
 │     ├── §3.4 idempotency + orphan delete
 │     └── (NB: §3.5 schema-drift CI guard is KH-side — implemented in 20.12)
 │
 ├── 20.8 Patch server endpoints + atomic write + mtime + multi-field + loopback (Slice 3)
 │     ├── depends on 20.7 (schema imports, mirror-regen call)
 │     ├── §5.1 endpoint surface
 │     ├── §5.2 patch application algorithm
 │     ├── §5.3 atomic write-to-temp + rename
 │     ├── §5.4 mtime collision detection
 │     ├── §5.5 multi-field save with single-pass regen
 │     ├── §5.6 Tier 2.2 hook interaction (non-coupling note)
 │     ├── §5.7 concurrency / no-locking justification
 │     └── §5.8 loopback-only enforcement
 │
 ├── 20.9 Viewer rendering — read mode (Slice 4a)
 │     ├── depends on 20.6 (stripped UI surface) + 20.7 (mirror shape)
 │     ├── §4.1 shared shell + mode-aware RecordFrontmatterCard READ side
 │     ├── §4.2 per-mode behaviour matrix (read columns)
 │     ├── §4.3 index pages (Task-list / Roadmap / Backlog)
 │     ├── §4.4 in-page anchors for sibling-Subtask deps
 │     ├── §4.5 broken-target marker
 │     └── §4.6 owner inheritance display
 │
 ├── 20.10 Viewer rendering — edit mode (Slice 4b)
 │     ├── depends on 20.8 (patch endpoint must exist) + 20.9 (read-mode DOM)
 │     ├── §4.1 RecordFrontmatterCard EDIT side (dropdowns + text inputs + per-entry forms)
 │     ├── inv 26-29 free-text pencil + textarea + Cmd+Enter/Esc + structured patch wire
 │     ├── inv 30-33 enum dropdowns (Zod-sourced; nullable "(unset)"; no state-machine)
 │     ├── inv 34-35 array editors (comma-separated + per-entry DocLink form)
 │     └── inv 51 localStorage draft preservation
 │
 ├── 20.11 CLI binary + plugin manifest + browser-close + port retry + --check flag (Slice 5)
 │     ├── depends on 20.10 (full viewer functional)
 │     ├── §6.1 CLI binary (bin/task-view.js)
 │     ├── §6.2 plugin manifest (.claude-plugin/plugin.json)
 │     ├── §6.3 shared-server rationale
 │     ├── §6.4 --check flag for CI usage
 │     ├── §6.5 browser-close detection (30s idle + at-least-one-request)
 │     ├── §6.6 port retry policy (5 retries)
 │     └── §6.7 $PATH install convention
 │
 ├── 20.12 KH-side CI glue + initial mirror commit (Slice 6, lives in knowledge-hub)
 │     ├── depends on 20.11 (--check flag must exist + task-view installable)
 │     ├── §3.5 task-view-vendor-drift.yml workflow (warn-only)
 │     ├── §6.4 --check job wired into .github/workflows/ci.yml
 │     ├── PRODUCT inv 5 + 40: initial mirror generation committed (docs/reference/tasks/*.md, roadmap/*.md, backlog/*.md)
 │     └── CLAUDE.md Commands table entry for /task-view invocation (optional documentation)
 │
 └── 20.13 KH acceptance verification + tool v0.1.0 GitHub Release tarball (final acceptance)
       ├── depends on 20.11 (tool functional) + 20.12 (KH glue in place)
       ├── End-to-end Mermaid flow happy path verified against KH's 3 ledgers
       ├── All 55 PRODUCT invariants spot-checked via tool repo's tests/ + KH-side manual
       ├── v0.1.0-task-view tag pushed to GitHub Release (OQ-T1 default)
       └── ID-20 promoted to done by Orchestrator post-Checker

Phase / checkpoint plan

Phase 1 — Foundation (must land before any UI work)

• 20.6 Fork prep + strip + rename + vendor schemas
• 20.7 Schema detection + path resolution + mirror generator

Checkpoint after 20.6 + 20.7:

• task-view repo exists on GitHub, locally renamed from plannotator.
• Strip ledger applied (14 apps + 7 packages deleted; UI primitives kept).
• Vendored schemas (4 files) parse representative ledger JSON.
• detectSchema routes all 3 known document_name values + rejects unknown.
• Mirror generator produces byte-identical output across runs; orphan-delete verified.
• Pure-logic test suite passes (bun test in the tool repo).

Phase 2 — Backend + read mode (parallelizable per TECH §Parallelization)

• 20.8 Patch server (depends on 20.7)
• 20.9 Viewer read mode (depends on 20.6 + 20.7)

These two can land in parallel worktrees per TECH guidance — Slice 3 + Slice 4a are decoupled until edit-mode (20.10) wires them together.

Checkpoint after 20.8 + 20.9:

• Server boots on 127.0.0.1 + serves GET /api/ledger + handles PATCH endpoints (no UI integration yet — verify via curl).
• Viewer renders all three modes in read-only form against KH’s ledgers (manual smoke test using the locally-running server).
• Index pages render for all three modes; broken-target markers display correctly; owner inheritance qualifier appears.

Phase 3 — Edit mode + invocation glue

• 20.10 Viewer edit mode (depends on 20.8 + 20.9)
• 20.11 CLI + plugin packaging (depends on 20.10)

Checkpoint after 20.10 + 20.11:

• Click pencil → textarea → edit → Save → JSON file updated atomically → mirror regenerated → UI re-renders.
• task-view docs/reference/task-list.json and /task-view docs/reference/task-list.json both launch the same server.
• --no-browser, --port, --check flags behave per inv 42.

Phase 4 — KH integration + acceptance

• 20.12 KH-side CI glue + initial mirror commit
• 20.13 KH acceptance verification + v0.1.0 release

Final checkpoint:

• .github/workflows/ci.yml runs task-view --check against all three ledgers; passes.
• .github/workflows/task-view-vendor-drift.yml warns on schema drift (does not block per OQ-T2 ratification).
• All 55 PRODUCT invariants verified (transitively via tool repo’s tests + KH-side manual smoke).
• v0.1.0-task-view tag pushed to GitHub Release.

Sibling-only dependency verification

Every dependency emitted by the Subtasks below points to another Subtask of ID-20:

Subtask	Depends on	All deps are siblings of ID-20?
20.6	(none)	✓ no deps
20.7	20.6	✓
20.8	20.7	✓
20.9	20.6, 20.7	✓
20.10	20.8, 20.9	✓
20.11	20.10	✓
20.12	20.11	✓
20.13	20.11, 20.12	✓

No cross-Task dependencies surfaced. The forcing-function escalation tripwire (Q-PLANNER-2 / A6) was not hit. ID-22 (ledger relocation) is explicitly de-coupled per PRODUCT inv 46. ID-19.x (worktree-isolation hooks) is non-coupling per TECH §5.6. ID-15.x (legacy ID migration) is independent — task-view consumes the current ledger schemas; if ID-15.7+ introduces schema changes mid-flight, the vendor-drift CI guard (per OQ-T2) catches it post-hoc rather than gating Subtask dispatch.

25-Subtask ceiling status

Total Subtasks in ID-20 after this PLAN lands: 13 (20.1 through 20.13). Well within the 25 soft ceiling. Task boundary remains correct.

New OQs surfaced during decomposition

Zero new OQs. PRODUCT (3 OQs, all ratified at S57) and TECH (3 OQs, all ratified at S58 close per Liam) together define every implementation decision needed for the 8 Subtasks below. Where any Subtask’s details field reaches into a decision space, the relevant ratified OQ is cited inline (e.g. 20.6 cites OQ-T1 GitHub Release tarball; 20.7 cites OQ-C record-id filename rule).

Per the workflow ≤3 ceiling: 0 of 3 used.

Test philosophy alignment

All Subtask testStrategy lines reference docs/reference/test-philosophy.md discipline transitively: tests verify real behaviour (rendered DOM, atomic file writes, schema parse results) not mock-internal state. Per TECH’s Testing-and-validation table, every test is colocated with the TECH § proposing the change. The implementation Subtasks below adopt the TECH test layout directly — no separate “test scaffolding” Subtask is needed.

Coverage verification — all 55 PRODUCT invariants mapped transitively

Invariant range	Implemented in Subtask	TECH §
inv 1-3	20.6	§1.1, §1.4, §1.5
inv 4-6	20.7	§2.1, §2.2, §2.3
inv 7-13	20.9 + 20.7 (mirror)	§3.3 + §4.1, §4.4, §4.5
inv 14-19	20.9 + 20.7 (mirror)	§3.3 + §4.3, §4.6
inv 20-25	20.9 + 20.7 (mirror)	§3.3 + §4.1, §4.3
inv 26-29	20.10	§4.1 RecordFrontmatterCard, §5.1, §5.2
inv 30-33	20.10	§4.1 dropdowns
inv 34-35	20.10	§4.1 RecordFrontmatterCard array fields
inv 36-38	20.8	§5.3, §5.4, §5.5
inv 39-40	20.7 (regen) + 20.12	§3.4 + §3.5
inv 41-44	20.11	§6.1, §6.2, §6.5, §5.8
inv 45-46	20.13 (verification)	§7.1, §7.3
inv 47-52	20.9 + 20.11	§4.3, §6.5, §6.6 + §1.3 cross-platform
inv 53-55	20.9 + 20.10	§1.3 retained KeyboardShortcuts

55/55 invariants covered transitively. The Testing-and-validation table in TECH carries the precise file:line test locations per invariant — each Executor consumes that table as their per-invariant acceptance reference.

Subtask records (TM-shape, ready for task-list.json append)

The eight records below are the implementation Subtasks 20.6-20.13. Records appended verbatim into docs/reference/task-list.json under ID-20’s subtasks array. See /Users/liamj/Documents/development/knowledge-hub/.claude/worktrees/agent-aa1cddc8523b43e14/docs/reference/task-list.json for the final landed state.

20.6 — Fork prep + strip + rename + vendor schemas (Slice 1, tool repo)

• Repo: NEW task-view GitHub repository (separate from knowledge-hub).
• Implements: TECH §1.1 (repo creation) + §1.2 (strip ledger: 14 apps + 7 packages deleted) + §1.3 (retained surface) + §1.4 (rename map) + §1.5 (vendoring strategy).
• PRODUCT invariants covered: 1 (fork identity + permanent divergence), 3 (zero KH runtime deps; schemas vendored).
• Dependencies: none (foundation slice).
• Effort estimate: ~2-3h (largely mechanical strip + rename, no novel logic).
• Acceptance: new GitHub repo exists with no upstream remote; dual MIT-OR-Apache-2.0 LICENSE retained; strip ledger applied per TECH §1.2 enumerated apps + packages; rename map per §1.4 applied via sweep; vendored schemas in packages/schemas/src/ parse a representative KH ledger JSON without lib/validation/ imports; first commit chain (clone, rename, strip, vendor, wire) lands per §1.1 step list.

20.7 — Schema detection + path resolution + mirror generator (Slice 2, tool repo)

• Repo: task-view.
• Implements: TECH §2.1 (detectSchema function with three-way discrimination) + §2.2 (record-level path resolution: .md filename → parent ledger walk) + §2.3 (CWD inference scan) + §3.1 (mirror dir layout) + §3.2 (record-id filename rule per OQ-C raw id, unsafe-char → -) + §3.3 (per-mode mirror content shape: Task-list / Roadmap / Backlog YAML frontmatter + markdown body) + §3.4 (idempotency + orphan deletion via atomic write-to-temp + rename).
• PRODUCT invariants covered: 4 (document_name routing; Backlog non-literal handled by value match), 5 (mirror sibling dir + idempotent + orphan delete), 6 (record-level path → parent ledger preselect), 39-40 (regen on each launch; tolerant of mirror absence).
• Dependencies: 20.6 (vendored schemas needed for parse + dropdown sourcing).
• Effort estimate: ~2h.
• Acceptance: detectSchema unit tests cover all 3 known values + unknown rejection; mirror generator produces byte-identical output across runs (snapshot test); orphan deletion verified by removing a Task and re-running; record-level path resolution opens parent ledger + preselects named record via ?record= URL fragment per TECH §2.2.

20.8 — Patch server endpoints + atomic write + mtime + multi-field + loopback (Slice 3, tool repo)

• Repo: task-view.
• Implements: TECH §5.1 (endpoint surface: GET /api/ledger, GET /api/ledger/record/:recordId, PATCH /api/ledger/record/:recordId, POST /api/ledger/regen) + §5.2 (patch application algorithm: walk fieldPath, replace, parse via Zod, return) + §5.3 (atomic write-to-temp + POSIX rename) + §5.4 (mtime collision detection before patch; 409 Conflict on stale base) + §5.5 (multi-field save: single PATCH with multiple FieldPatch entries, single validation pass, mirror regen once) + §5.6 (Tier 2.2 hook non-coupling note — patch server writes via Bun.write + fs.rename, NOT Claude Write tool) + §5.7 (no file locking; cross-tab race covered by mtime check) + §5.8 (loopback-only hostname: '127.0.0.1' bind).
• PRODUCT invariants covered: 36 (atomic write), 37 (mtime collision + reload + localStorage hint), 38 (multi-field save + mirror regen once), 44 (loopback-only).
• Dependencies: 20.7 (schema imports for schema.parse(snapshot); mirror-regen call after successful patch).
• Effort estimate: ~2h.
• Acceptance: tests/unit/atomic-write.test.ts simulates mid-write crash + asserts canonical file integrity; tests/integration/mtime-collision.test.ts modifies file out-of-band + asserts 409 + reload-button hint; tests/integration/multi-field-save.test.ts submits multiple FieldPatch in one request + asserts single regen; tests/unit/loopback-bind.test.ts asserts bind to 127.0.0.1 (remote bind fails).

20.9 — Viewer rendering, read mode (Slice 4a, tool repo)

• Repo: task-view.
• Implements: TECH §4.1 (shared shell + mode-aware RecordFrontmatterCard READ side: read-only display per mode) + §4.2 per-mode behaviour matrix (read columns) + §4.3 (index pages: Task-list tasks/index.md, Roadmap section index, Backlog filterable index with URL query string) + §4.4 (in-page anchors for sibling-Subtask deps via slugify.ts) + §4.5 (broken-target marker — CSS strikethrough + “(missing)” suffix + page-top warning) + §4.6 (owner inheritance qualifier “(inherited from §{sectionId})” for Roadmap items where owner === null).
• PRODUCT invariants covered: 7-13 (Task-list mode view: frontmatter + Subtask blocks + cross-doc links + dependency links + sibling-Subtask in-page anchors), 14-19 (Roadmap mode: section index + per-item pages + owner inheritance + forward_looking_only honoured), 20-25 (Backlog mode: index + filters + per-item + dependency links + promotion-ready badge + blocked banner), 47 (empty ledger empty-state page), 48 (schema fail-on-load: ZodError + exit non-zero), 52 (cross-platform path separators).
• Dependencies: 20.6 (stripped UI surface available), 20.7 (mirror shape produced — viewer consumes it).
• Effort estimate: ~2-3h (largest UI Subtask; could be split into Task-list / Roadmap / Backlog sub-slices by Executor if mid-flight scope blows up, but the shared shell makes that artificial).
• Acceptance: all tests/integration/*-render.test.ts per TECH Testing-and-validation table inv 7-25 pass; Task with subtasks: [] renders _No subtasks._; Roadmap section with no items renders _No items in this section._; broken dependency renders strikethrough + page-top warning; Backlog filter dropdowns set URL query string state; promotion-ready badge appears when details or testStrategy present.

20.10 — Viewer rendering, edit mode (Slice 4b, tool repo)

• Repo: task-view.
• Implements: TECH §4.1 RecordFrontmatterCard EDIT side (dropdowns sourced from Zod ._def.values; text inputs for free fields; per-entry forms for cross_doc_links[]) + free-text pencil affordance + autosized textarea + Cmd/Ctrl+Enter (Save) + Esc (Cancel) wiring + structured patch wire format (per TECH §5.1 FieldPatch[]) + inline schema-validation error display + array-edit (comma-separated parse + trim + reject malformed) + DocLink per-entry form (Add link / delete row) + browser localStorage draft preservation per inv 51 keyed by {ledgerPath, recordId, fieldPath}.
• PRODUCT invariants covered: 26-29 (free-text edit: pencil + textarea + Cmd+Enter/Esc + structured patch wire + inline error + textarea preserved on failure), 30-33 (Zod-enum dropdowns: all valid values; nullable “(unset)”; no state-machine enforcement; same save discipline as free-text), 34-35 (array edit: comma-separated cross-ref arrays + DocLink per-entry form), 51 (localStorage drafts on failed save), 53-55 (keyboard nav inherited from Plannotator; text-only dropdowns; UK English in UI).
• Dependencies: 20.8 (PATCH endpoint must exist to receive structured patches), 20.9 (read-mode DOM provides the rendered fields the pencil affordance attaches to).
• Effort estimate: ~2h.
• Acceptance: tests/integration/edit-affordances.test.ts (pencil click → textarea), tests/integration/textarea-controls.test.ts (Cmd+Enter / Esc), tests/integration/details-edit.test.ts (Subtask.details textarea preserves journal blocks verbatim), tests/integration/save-error.test.ts (invalid value → ZodError inline, textarea preserved), tests/integration/enum-dropdown.test.ts (all Zod values present; “(unset)” for nullable), tests/integration/no-transition-enforcement.test.ts (pending → done direct flip succeeds), tests/integration/array-edit.test.ts (Subtask cross-Task dep rejected per superRefine), tests/integration/cross-doc-links-edit.test.ts (DocLink form add/edit/delete), tests/integration/localstorage-drafts.test.ts (failed save preserves textarea content).

20.11 — CLI + plugin packaging + browser-close + port retry + —check flag (Slice 5, tool repo)

• Repo: task-view.
• Implements: TECH §6.1 (CLI binary bin/task-view.js with parseArgs + positional path + flags: --no-browser / --port <N> / --check) + §6.2 (plugin manifest .claude-plugin/plugin.json with /task-view slash command) + §6.3 (shared-server rationale; plugin manifest invokes CLI binary) + §6.4 (--check runs one-shot mirror-regen + exit non-zero on drift; for CI use) + §6.5 (browser-close detection: 30s idle + at-least-one-request gate → process.exit(0)) + §6.6 (port retry policy: MAX_RETRIES = 5 from upstream, unchanged) + §6.7 ($PATH install convention: bunx, bun install -g, Claude plugin marketplace).
• PRODUCT invariants covered: 41 (plugin slash command launches + opens browser + prints readiness; waits for close), 42 (CLI binary identical + --no-browser / --port / --check flags), 43 (no-path invocation scans CWD; numbered list / friendly miss), 49 (port retry 5x then “could not bind”), 50 (browser-close detection 30s idle).
• Dependencies: 20.10 (full viewer functional — CLI/plugin launches the same server).
• Effort estimate: ~1-2h.
• Acceptance: tests/integration/dual-entry.test.ts (CLI + plugin invocation both serve identical routes), tests/integration/cli-flags.test.ts (each flag behaves), tests/integration/cwd-scan.test.ts (zero / one / multiple document_name JSON files in CWD), tests/integration/port-retry.test.ts (occupy port + assert retry), tests/integration/browser-close.test.ts (no requests for 30s after first request + at-least-one-request → exits 0).

20.12 — KH-side CI glue + initial mirror commit (Slice 6, lives in knowledge-hub repo)

• Repo: knowledge-hub (this repository — production-readiness branch).
• Implements: TECH §3.5 (KH CI workflow .github/workflows/task-view-vendor-drift.yml — warn-only on drift per OQ-T2 ratification; fetches tagged task-view release vendor bundle + diffs against lib/validation/{task-list-schema,roadmap-schema,backlog-schema,work-status}.ts) + §6.4 KH-side (wire task-view --check docs/reference/task-list.json + sibling 2 ledger paths into .github/workflows/ci.yml as a new step or job) + PRODUCT inv 5 + 40 (commit initial mirror set to docs/reference/tasks/*.md, docs/reference/roadmap/*.md, docs/reference/backlog/*.md) + optional CLAUDE.md Commands table entry documenting /task-view invocation pattern.
• PRODUCT invariants covered: 5 (initial mirrors committed alongside canonical JSON), 39 (external regen via KH CI guard), 40 (viewer tolerates mirror absence — this slice provides the initial baseline so subsequent runs are no-ops).
• Dependencies: 20.11 (--check flag must exist; task-view installable via bunx task-view per OQ-T1 GitHub Release tarball default).
• Effort estimate: ~1h.
• Acceptance: .github/workflows/task-view-vendor-drift.yml exists + warns (does NOT block) on diff per OQ-T2; task-view --check step in ci.yml runs against all 3 ledgers + passes; initial mirror set committed (~13 Tasks worth of tasks/ID-N.md + Roadmap sections + Backlog items); CLAUDE.md Commands table entry added if Liam wants (documentation polish, optional).

20.13 — KH acceptance verification + tool v0.1.0 GitHub Release tarball

• Repo: Both task-view (release tag) + knowledge-hub (smoke harness).
• Implements: End-to-end Mermaid flow happy-path verification (TECH § End-to-end flow: Liam → CC → CLI → Server → FS → Browser, open + edit + save + close) + spot-check of all 55 PRODUCT invariants via task-view repo’s tests/ (already authored as part of 20.6-20.11) + KH-side manual smoke + v0.1.0-task-view GitHub Release tarball published per OQ-T1.
• PRODUCT invariants covered: 45 (same binary against any project’s conformant ledgers — verified by running task-view against KH’s 3 ledgers without modification), 46 (ID-22 ledger-relocation requires no viewer change — verified by symlink test or by re-running after ID-22 dispatches), plus transitive sanity check of all prior invariant coverage.
• Dependencies: 20.11 (tool functional), 20.12 (KH glue in place).
• Effort estimate: ~1h (verification, not implementation).
• Acceptance: Mermaid flow happy path manually verified by Liam against docs/reference/task-list.json; v0.1.0-task-view tag pushed to GitHub Release with tarball + install instructions in release notes; final ID-20 promotion to done by Orchestrator post-Checker pass; status_note populated with shipped summary.

Risks specific to this PLAN’s decomposition

Risk	Mitigation
20.6 strip ledger underestimates Plannotator coupling (some module hard to remove)	Strip is incremental; if a “delete” target turns out to be load-bearing for kept modules, Executor escalates mid-flight and the orchestrator may split the Subtask. ~2-3h estimate has buffer for this discovery.
20.9 viewer scope expands beyond one Subtask	Pre-identified split point: Task-list / Roadmap / Backlog modes could be three sub-slices if scope blows up. Shared shell makes this less natural but viable.
20.10 edit mode requires deeper Plannotator pattern refactoring than expected	AnnotationCard.isEditing pattern (TECH §1.3 line 88) is the inspiration; if it turns out to require parallel reuse rather than fresh implementation, 20.10 absorbs the cost — no separate Subtask.
20.12 KH CI integration trips Tier 2.2 hook	TECH §5.6 confirms patch-server I/O is NOT Claude-tool-mediated, so the hook doesn’t fire. CI workflows run in GitHub Actions, not Claude Code, so the hook is irrelevant for CI step.
20.13 acceptance reveals mirror-shape gap not caught in unit tests	Recovery: extra mirror-shape Subtask added (would be 20.14) or 20.7 re-opened. Mermaid-flow happy-path is the canonical acceptance contract.

Notes for Orchestrator dispatch

• Worktree-parallelizable pairs (per TECH §Parallelization):
  • 20.8 + 20.9 (Patch server + Viewer read mode) — parallel-safe after 20.7 lands.
  • 20.12 can run any time after 20.11 — no blocker on 20.13 sequencing.
• Repo isolation discipline: Subtasks 20.6-20.11 + 20.13 (tag push) work in the EXTERNAL task-view repo. Their Executor dispatches use that repo’s worktree, NOT KH’s. Subtasks 20.12 + 20.13 (KH-side smoke) work in KH’s production-readiness branch worktree. Briefs must explicitly name the repo boundary.
• Sub-agent worktree heritage gotcha (per CLAUDE.md ID-19.4): When dispatching 20.12 to a sub-agent worktree, verify the Tier 2.2 hook propagated to main repo settings BEFORE dispatch (per CLAUDE.md “Hook propagation discipline” gotcha). The new GitHub repo for task-view has no Tier 2.2 hook — that’s fine since task-view writes its own files, not KH’s. KH’s hook protects KH paths only.
• OQ-T1 GitHub Release default: 20.13’s release tarball is the canonical install path for v0.1.0. The bunx task-view shortcut works against the tagged release URL. npm + Claude plugin marketplace are deferred to FU-2.
• Stop-hook regen wiring deferred: PRODUCT inv 39 mentions “Stop hook on JSON edit + CI guard” as the external regen mechanism. CI guard ships in 20.12. The Stop-hook side is NOT in this decomposition — it’s a per-project add-on, can ship as a separate follow-up Task (or as part of 20.12 if Liam wants) since it’s strictly nice-to-have (CI catches drift; Stop hook is an “edit experience” upgrade).