Refine task-phase tracking and phase explanations.

Strengthen current-phase-first task-list behavior across tracking and phase startup rules, improve phase/progress explanations so they are easier to picture and shorter to read, and add a standalone high-signal communication experiment without merging it into the active owner graph.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: DarKWinGTM

README.md

@@ -182,7 +182,7 @@ for f in $RULE_FILES; do cp "$f" ~/.claude/rules/; done
 | Rule | Purpose | Key Benefit |
 |:-----|:--------|:------------|
 | [`accurate-communication.md`](accurate-communication.md) | Clear, honest communication | No vague claims, no over-strong contradiction wording, reusable partial-evidence technical snapshot wording, stronger human-language glosses, clearer explanation of variables/fields/config keys/internal labels when answers depend on them, goal-qualified proposal wording for advisory future-work ideas, honest duplicate-looking team-agent reporting, governing-basis clarification before deep branch analysis, compact post-compact re-anchor wording, explicit memory-derived-context disclosure wording for path-matched remembered context, natural-professional wording, direct human-readable action/result wording preferred over metaphor-heavy internal shorthand, main-point-first framing for diagnosis/test/recommendation/proposal/update answers, continuation-first guidance, clearer recommendation-plus-reason next-step wording that still preserves alternatives when multiple paths are real, and active summaries that keep resolved topics available for reasoning without repeating them as current issues by default |
-| [`artifact-initiation-control.md`](artifact-initiation-control.md) | Startup artifact governance | Resolve design/changelog/TODO/phase/patch posture before meaningful governed work drifts, initialize live task tracking early when non-trivial work needs visible execution state, and keep patch non-default during greenfield startup unless a real before/after review surface exists |
+| [`artifact-initiation-control.md`](artifact-initiation-control.md) | Startup artifact governance | Resolve design/changelog/TODO/phase/patch posture before meaningful governed work drifts, initialize live task tracking early when non-trivial work needs visible execution state, treat phase-backed live task tracking as expected startup behavior, and keep patch non-default during greenfield startup unless a real before/after review surface exists |
 | [`authority-and-scope.md`](authority-and-scope.md) | Decision hierarchy | User authority respected, fresh user directives override previously offered assistant options, unnecessary option branching is discouraged when one safe continuation path already exists, future-work proposals stay advisory until explicitly selected, user-declared RULES-first issues stay RULES-first instead of being diverted into memory-first fixes, memory applicability now defers to the dedicated memory-governance owner, non-matching path-scoped remembered context cannot override the current repo/objective, unresolved governing-basis selection stays user-owned unless authority/evidence already settles it, compacted-session continuation re-anchors to the latest active directive and active frame, and overlapping team expansion stays advisory unless a distinct new role is actually needed |
 | [`custom-agent-selection-priority.md`](custom-agent-selection-priority.md) | Custom agent selection priority | Prefer visible user custom agents as the primary specialist pool when a task clearly matches them, and reuse an existing matching teammate before spawning another overlapping team role |
 | [`dan-safe-normalization.md`](dan-safe-normalization.md) | Prompt-wrapper normalization | Safer intent evaluation before decisioning |
@@ -196,15 +196,15 @@ for f in $RULE_FILES; do cp "$f" ~/.claude/rules/; done
 | [`functional-intent-verification.md`](functional-intent-verification.md) | Intent validation | Commands verified before run |
 | [`memory-governance-and-session-boundary.md`](memory-governance-and-session-boundary.md) | Memory governance and session boundary | Treat memory as scoped reusable context rather than active authority, keep root `MEMORY.md` as an active index only, use `global/path/archive` semantics, make path the primary applicability key, keep session IDs as provenance only, and keep archived memory inactive by default |
 | [`operational-failure-handling.md`](operational-failure-handling.md) | Operational failure policy | Bounded retry ceilings, honest cooldown guidance, and stop/escalation behavior for technical failures, including inspect-first handling for duplicate-looking or stale team-agent presence |
