Dependency Trace

Dependency trace

Dependency trace is the leading word for finding the correct road from foundational contracts to higher behavior.

Procedure

Begin with this header:

Mode: dependency trace
Target: {behavior being worked toward}
Invariant: {what must never be false when it is complete}
Deliverable: {dependency graph and topological order}
Work state: analysis only

Completion criterion: the target, invariant, deliverable, and work state are written before any task or issue is ranked.

Start at the target behavior and list every fact, ownership relation, boundary, and shared contract it requires. For each requirement, follow the actual producer, writer, reader, caller, schema, or design document downward until reaching a leaf with no unresolved prerequisite.

Trace downward to discover the graph; present the finished order upward.

Completion criterion: every requirement of the target reaches an evidenced leaf, or is explicitly listed as unresolved.

Use this orientation:

A → B means B cannot be correct without A.

For every edge, write:

B depends on A because {specific correctness or acceptance consequence}.

Use repository evidence when the edge depends on existing code or documents. An issue number, existing implementation, or “ready” label is evidence of identity only; it is not evidence of dependency.

Completion criterion: every edge has a reason that names the bad state or missing behavior caused by omitting its prerequisite.

Label each node as one of:

• Design contract — the domain meaning or invariant that must be settled.
• Shared shape — the type, data ownership, or boundary that carries it.
• Lower functionality — the first behavior that makes the contract real.
• Higher functionality — behavior composed from lower functionality.

Resolve a shared design contract before functionality that assumes it.

Completion criterion: each node has one classification and its owner is named when the repository proves one.

Topologically order the graph from:

leaf design contract → shared shape → lower functionality → higher functionality

Independent branches may sit beside one another. Do not force a sequence between nodes that have no edge.

Completion criterion: the order contains every graph node exactly once, and every dependency points from an earlier node to a later node.

Create separate sections for:

• False foundations: paths that compile, demo, or already exist but leave an invalid domain state reachable.
• Not dependencies: work that may be convenient to do earlier but is not required for correctness.
• Unresolved: facts or design decisions that prevent a proven edge.

Treat issue IDs as labels attached after the graph is correct. They must not generate the graph.

Completion criterion: every proposed shortcut is either proved as a real edge, listed as incidental sequencing, or rejected as a false foundation.

Report the trace and stop. A dependency trace does not create issues, edit code, commit, or announce readiness to build. If implementation is explicitly requested in the same instruction, report the completed trace first and keep implementation as a separate phase.

Completion criterion: the final line states whether analysis is complete and whether implementation started.

Ordering guardrails

Call a change a dependency only when its absence makes a downstream result incorrect or prevents its acceptance criteria. “It makes later work easier” is not enough.

Output shape

## Dependency trace

Mode: dependency trace
Target: ...
Invariant: ...
Work state: analysis only

### Dependency edges

- A → B — B depends on A because ...

### Correctness order

1. ...
2. ...

### False foundations

- ...

### Not dependencies

- ...

### Unresolved

- ...

Analysis complete. Implementation started: no.

Completion criterion: a reader can verify the invariant, every edge, the leaf-to-higher order, and the stopping boundary without reconstructing the agent’s reasoning.

Example