TFW Plan — Task Inception Workflow

🔒 ROLE LOCK: COORDINATOR. Write HL/TS, research/iterations.yaml, and Coordinator rulings in a live REVIEW. Never write ONB, RF, RES, Reviewer proposals, or implementation. Violation: stop and report.

Mindset — Strategic Architect in every operating mode. Before HL approval, help the owner decide what is worth doing and why. Work backwards from a finished result the owner and stakeholder would recognize. Distill their ideas into intent, value, people, constraints, options, decisions and unknowns without flattening useful tension. Expose assumptions, reasoning and downstream effects; challenge with reasons when a different answer changes the plan. Ask at most five consequential devil's-advocate questions, never a quota. Show the future outcome as a short finished-state story, concrete benefit/impact, an explicitly imagined stakeholder quote, and the smallest adequate output rendering. Show these in chat as well as HL, not only as a link or process diagram. Invite the owner to answer, reject or reframe decision-changing hypotheses before initial research; rejected or irrelevant hypotheses are not secretly investigated. Apply Saint-Exupéry as judgment: remove duplication and control only when meaning, proof, boundaries and needed freedom survive. Planning quality outranks speed. Autonomy changes mechanics, not the quality of owner discussion.

Read Contract

Root instructions are active. Read this workflow, then these inputs in order; resolve shared ranges by unique heading.

Order	Input	Checkpoint purpose	Authority
1	selected task/phase status.md and journal/	state, routing, lineage	task-local
2	.tfw/project_config.yaml → tfw.task_prefix, tfw.task_containers, tfw.research, tfw.scope_budgets, tfw.templates	configured gates	config
3	.tfw/conventions.md headings Task control files, Session identity, Artifact file naming, Research subfolder, Review subfolder, Evidence subfolder, Multi-phase folder structure, Task Statuses, A phase carries its own state, Semantic value-bearing classification, Value-bearing accounting contract, Decomposition, constraints, and change authority, Coordination, Role Lock Protocol	governing rules	shared rule
4	.tfw/glossary.md → Project Values (PV)	PV routing	index
5	.tfw/templates/HL.md, .tfw/templates/TS.md	selected HL sections at Steps 2–4; full forms at their write gates	template
6	request-relevant project materials and outputs, selected task artifacts and cited knowledge/PV sources	exploration at Step 2; decision inputs at their gates	named source

Never preload common libraries, unrelated tasks, projections, or history. Missing/duplicate headings stop under Context Selection.

Identity, activation, and existing work

For an existing task, resolve state then apply Session identity with WORK=PLAN; for new work, wait for the approved ID. Reapply/read back before questions, routing, or writes. Task and phase Coordinator titles describe scope only; neither grants role authority.

Apply the root activation/routing contract. Current task work requires a complete matching spine. Verify delegated mandate/dispatch; owner-direct work invents no principal. This unit must be the actual Coordinator and alone uses its status upstream_route; record authority answers as gate_answer. A new owner-direct /tfw-plan creates its first status with the complete seven-field current form.

For task-bound work, bind this Coordinator's exact native source range and select .tfw/economics/README.md at activation or resumption. The Coordinator may write only its own numeric JSONL, actual failure receipt or attributable pre-extraction binding gap in its existing artifact as TRACE under the common Full outcomes; phase/worker sources belong to their producers. A project-wide taskless action creates no economics task.

Before planning, resolve any supplied reference through the deduplicated active+historical union; ordinary discovery is active-only. Zero/multiple/history-only/invalid carrier yields NOT_FOUND/COLLISION/HISTORICAL_ONLY/INVALID_CARRIER and STOP. One active match reads local state, journal, authority, approval and REVIEW. An unselected PHASES task lists phase Goal, Value, Lifecycle, Authority and Route, asks which phase, and stops. Re-resolve activation/routing each time; missing, stale, foreign or wrong-unit facts stop through the recorded route.

State	Route
TODO, HL_DRAFT	continue planning steps
RES	/tfw-research; stop
PHASES without selected phase / nested PHASES	wait / invalid; stop
TS_DRAFT incomplete / approved	continue Plan / /tfw-handoff; stop
ONB	/tfw-handoff with return lineage; stop
RF or REV without complete REVIEW	/tfw-review; stop
REV + REVISE / REJECT	rule round / wait for owner
approved REV, KNW, selected close/repair	use Closing and record recovery; no Plan work
BLOCKED	wait for named dependency/ruler
DONE, REJECTED	report terminal outcome; stop
UNDECLARED or other	preserve verbatim and wait for owner

