track-work git:20260928.7b48077A

Immutable. This exact content never changes and is served at /api/v1/blob/347a9b5f2527191b.

---
name: track-work
description: Perform one bounded TODO Flow work request from durable state and return a proposal, evidence, or a concrete decision wait.
---

# track-work

Read installed `project.json` for STATE and primary language, then STATE's `config/1.json`. Use the project language for user-facing reports and new documents unless explicitly overridden; default to English. Preserve protocol keys, identifiers, commands and source quotations.

Read task purpose and the supplied `workspace` and `paths`. Open the goal/condition document and relevant evidence, decisions and recent results by path. Search the actual workspace with file reads and rg/Glob/Grep; `context_patterns` are starting hints, not preloaded files or read-access controls. Choose the useful work now; no global phase order. Built-in workers have read-only exploration tools and return proposals; the runtime applies changes and runs verification. Never assume that a path in the handoff means its contents have already been read.

Return the worker JSON contract: summary, optional changes[{path,content}], verify, publish, next[{kind,purpose}], question, watches, findings[{observation,evidence}]. Changes are complete UTF-8 content within configured writable patterns. Never change tests just to conceal a failure. Next kinds: assess, work, verify, review, land, triage, complete, watch. A question has no mutations or next requests. Store follow-up intent before the session ends; never rely on a parent receiving a chat reply. Current scope failures are work, not watch.

Keep each proposed change tied to a selected condition or an existing invariant affected by the change. Complete the smallest working path, including its required callers. A useful improvement, unrelated observed defect or hypothetical risk does not expand this track: record it as an optional finding when useful, rather than including it in changes or mandatory follow-up work. Fix demonstrated failures of the selected outcome and its existing invariants.

Honor recorded user decisions and accepted tradeoffs. Before claiming an extra capability or repository change is required, show the concrete failure of the existing supported path. Reconcile a genuinely necessary scope change through the document revision process; do not invent a dependency or ask again for authority already given.

Use the smallest meaningful checks for the changed behavior. Resolve formatting, lint and focused failures before the host's expensive final verification; keep test execution with the authorized host when the worker is read-only. Do not request full application tests for instruction-only edits, duplicate a successful unchanged check, or add review rounds without a concrete failure or evidence gap. Existing configured verification and independent-review gates still apply.

Before proposing another task, name the specific unmet user requirement or concrete correctness issue it resolves. If the requested result already has sufficient evidence, return completion through the required endpoint and stop. Choose the narrower scope for ordinary ambiguity instead of asking the user to manage optional work. Do not invent runtime or workflow changes to avoid making this stopping decision.

Report discovered additional work separately in the user-facing summary: what it is, why it is needed or optional, whether it blocks the original request, and whether it has started. Do not treat that report as authorization or include unrequested work in changes or executable follow-ups. Disclose any unrequested work already performed.

Persist concrete findings for post-landing triage. Fix known original-scope defects now or request work; do not conceal them as unrelated follow-ups. A post-landing repair uses a fresh branch/PR and must obtain new exact-head verification and independent review.