Forward trace: requirement → decision → commit → gate → verification → CI on
that sha → release → closure. The distinction the skill exists for is that each
link is either checked or named as unchecked; a trace where every link is
asserted is a narrative, and narratives are what audits exist to defeat.
`trace.sh` does the mechanical part — commit, files, test files touched, release
containing it, referenced issues as URLs — and then always prints the four things
git cannot prove. The GREEN run's own accounting: "the tool did the mechanical
15%. Its real contribution is the 'Cannot verify from here' block, which is a
checklist, not an output." Kept, because it is true.
The RED run established the shape by tracing a commit by hand in sixteen steps.
Its decisive moves were reading issue COMMENTS — where the decisions actually
live — and running a probe that falsified a claim. Both are now steps.
The GREEN run then used step 5 against a gate I shipped this morning, and broke
it. It also found four things wrong with what I had written:
- The slug sed used `[^/]+?` expecting a lazy quantifier. POSIX ERE has none, so
`.git` was swallowed and every emitted evidence URL carried the suffix. It
happened to work against Gitea and would 404 on GitHub — a bad failure for the
one tool whose pitch is that an unchecked link must not look checked.
- "Prints every issue it references" was overclaimed: it greps the commit body,
so it structurally cannot find the issue that cites the COMMIT. That is the
commoner break — the issue filed afterwards that falsifies the outcome — and
it is now step 6 with the two searches that find it.
- Step 3 told you to check which job passed, and the estate's own
`workflow_run_status` returns no jobs. A step whose tooling dead-ends is where
a trace becomes "the run was green"; the REST fallback is now written out.
- The output format did not survive contact. It grew four slots, each forced by
a real trace: two requirements differing in kind (a defect report and a
standing bar), the gate as an artifact separate from the test, the RED/GREEN
baseline against the parent, and the commit's factual claims checked. Without
the last one, "commit → verified" means only "this sha exists".
Also: `git describe --contains` reads local tags, so the tool now says so on
every hit rather than only when it finds nothing.
Closes#10
Bump-Type: minor
