mathias
d6e892ac4c
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