The launch-readiness control room for AI-native teams.
Gantry turns any project folder into a launch operating room. AI agents maintain a
structured .gantry/ vault; humans get a plain-language dashboard that answers one
question: "Are we ready to launch?"
Product launches are coordinated across scattered markdown notes, QA checklists, app store metadata, issue trackers, telemetry, and chat threads. AI coding assistants can help maintain all of it — but they need predictable files, schemas, and a way to understand launch state without guessing.
Gantry is a local-first desktop app (Tauri + Rust) with two equal interfaces over one source of truth:
- AI interface — a structured
.gantry/vault of markdown + YAML frontmatter + JSON, governed by a file contract (AGENTS.md), JSON schemas, a generatedindex.json, and a CLI with stable exit codes for CI. - Human interface — a desktop dashboard that translates raw launch files, code changes, and telemetry into a plain-language Go / At Risk / No-Go readiness view, complete with a live timeline of recent commits and Git-attributed activity.
Everything lives in your repo. It stays readable in any editor and portable through Git. No proprietary cloud account required.
- Verification over vibes. Every readiness indicator traces back to files, checklist state, source changes, or integration data.
- Accepted risk is explicit. Waivers are stored in the repo with approvers, reasons, and expiry dates; they never disappear from the launch record.
- Evidence is portable. CI runs, test reports, telemetry pulls, approvals, and artifacts can be attached as structured local evidence records.
- AI-native, not AI-only. Agents are first-class collaborators; the workspace stays clear to non-technical humans.
- Plain language. "A critical issue is still open" instead of "P0 blocker unresolved."
- Git-integrated attribution. Toggling checklist items or gates automatically writes
a signature comment (e.g.,
<!-- @owner YYYY-MM-DD by:@author -->) directly into the markdown source, attributing changes using your localgit configto maintain an offline audit trail. - CI-ready.
gantry validate --cireturns0(Go),1(blocked), or2(configuration error) so launches can be gated in any pipeline.
| Feature | Gantry 🚀 | Linear / Jira | Custom CI Scripts | Notion / Wiki |
|---|---|---|---|---|
| Source of Truth | In-repo, Git-tracked .gantry/ |
Centralized Cloud Database | Custom CI Configs / Logs | Cloud Workspace Docs |
| AI Agent-Native | Yes (schemas, JSON/YAML, stable API) | No (complex HTTP APIs, lacks context) | No (structured stdout parsing only) | No (unstructured page editing) |
| Change Attribution | Git-Native (uses local git config & git log) |
Centralized account logs | CI run trigger account | Browser edit history (unstructured) |
| Human Interface | Local Desktop Dashboard | Heavy Web Interface | CLI Logs only | Document editor |
| CI/CD Gateable | Yes (gantry validate --ci) |
Hard (requires webhooks + custom logic) | Yes (requires script maintenance) | No |
| Out-of-sync risk | Zero (lives inside your git branch) | High (issues aren't tied to branch state) | Medium (scripts get out of sync) | Extreme (manually maintained) |
Download a prebuilt binary from Releases
(gantry-macos-aarch64, gantry-linux-x86_64, gantry-windows-x86_64.exe), put it on
your PATH, and you're done.
Or install the CLI directly via Cargo:
cargo install --git https://github.com/trygantry/gantry gantry-cliOr build from source (requires Rust stable):
git clone https://github.com/trygantry/gantry.git
cd gantry
cargo build --release -p gantry-cli
# binary is at target/release/gantryDesktop app — download the installer from Releases or build with:
npm install && npm run tauri buildFor a detailed walkthrough, see the Getting Started Guide.
Gantry detects your tech stack and creates a starter .gantry/ vault:
gantry init --autoGate releases — exits 0 only when all launch checks pass:
gantry validate --ciThe desktop app reads the .gantry/ vault from your current working directory, so
launch it from inside your project:
# From within your project folder:
cd ~/your-project
open /Applications/Gantry.app # packaged install
# Or run in dev mode from within the Gantry source tree:
npm install && npm run tauri devOr drive the CLI directly during development:
npm run gantry:summarize
npm run gantry:validate| Command | Purpose | Exit codes |
|---|---|---|
gantry init --auto [--dry-run] [--json] [--force] |
Automatically detect stack and initialize starter .gantry/ vault |
0 / 2 |
gantry validate [--ci] [--report-url <url>] [--env <name>] |
Validate docs, schemas, links, freshness, and gates | 0 Go · 1 blocked · 2 error |
gantry impact [--base <ref>] [--json] |
Show summary of modified files and impact on blockers/QA | 0 / 2 |
gantry index [--env <name>] |
Rebuild .gantry/index.json and persist snapshot state |
0 / 2 |
gantry summarize [--env <name>] |
Print a plain-language launch summary | 0 / 2 |
gantry audit [--dry-run] [--json] [--format markdown] [--output <path>] [--env <name>] |
Score readiness, generate repair tasks, or output PR markdown reports | 0 / 2 |
gantry diff <base>..<head> [--json] |
Compare two readiness snapshots by commit refs | 0 / 2 |
gantry notify [--dry-run] |
Build/send Slack digest for the latest snapshot transition | 0 / 2 |
gantry telemetry pull [--env <name>] |
Pull Sentry crash-free telemetry into .gantry/observed.json |
0 / 2 |
gantry mcp |
Launch Gantry's stdio read-only Model Context Protocol (MCP) server | 0 / 2 |
gantry tasks [--json] |
List pending repair tasks | 0 / 2 |
gantry task complete <id> / gantry task ignore <id> <reason> |
Update a repair task | 0 / 2 |
gantry waiver list [--json] |
List accepted-risk waivers | 0 / 2 |
gantry waiver add --target-type <type> --reason <reason> --approved-by <name> --expires-at <date> [...] |
Add a time-bounded risk waiver | 0 / 2 |
gantry waiver expire <id> |
Expire an active waiver | 0 / 2 |
gantry evidence add --kind <kind> --title <title> [...] |
Attach a structured evidence record | 0 / 2 |
gantry release manifest [--json] |
Show the generated release manifest for the active release | 0 / 2 |
gantry release history [--json] |
List generated release manifests | 0 / 2 |
gantry trends [--json] |
Summarize readiness trends from local snapshots | 0 / 2 |
Use Gantry's first-party composite GitHub Action (.github/actions/gantry-validate) to block a release when it isn't ready and post launch-readiness comments on pull requests:
# .github/workflows/launch-gate.yml
name: Launch Gate
on: [pull_request]
jobs:
gantry:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write # required to post PR comments
steps:
- uses: actions/checkout@v4
- name: Gantry Launch Readiness check
uses: trygantry/gantry@v0.3.0
with:
workspace: "."
fail-on-no-go: true
comment: trueSee docs/github-action.md for inputs and details.
.gantry/
├── AGENTS.md # contract for AI agents editing the vault
├── config.json # vault settings, release target, integrations
├── index.json # generated machine-readable launch index
├── state.json # snapshot pointer + notification idempotency ledger
├── observed.json # ingested telemetry observations by environment
├── waivers.json # accepted-risk waivers with approver, reason, and expiry
├── scorecard.json # optional configurable readiness rules
├── evidence/*.json # structured evidence records and attestations
├── releases/*.json # generated release manifests by version
├── snapshots/*.json # timestamped launch-state snapshots for diff/notify
├── tasks.md # shared human + AI launch task queue
├── README-launch.md # plain-language launch overview
├── go_no_go.md # final readiness gates and sign-offs
├── blockers/*.md # individual launch blockers
├── qa/*.md # QA plans and checklists
└── schema/*.json # JSON schemas for validation
Gantry validates frontmatter metadata inside the vault using schemas located in .gantry/schema/*.json. Below are the primary file specifications:
Blocker files track individual release-blocking issues:
---
type: blocker
id: BLK-101
title: App crashes during monthly subscription purchase
severity: P0
status: blocked
owner: "@dev_jane"
source_files:
- src/purchases/paywall.ts
sentry_issue: https://sentry.io/issues/55812
last_verified: 2026-05-27
created_at: 2026-05-27
---QA files define test plans with standard markdown checklists:
---
type: qa
id: QA-REGRESSION
title: Release Regression Plan
owner: "@qa_bob"
platforms:
- ios
- android
last_verified: 2026-05-27
---Checklist items in the markdown body use the format:
- [ ] Verify checkout completes in sandbox. <!-- owner:@qa_bob priority:P0 -->The final readiness gate configuration and release target settings:
---
type: go_no_go
release: 1.0.0-beta.3
target_date: 2026-06-15
required_crash_free_rate: 99.5
required_qa_completion: 100
status: at_risk
---Waivers record accepted risk without hiding it. An active waiver can prevent a matched finding from forcing No-Go, but the waived item remains visible in the dashboard, CLI output, audit reports, and release manifests.
[
{
"id": "WAV-20260605-001",
"target_type": "blocker",
"target_id": "BLK-101",
"target_path": "blockers/BLK-101-purchase-crash.md",
"target_code": null,
"reason": "Known issue accepted for staged rollout; rollback path verified.",
"approved_by": "@release_lead",
"created_at": "2026-06-05",
"expires_at": "2026-06-12",
"status": "active"
}
]Supported target_type values are blocker, qa, document, gate, signoff,
and validation.
Evidence records attach proof to a release without requiring a hosted service. They can point at local test reports, CI URLs, artifact hashes, telemetry pulls, approvals, or manual notes.
{
"id": "EVI-REGRESSION-20260605",
"kind": "test_report",
"title": "Release candidate regression suite",
"source": "ci",
"path": "test-results/regression.xml",
"url": "https://github.com/example/app/actions/runs/123",
"artifact_sha": null,
"commit": "abc1234",
"environment": "production",
"release": "1.2.0",
"created_at": "2026-06-05T10:30:00Z",
"expires_at": null,
"metadata": {},
"attachments": []
}Supported evidence kind values include test_report, security_scan,
telemetry_pull, approval, artifact, app_store_build, ci_run, and
manual_note.
If scorecard.json is present, Gantry evaluates its rules and uses the results for
category scores, readiness reasons, CI output, and desktop scorecard rows. If the file is
absent, Gantry falls back to the built-in scoring model.
[
{
"id": "qa-complete",
"category": "QA",
"title": "Regression QA is complete",
"severity": "error",
"weight": 40,
"predicate": "min_qa_completion",
"params": { "min_pct": 100 },
"failure_message": "Required QA completion threshold has not been met.",
"suggested_action": "Complete or explicitly waive remaining QA checklist items."
}
]Supported predicates are no_open_blockers, max_open_blockers,
min_qa_completion, required_signoff_role, no_missing_docs,
no_validation_errors, no_broken_links, telemetry_fresh,
min_crash_free_rate, required_evidence_kind, and max_stale_docs.
gantry index writes a release manifest for the active release. The manifest records
the commit, environments, blockers, completed QA suites, sign-offs, active waivers,
evidence IDs, readiness state, and readiness score. Re-running gantry index avoids
rewriting the manifest when the meaningful manifest content has not changed.
config.json supports per-environment launch policy plus Slack notification routing:
{
"defaultEnvironment": "production",
"environments": {
"production": {
"requiredQaCompletion": 100,
"blockOnP0": true,
"minCrashFreeRate": 99.9,
"maxObservedAgeHours": 24,
"blockOnMissingTelemetry": true,
"telemetryRules": [
{
"metric": "datadog.p99_latency_ms",
"comparator": "<=",
"threshold": 250,
"severity": "required"
}
]
}
},
"notifications": {
"slack": {
"enabled": true,
"webhookEnv": "GANTRY_SLACK_WEBHOOK_URL",
"events": [
"readinessChanged",
"scoreThresholdCrossed",
"blockerResolved",
"qaSuiteComplete",
"signoffComplete",
"gateComplete"
]
}
}
}Telemetry pull uses GANTRY_SENTRY_TOKEN; Slack dispatch uses the env var named by
notifications.slack.webhookEnv.
Gantry computes a weighted Readiness Score from 0 to 100 based on local launch
facts: blockers, QA completion, documentation health, gates, sign-offs, telemetry, and
evidence. If .gantry/scorecard.json is present, its rules drive category scores and
readiness reasons. Otherwise, Gantry uses the built-in four-pillar model:
| Pillar | Weight | Description |
|---|---|---|
| Engineering | 30% | Based on open blocker severity (P0: -50, P1: -25) and presence of blocker source files (-15 per missing file). |
| QA | 30% | Direct percentage of completed checklist tests (e.g., 49/49 passes = 100%). |
| Product Docs | 20% | Quality and validity of core markdown files (-15 per schema/frontmatter validation error, -10 per broken wiki link). |
| Go/No-Go Gates | 20% | Percentage of stakeholder sign-off gates checked in go_no_go.md. |
Gantry also tracks minor operational categories (Monitoring, Store, Support, etc.). These don't directly drag down the primary weighted score unless overridden, but they help identify gaps:
- Monitoring: -30 if Sentry integration is not configured in
config.json. - Support: -50 if the
runbook.mdlaunch day runbook is missing, and -20 if it has formatting errors. - Store: -25 per App Store metadata validation error.
To ensure safety over sheer averages, Gantry applies a Blocking Override Cap:
- If the launch status is marked as No-Go or has unresolved showstoppers, the overall score is hard-capped at 49%, regardless of how high other categories score.
- Active waivers can accept specific risks, but waived findings remain visible as accepted risk and are included in reports and release manifests.
gantry index writes snapshots under .gantry/snapshots/ and a release manifest under
.gantry/releases/. Use gantry diff <base>..<head> to compare snapshots,
gantry release history to inspect manifests, and gantry trends --json to summarize
readiness score, blockers, QA completion, telemetry freshness, waivers, and evidence
counts over time.
Launch Dashboard · Readiness Scorecard · Evidence Ledger · Docs Health · Critical Issues · QA Readiness · Go/No-Go Room · Trends · What's New (Timeline) · Vault Editor.
Tauri 2 · Rust backend · vanilla HTML/CSS/JS frontend · local markdown + JSON storage · JSON Schema validation · Rust filesystem watcher.
Contributions are welcome. Start with CONTRIBUTING.md and look for
issues labeled good first issue. Please also read our
Code of Conduct.
Gantry's core — the desktop app, CLI, and file contract — is licensed under Apache-2.0. The hosted Gantry CI Gate (org-wide launch policy enforcement, cross-repo dashboards, audit trail) is a separate commercial product. See LICENSING.md.