Requirements
The system SHALL represent changes and requirements as first-class traceable items.
The system SHALL connect each change to the requirements it addresses.
The system SHALL preserve domain and specification decisions as durable items recorded by the change that made them.
The system SHALL keep execution tasks as temporary Markdown under tspec/, never as durable graph items.
WHEN an approved requirement’s meaning must change, the system SHALL supersede it with a new requirement and SHALL NOT edit it in place. A non-semantic fix such as a typo MAY be edited in place.
The system SHALL let a change reach the accepted state only on a human’s instruction, and validation SHALL enforce the transition.
The system SHALL resolve each roleGuidance.<role>.page value to the guidance file that exists under docs/modules/specs/pages/.
The change guidance page SHALL declare its item fields as an Item template block with the labeled-list fields Rationale, Outcome, and Out-of-scope.
The decision guidance page SHALL declare its item fields as an Item template block with the labeled-list fields Context, Decision, and Consequences.
The system SHALL verify that each requirement addressed by a change is satisfied by the implementation before the change reaches closed.
The system SHALL NOT advance a change to closed when any requirement the change addresses is not satisfied.
The archive conformance verification SHALL be read-only and SHALL NOT alter any durable item.
The decision guidance page SHALL declare an Item template whose labeled-list fields are Context, Options (each alternative with its advantages and disadvantages), Decision, Rationale (why the chosen option won), and Consequences.
The system SHALL let a project associate an issue tracker with the workflow, or none, defaulting to none.
The system SHALL record the identifier of the tracker issue associated with a change.
WHEN a change is proposed and a tracker is configured, the system SHALL create or link the tracker issue and record its identifier on the change item.
WHEN a change already exists in the configured tracker, the system SHALL import it as a change with its requirements, recording the tracker identifier on the change item.
The system SHALL keep the linked tracker issue’s status in step with the change’s lifecycle.
IF the linked tracker issue changes state, THEN the system SHALL NOT change the corresponding change’s state.
The system SHALL record each proposed requirement as observable behaviour, with any mechanism it names recorded as a decision instead.
The system SHALL document the tracer-spec init command and the antora-tracer validate invocation in the Antora site, covering every flag, option, and argument.
tracer:links[]
The system SHALL document every workflow skill — explore, propose, apply, archive, validate, write-item, and track — in the site, both as a task-oriented how-to and as an exhaustive reference entry naming each skill’s trigger, arguments, subcommands, and configuration.
tracer:links[]
The system SHALL organise every site page into exactly one Diátaxis mode — tutorial, how-to, reference, explanation, or self-traceability — with the tutorial linking out to no other mode.
tracer:links[]
The system SHALL list all seven workflow skills, including tspec-track, in the README wherever the skill set is enumerated.
tracer:links[]