CTC Agent Workflow¶

This router selects the smallest context, skill and validation level. It does not create Product policy, restriction, deployment authority or additional work.

1. Routing Receipt¶

Before the first write record:

REQUEST_AUTHORITY: DIRECT_USER | TASK_AUTHORITY | AI_PROPOSED
ROUTE: NEW_SYSTEM | LEGACY | TRANSITION | RECONSTRUCTION | CONTRACT | INFRASTRUCTURE | ARCHITECTURE_GOVERNANCE
MODE: DIRECT | PLAN | CHANGESET | WORK_GRAPH
AUTHORITY: exact current owners
PRIMARY_SKILL: one domain skill or NONE
WRITE_BOUNDARY: exact paths and effects
VERIFY: focused checks and evidence ceiling

Reissue the receipt only when the requested outcome, selected Task, authority or base revision changes. Explicitly locate and read applicable scoped AGENTS.md files along the affected paths from the repository root. Read only the rules, accepted decisions and skill references needed for that scope; a link or a file's existence does not prove that the current agent loaded it.

2. Preserve The User's Requested Outcome¶

Classify every proposed change:

Class	Default action
`USER_REQUESTED`	implement within the exact requested effect
`REQUIRED_FOR_REQUEST`	implement only when necessary to make the request correct or verifiable
`AI_PROPOSED`	do not implement without separate scope or approval

A current direct request outranks stale planning and AI-hygiene defaults for the requested outcome. When an existing Task is narrower, reconcile its bounded scope with the current request instead of refusing the work or asking the user to repeat the request. Use the reviewed working-tree Task and document contents, including uncommitted updates. New-System's retired manifests, EXECUTION ledger, preflight packets and Context Gate do not confer current authority. A document or exact scope update is not a reason to demand a preliminary commit or another Git approval.

Direct user authority does not imply unrelated Git, DB, credential, provider, Wiki, service, deployment, Production or destructive effects. Those remain separately classified.

2.1 Investigate Before Asking¶

Read the current request, accepted decisions and relevant repository owners before asking for missing information. Finding the Task, caller, component, test command or an already recorded decision is the agent's responsibility; do not make the user name skills or repeat those facts.

Ask only when investigation leaves a material Product/behavior choice unresolved, or a necessary permission/effect is not authorized. Name the exact decision or effect and the affected scope. Do not guess business policy, credentials, destructive behavior or external authority. Continue independent authorized work while that scope is blocked. A read-only review stays read-only; this rule does not turn a request to analyze/report into permission to implement.

3. Select One Primary Skill And Load Stage Skills As Needed¶

Work	Primary skill
System direction, harness, documentation authority, module/evidence review	`ctc-system-review`
Legacy/API/tenant/DB/consumer-sensitive implementation	`ctc-change-safety`
New-System screen composition, parity, visual redesign or bounded UI polish	`ctc-ui-design`
Actual browser, role, CRUD or operator workflow verification requested by the user or required by approved Task acceptance	`ctc-field-process-testing`
Source owner/caller/execution-flow mapping	`code-mapper`
Read-only MySQL schema/data inspection	`db-inspector`
Versioned framework/API documentation research	`docs-researcher`
Broad repository search where exact owners are unknown	`search-specialist`
Multi-owner fan-out/fan-in orchestration	domain skill plus `ctc-work-graph` overlay

Use graphify or graphify-catalog only after the primary skill identifies a graph/search need. Use NONE only for a genuinely local, obvious change not covered by a specialist.

Load the primary skill after routing and another specialist only when its authorized stage is reached. UI parity may need ctc-ui-design, API/DB changes ctc-change-safety, then approved runtime acceptance ctc-field-process-testing. Selecting a testing skill identifies evidence, not new execution permission. Do not omit required implementation or verification because the initial skill covered another stage.

Keep the selected skill in the routing receipt. A stage transition alone needs no new Task, skill-history list, repeated approval or repeated still-valid checks. Reconcile actual scope/authority changes before writing; do not preload all skills or copy their procedures into the Task.

4. Select The Smallest Delivery Mode¶

