The matrix section still claimed PR-005 "has no software row at all" and could
be verified only by prohibition. jRay's register has carried four rows against
it since the schema-v2 landing: JR-038 (Done), JR-034 and JR-039 (both High,
both T1, both still Planned), and JR-040 (T4). jRay is the component that
actually performs egress, so that is where the goal became verifiable rather
than merely preserved.
Three of the four are untagged in the matrix. That is unbuilt work, not a
broken chain, and saying so here keeps the rollup from reading as an
inconsistency. The structural guarantees still hold PR-005 from the other
side; nothing about SR-004 or GR-005 changes.
jRay/SPEC.md already stated this in the past tense. The vendored copy under
jRay/scripts/vendor/jray-project is a nested checkout of this repo, so it
follows on the next vendor bump rather than needing its own edit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TRACES: JR-034, JR-039 | PR-005
Commits that implement, change, or withdraw a requirement carry a TRACES
trailer using the same token and syntax as the code tags, so one grep pattern
serves both.
This is the last link. Code tags say where a requirement lives; commit trailers
say when and why it changed, and `git log --grep=AR-012` then reconstructs a
requirement's whole history — which no other artifact provides.
A commit serving no requirement omits the trailer: absence is meaningful, and
inventing a tag to satisfy the form is how orphan tags get created. Withdrawing
a requirement counts as changing it, so the withdrawal stays findable.
Also updates the chain diagram, which still referenced the retired @implements
tag and the thematic A1..E8 IDs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gives the system specification an owner. It defines the PR-nnn project
requirements and SR-nnn cross-component contracts that every component spec
traces up to, and until now it lived in no repository at all.
The three component repositories are linked from the README and gitignored
here rather than added as submodules. A submodule pins a commit, so with
feature branches and worktrees in flight across the components, every
component commit would leave this repository's pointer stale. The dependency
is meant to run the other way: components pull this repository in for the
shared tooling and system spec, both of which change rarely.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dtourolleandClaude Opus 5