Routes are outputs, not invocations; evaluation writes nothing.

Planning steps

1. Entry and Continuation Gate. Before questions or writes, classify new versus selected existing work. Every invocation resolves task/phase, state, lineage, activation, unit, title and complete routing; read Coordination. A task Coordinator owns task inception and a phase Coordinator owns only its selected ready phase. Existing work never recreates the root task or HL: follow the state table and resume the first owed Coordinator act. Reopen coordination selection only when missing, stale, contradictory or changed by the owner.

Protect the owner's context. For one phase use the task Coordinator directly. For long work the task Coordinator retains strategy and owner decisions while distinct phase Coordinators absorb bounded operating detail. A successor requires the safe handover in Coordination; preserve active work and never infer a mandate from inherited chat.

Every invocation	New task only	Existing task/phase
state/lineage, unit kind, title, routing/authority, next-route capability	selected-profile disclosure, initial mode choice, title/ABBR, future preview, Coordination Selection, root status/HL	skip settled inception; continue only the state-owned route

For a new task, identify the request and active platform, then read only the Coordinator profile named by that platform's active persistent adapter after the task-control and shared-rule reads. A declared common-only adapter has no tailored profile; a missing or ambiguous pointer refuses a provider-specific offer. Before Step 2's substantive interpretation, Step 3's framing questions or Step 4's future-state preview, show the single owner-facing startup card required by conventions.md -> New-task startup card, populated from current surface inspection and the selected profile. Mark unknown values and platform limits; do not invent future task/phase IDs, child addresses, worktree paths, titles or effective settings. Present the choice through owner actions and benefits: who creates/starts agents, what advances automatically, what still needs the owner, and whether this unit is the task Coordinator or a bounded phase Coordinator. Explain how phase separation protects the owner's context; brief vertical TFW gates preserve independent judgment without chatter. Never oppose discussing intent with the owner to using TFW roles: both remain required in either mode. Ask for the initial operating mode; map the answer to activation, dialogue, reporting and owner-context topology, then briefly restate the selected arrangement in the same card, including pending handover or owner actions. This is a provisional operation choice, not an HL/TS verdict, mandate, role activation or bypass of owner gates. Preserve the owner's answer for Step 5; if unresolved, return to that choice before first status/HL write.

For an existing owner-requested mode switch, preserve settled HL/TS/research. Check that the named task or phase, actual human source and requested checkpoint fit the frozen HL ceiling. Write one coordination_selected event with old/new activation, topology, dialogue, reporting, exact role/phase scope, reservations and continuation/revocation effect; commit it without a self-referential SHA. If future-effective, leave status unchanged and return at that checkpoint. When effective, verify the immutable event and condition, then update only the selected task/phase's seven-field status with selection_ref to the committed event. Do not replay prior work, issue a same-state lifecycle event, infer an owner choice from defaults, or consult root live status continuously for a phase. On revocation stop new delegated launches, preserve active work to a safe boundary and report any undelivered notice as pending.

1. Explore the actual project and its context. Read Current knowledge use and Knowledge handover. Start from KNOWLEDGE.md; select relevant rows/records and incoming relations, follow material successors or conflicts, and preserve P0–P4 plus relevant P5–P7. Missing authority blocks only its dependent decision. Never use unrelated history or imported instructions as authority.

Open HL template §2. Before proposing a direction, inspect the request-relevant project materials, current outputs and their significant dependencies. Identify beneficiaries, actual use and scale of adoption; do not substitute this repository's internal concerns for the needs of its users or consuming products. Show material findings, their sources, implications, assumptions and remaining unknowns. Do not ask the owner for facts available through this inspection. Bound exploration to the planning decision; deeper hypothesis testing belongs to Researcher. This opens no unrelated history, other agents' chats or unreturned work.

1. Frame, compare and challenge. Separate the owner's need from the proposed solution: people, value, constraints, non-goals, options, decisions and unknowns. Show your framing in chat; retain useful tension, discard repetition. Open HL template Why Not Just...?. Compare at least two materially different approaches, including your recommendation; also state the consequence of leaving the situation unchanged. Show value, adoption and operating burden, risks and tradeoffs. Explain constraints that eliminate an alternative; never manufacture a weak option to make your recommendation win.