DIRECT: one known reversible owner and no Task-state change.
PLAN: bounded decision or review, no Product runtime write.
CHANGESET: one selected Task and coherent multi-file result.
WORK_GRAPH: independent owners can proceed in parallel and must converge.

Size a work slice by one accepted outcome and its proof, not a fixed file count. Complete the required caller/consumer changes and focused checks together. Do not pause for another approval merely because several files changed; finish the authorized slice without silently advancing to an unrelated Task.

ctc-work-graph coordinates work; it does not become the primary domain skill or authorize effects.

For an authorized parallel subagent lane, the integration owner keeps the selected Task as ACTIVE while work is in progress and records the exact writable paths; a read-only lane does not receive a Product write lease.

4.1 Model And Effort¶

Preserve the user's selected provider/model. Within its supported settings, use lower effort for obvious bounded edits, a middle setting for ordinary implementation, and higher effort for unresolved architecture, concurrency or difficult diagnosis. User-selected effort takes precedence. Check missing context, tools and acceptance criteria before escalating. Effort never replaces permission or proof. This is selection guidance, not automatic runtime configuration; do not claim a setting changed unless confirmed by the client/runtime, or install/remove a plugin or switch provider merely to follow it.

5. Work Loop¶

The common workflow is Plan -> Execute -> Verify. Exploration belongs to Plan; review belongs to Verify. These are work stages, independent of the delivery mode in Section 4 or a client's UI mode.

Plan¶

Read the request, root/scoped instructions, relevant documents and existing owner/caller path. Check the base revision and dirty paths before deciding what to change.
Define the observable outcome, non-goals, exact paths/effects, acceptance criteria and relevant edge/failure cases. Break complex work into independently verifiable outcomes, each paired with its checks and expected evidence. Reuse existing tests and commands.
For complex work, present the concrete scope, architectural choice/tradeoffs and verification plan for human judgment before implementation. Ask only for material decisions still unresolved or required authorization not already supplied. An explicit request or previously approved plan that settles those choices is sufficient; record its source instead of asking again. While a required decision is pending, keep that scope read-only and continue independent authorized work. A routine reversible fix needs only a short plan in the conversation, not a separate approval.

Execute¶

Implement the approved outcome and its required tests/docs in the existing owners. Preserve accepted flows and unrelated dirty work. Do not invent required fields, denials or prerequisites. Revisit only the affected plan decision when new evidence materially changes behavior, architecture, scope or effects; ordinary implementation details do not reopen approval.

Verify¶

Run focused checks and the agreed acceptance scenarios against the actual changed source. Select typecheck, lint, integration, browser and visual evidence by the affected behavior; do not run all layers for every edit. Use aggregate checks only for shared-owner integration, architecture acceptance or release. Fix in-scope failures and recheck their affected evidence.
Review the final owned diff against the outcome, edge cases, regressions and unintended effects. Label self-review honestly. Use an independent reviewer only when available and authorized; a second agent is not mandatory, and this workflow alone does not authorize delegation.
Report each acceptance criterion with its evidence and remaining limitations. Where human UX or business judgment is required, provide a concrete preview/result and mark that acceptance pending until received. Automated PASS is not human acceptance. Required acceptance and Git authority must be satisfied before merge; follow PROJECT_OPERATIONS for separately authorized delivery.

Task Prerequisites¶

A Task prerequisite requires a demonstrated screen/workflow dependency or a child-parent table relationship. Record the exact screen path or table relationship and the required capability; a relationship already supported by the current system does not require redeploying its Task. Task numbers, planned order, an earlier unfinished Task, and sharing a helper are not prerequisites. Shared-file/state serialization prevents concurrent edits; it does not impose Task delivery order. An actual defect or missing required code blocks that candidate on its own merits, without inventing a prerequisite on another Task's completion. Independent verified candidates may be delivered in any order within the user's authorization. Supersede older number-only delivery rules when encountered.

Review Coverage Before Approval¶

On the first review or deployment-readiness request, determine coverage before judging test results. In the existing Task evidence section (or the conversation for a read-only DIRECT check), map each acceptance criterion to the actual writer/reader and input branch, candidate identity, executed proof, and result. Inspect the test assertions and fixture setup; a test name, PASS count, matching hash, previous DONE, or clean existing-data audit does not establish coverage. Do not wait for the user to ask again before examining missing branches.