-| [`phase-implementation.md`](phase-implementation.md) | Phase planning semantics | First-class `/phase` + `SUMMARY.md` model with major/subphase identities, early phase-establishment bridge, and explicit phase-to-patch linkage when patch is in scope |
+| [`phase-implementation.md`](phase-implementation.md) | Phase planning semantics | First-class `/phase` + `SUMMARY.md` model with major/subphase identities, early phase-establishment bridge, current-phase-first live task-list linkage, and explicit phase-to-patch linkage when patch is in scope |
 | [`runtime-topology-control.md`](runtime-topology-control.md) | Runtime topology discipline | Bounded inspect-first, one-authority-at-a-time runtime mutation posture that prevents debug-by-expansion and requires explicit approval for additive or authority-changing topology moves |
 | [`recovery-contract.md`](recovery-contract.md) | Blocked-response contract | Every constrained/refused path has actionable next steps |
 | [`tactical-strategic-programming.md`](tactical-strategic-programming.md) | Tactical vs strategic doctrine | Tactical entry stays fast, but every tactical move must point toward a declared strategic target and convergence path |
 | [`natural-professional-communication.md`](natural-professional-communication.md) | Communication style doctrine | Default to calm, human-readable, non-robotic, non-character-driven professional communication, reject metaphor-heavy or management-style abstraction when direct wording would be clearer, and front-load the operational purpose when the answer would otherwise bury it behind warm-up framing |
 | [`refusal-classification.md`](refusal-classification.md) | Deterministic refusal taxonomy | Consistent block decisions and traceable output modes |
 | [`refusal-minimization.md`](refusal-minimization.md) | False-refusal reduction | Prefer recoverable constrained/context paths when authorized |
 | [`strict-file-hygiene.md`](strict-file-hygiene.md) | File hygiene | Prevent junk files while allowing required governed startup artifacts |
-| [`todo-standards.md`](todo-standards.md) | Task management | Durable TODO tracking plus proactive built-in task-list usage for non-trivial live execution visibility |
+| [`todo-standards.md`](todo-standards.md) | Task management | Durable TODO tracking plus current-phase-first built-in task-list usage for non-trivial live execution visibility |
 | [`project-documentation-standards.md`](project-documentation-standards.md) | Project documentation standards | Standardized docs for all projects plus startup artifact gate, explicit live-task-list-vs-durable-TODO distinction, non-default startup patch posture for greenfield baseline formation, portable public onboarding/install guidance, and portable-by-default package-local support assets when they are reusable source content |
 | [`portable-implementation-and-hardcoding-control.md`](portable-implementation-and-hardcoding-control.md) | Portable implementation control | Keep shared artifacts, reusable support/package source artifacts, and public onboarding/install guidance portable by default, bind environment-specific values late, and prevent machine-local hardcoding drift |
 | [`unified-version-control-system.md`](unified-version-control-system.md) | Unified version governance | Single deterministic UDVC-1 controller |

TODO.md

@@ -6,6 +6,8 @@
 
 ## ✅ Completed
 
+- [x] Add easy-to-picture concise phase/progress explanation guidance so phase and next-step answers start from plain-language framing the user can picture quickly before denser governance/execution detail; synchronize design/changelog/master surfaces and runtime rule copies.
+- [x] Link live task-list behavior explicitly to the current active phase so non-trivial phase-backed work now expects a built-in task list early, one phase may contain multiple execution tasks, and future-phase draft tasks do not replace current-phase execution visibility; synchronize design/changelog/master surfaces and runtime rule copies.
 - [x] Suspend the custom table-format experiment from the active RULES system, keep the file for future redesign without deleting it, remove its active enforcement role from related owner chains, synchronize design/changelog/master surfaces, and update installed runtime copies so general support for using tables when helpful remains active without the custom format doctrine.
 - [x] Correct the default table style so tables remain available when useful, but ordinary answer tables now use the selected light plain aligned no-frame form instead of the previous compact pipe-table default; synchronize design/changelog/master surfaces; resync installed runtime copies; narrow the overreaching remembered table preference; and complete a final consistency audit.
 - [x] Refine task-list-first execution tracking so Claude Code's built-in task list is now explicitly the live execution surface for non-trivial active work, while `TODO.md` remains the durable repository/project tracking artifact; synchronize design/changelog/master surfaces; resync installed runtime copies; and complete a final consistency audit.
@@ -85,6 +87,8 @@
 
 | Date | Changes |
 |------|---------|
