Quality gates and traceability

Quality gates help decide whether a product state is ready to ship. A gate verdict is computed from spec coverage, test results, component risk, freshness, and production issues when available.

Scopes

Quality gates can evaluate:

Scope	What it means
Main	Current canonical product repository
Branch	A merge-preview projection of a branch
Release	A specific release version: its stored capture (see Release captures)

Verdicts

Verdict states include:

• Pass: the gate is clear.
• Blocked: at least one hard gate failed.
• Risk accepted: a soft signal was explicitly accepted.

A release can also be pending: it has no capture yet because the test results of its build are not in. See Release captures.

Release captures

A release's verdict is a capture: Tiden evaluates the gate for the release and stores the result, so later changes on main do not move it.

• From the build SHA. When the release was announced with a build SHA (the commit it was built from), the capture uses only the test results reported for that commit. A run of any branch counts if it tested that commit. A test with no result on that commit counts as not run.
• From main. Without a build SHA, the capture copies the main verdict as it is at that moment.

Pending. A release with a build SHA shows as pending while Tiden waits for that commit's results: no run for the commit has reported yet, or a run for it is still open or still being synced into Tiden. A run whose sync failed counts as not finished until the sync is retried. Tiden captures the gate as soon as the runs finish. A release that waits for a new build SHA keeps showing its earlier capture until then. tiden gate check --release exits with code 3 while the release is pending.

Capturing again. A release keeps every capture, and the newest one is current. Repeating an announce with the same build SHA, or with none, does not change the gate. An announce with a new build SHA captures from that commit once its runs finish. tiden release capture takes a new capture on request; see Capture the gate again.

Risk is accepted on a branch, before it merges. A release's captured verdict cannot be risk-accepted afterwards.

Component breakdown

Verdicts are grouped by component. Component results can include:

• Coverage failures.
• Pass-rate failures.
• Residual risk.
• Open production issues.
• Fix hints.

Use the component breakdown to decide whether the next action is to add tests, fix failures, accept risk, or investigate production issues.

Planned specs

Specs in Backlog or Review are planned work. The gate does not count them as missing tests, and it shows how many planned specs it left out. Tests linked to a planned spec still count, so a failing one still fails the gate. See Spec statuses.

Parent specs

A parent spec, such as a Feature with stories under it, often has no tests linked to it directly. Its stories carry the tests. Tiden then reads the parent's coverage from its child specs.

Take a Feature "Calendar events" with two stories. Each story has one linked test, and both tests pass. The Feature shows as covered, with the note "Covered through 2 of 2 child specs". The Quality Gate on main does not block on the Feature.

If one of the two stories has no test, the Feature shows as partly covered ("1 of 2 child specs"), and the gate blocks on that story. It does not block on the Feature as well, so one gap is reported once, on the spec that needs the test.

• A parent with its own tests. Its own tests decide. Child specs do not change its result.
• Nested parents. A parent with no tests of its own, under another parent with none, reads from the specs at the bottom of the tree.
• Planned child specs. A child spec in Backlog or Review with no test does not count against its parent while the planned-spec rule is on for the product. See Planned specs.
• Branches and sessions. On a branch, and in the progress check of an intent session, a parent is judged by its child specs. When all the child specs that still need tests are part of that check, the gate asks for the tests on those child specs. When some of them are not part of the check, the parent shows as not verified and names the child specs that still need tests.

Where you see it:

• The spec tree in the web app shows a rolled-up parent with a "↳ 2/2" mark. Hover over the mark to read "Covered through 2 of 2 child specs".
• tiden coverage-gaps and tiden trace print covered ↳ 2/2 child. See CLI.
• The --format json output of the CLI carries the same information in viaChildren, childSpecs, and childSpecsCovered. Session progress rows carry childrenCarry. Coverage in feature context carries viaChildrenIds.

Traceability matrix

Traceability groups specs by component and shows related test cases. Spec coverage values include:

• verified: linked tests support the spec.
• not_run: linked tests exist but execution state is missing or stale.
• no_test: no linked test coverage exists.

A parent spec with no tests of its own takes its value from its child specs. See Parent specs.

CLI gate checks

Check current main:

tiden gate check --product-id <product-id>

Check a release:

tiden gate check --product-id <product-id> --release <release-id>

The CLI exits with code 3 when a verdict is blocked, not verified, or still needs a risk acceptance, and when a release is pending.