G04 / Govern
Quality and operations
Run release checks and operations without losing control: computed quality verdicts, approved runbooks, dry-runs, and hard safety rails.Page evidence and guidance
Use this page when Development has passed but you still need release confidence or production discipline. Quality computes a release-readiness verdict from project evidence. Operations runs approved runbooks with dry-runs, hard rails, and recorded human decisions.
Both phases are opt-in. Guild Stack never auto-enters Quality or Operations, but it surfaces them as the proposed next phase when their preconditions exist so release readiness and production work are not silently skipped.
Try it: /guild:qa after a passing Development verify, then /guild:ops release when you are ready to run a release-class runbook.
- Discover checksproject signals
- Quality verdictready or block
- Dry runblast radius + rollback
- Approvalhard safety gate
- Release recordrunbook evidence
No set-and-forget operations
Destructive, network, spend, incident, rollback, and production-sensitive actions remain human-gated. Guild Stack can prepare the runbook path and record the decision; it does not replace release ownership.
Quality matrix
Quality runs four stations: signal scan, matrix selection, harness execution, and release verdict. The check classes are a closed set, and each class records why it ran, did not run, or could not prove the answer.
| Check class | Signals that can select it | Audit asks | Possible class state |
|---|---|---|---|
| E2E | User journeys, route changes, acceptance criteria, workflow changes. | Did the selected end-to-end harness run, or is the gap owner-accepted? | selected, not_applicable, gap, inconclusive. |
| Smoke | Entry points, command surfaces, install/start paths. | Did the smallest release sanity path complete? | selected, not_applicable, gap, inconclusive. |
| Accessibility | UI entrypoints, docs pages, interaction changes. | Was an accessibility harness present and run when applicable? | selected, not_applicable, gap, inconclusive. |
| Performance | SLO mentions, hot paths, runtime-sensitive changes. | Was performance risk checked or explicitly accepted? | selected, not_applicable, gap, inconclusive. |
| Integration | Service boundaries, adapters, external interfaces, repo edges. | Did integration coverage match the changed boundary? | selected, not_applicable, gap, inconclusive. |
The release recommendation is computed. It is BLOCK if a selected class fails, if an inconclusive result has no owner-accepted risk, or if a security/privacy/reliability-relevant gap has no owner-accepted risk. Otherwise it is RELEASE-READY. A BLOCK can be forced to release only by a named human with a recorded rationale.
Runbook record panels
Operations starts after the runbook class is selected and confirmed. The record is not a decorative checklist; it is the proof that the runbook path, dry-run, and rails were handled.
| Panel | Artifact | What it proves |
|---|---|---|
| Quality report | .guild/runs/<run-id>/quality/<run-id>.md | The guild.quality.v1 release-readiness verdict, selected classes, harness evidence, gaps, and owner-accepted risks. |
| Operations record | .guild/runs/<run-id>/ops/<run-id>.md | The guild.ops.v1 runbook class, approval posture, dry-run fact, hard-rail checks, and execution result. |
| Release evidence | .guild/runs/<run-id>/ops/ outputs | The guild.release.v1, incident, rollback, monitoring, or maintenance evidence produced by the runbook. |
| Review trails | .guild/runs/<run-id>/review/quality/* and .guild/runs/<run-id>/review/ops/* | Whether G-quality and G-operations used cross-host review, weak review, skipped review, or a human decision. |
For power users: a release gate you can inspect
The selection matrix is deterministic and visible before any harness runs. Guild Stack derives it from on-disk signals such as the CodebaseMap, plan, UI entrypoints, service boundaries, SLO mentions, and discovered test directories. You get the surfaced choices [proceed], [edit-selection], and [explain-signals]. There is no hidden --classes= shortcut; edits are recorded as user overrides.
Checks run only harnesses your project already has. Guild Stack does not install or author a test framework during the Quality phase. If the budget runs out, the affected class becomes inconclusive: budget exhausted; it is never treated as a silent pass.
| Per-class result | Meaning |
|---|---|
pass | The selected harness completed successfully. |
fail | The selected harness failed. |
inconclusive | Execution could not produce a decisive result. |
not_applicable | The class did not apply, with reason. |
gap | The class applied, but no harness was discovered. |
The qa auto-approve token is PASS-only
--auto-approve=qa and --auto-approve=all can clear a computed
RELEASE-READY verdict. A BLOCK-to-release override is never
auto-passed under any token. There is no ops auto-approve token.
For beginner users: the safe path
Run /guild:qa after Development has produced handoff receipts and a passing verify.md. If that upstream evidence is missing, Guild routes you back to Development unless you explicitly record an operator decision to proceed without it.
If Quality returns RELEASE-READY, you can move to /guild:ops release. If it returns BLOCK, fix the issue, accept the risk with a named owner, or stop the release. The important part is that the choice is recorded under .guild/, so a future reviewer can see why the release moved or stopped.
For harness developers: the phase contracts
Quality is a lifecycle phase, not the same thing as guild:verify-done. verify-done gates the run against the spec and receipts. Quality gates release readiness against a broader product and runtime surface. A run can pass verify-done and still be blocked by Quality.
Quality writes:
| Artifact | Path | Contract |
|---|---|---|
| Quality report | .guild/runs/<run-id>/quality/<run-id>.md | guild.quality.v1 |
| Harness evidence | .guild/runs/<run-id>/quality/evidence/* | Per-class evidence |
| Review trail | .guild/runs/<run-id>/review/quality/* | G-quality broker trail |
G-quality has two mechanisms that both remain in the model: an advisory qa-test-strategy report challenged by security and architect reviewers, and a policy-gated cross-host guild-review-broker call when review policy requires it. Cross-host review is the stronger posture; same-host or skipped review is recorded as weaker.
Operations: runbooks with rails
/guild:ops [runbook] selects one of five runbook classes. You can name the class positionally or let Guild detect it; detected classes are surfaced and confirmed before execution.
| Runbook class | Default approval posture |
|---|---|
release | First/unproven run is interactive; approved unchanged runbooks may run without repeated approval. |
monitoring | May run without repeated approval after approval when blast radius is low. |
incident | Interactive always. |
rollback | Interactive always. |
maintenance | May run without repeated approval after approval; interactive if it touches data or secrets. |
The runbook trust root is the wiki: .guild/wiki/standards/runbooks/<name>.md, promoted through guild:decisions. Operations executes runbooks. The devops-* specialists author or update runbook content.
Four rails are non-negotiable:
- An unproven runbook is always interactive.
incidentandrollbackare always interactive.- Destructive, network, and spend actions always prompt inline, even inside an approved runbook.
- A pre-flight dry-run is mandatory, and
op_class_allowlistmay not contain a hard-set class.
Rail 4 records two machine-checkable facts in guild.ops.v1: the dry-run ran, and no hard-set class appeared in the allow-list. A hard-set class in the allow-list fails plan validation rather than waiting until execution.
How Operations consumes Quality
For release and rollback, a Quality BLOCK without a recorded human force-pass refuses the runbook and routes you back. monitoring, maintenance, and incident may still proceed because operational response can be necessary even when release readiness is blocked.
Operations writes:
| Artifact | Path | Contract |
|---|---|---|
| Ops record | .guild/runs/<run-id>/ops/<run-id>.md | guild.ops.v1 |
| Release evidence | Under the run’s ops/ outputs | guild.release.v1 |
| Incident or rollback evidence | Under the run’s ops/ outputs | guild.incident.v1 |
| Review trail | .guild/runs/<run-id>/review/ops/* | G-operations broker trail |
Operations supplies release evidence to the D8 initiative close gate. It does not close the initiative itself. D8 still has three separate legs: execution verified, release readiness resolved, and documentation sync resolved.
Source anchors
This page is anchored to docs/v2/lifecycle.md for the six-phase lifecycle, Quality/Operations phase contracts, auto-approve asymmetry, and D8 relationship; to docs/v2/architecture/modules/quality.md for the shipped Quality skill and guild.quality.v1 behavior; and to docs/v2/architecture/modules/operations.md for the shipped runbook taxonomy, safety rails, and guild.ops.v1 / guild.release.v1 boundaries.
See also
- Security - the always-ask hard set in full.
- Adversarial Review - G-quality and G-operations review posture.
- Initiatives - the D8 close gate.
- Command Reference -
/guild:qa,/guild:ops, and global flags. - Observability - run traces and evidence records.
