Module trace 

The trace module: the work graph above the branch, both ways.

The canonical model reached as far as a branch — worktree::state::issue_of reads an issue id out of a branch name, and the topology gate enforces it. These three capabilities continue that one edge in both directions, deriving everything and storing nothing: an issue’s branches and commits come from git for-each-ref and git log, and a commit’s issue is the issue whose branches contain it.

The milestone is the one field here that git does not hold. It is not derived either: it is read from the canonical issue record through the index, which is where the project model already declares it, and it is the reason these handlers take a Context rather than a path.

Where the pull requests are

A pull request is a GitHub fact, and this executable makes no network call — test/cases/08_no_forbidden_constructs.sh is the proof, and the rule is the reason scripts/github-sync exists in scripts/ rather than in lib/. So the pull-request half of the same derivation is scripts/traceability, which reads pull requests with gh (or from a fixture), maps each head branch to an issue by this module’s rule, and joins the two answers. The seam between them is the branch name, which both sides read and neither side stores.

Why no command line

Every exposure of a capability is declared here, and the command line is the one projection that is declared twice — a cli exposure has to have a matching clap command in cli.rs, which capability::closure proves. These capabilities claim MCP and HTTP only; scripts/traceability reaches the git half over MCP, the way any other client would.

Structs

TraceCommitInput

One commit.

TraceIssueInput

One issue of the project model.

TraceReportInput

How much of the trunk to attribute.

Constants

TRACEABILITY_URI

The URI under which the whole traceability report is read as an MCP resource.

Functions

module

The trace module: the issue-to-commit edge, derived on every call.