Explicit Preconditions with Gate Markers
Mark a workflow precondition clearly and tie its exit to observable evidence.
These examples and illustrative results are independently authored teaching materials, not measured model results.
Use case
A release candidate is ready, but review must cover the current version before submission. The teaching candidate label is build-b; the approval record covers only build-a. Replace these labels with real commit SHAs in an actual project. The fixture explains the check without performing a release.
Mechanism
Place the prerequisite and its evidence together in a visible block. Identify the action and candidate, then inspect the approval’s object, revision and scope. Proceed only when they match. For missing, stale or mismatched approval, deliver the candidate report and stop before the action. Cite existing valid approval instead of requesting it again.
Bad example
The candidate is build-b and the approval record covers build-a. Important: make sure review happened before releasing, then submit the candidate.
Good example
The candidate is build-b; existing approval covers only build-a.
<HARD-GATE>Before release submission, check the candidate version and action against the recorded approval. Proceed only if it covers this candidate and submission. For missing, stale or out-of-scope approval, show the candidate report and wait for the relevant decision. Do not submit the current fixture. Do not repeat a request already covered by valid approval.</HARD-GATE>
Replace teaching labels with real commit SHAs and retain the approval record's location.
Why the change matters
Reviewed does not identify which candidate was reviewed, allowing an old approval to be borrowed for a new revision. Matching version and scope explains the proceed/stop decision. The tag makes the rule easier to find; the record supplies the evidence.
Observable expectation
For this fixture, an illustrative response says build-b is not covered by the build-a approval, the candidate is prepared and no submission occurred. With a valid record covering build-b and submission, cite it and proceed without asking again.
Inspect execution records for matching evidence. Submitting a mismatched candidate fails the prerequisite.
Limits
A visible tag is not a tool permission or server access control. Consequential systems still require their own enforcement. Approval scope can differ by action; real SHAs, expiry and approval rules follow the project’s contract.