Implemented architecture — 0.2

Unattended service

src/server.js loads a trusted repository policy at startup and starts Automation alongside the local web server. npm run automate runs the same worker without a UI. Setup is a one-time installation activity; the routine failure path has no manual import, command choice or status transition.

flowchart LR
    A[GitHub failed workflows] --> B[Bounded attempt-specific collection]
    B --> C[(SQLite investigations and durable tasks)]
    C --> D[Leased worker]
    D --> E[Disposable recipe execution]
    E --> F[Reproduced failure and protected test inventory]
    F --> G[Structured repair model]
    G --> H[Bounded source patch policy]
    H --> I[Fresh candidate verification]
    I --> J[Deterministic repair branch and PR]
    J --> K[Original CI native merge and merged-commit checks]
    K --> C
    C --> L[Live observation dashboard]

Modules

Module	Responsibility
`automation/config.js`	One-time recipe discovery, immutable image resolution, policy validation and digest
`automation/github.js`	Scoped token/App authentication, run/job collection, bounded logs, publication and merge reconciliation
`automation/http.js`	Stream-size limits and log-redirect destination checks
`automation/state.js`	Durable task/step/health storage, leases, fencing and retry scheduling
`automation/execution.js`	Disposable source/candidate copies, constrained Docker/local execution, protected-file inventories and bounded patch application
`automation/repair.js`	Bounded Claude Messages request and structured edit contract
`automation/engine.js`	Automatic collection, reproduction, repair, verification, publication, observation and terminal outcomes
`public/automation-ui.js`	Automatic queue, health, stages, PR links and decision evidence

Existing analyze.js, store.js, the local CLI and the manual fallback remain supported.

Correctness boundaries

Collection scopes business identity by configured repository, provider run, attempt and job. Duplicate collection does not create a second task. Transport delivery and remote side effects are not claimed to be exactly once.

The worker records the source SHA, recipe digest, tracked-file manifest, baseline output and test inventory. A reproduction requires either the same diagnostic signature or the same failed test identity/category. A generic zero exit does not qualify as reproducing a failure.

Model output is data, never an instruction to execute a new command. Only trusted policy commands run. Source changes require a unique existing old-text match in a registered editable file. Tests/configuration/fixtures are protected. All edits are checked before writing.

Verification checks the complete original test inventory, no skipped tests, unchanged expected source/protected inputs after execution, and every configured command. The source commit plus patch digest identify the locally tested candidate. The later provider commit is retained separately.

Git metadata is removed before repository code runs. Subsequent host-side file inventories use the trusted manifest rather than invoking Git inside a mutable execution workspace. This avoids allowing a test to alter Git configuration and influence later host Git commands.

Publication uses a deterministic repair branch. On retry, existing PR/tree/parent identity is checked against the verified patch, handling a response lost after remote creation. Concurrent publication can still encounter a provider conflict; retry/reconciliation is required, not blind success.

Resolution requires original required checks on the repair head and the merged commit. Native repository policies remain authoritative. Local automated passing evidence cannot be submitted to the legacy manual resolution gate to skip these stages.

Execution and lifecycle

Docker recipes pin image digests and use an unprivileged user, read-only container root, no verification network, dropped capabilities and bounded CPU/memory/PIDs/output/time. Install networking is a separate trusted-policy decision. This is shared-kernel Docker isolation, not a microVM or hosted multi-tenant boundary.

An explicit trusted-local backend runs as the operator with a reduced environment. It is suitable only for registered code already trusted to execute locally, and cannot provide network/OS isolation.

Task leases are renewed and fenced. Checkpoints survive process restart; lost workspaces cause reconstruction. Stale source/repair revisions supersede work and obsolete observed PRs are closed where possible. Inconclusive/unsupported cases retain evidence. There is a two-candidate budget, bounded transient retries and a 24-hour workflow lifetime.

Deliberate limits

Single operator and SQLite; polling over workflows created in the last 24 hours; a maximum 1000 records per provider list; no signed webhook receiver; no multi-provider/organization model; limited Node test reporting; no submodules/tracked symlinks; no arbitrary service topology; no complete functional proof; no encrypted evidence store, retention engine, cost billing or third-party attestation.

The enterprise research describes the target beyond this implemented slice. Live GitHub, model and Docker validation require connected external accounts/runtime and are documented separately.

Explore all guides · Back to top

Architecture