RigelPlatformHow it works

From repos to a governed change.

What's deterministic, what uses a model, and where the gates sit. Written for the engineer who will check.

01 · Architecture

Follow a request through Rigel.

Repos become a chart. The chart briefs agents. Agents' changes go through gates. Rigel centralizes cross-repo application knowledge, workflows, architecture and infra conventions so agents across your estate build consistently.

Sources

GitHub

repos · signed webhooks

Sources

Jira

issues · signed webhook

Sources

UI · CLI · API

you, registering repos

Rigel · web + worker

Web + API

REST, SSE, webhooks, UI

Rigel · web + worker

Worker tier

durable workflows

Rigel · web + worker

Code graph

AST · no model

Models · state

Claude

Anthropic API or AWS

Models · state

Postgres

+ pgvector · the chart

Models · state

Voyage AI

embeddings · rerank

Surfaces

MCP server

20 read-only tools

Surfaces

Rigel agents

allowlisted tools

Surfaces

Sandbox

fresh clone · allowlist

Outcomes

Your agents

Claude Code, Cursor…

Outcomes

PR Supervisor

CI · fixer · review · gates

Outcomes

Pull request

on GitHub

GitHub, Jira and the UI or CLI feed the web and API server, which dispatches durable workflows on a separate worker tier. Workers build the code graph (no model), call Claude for extraction and analysis, embed text with Voyage AI and write everything to Postgres with pgvector. The MCP server reads Postgres for your coding agents. Rigel's agents read the same chart, change code in a sandbox and open pull requests that the PR Supervisor gates.

Stack: Node.js and TypeScript, a React UI, durable workflows, PostgreSQL with pgvector. Web and worker tiers deploy separately.

Follow a request through the system

Onboard a repo
  1. You register a repo in the UI, through the API or with the CLI.
  2. The server dispatches a durable workflow instead of doing the work inline.
  3. Clone, discover services, scan docs, then build the AST code graph. No model.
  4. Claude extracts APIs and channels, then runs seven read-only analysis passes per service.
  5. Docs and endpoints are embedded with Voyage AI.
  6. Everything lands in Postgres, keyed by repo and branch.
  7. A docs PR opens in the repo with the results.
Agent asks over MCP
  1. Your coding agent calls find_consumers on the Rigel MCP server.
  2. The server reads the chart from Postgres. It holds no state of its own.
  3. Matches come back: consumers in other repos, each with a severity and a reason.
  4. The agent keeps the old field deprecated and lists the consumers in its PR.