For changed persistence paths, check applicable create/update/delete or unlink paths, omitted versus explicitly cleared fields, previously stored data allowed by the old writer/schema, invalid parents, tenant boundaries, and failure atomicity. Derive expected behavior from the accepted contract; do not invent repairs or blanket gates. Run missing authorized checks before approving; unavailable required proof remains NOT_RUN/BLOCKED and prevents a readiness claim.

When Tasks share changed code, inspect each affected Task's relevant acceptance criteria and record one joint candidate verdict plus separate Task results. A shared file is neither evidence that the other Task passed nor a reason to repeat identical valid tests. A failed shared dependency blocks promotion of that candidate; preserve unaffected evidence and synchronize affected Task states. Before reporting ready, recheck the exact deliverable, required dependencies, evidence coverage and remaining failures. Reuse evidence only when its source, configuration, environment and covered behavior still match. Readiness never authorizes deployment.

For New-System work, read and follow Task Context And Handoff Standard before selecting/revising a Task. The executing agent selects the Task, records the request and acceptance checks, runs the applicable commands, and leaves the result in that Task; do not ask the user to apply this document or create parallel intent/spec/plan trees. A documentation link is not an automatically executed check.

On resume, recheck the current revision, owned diff and authoritative handoff before continuing. Keep the outcome/non-goals, next executable step, checks with source identity, and remaining permissions in the existing Task, or the current conversation for DIRECT work without a Task. Do not create a parallel status or handoff file. Reuse evidence only while its relevant source, configuration and environment remain unchanged; unknown or unavailable proof stays NOT_RUN or BLOCKED. Update an existing durable decision record when its decision changes instead of duplicating it in a new ADR.

Agent-Independent Execution¶

Repository AGENTS.md, scoped rules, canonical docs, the selected Task and versioned verification commands are the contract for Codex, Claude Code, OpenCode and Copilot. Client-specific instruction files remain thin pointers. If a client does not discover AGENTS/skills automatically, read those same files explicitly; do not copy policy into a second client-specific rule set. A client's Plan mode is optional: the read-only planning/approval boundary above still applies without it.

Choose installed tools when they improve the current work; MCP availability is not a prerequisite for understanding the repository. If a preferred graph, semantic tool or local skill loader is unavailable, use source search, direct file reads and the repository commands, stating the limitation. Never substitute a graph or generated explanation for source/runtime proof, or claim cross-client behavior was tested merely because these instructions and their links pass static checks.

Completion, Status And User Report¶

