BuildMender0.2Run BuildMender locally ↗
Menu

ENGINEERING WORKFLOW AUTOMATION

A failed build.
An automatic
path forward.

From a failed GitHub check to a verified repair. BuildMender collects the evidence, reproduces supported failures, tests a bounded fix, and follows it through CI and merge.

Run BuildMender locally ↗Explore the workflow ↓

Connect once. Run unattended within your repository policy.

GitHub ActionsNode.js 24+Local SQLite
● ● ●REPAIR EXECUTION / EXAMPLEIllustrative
⌘
payments-api / unit-tests

Run #1042 · main · 8c7f4a2

Failed →
REPRODUCTION EVIDENCE› npm test
✕ calculates the final invoice total
expected: 4200 · received: 4199
✓ original failure reproduced
✓Collect & reproduceExact attempt · disposable checkoutVerified
✓Repair & testSource edits · original tests protectedVerified
◷Observe original CIRepair PR · repository merge policyWaiting
Evidence before resolutionView workflow ↓
Built for the work between “CI failed” and “verified on main.”What works today ↗

THE ENGINEERING GAP

A red check is a signal.
The work comes after.

Logs, local reproduction, candidate fixes, repeat test runs, PRs and merge checks: the same sequence repeats. BuildMender turns that sequence into a durable execution loop.

01

Context is scattered.

Run attempts, failing jobs and diagnostics belong together. Collection preserves the identifiers needed to investigate the actual failure.

02

A fix needs proof.

A plausible diff is only a candidate. Reproduction and the original test inventory establish whether it actually addresses the failure.

03

Green locally is a start.

The repair still needs the repository’s original CI, merge policy and checks on the merged commit before the workflow is resolved.

EXPLORE THE PLATFORM

One investigation.
Every stage connected.

Collection, execution, model-assisted repair and GitHub reconciliation share a durable task history. Explore the implemented building blocks.

GITHUB POLLING & EVIDENCE

Start with the failed attempt.

GitHub polling collects failed runs, exact attempts, jobs and logs for registered repositories. Related failures become investigations with evidence rather than disconnected uploads.

  • GitHub App or scoped token authentication
  • Repository policy and supported-event filtering
  • Durable SQLite tasks with leases and retry history
Read the architecture ↗
COLLECTOR / EXAMPLE EVIDENCE
Repository
example/payments-api
Workflow / attempt
CI / #1042 · attempt 2
Job
unit-tests / failed
Commit
8c7f4a2…
Next stage
Disposable reproduction →

THE AUTOMATION LOOP

Connect once.
Let the workflow carry the work.

Routine supported cases run without repeated uploads or per-failure commands. Select a stage to see its evidence requirement and stop condition.

STAGE 01 / DETECT & COLLECT

Turn a failed run into a durable task.

The collector retrieves exact attempt metadata, failed jobs and diagnostic logs. A supported repository policy admits the task into the execution queue.

REQUIRED EVIDENCE

Repository, commit, run attempt, failed job and usable diagnostic.

STOP CONDITION

Excluded events, unsupported repositories or missing evidence do not proceed to repair.

Workflow illustration · no live repository is connected to this page.

AUTOMATION WITH EXPLICIT BOUNDARIES

Autonomous execution.
Evidence at every gate.

Repository credentials, execution policy and model access need one-time configuration. From there, the service handles the supported loop and records why a task proceeds or stops.

⌁

Protect the test contract.

Repairs must preserve protected original tests and the test inventory. A candidate cannot make a failing check disappear by changing its definition.

↗

Constrain the workspace.

Disposable checkouts, bounded source edits and a configured execution recipe keep each attempt scoped. Docker is the default backend; it is not a microVM security boundary.

◎

Keep native policy authoritative.

GitHub review requirements and merge rules remain in charge. Required review can leave a task waiting; the service does not bypass it.

“Stopped” is a valid outcome.

Blocked, unreproduced, superseded or exhausted tasks retain their evidence. The service does not call an unverified repair resolved.

Inspect the design ↗

RUN THE APPLICATION

Your repositories.
Your execution policy.