Agent opens a PR
  1. A Rigel agent gets the same chart in-process, through allowlisted tools.
  2. It reasons with Claude under a USD budget and a turn cap.
  3. Code changes happen in a sandboxed fresh clone. .github/** is protected.
  4. It pushes a branch and opens a pull request.
  5. The PR Supervisor waits for CI, fixes up to 4 times, waits for review and applies gates, then merges or explains.
A PR merges
  1. A merge on a tracked branch fires a signed webhook.
  2. The run is keyed on repo and merge commit, so redeliveries don't double-run.
  3. Triage picks the affected (service, pass) cells. Only those re-run.
  4. Fresh docs are written back to the chart.
  5. One rolling docs PR is updated, under an advisory lock.
Components
  • Web + API server: REST and SSE API, GitHub and Jira webhooks, and the React UI.
  • Worker tier: the same image, deployed separately; it runs every durable workflow step.
  • Postgres + pgvector: all state: the chart, embeddings, code-graph edges, sessions, runs and audit logs.
  • Code-graph service: optional; AST extraction and clustering, no model.
  • MCP server: 20 read-only tools over stdio or stateless Streamable HTTP.
  • CLI: init, analyze, pr-analyze, query for local one-shot use.

Events in. Governed work out.

Six sources in, six destinations out. Every path runs through the same chart.

Into Rigel
  • GitHub — webhooks: pull_request · issue_comment · registry_package
  • Dependabot — REST: repos/{owner}/{repo}/dependabot/alerts
  • Jira — webhook: jira:issue_created · HMAC-SHA256
  • Your coding agents — MCP over stdio or streamable HTTP
  • AWS — release pipelines · ops signals · read-only
  • Temporal — poll: failed workflows · fingerprint dedup · Beta
Out of Rigel
  • GitHub pull requests — Git Data API commits · draft PRs
  • PR comments — line-anchored review · suggestion blocks
  • Slack threads — 9 lifecycle events · 1 thread per PR
  • MCP answers — 20 read-only tools · JSON results
  • Jira comment — REST comment · exactly one per bug
  • Confluence pages — versioned publish · opt-in push
What each scenario does
  • A PR is opened. Someone opens a pull request on GitHub. Rigel works out what it could break and comments on the PR. When it merges, the docs update themselves.
  • A bug lands in Jira. A bug is filed in Jira. Rigel investigates it against the map; if it is confident, it opens a draft fix and leaves one comment on the ticket.
  • Dependabot raises an alert. Dependabot flags a vulnerable package. Rigel patches it, including packages buried deep in the tree, and opens one tested PR.
  • A coding agent asks. Your AI coding agent asks Rigel a question before it edits code, and gets the answer straight back.
  • A feature is planned. A feature idea in Jira becomes a clear requirement, then a design, published to Confluence.
  • A release is cut. A release goes out on AWS. Rigel writes the change-approval pack and posts a summary in Slack.

02 · Deterministic vs model

We tell you which parts use a model.

Structure comes from code. Models read and write what code analysis can't, and their output is bounded.

No model→ Clone· Discover services· Scan docs· Code graph (AST)· Map dependencies· Extract APIs & channels· 7 analysis passes· OpenAPI (gated)· Voyage AI embedding· Docs PR

Deterministic · uses a model · model output behind a validation gate

LayerTechniqueUses a model?
Service discoveryFilesystem walk of package manifests and monorepo workspaces, classified by Dockerfile, start scripts and entry pointsNo
Internal dependency graphManifest dependencies; workspace references become internal edgesNo
Code graphAST extraction and community clusteringNo
Docs scanFinds existing documentation in the repoNo
File classification, risk scoreRules over file paths and a published formulaNo
Semver and path gatesParse the manifest diff and the changed-file listNo
Inter-service communicationFramework-aware extraction that records HTTP calls, queues and topics, event buses and shared databasesYes
API surfaceFramework-aware extraction returning structured endpoint metadataYes
Infrastructure as codeFile discovery (AWS templates, Kubernetes manifests, Helm charts), then model extractionBoth
Deep analysisSeven passes per service: identity, API and data contracts, message and event contracts, business logic, configuration, failure modes, integration manifestYes, read-only tools
OpenAPI generationModel generation behind a validation gate. Invalid output never replaces a valid specYes, gated
Embeddings, rerankingVoyage AI over endpoints, docs and knowledgeEmbedding model
Cross-repo synthesisIntegration graph and data-flow narratives per constellationYes
CapabilityNode.js / TypeScriptJava, Kotlin, Python, Go, Ruby
Service discoveryShippedComing soon
Internal dependency graphShippedComing soon
API and channel extraction (model)ShippedOnly for services found through package.json
Seven analysis passes per serviceShippedOnly for services found through package.json
Code graph (AST, no model)ShippedDepends on the code-graph tool's language support; verify on your repo
Docs scan and infrastructure-as-code passShippedShipped
Package consumer matchingShipped (npm)Coming soon
Dependency upgrades, semver and path gatesShipped (npm)Coming soon

A repo with no package.json produces no services today, so Rigel won't chart its APIs or find its consumers. A mixed repo gets the full chart for its Node.js services.

Cost controls
  • Extraction is cached per repo, branch and commit, so re-runs on an unchanged commit don't repeat model calls.
  • Onboarding concurrency is limited per repo and globally.
  • Repos too large for a single run fail fast instead of half-finishing.

03 · Staying current

The chart updates itself on merge.

Only the cells a diff affects are re-analysed.

Refresh on merge · 3 of 28 cells re-analysed
merged feat: refund window on orders → main

webhook· idempotency key· triage· re-analyse· advisory lock· rolling docs PR

Service01020304050607
orders●●●
inventory
notifications
billing-worker

Passes: 01 identity · 02 API & data contracts · 03 message & event contracts · 04 business logic · 05 configuration · 06 failure modes · 07 integration manifest.

1
Trigger

A PR merges on a repo's tracked branch. Repos can opt out.

2
Idempotent

Keyed on repo and merge commit, so webhook redeliveries don't double-run. One refresh per repo at a time.

3
Triage

An agent on a fixed budget reads the diff against the service inventory and returns the affected (service, pass) cells. When in doubt, it refreshes.

4
One rolling docs PR

All doc changes for a base branch go to one PR, committed only if a fresh doc was written.

Races, loops and branches

No races: onboarding, refresh and OpenAPI updates take a Postgres advisory lock before writing to the docs PR.

No loops: merges of Rigel's own docs branches don't trigger refreshes.

Branch-aware: snapshots are keyed by repo and branch. Older ones are pruned nightly. Invented pass IDs from triage are dropped.

03b · Trust the chart

How much to trust the chart.

Edges come from code, manifests and model extraction. Here's what that guarantees, and what it doesn't.

What a match means

Package matches read package.json dependencies, so they are exact. Endpoint matches Beta compare recorded HTTP paths, exactly or as patterns. Queue matches Beta compare channel names, ignoring case.

"No consumers found" is not proof

It means nothing in the chart matched. Known blind spots: URLs built at runtime from config or environment, routing done by a service mesh or gateway, topic names read from config, and repos not yet charted.

Freshness

The chart refreshes on every merge to a tracked branch. A triage agent picks the cells to re-analyse and is told to refresh when in doubt. Re-run Deep Survey on a repo at any time for a full pass; extraction is cached per commit, so unchanged code isn't re-billed. MCP answers can lag the database by up to 5 minutes (context cache). Per-service "last analysed commit" for agents: On our radar.

Measured accuracy

We haven't published measured accuracy yet. When we have an evaluation we stand behind, we'll show the method and recall/precision per edge type here rather than a headline number.

Limits we know

Repos too large for one workflow run fail fast with a message (1,000-step limit). Onboarding runs one workflow per repo at a time, two globally. Code graph builds time out at 300 seconds. The last 5 snapshots per repo and branch are kept. We'll publish a tested-scale figure once we can back it with real estates.

Your existing docs and catalog

Deep Survey reads docs already in the repo, including docs/, adr/, decisions/ and rfcs/ folders. Catalog files aren't read; catalog sync is On our radar. The chart lives in your Postgres and the generated docs and OpenAPI specs are committed to your repos, so nothing is locked inside Rigel.

04 · Risk scoring

The whole risk formula.

A transparent heuristic, not a machine-learning model. It doesn't predict incidents; it shows what a change touches.

8 factors · Σ weight 25

FactorWeightSeverity thresholds
Service scope× 3≥5 affected = critical · ≥3 = high · ≥2 directly changed = medium
Cross-service impact× 4any breaking = critical · ≥3 warnings = high · ≥1 warning = medium
Database migrations× 4≥3 migrations = critical · any migration or ORM schema file = high
API changes× 3≥5 endpoints = high · ≥1 = medium
Change volume× 2≥20 source files or ≥1,000 lines = high · ≥10 or ≥500 = medium
Configuration changes× 2any CI file, or ≥3 config files = medium
File deletions× 2≥5 = high · ≥2 = medium
Destructive schema changes× 5deleted schema file, or ≥2 schema/migration files with net deletions = critical · 1 = high
score = round( Σ(severity × weight) / Σ(weight) × 100 )

severity  low 0.1 · medium 0.4 · high 0.7 · critical 1.0
level     ≥70 critical · ≥45 high · ≥25 medium · else low

All factors low scores 10 (low). Only non-low factors appear in the PR comment.

Worked examples: docs-only stays low; a new endpoint reaches medium; a shared-DB migration reaches critical.

Pipeline and cross-service rules

Changed files → classify each (source, test, config, CI, migration, schema, docs) and map it to a service → walk the dependency graph for transitive impact → detect cross-service impacts → score.

  • API contract (warning): endpoints changed in service S, for every service with a recorded channel that targets S.
  • Shared dependency (warning): source changes in a shared library, for every dependent.
  • Data schema (breaking): a migration in S, for every service sharing S's database.

API and contract factors depend on the endpoints and channels recorded at onboarding. Destructive schema changes are a proxy (net line deletions in schema or migration files); SQL isn't parsed.

05 · How agents run

Safety comes from the tools given.

Agents run without interactive approval prompts, so the tool surface Rigel builds is the boundary.

Effective tool surface

tools = declared ∩ allowed − hard bans

An agent's tools are the intersection of what its template declares and what the operator allows, minus hard-banned built-ins.

  • Template declares — Glob · jira.read
  • Operator allows — slack.post · aws.logs
  • Effective — Read · Grep · find_consumers
  • Hard-banned — Edit · Write · Bash

Also banned: WebSearch · WebFetch · Agent.

A guard-railed sandbox for code changes

Agents that edit code get a sandbox tool, not a shell: a fresh clone, allowlisted first commands, no shell interpreter, lifecycle scripts off, capped output, time and command count.

Guard-railed, not hermetic: allowlisted tools such as node can still run code. Security & Trust has the detail.

No pushes to .github/**

The checks an agent is judged by can't be edited by the agent. Refused three ways, fail-closed:

  1. At write time, in the sandbox
  2. On a pre-push diff against the base
  3. By a git pre-push hook in the clone

Budgets and caps

  • USD budget on every run, chat query and drafting session — $
  • PR fix loop iterations — ≤ 4
  • Agent mesh hops — ≤ 4
  • Chained workflow depth — ≤ 5

Runs also have turn caps. Every run is a retryable, idempotent workflow step, so a pod restart doesn't lose work.

Credentials and read-only surfaces

  • External MCP servers get credentials from their configuration; spawned processes get a minimal environment.
  • Analysis, chat, MCP and debug surfaces expose no tools that change anything.
  • Editing built-ins are banned for every playbook, even if a template asks for them.
Fail open · protect productivity

If these critics error, your work continues.

Business-language critic (requirements)
Grounding critic (solution designs, advisory)
Fail closed · protect data

If these critics error, nothing is written or sent.

Knowledge-base leakage critic
A2A requirement-envelope critic Beta

06 · Which PRs get what

Gates depend on who opened the PR.

The honest version, by PR author.

  • Your agents' PRs (Claude Code, Cursor, Copilot): context over MCP and a risk score, today.
  • PRs from Rigel's own agents: gated auto-merge, today. Code changes need GitHub Copilot code review.
  • Supervising your agents' PRs: Coming soon, our next priority.

Rigel merges only inside your branch protection. Major upgrades, CI paths and PRs titled [needs-review] always wait for a person. Every default →

PR opened byImpact analysis, persona reviewPR Supervisor gates, Repo Guard, Flight LogAuto-merge
Rigel's own agentsbug triage, dependency advisors, docs refresh, @mention re-fix, operator-run playbooksYes, when enabled for the repoYesWhen the origin's gates pass (bug-triage PRs never auto-merge)
Your other coding agentsClaude Code, Cursor, Copilot agent and othersYes, when enabled for the repoNot today Coming soonNo; your team merges
PeopleYes, when enabled for the repoNoNo; your team merges
01
Wait for CI

Poll checks, statuses and review threads on a time budget separate from the fix cap.

02
Classify and fix

Green, failing, pending, no CI or blocked. Fixable failures get the PR Fixer, 4 iterations at most.

03
Wait for review

After a fix to code, request a fresh GitHub Copilot review and wait for it. No merge while it's pending.

04
Merge gate

CI exists and is green, no unresolved threads, not a draft, and the opening flow allows auto-merge.

05
Policy gates

For dependency PRs: needs-review brake, semver gate and path gate. A held green PR gets a decision comment.

Disclosures

Rigel doesn't require a human approval itself. If your branch protection requires reviews, merges wait for them, and we recommend requiring them. If a human merges or closes the PR, the supervisor stands down.

Auto-merge on green is on by default for supervised flows except bug triage. Docs-only PRs may merge in repos with no CI.

The upgrade advisors have a separate playbook-level "auto-merge on green" setting, off by default. When on, the advisor merges through its own merge tool, which refuses drafts, changes-requested reviews, unmergeable PRs, PRs with no CI and [needs-review] titles, but doesn't run the semver and path gates. Leave it off to keep every dependency merge behind those gates.

Lifecycle events go to Slack, one thread per PR; a PR that needs a human gets a "Human action needed" alert with the reason.

07 · Models & integrations

Claude, through the provider you choose.

Claude models

Opus, Sonnet and Haiku, selectable per deployment. Use the Anthropic API, or Claude through your own AWS account. Multi-turn agents run on the Claude Agent SDK; single-turn calls retry with backoff.

  • Every prompt is replaceable, system-wide, or extended per repository with up to 20,000 characters, from Settings and without a redeploy.
  • Embeddings and reranking use Voyage AI under your Voyage account. No alternative embeddings provider today.
  • Cost: tokens and estimated cost roll up onto every run and session.
code host · webhooks

GitHub

Repos, PR webhooks, docs PRs and merges. One token today; GitHub App Coming soon.

your coding agents

Claude Code · Cursor · VS Code

Connect over MCP for 20 read-only tools.

reviewer of record · optional

GitHub Copilot code review

Required as reviewer for code-change auto-merge; without it, a person merges.

Flight Log

Slack

9 PR lifecycle events, one thread per PR, through your Slack MCP server. Slack app Coming soon.

bug triage

Jira

Signed webhooks start bug triage; one comment back per bug.

publishing · opt-in

Confluence

Publishes requirements, solution designs and release docs. Off by default.

models · ops

AWS

Claude through your AWS account, plus read-only ops tools for logs, metrics and deploy pipelines.

models

Anthropic

Claude models on your key.

embeddings · required

Voyage AI

Code embeddings for semantic search; code excerpts are sent to Voyage on your key.

stdio · HTTP

Any MCP server

Register stdio or HTTP servers; per-agent allowlists.

failure triage

Temporal Cloud Beta

Failed workflows triaged into a fix PR and one Slack message.

Agent2Agent

A2A agents Beta

Agent2Agent registry and a depth-capped mesh.

GitLab and Bitbucket: on our radar.

08 · What ships today

What ships today

Shipped has no badge. Beta works but is still changing. Coming soon is not available yet. "On our radar" means listening, not committing.

Last updated 1 October 2026

DimensionTodayNext
Code hostGitHub (one deployment-wide token)GitHub App Coming soon; other hosts: On our radar
Languages, full chartNode.js / TypeScript (details)Java, Python, Go Coming soon
Package ecosystem for upgradesnpmOther ecosystems Coming soon
Model providerClaude via the Anthropic API or your AWS accountPer-workspace keys Coming soon
EmbeddingsVoyage AI (required)In-boundary option: On our radar
Reviewer of record for code-change auto-mergeGitHub Copilot code reviewPluggable reviewer Coming soon
PRs Rigel can gate and mergePRs from Rigel's own agentsAny coding agent's PRs Coming soon
DeploymentSelf-host on Kubernetes or Docker BetaRigel Cloud, Helm chart Coming soon
ModuleCapabilityStatus
MapDeep Survey (seven passes per service) Node.js / TypeScriptShipped Coming soon · Java, Python, Go
MapCode graph optional componentShipped
MapConstellations and assemblyShipped
MapVisual cross-repo constellation mapComing soon
MapBranch-aware chartShipped
MapLiving Docs: refresh on merge, rolling docs PRShipped
MapOpenAPI on merge opt-in per repoShipped
MapSemantic search needs Voyage AIShipped
MapSelf-learning knowledge baseBeta
MapAsk RigelShipped
MapIDP catalog syncOn our radar
MCP20 read-only tools over stdioShipped
MCPHTTP transport (in-cluster, no built-in auth)Beta
MCPHosted, authenticated endpoint with Rigel CloudComing soon
ImpactBlast radius and risk score on PRs enable per repo; any PR authorShipped
ImpactPersona review enable per repoShipped
ImpactCross-repo consumers: packages, via MCP and agents package.json manifestsShipped
ImpactCross-repo consumers: endpoints and queues, via MCP and agents being hardenedBeta
ImpactCross-repo consumers in the PR comment; Cross-Repo Impact screenComing soon
ImpactGitHub Action not on the MarketplaceBeta
ImpactDaily Deploy Risk Digest needs an operator-registered GitHub MCP serverShipped
ImpactRelease Analysis (change-approval pack) AWS release pipelines; other CD systems on our radarShipped
AutopilotPR Supervisor with origin-aware gates, for PRs Rigel's agents open GitHub; Copilot review for code changesShipped
AutopilotSupervision of PRs from other coding agents not available todayComing soon
AutopilotPer-org configurable merge policiesComing soon
AutopilotPR Fixer and @mention re-fixShipped
AutopilotPlaybooks (on a schedule you set, or on demand)Shipped
AutopilotDependency Upgrade Advisor npm on GitHubShipped Coming soon · Maven/Gradle, pip/Poetry, Go modules
AutopilotLib Version Bump AdvisorBeta
AutopilotJira Bug Triage Jira Cloud; PRs never auto-mergeShipped
AutopilotTemporal failed-workflow triageBeta
AutopilotWorkflow Builder v1 limitsShipped
AutopilotAgent BuilderShipped
AutopilotA2A agents, mesh, self-hosted agent hostBeta
AutopilotFlight Log (Slack) one workspaceShipped
AutopilotRepo Guard (installed by you from our template)Shipped
AutopilotOps Debug Agent, Staging Alarm Triage AWSShipped
AutopilotFeature autopilot (agents build solution tasks)Coming soon
AutopilotUnified audit exportComing soon
PlanRequirement Brief, Solution CourseShipped
PlanVersions, share links, exportShipped
PlanConfluence push off by defaultBeta
SecurityRead-only Postgres MCP boundary (eight layers)Shipped
SecurityLeakage critics (knowledge base, A2A)Beta
SecurityHermetic sandbox (container isolation, minimal environment)Coming soon
PlatformRigel Enterprise (self-host)Beta
PlatformHelm chart, licence keys, air-gapped installComing soon
PlatformVersioned database migrationsComing soon
PlatformRigel Cloud (multi-tenant SaaS)Coming soon
PlatformPer-tenant bring-your-own Anthropic keyComing soon
PlatformPer-org single sign-on and rolesComing soon
PlatformSingle sign-on via your OpenID Connect identity provider (one realm) required for any shared deploymentShipped
PlatformBudget caps per run, chat query and drafting session; cost tracking; admin usageShipped
PlatformOrganisation-level spend capsComing soon
PlatformBillingComing soon

Next, in order

  1. Govern any coding agent's PRs, with a pluggable reviewer (our launch priority)
  2. Remote MCP endpoint auth
  3. Rigel Cloud with your own Anthropic key
  4. Java, Python and Go discovery and upgrades
  5. GitLab and Bitbucket (on our radar)

We'll add dates here when we commit to them.

09 · Under the hood

Under the hood.

Real config, real arguments, real rules.

.mcp.json · project root · Claude Code / Cursor

{
  "mcpServers": {
    "rigel": {
      "type": "http",
      "url":  "https://rigel-mcp.internal.example/mcp"
    }
  }
}

# tools (read-only)
# list_repositories · get_service_info · get_dependency_graph
# get_api_surface · get_communication_channels · semantic_search
# find_consumers · cross_repo_impact · get_callers · get_callees
# get_imports · get_class_hierarchy · get_subgraph · …

One entry gives your agent the whole chart. Read-only by contract: no tool on this server can write. Remote over stateless Streamable HTTP at /mcp, or stdio locally. Run the remote endpoint inside your network until endpoint auth ships. Hostnames are examples.

find_consumers · MCP tool call · JSON

// request
{
  "name": "find_consumers",
  "arguments": {
    "source_repository_id": "orders-api",
    "package_names": ["@your-org/orders-client"]
  }
}

// result
[
  { "repository": "fulfillment", "service": "fulfillment-service",
    "matchType": "package", "severity": "warning",
    "reason": "depends on @your-org/orders-client" },
  { "repository": "billing", "service": "billing-worker",
    "matchType": "package", "severity": "warning", … }
]

Ask who breaks before you change it. Matches a change against every onboarded repo's snapshot by package, endpoint or queue. Package matching is exact; endpoint and queue matching are Beta. Severity is info or warning, never a guess at "breaking".

risk-scorer.ts · core/analysis

const WEIGHTS = {
  serviceCount:      3,
  crossService:      4,
  migrations:        4,
  schemaDestruction: 5,
  apiChanges:        3,
  changeVolume:      2,
  configOrCi:        2,
  deletions:         2,
};
// severity ∈ {0.1, 0.4, 0.7, 1.0}
score = Σ(weight × severity) / Σ weight × 100

// ≥ 70 critical · ≥ 45 high · ≥ 25 medium · else low

A heuristic you can read, not a model. Eight weighted factors, each graded on a four-step severity scale. The PR comment shows every factor that moved the score.

merge gates · orchestrator/activities · dependency-advisor origin

pathGate(files)
  allow  **/package.json · lockfiles · e2e-tests/**
  deny   .github/ · .aws/ · template.yaml · .gitmodules

semverGate(manifestDiff)
  patch | minor                         → merge
  internal major ∧ sole change
    ∧ ¬denyList ∧ title starts "[major]" → merge
  external major | downgrade | prerelease
    | added / removed dep | unparseable → hold

brake(title)
  "[needs-review]"                      → hold  # always wins

on hold of a green PR → upsert decision comment

Deterministic gates, re-derived from the diff. The supervisor never trusts the agent's own summary: it re-reads every changed manifest between merge-base and head. Per-org policies are coming soon; today the policy is in code.

sandbox policy · core/sandbox/bash-sandbox.ts

sandbox:
  clone:      shallow, token-scoped, /tmp/rigel-sandbox-*
  commands:   [npm, npx, pnpm, yarn, knip, node, git, …read/text tools]
  rejected:   ["$(", "`", path escapes outside the clone]
  env:
    npm_config_ignore_scripts: 1
  limits:
    per_command: 5m      # 2m default
    commands:    200
    output:      16KB
  protected:
    - ".github/**"     # write time · pre-push diff · pre-push hook

A sandbox tool, inside a fence. Code-changing agents get a sandbox tool, not a shell: a shallow clone, a first-token command allowlist and no shell interpreter. It reduces risk but is not a VM: allowed tools can still execute code, so pair it with branch protection.

10 · Glossary

In plain words.

TermIn plain words
ChartThe service dependency graph Rigel builds from your code.
ConstellationA group of related repos that make up one application.
Deep SurveyThe 7-pass analysis Rigel runs on each service.
Blast radiusWhat else a change can affect.
PR SupervisorThe gates that decide whether a PR from Rigel's own agents merges or waits for a person.
Flight LogOne Slack thread per agent PR, from open to merge.
Requirement BriefTurns a one-line ticket into a sign-off-ready requirement.
Solution CourseA solution design and task breakdown grounded in the chart.
MCPModel Context Protocol, the standard way AI agents call outside tools.
PRPull request: a proposed code change, reviewed before it merges.
CIContinuous integration: the automated tests and checks that run on every PR.
BetaWorks, but still changing.
Coming soonNot available yet.

Want the walkthrough from an engineer?

We'll trace one of your repos from onboarding to a governed PR.