v0.8.68 Runtime: make current Work state model-visible on parent turns

[Hmbown]

Problem

CodeWhale already has a useful Work surface: checklist_* is the counted execution ledger and update_plan carries strategy metadata. The TUI shows this as To-do plus Strategy context, and forked sub-agents receive a synthesized Fork State block.

The part that still needs hardening is parent-turn grounding. Today the parent model can create/update the state through tools and can see tool results in the transcript, but the repo evidence I found does not show an equivalent synthesized current Work-state block being injected into normal parent turns after long sessions, resume, compaction, or drift. If we want to describe this as dynamic planning rather than a nice UI projection, the parent model should reliably receive the live checklist/strategy state too.

Evidence

Implemented today:

• crates/tui/src/prompts/constitution.md teaches agents to use checklist_write and optionally update_plan for multi-phase work.
• crates/tui/src/prompts/modes/agent.md, plan.md, and yolo.md repeat that guidance per mode.
• crates/tui/src/tools/registry.rs exposes canonical checklist_* tools to the model catalog while keeping legacy todo_* aliases hidden.
• crates/tui/src/tools/plan.rs stores rich PlanArtifact fields and returns the updated snapshot in the tool result.
• crates/tui/src/tools/todo.rs stores checklist progress metadata under task_updates.checklist.
• crates/tui/src/tui/sidebar.rs renders the combined Work projection as checklist plus Strategy context.
• crates/tui/src/core/engine.rs captures todo_snapshot and plan_snapshot into StructuredState.
• crates/tui/src/tools/subagent/mod.rs wraps that state in <codewhale:fork_state> for forked sub-agents.
• crates/tui/src/commands/groups/session/relay.rs includes checklist and strategy metadata in manual relay output.

Gap to close:

• The normal parent turn path in crates/tui/src/core/engine.rs adds the user's message and then sends the transcript/tool catalog into handle_deepseek_turn; I did not find a matching synthesized current Work-state injection for the parent model outside the sub-agent fork path.
• Relying only on old tool results in the transcript is weaker during long sessions, compaction, resume, and model drift. The live sidebar can be correct while the next model call is not explicitly reminded of the current Work state.

Expected behavior

At the start of a parent model turn, when checklist or plan state exists, CodeWhale should provide a compact, current, model-visible Work-state block. It should be concise, deterministic, and not duplicate the entire transcript.

Suggested shape:

<codewhale:work_state>
Checklist (38% complete)
- [x] ...
- [~] ...
- [ ] ...

Strategy metadata
- Objective: ...
- Context: ...
- Constraint: ...
- Recommended approach: ...
- Verification plan: ...
- [~] phase now ...
- [ ] phase next ...
</codewhale:work_state>

The block should be injected only when non-empty, should avoid secrets, and should stay small enough not to fight the context budget.

Likely files

• crates/tui/src/core/engine.rs
• crates/tui/src/core/engine/turn.rs
• crates/tui/src/tools/plan.rs
• crates/tui/src/tools/todo.rs
• crates/tui/src/tools/subagent/mod.rs
• crates/tui/src/commands/groups/session/relay.rs
• Prompt/context tests under crates/tui/src/prompts.rs, crates/tui/src/core/engine.rs, or focused engine tests

Acceptance criteria

• Parent model requests include a compact current Work-state block when checklist or strategy metadata exists.
• The block includes checklist status/progress and high-value strategy metadata, but does not duplicate the entire transcript or every prior tool output.
• Sub-agent fork-state and /relay continue to use compatible wording so the three continuity paths do not drift.
• Add tests that fail if Work state is only rendered in the UI but omitted from model-facing parent-turn context.
• Add or update product/docs copy only after the runtime behavior is covered by tests, so the public claim stays grounded.

[Hmbown]

Confirmed: parent turn has no Work-state injection, and the formatter we need already exists

I verified the gap this issue describes. The parent-turn path does not inject current Work state, and the formatter that should produce it already exists and is tested — it is just only wired into the sub-agent fork path.

What already exists

• StructuredState::capture() (core/engine.rs:86-137) snapshots SharedTodoList (:97-105) and SharedPlanState (:107-114).
• StructuredState::to_system_block() (engine.rs:139-223) renders ### Work (checklist with [ ]/[~]/[x] markers, :153-166) and Strategy metadata (plan fields via append_plan_field / append_plan_list, :168-201, helpers at :226-237). Returns None when everything is empty.

The confirmed gap

• The capture at engine.rs:2429 is guarded by if subagents_available (:2428) and flows only into SubAgentForkContext.structured_state_block (:2442), consumed at engine.rs:2527 (rt.with_fork_context(context)) to build sub-agent runtimes — never the parent model request.
• The parent-turn handler handle_send_message (engine.rs:2225) builds a <turn_meta> block via turn_metadata_block (:1947-2003) carrying date, workspace, model, mode, mode-policy, provenance, authority, resource metadata, and working-set summary only (:1994-1996). No checklist, no plan.
• So the parent model is reminded of the workspace and the working set, but not of the current checklist or strategy metadata. The issue's concern about long sessions, compaction, resume, and drift is real — after compaction the old tool results that carried the plan are gone, and nothing re-grounds the parent.

This issue also closes a triplication

The checklist+plan rendering logic currently exists in three places with two divergent helper sets:

1. Fork — StructuredState::to_system_block, engine.rs:139-223 (uses append_plan_field / append_plan_list, :226-237).
2. Parent turn — currently absent (this issue).
3. Relay — build_relay_instruction, commands/groups/session/relay.rs:44-169 (uses local helpers write_plan_field / write_plan_list, :171-184 — a divergent copy of the engine helpers).

The clean implementation is to extract one shared fn render_work_state(todos: Option<&TodoListSnapshot>, plan: Option<&PlanSnapshot>, ...) -> Option<String> (the body of to_system_block minus the Fork/SubAgent/Workspace framing) and call it from all three. That reduces total code while landing this feature and gives #3984 a single grounded behavior to document. The StructuredState::capture path already produces exactly the TodoListSnapshot / PlanSnapshot the shared formatter consumes, so the parent-turn and relay paths can call capture() (or a sliced variant) rather than re-locking the shared state themselves.

This is closely related to the engine-policy refactor lane — specifically #3943 ("extract prompt metadata from runtime decisions"). Worth cross-linking so the shared formatter lands in the right module.

Prefix-cache discipline

One constraint the implementation must respect: turn_meta is intentionally placed last in the message (:2057-2064) for cache stability, and the codebase treats prefix-cache discipline as a hard architectural law (docs/TOOL_LIFECYCLE.md; tool catalog is name-sorted and memoized in registry.rs:200-246 for exactly this reason). A volatile Work-state block changes every turn (the checklist advances), so it must occupy the same trailing, post-cache-boundary position as turn_meta — not be inserted into the stable system-prompt head, which would bust the cache every turn. The issue's <codewhale:work_state> shape is right; its placement must be trailing.

Suggested acceptance addendum

• Add: "the parent-turn Work-state block is rendered by the same render_work_state formatter as the fork-state and /relay paths" — so the three continuity paths cannot drift.
• Add: "the block is placed in the trailing, post-cache-boundary region of the turn, not in the stable system-prompt head."
• The issue already asks for a test that fails if Work state is only rendered in the UI but omitted from model-facing parent-turn context — that is the right guard.