+| 2026-04-11 | Added easy-to-picture concise phase/progress explanation guidance so phase and next-step answers now start from plain-language framing the user can picture quickly before denser governance/execution detail. |
+| 2026-04-11 | Linked live task-list behavior explicitly to the current active phase so non-trivial phase-backed work now expects a built-in task list early, one phase may contain multiple execution tasks, and future-phase draft tasks do not replace current-phase execution visibility. |
 | 2026-04-11 | Suspended the custom `table-format-and-usage` experiment from the active RULES system, moved the file out of the root active rule area into `suspend/`, removed its active enforcement role from related owner chains, and restored general support for using tables when helpful without the custom format doctrine. |
 | 2026-04-10 | Corrected the default table style so ordinary answer tables now use the selected light plain aligned no-frame form instead of the previous compact pipe-table default; updated `answer-presentation` and `explanation-quality`; narrowed the overreaching remembered comparison-table preference so it defers to RULES for style; and opened the bounded `phase-028` / `patch/plain-aligned-no-frame-table-style-refinement.patch.md` refinement wave. |
 | 2026-04-10 | Refined task-list-first execution tracking so Claude Code's built-in task list is now explicitly treated as the live execution surface for non-trivial work, while `TODO.md` remains the durable repository/project tracking artifact; updated `todo-standards`, `artifact-initiation-control`, and `project-documentation-standards`; and opened the bounded `phase-027` / `patch/task-list-first-execution-tracking.patch.md` refinement wave. |

accurate-communication.md

@@ -1,7 +1,7 @@
 # Accurate Communication Standard
 
-> **Current Version:** 2.14
-> **Design:** [design/accurate-communication.design.md](design/accurate-communication.design.md) v2.14
+> **Current Version:** 2.15
+> **Design:** [design/accurate-communication.design.md](design/accurate-communication.design.md) v2.15
 > **Session:** 11c4bd2f-216e-4779-81bf-26d34a4fcaeb
 > **Full history:** [changelog/accurate-communication.changelog.md](changelog/accurate-communication.changelog.md)
 
@@ -113,6 +113,16 @@ Required guidance:
 - use the gloss to clarify the term, not to replace the technical truth
 - keep the gloss honest and scope-matched rather than oversimplifying into a false statement
 
+### 5.0 Easy-to-Picture Phase/Progress Framing Principle
+
+When reporting phase progress, phase meaning, or next-step reasoning, start with a short plain-language framing that helps the reader picture what the work is doing before denser execution or governance detail appears.
+
+Required guidance:
+- say in simple human terms what the phase or progress item is doing
+- say briefly why it matters or what part of the work it prepares, locks, or moves forward
+- keep this framing concise and easy to follow
+- do not begin with dense scope/governance detail if one short plain-language framing line would help the reader orient faster
+
 ### 5.1 Variable, Field, and Internal-Label Clarification Principle
 
 When an answer relies on variable names, field names, config keys, enum-like values, or internal labels that are not self-explanatory, do not treat the raw identifier as if its name alone explains the system.

answer-presentation.md

@@ -1,7 +1,7 @@
 # Answer Presentation
 
-> **Current Version:** 1.20
-> **Design:** [design/answer-presentation.design.md](design/answer-presentation.design.md) v1.20
+> **Current Version:** 1.21
+> **Design:** [design/answer-presentation.design.md](design/answer-presentation.design.md) v1.21
 > **Session:** 11c4bd2f-216e-4779-81bf-26d34a4fcaeb
 > **Full history:** [changelog/answer-presentation.changelog.md](changelog/answer-presentation.changelog.md)
 
@@ -156,6 +156,7 @@ Apply stronger presentation structure when one or more of these triggers are pre
 | branching | conditions, paths, handoffs | text flow diagram or clearly indented branch structure |
 | diagnostic snapshot | troubleshooting status, implementation progress report, verification snapshot, environment note | short orienting line + purpose-first line when needed + compact titled snapshot sections + small scoped fact table when helpful |
 | scope clarification | what this is vs what it is not, what happens now vs later, current scope vs deferred scope | grouped sections such as `What this is`, `What this is not`, `What happens now`, `What stays later`, `What the user will notice` |
+| phase / progress explanation | what this phase is for, what this phase got, what this prepares next | short plain-language opening + concise grouped explanation |
 | full-set framing | many relevant areas, complete checklist, several review axes that should be visible together | complete set first, then optional narrowing |
 | stage progression | current explanation is already sufficient and the real need is the next state or milestone | short explicit `What happens next` / `Next stage` / `Next state` block |
 | governing-basis ambiguity | multiple plausible policies/frames remain live and the answer changes depending on which one is chosen | short clarification block with compact basis options and one `Why it matters` line |
@@ -287,6 +288,13 @@ When explaining roadmap, phase scope, staged rollout, or product truth:
 
 Use these blocks when they materially improve scanability, not as a rigid mandatory template.
 