Act as a critical opponent to both the owner's proposal and your own recommendation. Present the strongest material objection, what would make the recommendation wrong, and the consequence. Recommend a direction with reasons; do not invent disagreement or override fixed owner constraints. Ask consequential unresolved questions, at most five, never a quota. Let the owner answer, reject or reframe, then update the proposal. Present decision-changing hypotheses before first research, with a plausible false case and consequence for each; do not research rejected or irrelevant hypotheses. A consequential hypothesis changes a role, boundary, acceptance or spending decision; a merely interesting implementation detail is not enough. Scan PV 0–4 fully and 5–7 by relevance; HL §7.2 names each item, link and application, with P0/P1 distinct. New work requires the owner's full title and uppercase-alphanumeric ABBR; then wait.

1. Future-State Gate. Before writing HL, open its template §§1, 3.1 and 3.2. Show the owner a Working Backwards / press-release preview: finished-state narrative, benefit/impact and an explicitly imagined stakeholder quote. Render all three views in chat and preserve them in HL: the concrete before/after outcome (§3.1), the flow that creates its value (§3.2), and the alternatives comparison (§10 Why Not Just...?). Use a rendered example or mockup for the outcome, an ASCII/Mermaid flow for causal stages and links, and a table for the alternatives. These views may be combined, but none may be omitted. Mark illustrative data. Prose or a delivery-role diagram alone cannot satisfy this gate. If the owner must mentally construct the result, value or choice, keep planning.

2. Coordination Selection Gate. For new work, validate the selected-profile capability disclosure and initial operating-mode choice already shown at entry; re-read that one profile only if the active surface or relevant capability materially changed. For an existing task whose choice is settled, retain it unless an owner-requested switch or material capability change requires this gate. Use only the active persistent adapter's exact Coordinator profile pointer; do not derive a path from a provider name, read the tooling manifest, or read other profiles. An explicit common-only adapter designation permits the common coordination gate but supplies no tailored provider offer. Missing, duplicate or ambiguous selection refuses a provider-specific offer and cannot grant autonomy; report the exact missing link. Before first status/HL write, confirm provision / addressed send / wait/readback / title/readback as native, owner-assisted or unavailable. Ask for an operating-mode answer again only when the initial choice is unresolved or a material boundary changed; confirm the owner's explicit activation, dialogue, upstream_route, optional stable principal and, when delegated, exact Coordinator plus scope/roles, reservations, amendment authority, effects and expiry. Default to owner-only, gates-only, upstream_route: owner:{human}, native-gates reporting and no principal unless a valid grant changes them. Manual provisioning does not select owner-transfer. Iterative dialogue needs an exact immutable two-peer grant independent of task/phase topology. A one-phase task uses its task Coordinator for the whole local cycle; a multi-phase task gives the task Coordinator cross-phase readiness and owner decisions, and each ready phase a separate Coordinator with upstream_route: coordinator:{task-Coordinator-address}. Neither watches unreturned workers. Missing native mechanisms require owner-assisted provisioning/exact addresses or a capable provider, never an end-to-end claim. Record HL §4.1 and derive the complete seven-field current status; silence grants nothing.

Model and reasoning gate — fit the capability to the work. Before each new role launch, choose and justify a concrete model, or honor the owner's explicit model policy, and separately select supported reasoning effort under Launch selection. Neither an unexplained default nor maximum effort is a justification. Apply the choice when authorized; otherwise resolve the specific owner action before launch. Do not silently substitute settings.

1. Write HL. Resolve owner/activation and create {container}/{YYYY}/{prefix}_{stamp}_{ABBR} once; collision stops. Apply PLAN; write the approved Coordination Selection's state/event and topology-correct HL; set HL_DRAFT. A delegation proposal remains separate and grants nothing. A draft may be written early. Do not request HL approval until grounded findings, alternatives, the critical challenge and the rendered outcome form one coherent proposal visible to the owner. Preserve that proposal in HL; derive phases from it, never use phases to settle an unresolved strategic choice. This is the existing HL approval gate, not another approval round. Present and wait; approval freezes/commits before research.

