Skip to content

CTC Work Graph Execution

  • Context and handoff: ../../new-system/docs/knowledge/TASK_CONTEXT_AND_HANDOFF_STANDARD.md

This file owns parallel orchestration. It does not own Product policy, Task scope, restrictions, Git or external effects.

1. When To Use It

Use LINEAR for one owner and one bounded outcome. Use WORK_GRAPH only when independent discovery, implementation or verification can run concurrently and an explicit fan-in is required.

Do not create a graph for ceremony, a small known edit, or merely because subagents are available.

2. Roles

COORDINATOR         scope, dependency and invalidation
DOMAIN OWNER        domain-specific decision or implementation
INTEGRATION WRITER  shared-file and final-source fan-in
VERIFIER            independent evidence
EFFECT OWNER        separately authorized external effect

Four sessions do not require four fixed role documents. Give each session only its current role, Task, base revision, read/write boundary, verification and stale-if condition.

3. User Direction Boundary

The graph preserves the current direct user request. Nodes may discover required work but cannot add AI_PROPOSED restrictions, architecture, packages, documentation or effects to the implementation path. An exact direct user request may be recorded as a guard override; the graph does not demand a second confirmation.

4. Parallelism

Allowed:

  • independent read-only source mapping;
  • independent evidence review;
  • non-overlapping implementation on the current shared checkout;
  • serialized handoff for overlapping files or mutable resources.

The checkout itself is not a writer lock. Independent exact file boundaries may proceed without waiting for other writers. Do not overwrite another writer's diff or claim it as your Task's work.

Each subagent writer lane must name its exact selected Task and writable paths before editing; a read-only lane remains parent-scoped.

Serialize edits to the same file, including shared authority, lockfiles, exports and UI owners. Serialize operations on the same DB fixture, browser session, service or other mutable resource, and Git staging, commit, merge and push. Different files or independent resources do not require a checkout-wide wait. Record reviewed external dirty paths in the selected Task doc; these paths are preservation-only, not additional write or delivery authority.

5. Node Contract

Each node receives only:

node/role
selected Task and base revision
objective and requested outcome
exact read paths
exact write paths or READ_ONLY
prohibited effects
required parent results
focused verification
stale-if

Each node returns only:

confirmed facts
changed paths or read-only findings
checks and evidence
unknowns/conflicts
downstream input

Do not fan in scratch reasoning, broad transcripts or separate progress documents.

6. Subagents

Subagents are read-only by default. Assign one question and a narrow source set. They do not create Tasks, change policy, commit, push, deploy or mutate DB/provider state. A write-capable subagent needs the same exact non-overlapping writer boundary as a main session.

7. Fan-In

  1. Freeze workers.
  2. Re-read the current base and shared owners.
  3. Reject stale or overlapping results.
  4. Integrate shared files through one writer.
  5. Run focused checks, then the Task's acceptance checks once.
  6. Run aggregate validation only when the integrated scope requires it.
  7. Perform one authorized Git/effect sequence and read it back.

Invalidate only descendants whose inputs changed. Do not restart independent passed work.

---

Source: .agents/rules/WORK_GRAPH.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.