Features

OpenGantry is a local CLI that scopes agent edits before they touch your repo. One verify contract for agentic graphs and IDE sessions — adapter rules differ, outcomes are always structured JSON. It is not Gantry.io and it does not chat on your behalf.

Workflow

How the pieces fit

Scan what is already there, turn findings into enforceable rules, legislate each change, then prove pass at every gate. Discovery proposes — blueprint, perimeter, missions, and verify enforce.

Discover

Scan the repo and collect file:line evidence — nothing becomes law yet.

The scanner writes `.gitagent/discovery-proposal.json` with concrete anchors (imports, patterns, layer hints). Review or accept before blueprint turns findings into enforceable rules.

  • Domain-aware scans: `gantry init --discover --domain code|content`
  • Evidence is proposals — hooks do not enforce until blueprint or manual acceptance
  • Agents use output to draft missions with realistic TMVC roots

          
          gantry init --discover --domain code
        
          
          gantry blueprint --domain code --yes
        

In practice

A day with OpenGantry

Composite scenes from how OpenGantry is used.

Staff engineer

The agent walked into a forbidden zone

I pinned MSN-0042 and let the session run. It tried to rewrite .gitagent/foreman/MANIFEST.json. Runtime failed closed. findings[] named the path. The next hop stayed in src/cli/.

gantry pin · TMVC deny

Tech lead

Verify is not the same pass that edited

I will not rubber-stamp a chat transcript. The executor appends PASS rows to EXECUTOR_LOG.md. Those rows have to quote the gate output. gantry verify maps every claim. A missing quote fails the mission.

SOD · verbatim PASS quotes

Docs lead

Release notes do not ship on vibes

The content adapter scopes src/content/. The agent drafted a changelog that sounded fine and failed the docs build. That build is the gate_command. Nothing publishes until verify is green.

content domain · docs build gate

Security lead

The PR has a receipt, not a promise

Review is a mission YAML, a quote in EXECUTOR_LOG.md, and an optional attest file under .gitagent/history/receipts/. I keep the verify JSON. I do not keep a screenshot of a model saying it was careful.

attest receipt · verify JSON

A Tuesday

~/your-repo · tuesday
$ gantry legislate "ship ingest retry" --msn MSN-0042 --skill-key gantry
$ gantry pin .gitagent/missions/MSN-0042.ship-ingest-retry.yaml
$ eval "$(gantry runtime env)"
TMVC deny .gitagent/foreman/MANIFEST.json
retry inside src/cli/, then:
$ gantry verify --json
{"ok": true,"trace": "mapped"}
gate: perimeter · trace: mapped

Domains

Pluggable domain adapters

One verify graph. Pluggable rules. Built-in code and content adapters ship today; CI, security, infra, API contracts, and other stacks hang on the same mission YAML plus gate_command — scope, trace, and structured pass/fail never change.

Block architectural drift before it merges

Agents shortcut through private modules, smuggle forbidden SDKs into core layers, and widen public surface area you never approved. The built-in code adapter turns your repo graph into binary perimeter rules — `gantry arch check` fails closed with offending_file, line, and resolution_hint.

  • Forbid `src/cli/**` from importing `src/server/internal/**`
  • Block `@aws-sdk/*` outside your infrastructure layer
  • Pin a mission to `src/features/checkout/**` — nothing else moves

Verify

Fail closed with structured findings

Pass or fail, you get machine-readable output instead of log scraping. Agents can retry against findings[] without dumping broken code into your lap.

{
  "status": "passed",
  "envelope_schema_version": 3,
  "phase": "full",
  "msn_id": "MSN-0042",
  "mission_file_path": ".gitagent/missions/MSN-0042.ship-feature.yaml"
}

How to read this

gantry report overview with last verify, local ring breakdown, and verify history table
After verify: see last outcome, ring health, and every recent run — click through to findings without re-running gates.
FAIL drill-down with status panel, findings, and phase durations
FAIL — file, rule, and resolution hint in one card; gate log one tab away.
ABORT badge with highlighted digest-ring slot for GXT_FINDINGS_RECURRED
ABORT — same finding recurred; escalate to Planner instead of another repair loop.
PASS drill-down with status panel and phase durations
PASS — confirm gates and trace before you push; phase bars show where time went.

          
          gantry report
        
          
          gantry report --last
        
          
          gantry report --json
        

Evidence

Hybrid hub and spoke

Execution stays on your machine (the spoke): missions, TMVC, cages, and gantry verify run locally with no cloud required. An optional future hub aggregates digest-only metadata — receipts and policy hashes, never source trees or gate stdout bodies.

Orchestration bus

Cold-path `gantry::verify` and hot-path `gantry::middleware` on buses like iii.dev — multi-worker graphs with promote-class gates. See `examples/iii-integration/` on GitHub.

Mission pin

`gantry pin [file]`, `gantry unpin` — active scope without stale branch drift.

Hash-only telemetry

`flight_telemetry.body_mode: hash_only` in `.gitagent/config.json` (default).

Attestation receipts

`gantry attest`, `gantry verify --receipt` — digest-only outcomes under `.gitagent/history/receipts/`.

Policy digest drift

`gantry doctor --policy <expected-digests.json>` offline against MANIFEST and config digests.

Audit trail detail Receipts, attestation, and review artifacts for compliance narratives.

Advisory performance judge

Deterministic gates cannot read your performance intent from docs. Ship PERFORMANCE.md + PERFORMANCE_RUBRIC.md, wire a BYO llm_verifiers command, run gantry scan, then gantry verify.

The judge checks structural strategies only — pooling, non-blocking I/O, memoization — never guessed millisecond latency. Verdicts are advisory: they appear as warnings and structured findings[] on PASS and never flip a failing gate to PASS.

See the performance judge example on GitHub. MCP tools (gxt_draft_legislation, gxt_verify, gxt_pin_mission) work with any MCP-capable harness — see the integration guide.