Operational route

Release readiness

Move from a verified run to product-level checks, release recommendation, runbook dry-run, rollback path, and explicit approvals.

Page evidence

Operational mapTask done and release ready stay separate.
  1. Discover checksproject signals
  2. Quality verdictready or block
  3. Dry runblast radius + rollback
  4. Approvalhard safety gate
  5. Release recordrunbook evidence
/guild:qa && /guild:ops release

Route comparison

Same job. A visible operating record.

Without a route record

A run can pass its task gate while release risk, dry-run posture, rollback, and operations approvals stay blurred.

With Guild Stack

Quality computes release readiness from evidence, then Operations runs approved runbooks under explicit safety rails.

Route stops

Request to verified result.

  1. 01

    Select checks

    Quality derives applicable check classes from project signals and surfaces the matrix.

  2. 02

    Compute verdict

    Release-ready or block is computed from evidence, not guessed by a model.

  3. 03

    Dry run first

    Operations prints steps, blast radius, and rollback path before execution.

  4. 04

    Keep hard gates

    Incident, rollback, destructive, network, spend, and production-sensitive actions still ask.

Receipts

What the route leaves behind.

  1. 01
    Path .guild/runs/<run-id>/quality/
    Role

    Release-readiness matrix and verdict.

  2. 02
    Path .guild/runs/<run-id>/ops/
    Role

    Runbook record, dry-run posture, and safety evidence.

  3. 03
    Path review/G-quality/
    Role

    Quality review packet and result.

  4. 04
    Path review/G-operations/
    Role

    Operations review packet and result.

Next

Follow this route through an illustrative run.

The demo traces one bounded task through approvals, specialist lanes, review, verification, and the final run record.