Complete the authorized acceptance criteria, not just an inventory, plan or checkpoint. Unfinished investigation is remaining work, not a blocker by itself. Continue the next executable step without waiting for the user to say "continue" again.
Before ending a turn, compare the result with every acceptance criterion of the current request. If an authorized, executable step remains, perform it; send a progress update instead of a final response. A command/suite finishing, writing a report, or reaching a substep is not Task completion.
End unfinished work only when the user explicitly stops/redirects it; all remaining paths depend on a demonstrated external blocker after independent work is exhausted; or an authorized handoff has an actual accepting executor. Name which condition applies. A hard runtime/tool limit may force a handoff: report that limit honestly and preserve the next step, never invent user approval or claim completion. Ordinary context compaction is not a stop condition.
A blocker must identify the exact missing permission, material user decision, unavailable resource or conflicting writer; the attempted resolution; and why no safe authorized alternative works. Do not repeat a failed action indefinitely: investigate or change approach. An unread diff, dirty checkout, unprepared candidate/fixture, test failure, or undesignated internal "integration owner" is not by itself an external blocker. Preparation and evidence reconciliation required by the assigned Task remain that executor's work within its authority; do not return them to the user as a request to name another worker. Respect genuine tool/provider and effect boundaries.
Keep Task status separate from check results. FAIL describes a check; it does not by itself end the request. Identify whether the failure is new or pre-existing, which acceptance criterion it blocks, and what work remains executable. Fix in-scope failures; record unrelated failures without expanding scope, and continue independent authorized work.
Task lifecycle uses BACKLOG -> IN_PROGRESS -> TEST_READY -> TESTING -> REVIEW_READY -> REVIEWING -> DONE -> COMMITED, with NEED_REPAIR as the repair-waiting branch. BACKLOG means queued; IN_PROGRESS means implementation/rework; TEST_READY means implementation complete and executor testing pending; TESTING means executor tests in progress; REVIEW_READY means required executor tests passed and Astra final review pending; REVIEWING means Astra final review in progress; DONE means all applicable tests and required final review passed, ready for authorized delivery; COMMITED means authorized deployment/delivery and its post-delivery checks actually completed. Preserve the user-selected spelling COMMITED. A local commit or push alone is not COMMITED. No-effect work remains DONE with delivery NOT_APPLICABLE; never fabricate a deployment.
Evidence results (PASS, FAIL, BLOCKED, NOT_RUN, NOT_APPLICABLE) are separate fields, not Task statuses. Do not use PARTIAL, READY, WAITING or BLOCKED as new lifecycle statuses. A confirmed defect requiring changes moves to NEED_REPAIR; actual repair starts at IN_PROGRESS. Record the defect, expected correction and next owner. Pending tests without an active executor return to TEST_READY; pending Astra review after required tests pass is REVIEW_READY. Record blocker, owner, next action and actual running/stopped condition separately. A stage value does not prove that an executor is currently running. Existing historical evidence and umbrella project states retain their meaning; do not falsify old executions to rename them.
One current status owner per Task. Use the location designated by the Task contract; if none is designated, use the Task header. Parent indexes and child documents must link to that owner instead of copying mutable statuses. For NS1-009 T001–T106, the single table in NS1-009.md owns the status and contains only Task, target and status columns. Do not add owner, next-action or result/evidence columns; keep evidence in the child Task.
Mandatory start update: after reading the Task and shared-writer boundaries, update only its canonical status entry: implementation IN_PROGRESS, executor tests TESTING, final review REVIEWING. Record executor, start time and next action there or in the detailed evidence, without duplicating the lifecycle value. Planning/assignment alone does not start execution.
Update the canonical entry whenever execution starts, review changes the verdict, handoff occurs, or work stops/completes. Record supporting evidence and remaining work in the detailed Task. Dated historical verdicts remain history; do not synchronize or rewrite them as current state.
Mandatory final readback: reopen the canonical entry and latest Task evidence; verify identifier, verdict, remaining scope, owner and running/stopped condition agree with the user report. Check reference links, not duplicate status copies. Add a missing canonical entry rather than another status table. Do not append evidence while leaving a contradictory canonical verdict unchanged.
An explicit no-file-write request or real concurrent-writer conflict is an exception: preserve the other writer's work and report the exact stale entry and pending owner. These rules do not authorize unrelated Product/Git/DB/runtime effects or abandonment of executable work.
Start the user report with "requested scope complete" or "incomplete", naming the scope. Then state the delivered result, remaining work and relevant verification. For incomplete work, state the exact reason, next action, responsible executor and whether it is running or stopped. If user action is required, say exactly what and why; otherwise say no user action is needed. Do not substitute a check list, tool statistics, token-saving slogans or a future offer for this conclusion.

6. Direct User Overrides¶

Record direct user authority and the exact overridden default in the current Task or DIRECT receipt. Reconcile stale Task ownership against the requested paths before editing; do not reintroduce a manifest, lease or Context Gate. This does not authorize broad globs or unrelated files, and never bypasses:

secret protection;
unauthorized external or Production effects;
destructive data loss without recovery;
an actual uncommitted concurrent writer: preserve that work and stop or narrow only the affected path;
false evidence or fabricated completion.

Do not ask for confirmation again when the current user message already authorizes the exact restriction or structural outcome.

7. Stop Or Narrow¶

Stop only the affected scope when a non-bypassable safety boundary, unknown destructive effect, conflicting writer or an applicable required check prevents the next action. A failed check stops promotion or dependent actions, not authorized diagnosis and repair. A proposed unrequested restriction becomes DECISION_REQUIRED and blocks only that proposal; the rest of the requested work continues.

Source: .agents/rules/AGENT_WORKFLOW.md — ctc repository · This page is an English translation of the source document.