gz status

Overview

gz status is read-only: it writes no ledger event and no file (status in src/gzkit/commands/status.py). After the Lane: line it prints:

• Workflow fronts — when data/active_campaign.json exists, the ## Workflow fronts section of the campaign its active key names, with that source path (_read_workflow_fronts). It is declared context: the command does not refresh the GHI queue, inspect handoff lineage or run research. A malformed registry, a campaign outside the project, or a missing or empty section prints Workflow fronts unavailable: <reason> and the run still exits 0. Without the registry the section is omitted.
• One entry per ADR in the ledger graph, semver ADRs in semver order, then pool ADRs: lane, gate projection, OBPI summary and rows, closeout readiness and blockers, lifecycle, and a TASK summary when tasks exist. An ADR whose linked OBPIs are not all complete reports Pending whatever its attestation or receipt events say.

--table prints one summary row per ADR; --show-gates adds the per-gate breakdown; --full keeps full IDs and renders every OBPI row; --json emits mode, adrs, pending_attestations and, with a registry, workflow_fronts; --epic <slug> keeps only pool ADRs of that epic (the ADRs are filtered, the front map is not). docs/user/manpages/status.md defines each field.

Tracked-defect GHI refs in this summary are never resolved live and render (unresolved); resolve one with gz adr status <ADR-ID>, gz obpi status <OBPI-ID>, or gh issue view. Exit 0 on success, 1 when the project is not initialized.

Operator ruling (verbatim canon)

Status covers handoff system, GHI triage, ADR/OBPI campaign, and new R&D. Read Workflow fronts in the campaign selected by data/active_campaign.json; use gz-status to report evidence, freshness or unknowns, and next actions. Focused inquiries include material dependencies. Handoffs preserve the map reference and session changes. The campaign owns the map; live sources establish progress. Campaign sequence, ascending feature-ADR order, and operator-only OBPI initiation govern execution.

Carried verbatim from root AGENTS.md § Operator Doctrine on 2026-09-17 (GHI #921); the corpus .gzkit/corpus/AGENTS.md.jsonl keeps the ruling's history.

Work order (operator ruling, verbatim canon)

• Work feature ADRs in ascending semver order: the lowest version with unlanded OBPIs is in flight. Do not work, author, or recommend a higher feature ADR ahead of it. The campaign selects work but cannot override that order. If campaign sequencing conflicts, semver governs; surface the conflict to the operator rather than silently resolving it. “One feature at a time” does not authorize swapping the order. An ADR in flight may be revised to take more OBPIs. The revision updates the document (an Intent amendment, a Decision item, a checklist item and the scorecard baseline) and the briefs table in the same change. A Validated ADR is not revised: scope missed from one enters the in-flight ADR as a repair assignment that cites the obligation it repairs. An item off the ADR's theme is labelled as such in the Intent amendment. The (m)ADR is a stopgap: a release-increment bucket, meant to be thematically cohesive. Its successor is a feature bundle between an enhancement proposal and a feature specification. Names are chosen later. This replaces the exception of 2026-09-29 (GHI #871), by which a correction to a Validated ADR took the next unallocated feature semver and could be worked ahead of the in-flight ADR; that route is retired (operator rulings 2026-10-04: 'the new loosening law here is we need to be able to revise an adr to allow for more obpis - the document and briefs table gets updated'; 'A, in-flight only'; the wording and the retirement, each 'A').

Carried verbatim from root AGENTS.md § Operator Doctrine on 2026-09-17 (GHI #921), and into this skill on 2026-09-24 (GHI #1091, sweep finding S06): the ruling governs authoring and recommending, not only working. The corpus .gzkit/corpus/AGENTS.md.jsonl keeps the ruling's history.

Workflow

1. Decide whether the inquiry is project-wide or focused on one ADR or OBPI. An ordinary "status?" is project-wide; the operator need not name every front.
2. Run uv run gz status (add --table for the ADR summary, --json to read fields). Read the workflow-fronts section it prints, or the workflow_fronts JSON field. That section is the campaign's declared map, not a live assessment of any front. If it reports the source unavailable, say so; do not infer that a front is healthy.
3. For project-wide status, consider every front the ruling above names: handoff system, GHI triage, ADR/OBPI campaign, and new R&D. The campaign section is the authority for what each front covers and which evidence to read. Typical sources: handoff lineage, rulings and observed resume behaviour (gz-session-handoff); current GitHub work orders (ghi-triage for a full ranked pass); campaign sequencing and the ledger-backed ADR/OBPI state from step 2; research records (gz-rnd). Date cached evidence and label anything not re-verified. Do not equate issue volume, an unresolved hypothesis, or declared context with ill health. Keep observed defects and actual blockers specific.
4. For a focused inquiry:
   • one ADR: uv run gz adr status <ADR-ID> (the gz-adr-status skill), which resolves tracked-defect GHIs live;
   • one OBPI: uv run gz obpi status <OBPI-ID> for its runtime, proof, attestation and anchor state and its issues. It does not report locks; uv run gz obpi lock check <OBPI-ID> does.
5. Give each front a concise state, evidence/date, and next action in a general answer. A focused answer covers its target and material cross-front dependencies. Campaign sequence and operator initiation govern execution; a status inquiry does not initiate OBPI work or promote an R&D question into a new ADR.

Example

# Project fronts and ADR summary
uv run gz status --table

# Machine-readable fronts, ADRs and pending attestations
uv run gz status --json

# Focused single-ADR and single-OBPI views
uv run gz adr status ADR-0.0.67-tool-skill-invariant1-enforcement
uv run gz obpi status OBPI-0.0.67-02-wire-orphan-verbs-into-skills