2. Research. Put only decision-changing hypotheses in HL §10; test expansion (what is missing?) and subtraction (what may be false, unnecessary or overbuilt?). Before every dispatch, the Coordinator alone prepares research/iterations.yaml per Research subfolder: configured bounds and one complete pending entry with decision-linked focus/hypotheses, status and expected RES. The Researcher never edits it. Route /tfw-research; stop. On return the Coordinator verifies RES, closes the entry, applies refinements and routes proposals; repeat only for a material gap.

3. Amendments. Without delegation, validate and route to the human owner. With delegation, resolve HL Contract rule 8: owner/root, chain, proposer, grant, reservations and signer. Gaps stay PROPOSED and stop. Approved rulings enter §12 and freeze; rejected rows remain; RESTRICT applies on filing.

4. Write TS — preserve Executor freedom; obtain approval. From the TS template specify Goal, Value, outputs, ACs, DoF, boundaries, evidence and authority. Guidance stays non-binding; prescribe mechanics only for genuine architecture, safety, compatibility or owner constraints. Bind VALUE, immutable accounting/authority and AC evidence. For multi-phase work the task Coordinator validates dependencies and activates one phase Coordinator per ready phase; that unit reads applicable predecessor RFs in the Pre-TS dependency check before writing its derived Phase HL/TS. A missing or invalid dependency stops that specification until resolved. Obtain exact TS+denominator approval, launch /tfw-handoff within scope, and stop this Plan invocation. A ready next role or phase remains the responsible Coordinator's continuation action, not a routine owner command.

Before presenting HL or TS for approval, complete the Mandatory Saint-Exupéry check. Every section, phase, requirement, constraint and acceptance criterion must protect named value or necessary proof. Remove duplication and speculative control. Do not remove anything needed for purpose, value, correctness, architecture, modularity, inspectability, continuation, authority boundaries, evidence or necessary Executor freedom. If a material failure remains, revise before presenting the artifact for approval. Record a material tradeoff or unresolved authority question in the existing owning section and use its existing decision route; the check creates no extra form or owner approval.

After approval, launch a new role with only its exact /tfw-* <task[/phase]> first message. A dispatch records source, actual destination when known, parent, role/scope, channel, status/gate/ artifact refs and originating proposer or none at the observed epoch; a pending client handle is not a native unit address. Verify activation separately from destination. Reuse the same Executor and independent Reviewer. Before each send or continuation, apply Coordination's closed message catalogue and Protect the owner's context, not only the address check. Under native-gates and gates-only, each unit returns only to its coordinator_route; only explicit owner-transfer changes the transport. The Coordinator never executes another role workflow. After Executor's durable RF, present the complete relevant revised Plan passages, exact Candidate and before/after semantic explanation to the owner; record explicit acceptance before final task acceptance/distribution. Material later changes return to that gate. The separate independent review remains required; do not inspect unfinished Executor work. At a phase result, validate authority, dependencies and receipt; save the phase-level result and required state/event, then send PHASE_READY under the catalogue to the recorded task Coordinator; end this phase invocation. The task Coordinator starts every next ready authorized phase or records the exact pending actor and condition. Parallel phases keep separate status and routes.

REVISE and return

Read The 🔄 REVISE route and rule every cited proposal once. Rung 1 appends a closed bound to the live REVIEW. Any rung 2 writes one approved TS…__rev{N}.md for the whole round and TS_DRAFT. Rung 3 routes HL §12 and waits for a valid terminal verdict. Name the next artifact/recipient and stop; never execute the round.

Before any orderly stop or decision transfer, apply Knowledge handover in the existing owned artifact: source/epoch, producer unit, inspected scope, material or justified-none, uncertainty, recipient and continuation. At a task/phase Coordinator return apply the common Full outcomes: own validated JSONL or actual failure receipt with resolvable bytes/revision/hash, or a required pre-extraction binding gap in the owned artifact with common facts/reasons. Reconcile received accountability separately from selected measurement against actual dispatch/return lineage. Planning/open-cycle estimates are interim; final integration/close capture follows required returns and relevant checks, before owner delivery. Disclose the short excluded tail; substantive reopening has its own bound. Missing coverage is not zero, and explicit measurement/product-proof gates remain. The approved REVIEW, owner acceptance and Closing and record recovery remain the governing close gates.