TT Claude Memory

feedback_build_plan_hybrid_shape_a_narrative_plus_native_tasks

Properties1
descriptionBUILD-PLAN.md files retained as strategic prose + Phase/Milestone groupings + cross-references; native Claude Code Tasks (CLAUDE_CODE_TASK_LIST_ID=tt-inherit-v2) hold live execution state. Steps materialise to Tasks just-in-time (when about to be worked) — not all-upfront. Locked 2026-05-24 per Rich-directive.

3 min read

Shape A locked: BUILD-PLAN.md and native Tasks have complementary roles + intentionally minimal duplication.

ArtefactRole
BUILD-PLAN.md per repo + master-planStrategic narrative — ALL planned steps as prose; Phase + Milestone functional groupings; cross-references to arch-state §15 amendments + cascade-Q files + audit-records; per-step description + rationale + exit_criteria
Native Claude Code Tasks (CLAUDE_CODE_TASK_LIST_ID=tt-inherit-v2)Live execution state — only ACTIVE steps materialised (just-in-time); status + addBlockedBy dependency-resolution + multi-session broadcast

Duplication is intentionally limited: step-ID + subject + depends_on in both. Rich description + rationale + cross-references only in BUILD-PLAN.md.

Just-in-time materialisation discipline

WhenAction
Step planned but blocked on multiple future depsStays as BUILD-PLAN.md prose only — NOT in Tasks
Step’s deps are done OR about to be doneTaskCreate with addBlockedBy + metadata.owner
Step completedTaskUpdate status: completed; remains visible via TaskList history; BUILD-PLAN.md prose unchanged

Result: Tasks list stays manageable (10-30 active items); BUILD-PLAN.md files together describe hundreds of planned steps; most live in prose only until ready.

Improvements to apply in Phase B (build-plan migration)

Apply across code-inherit-v2/BUILD-PLAN.md + code-inheritkit/BUILD-PLAN.md + code-ias/BUILD-PLAN.md + code-inheritv2-www/BUILD-PLAN.md + code-inheritv2-test-suite/BUILD-PLAN.md + inherit-v2-phase-1-master-plan.md + sprint-backlog.md (~10-15 LIVE files; ~150-200 forward-looking refs):

  1. Drop forward calendar refs (Sprint N / M7-M8 / Q4 2026) per [[feedback-no-forward-calendar-projection-in-plans-or-conversation]]
  2. Add step-N + depends_on: notation per step within Milestones (preserve M1/M2 functional groupings)
  3. Add top-of-file “Live execution state” pointer referencing native Tasks list tt-inherit-v2; instruct reader to claude + TaskList for current status
  4. Add task_list_id: tt-inherit-v2 frontmatter field (machine-resolvable mapping)
  5. Customer-signal-gated steps flagged explicitly with exit_criteria (prevents Sprint 1 misfire pattern)
  6. Cross-repo dependency notation consistent prefix per repo: v2-step-N, ik-step-N, ias-step-N, test-suite-step-N, www-step-N
  7. Per-step exit_criteria field (industry pattern; matches Tasks metadata; prevents “is this done?” ambiguity)
  8. Markdown checkbox-style for steps - [ ] ik-step-22 — ... (forward-open); - [x] (done); matches markdown-plan convention + AI-spec-templates
  9. Three-document spec/plan/code pointers in §0/§1: spec=arch-state + cascade-Q + critique-ready-spec; plan=this BUILD-PLAN; code=specific src/ paths
  10. Index-into-subfiles pattern if a BUILD-PLAN.md exceeds ~1500-2000 lines (defer until threshold hit; current files below it)

Phase B sequencing (when fresh session authors the launch-prompt)

  1. Phase A (batch-imp-22 v1.2) must land first — native Tasks proven across all three task-lists (tt-inherit-v2 + rich-personal + rich-tt) + three markdown ledgers retired per Rich-locked retirement strategy
  2. Phase B launch-prompt authored as batch-imp-23-build-plan-migration-launch-prompt.md
  3. Initial step-N numbering: each component starts at step-1; assign numbers in source-order from existing BUILD-PLAN.md sections OR by dependency-topological-order (Rich-lock at authoring time)
  4. Decide checkbox-style vs prose-only style at authoring time (lean checkbox: industry convention + visual scannability)
  5. Migration batch: 10-15 LIVE files in ONE atomic docs-strategy commit per per-repo discipline; cross-repo commits may need coordination per worktree-isolation precedent

What stays unchanged (do NOT touch in Phase B)

  • arch-state §15 amendments (strategic-narrative; pre-existing)
  • cascade-Q files
  • audit-records (historical batch closures)
  • pre-commit hooks (frontmatter pin-drift + lock-cascade)
  • per-repo CLAUDE.md (already aligned)
  • §3 Repository topology + §5 Handoffs + §6 Drift-detection in existing BUILD-PLANs (load-bearing; well-designed)

Related: feedback-no-forward-calendar-projection-in-plans-or-conversation (date-rule binding) + feedback-compound-launch-prompts-amplify-context-degradation-risk (Phase B is single-action scope; don’t bundle with Phase A or C/D).

Graph View

Backlinks