BuildMender currently runs as a single-user local service. Start with a controlled Node.js repository, configure credentials once, and validate the full loop with a deliberate failing canary.

  1. 1
    Prepare the host

    Node.js 24+, Git and a supported repository. Docker for the default execution recipe.

  2. 2
    Register and connect

    Create repository policy and configure scoped GitHub access plus the repair model in private local configuration.

  3. 3
    Start and verify

    The service starts collector and workers. Use the operating guide to validate tests, canary behavior and restart recovery.

Open the complete run & test guide ↗
TERMINAL / FROM THE CI-RESOLVE CHECKOUT
# Node.js 24+ is required
node --version

# Register your target repository
node bin/ci-resolve.js setup \
  --cwd /path/to/repository

# Configure GitHub and model credentials
# in .private/automation.env as documented.

# Run collector, workers and dashboard
npm start

# In a separate terminal: verify the suite
npm test
First run?

These are entry commands, not the complete credential or repository setup. Follow the guide before enabling automatic publication or merge.

AVAILABILITY / VERSION 0.2.0

Know exactly
what you’re adopting.

The current release implements a bounded repair loop. Enterprise architecture research describes the longer-term platform and is clearly separated from available capabilities.

Implemented

The local automation release

  • GitHub Actions failed-run collection
  • Node TAP/spec test failure reproduction
  • Bounded model-assisted source repairs
  • Protected tests and verification recipes
  • Repair PRs and CI / merge reconciliation
  • Durable tasks and a progress workbench
Operate this release ↗
Research / not implemented

The enterprise direction

  • Multi-tenant hosted control plane
  • SSO and enterprise access controls
  • Postgres-backed distributed infrastructure
  • MicroVM execution fleet
  • Broader languages and test frameworks
  • Expanded governance and integration surface
Read the enterprise research ↗
Validation boundary

Local automated tests exercise execution and browser flows; GitHub and model integration tests use controlled responses. Live GitHub, model and Docker validation still requires connected credentials and a usable Docker host. This website is a product reference, not a hosted repair service.

THE OPERATOR’S LIBRARY

From first run
to a verified repair.

Detailed guides cover environment setup, automated operation, architecture and validation. Read them in the browser or download the source Markdown.

START HERE · OPERATIONS

Run & test guide

Host prerequisites, repository policy, credentials, browser checks, live canary, background service and troubleshooting.

Read the guide ↗ENGINEERING

Architecture & boundaries

Execution modules, durable state, repair controls and the implemented system’s operational limits.

Explore the architecture ↗STRATEGY · RESEARCH

Enterprise platform research

Competitive landscape, platform modules and a broader engineering roadmap. Proposed capabilities are not release promises.

Read the research ↗QUALITY

Validation evidence

What the application’s checks cover, the browser workflows and the external integration limits.

Inspect validation ↗

BEFORE YOU START

Practical answers.

Automation needs a defined operating envelope. Here is the current one.

Does every CI failure get fixed automatically?

No. The release targets configured Node.js test failures with a complete supported TAP/spec inventory. Unsupported, unreproduced, stale or exhausted work stops with evidence. There is no universal bug-fix guarantee.

What manual work remains?

Initial host setup, scoped credentials, repository policy and a canary check are required. Supported failures then run unattended within that policy. Repository-required human review, expired credentials or unsupported failures can still need an operator.

Can it change tests to make a repair pass?

Candidate edits cannot modify protected tests or configuration. Verification checks the original test inventory and the configured commands before publication.

Does it merge changes without repository approval?

Merge behavior is explicitly configured and uses GitHub’s native permissions and rules. Required reviews are not bypassed. A workflow is resolved only after merged-commit checks pass.

Where do source code and credentials go?

Workers use disposable checkouts from your registered local cache. A bounded source context is sent to your configured repair model; inspect the architecture before using sensitive code. Credentials stay outside the repository worker and must be protected on the host.

Is there a hosted enterprise service or paid plan?

The available application is a single-user local SQLite service. This site does not provide hosted workspaces, account signup, billing or a published pricing plan. Enterprise capabilities remain research.

MAKE THE NEXT FAILURE ACTIONABLE

Start with one repository.
Prove the complete loop.

Run the service, introduce a controlled failure, and inspect the evidence from collection to merged-commit verification.

Follow the setup guide ↗Run BuildMender locally ↗