+### 7.1 Easy-to-Picture Phase/Progress Pattern
+
+When answering what a phase is doing, what it got, or what it prepares next:
+- start with one short plain-language line that helps the reader picture the work quickly
+- then use one small grouped explanation if needed
+- keep the whole explanation concise rather than expanding into a long governance-first block
+
 ### 7.1 Variable-Role Pattern
 
 When multiple variables, fields, config keys, enum-like values, or internal labels are central to the explanation:

artifact-initiation-control.md

@@ -35,6 +35,7 @@ Required guidance:
   - ask now
   - not required
 - when the work is non-trivial and tracking is materially useful, initialize the built-in task list early as the live execution surface instead of leaving work state implicit
+- when an active phase already exists for the work, treat live task-list initialization as expected rather than optional unless a narrow justified reason clearly blocks it
 - do not silently skip artifacts or live tracking surfaces that appear required
 
 ### 3) Existing-Authority-First Principle
@@ -103,7 +104,7 @@ Meaningful governed work begins when the assistant moves beyond lightweight expl
 | Design | target behavior, policy, contract, or architecture is new or materially changing |
 | Changelog | a governed chain is being created or version-impacting behavior is changing |
 | TODO | work is multi-step, tracked, persistent, or likely to span multiple execution slices |
-| Live task list | work is non-trivial and the user would materially benefit from seeing pending / in_progress / completed state during active execution |
+| Live task list | work is non-trivial and the user would materially benefit from seeing pending / in_progress / completed state during active execution; phase-backed work strengthens this from preferred to expected |
 | Phase | staged execution, gates, sequencing, rollback boundaries, or explicit user request make `/phase` materially useful |
 | Patch | explicit before/after review packaging outside live phase planning is materially useful for an existing governed surface; greenfield startup / baseline formation normally defaults to `not required` unless the user explicitly requests patch packaging |
 
@@ -181,6 +182,7 @@ Not allowed:
 |--------|--------|
 | Startup artifact posture resolved before meaningful drift | 100% |
 | Required artifacts silently omitted at startup | 0 critical cases |
+| Phase-backed live task tracking omitted at startup | 0 critical cases |
 | Retrospective artifact backfill | Low |
 | Trivial-work over-ceremony | Low |
 | Existing-authority reuse | High |

changelog/accurate-communication.changelog.md

@@ -1,7 +1,7 @@
 # Changelog - Accurate Communication Standard
 
 > **Parent Document:** [../accurate-communication.md](../accurate-communication.md)
-> **Current Version:** 2.14
+> **Current Version:** 2.15
 > **Session:** 11c4bd2f-216e-4779-81bf-26d34a4fcaeb
 
 ---
@@ -10,6 +10,7 @@
 
 | Version | Date | Changes | Session ID |
 |---------|------|---------|------------|
+| 2.15 | 2026-04-11 | **[Added easy-to-picture phase/progress framing guidance](#version-215)** | 11c4bd2f-216e-4779-81bf-26d34a4fcaeb |
 | 2.14 | 2026-04-09 | **[Added memory-derived-context disclosure wording](#version-214)** | 11c4bd2f-216e-4779-81bf-26d34a4fcaeb |
 | 2.13 | 2026-04-09 | **[Added main-point-first operational framing for diagnosis, tests, and recommendations](#version-213)** | 11c4bd2f-216e-4779-81bf-26d34a4fcaeb |
 | 2.12 | 2026-04-08 | **[Preferred direct human-readable wording over metaphor-heavy internal shorthand](#version-212)** | 11c4bd2f-216e-4779-81bf-26d34a4fcaeb |
@@ -55,6 +56,23 @@
 
 ---
 
+<a id="version-215"></a>
+## Version 2.15: Added easy-to-picture phase/progress framing guidance
+
+**Date:** 2026-04-11
+**Session:** 11c4bd2f-216e-4779-81bf-26d34a4fcaeb
+
+### Changes
+- Updated `accurate-communication.md` from v2.14 to v2.15.
+- Updated `design/accurate-communication.design.md` from v2.14 to v2.15.
+- Added explicit wording guidance that phase/progress reporting should start with a short plain-language framing that helps the reader picture what the work is doing before denser execution or governance detail appears.
+- Preserved existing main-point-first, direct human-readable wording, and concise synthesis behavior.
+
+### Summary
+Accurate-communication now makes phase/progress reporting easier to picture by front-loading a short plain-language framing before denser operational detail.
+
+---
+
 <a id="version-214"></a>
 ## Version 2.14: Added memory-derived-context disclosure wording