中文入口 · Product requirements · Technical design · About

ADRO

ADRO is an open-source control plane for auditable software delivery. It connects goal intake, freely composed Agent/Squad workflows, durable context, quality gates, repair, and release evidence in one recoverable graph. Agents can move forward or send work back through explicit feedback edges; the session harness keeps context, attempts, and evidence connected across that loop.

The local profile is a real Go service with an owned browser workbench. It persists requirements, bugs, sessions, transcripts, checkpoints, memory, leases, outbox records, artifacts, and audit facts. External Git, CI, deploy, identity, and notification systems are replaceable SPI adapters rather than hidden core dependencies.

Why ADRO

Capability	What ADRO guarantees
Composable delivery graphs	Typed nodes, conditions, parallel joins, and explicit feedback edges instead of a fixed pipeline
Recoverable execution	Durable transcripts, checkpoints, memory, leases, and attempt lineage across restart and repair
Governed automation	Tenant-scoped authorization, immutable run plans, bounded retries, approvals, and idempotent side effects
Verifiable outcomes	Hash-linked events, artifacts, test evidence, SBOMs, and release manifests
Replaceable integrations	Versioned SPIs for executors, Git, CI, deployment, identity, notifications, and artifact storage

How ADRO fits together

The layered architecture separates the user-facing composition surface, the orchestration and session-harness runtime, and the durable storage/integration substrate. The harness belongs in the middle layer because it carries the recoverable execution context between graph decisions and side effects.

The architecture view is complemented by a delivery-flow view and a capability map. The flow is intentionally not the architecture: it shows how a run moves from intent to proof, including the bidirectional repair loop.

Quick start

Requirements: Go 1.25+, Git, curl, and an installed coding client. Docker is not required for the local profile.

ADRO_ADMIN_PASSWORD='change-this-password' \
./start.sh --no-docker --no-open

The initial administrator password must contain at least 10 characters. The variable is used only when the local profile has no auth.json; restarting with a different value does not replace an existing password. For a local profile where the password is unknown, stop ADRO, back up and remove its auth.json, then start once with a new password of at least 10 characters.

Open http://127.0.0.1:8081. The API readiness endpoint is http://127.0.0.1:8080/readyz.

On a clean profile the workbench opens the first-Agent setup automatically. It discovers every installed runtime with a supported adapter and lets the administrator choose the runtime, model, thinking level, service tier, runtime arguments, Skills, MCP servers, access policy, and execution budget. An existing workspace ZIP can be preflighted and imported from the same setup before creating an Agent.

./start.sh --status
./start.sh --stop

--status reports every discovered coding client, including the Codex binary bundled inside ChatGPT on macOS. Set ADRO_EXECUTOR when the API should use a specific client as its default executor.

Set ADRO_HOME, ADRO_API_PORT, and ADRO_WEB_PORT to isolate state or run multiple local profiles. Use ADRO_EXECUTOR to pin one executable; ADRO_EXECUTOR_COMMAND accepts an argv-style command with {input} as the stage prompt placeholder.

Bring an existing workspace

The setup screen can preflight and import an ADRO workspace ZIP before the first Agent is created. Operators can also convert a compatible PostgreSQL workspace directly with the CLI:

go run ./cmd/adroctl workspace preflight-postgres \
  --source-dsn "$SOURCE_DSN" --source-workspace "$SOURCE_WORKSPACE" \
  --source-upload-root "$SOURCE_UPLOAD_ROOT" --workspace local

go run ./cmd/adroctl workspace import-postgres \
  --source-dsn "$SOURCE_DSN" --source-workspace "$SOURCE_WORKSPACE" \
  --source-upload-root "$SOURCE_UPLOAD_ROOT" --workspace local --conflict rename

The source transaction is read-only and repeatable-read. Credentials, custom environment variables, live tasks, queues, execution sessions, and local paths are excluded. See workspace migration for ZIP export/import, conflict modes, attachment handling, and rollback.

Development

go test ./...
make verify
make real-e2e   # requires an authenticated real coding client

make verify runs unit and race tests, vet, build, API/HTML/OpenAPI contracts, startup checks, the SPDX license/SBOM verifier, and the Playwright browser suite. Browser tests use the checked-in no-op executor fixture so CI does not depend on a developer workstation; make real-e2e is the model-backed path.

Documentation

Start here	Purpose
Product requirements	Scope, personas, behavior, and acceptance criteria
Technical design	Runtime boundaries, persistence, security, and extension contracts
Production deployment	Controls required beyond the local reference profile
Workspace migration	Portable export, preflight, import, exclusions, and recovery
Compatibility	Supported runtime, browser, and adapter surfaces
Contributing	Change and review expectations
Security policy	Private vulnerability reporting and threat-model links
Release process	Reproducible gates and real-runtime acceptance

Repository map

• internal/: domain, workflow, provider, harness, storage, API, and audit packages.
• apps/web/: the owned Chinese/English workbench.
• docs/: product, architecture, operations, compatibility, and release docs.
• sdk/: provider, harness, integration, and artifact extension contracts.
• migrations/: versioned persistence schema boundaries.

Core highlights: free-form graph composition, Agent/Squad routing, typed session-harness continuity, explicit bidirectional feedback, bounded retries, and evidence-backed completion.

Release and security policy are in RELEASE.md and SECURITY.md. The full About-panel copy is in ABOUT.md; the Chinese project entry is README.zh-CN.md.