A platform that fixes its own bugs
If CrewWork can safely repair defects in its own backend, frontend, and infrastructure code, you can trust its approach with yours. Platform self-repair (historically called self-modification) runs the full loop: detection, fix generation, tiered validation, and draft pull request creation.
It works under stricter controls than any project fix ever sees. A candidate cannot edit the Compose files, Dockerfiles, or quality-gate configuration used to grade it. That entire control surface is baked read-only into the trusted orchestrator image and overlaid onto every candidate before validation runs, so validation only ever exercises the candidate’s actual source and tests.
This page is the primary deep dive into the platform self-repair loop. For full system context, read the Platform and technical white paper.
From runtime error to validated fix, with no human filing a ticket
Platform self-repair stays tightly constrained. Intake is automatic: errors become deduplicated, priority-scored triage records with no one filing a ticket. From there, a run starts when an admin launches a fix manually, or automatically once an admin has opted into the platform’s own auto-trigger threshold; either path stays inside the same cooldown window and daily budget. The lane ships disabled by default. Every output is observable and reversible.
- Designed for long-term stability rather than opportunistic automation.
- Bounded execution with explicit budgets and scoped mutation targets.
- PR-only output with audit trails for every decision.
- Built to operate safely even when external dependencies degrade.
Intake
Platform-level runtime errors arrive via the Sentry webhook, are HMAC-verified, fingerprinted, and deduplicated before becoming triage records.
Generate
A fix candidate is produced in an isolated git worktree, using structured error context: fingerprint, triage history, and explicit target files. The engine reads repository code directly, within a bounded scope, explicit budgets, and scoped mutation targets.
Validate Runtime
The candidate is applied in the worktree and sanity-checked with smoke tests before the heavier matrix runs.
Validate Matrix
A tier-appropriate test matrix runs in isolated containers. Matrix is a hard gate: failure means the workflow halts here and no PR is opened.
Review
PR auto-review evaluates the change against per-domain policy before anything leaves the isolated worktree. A non-approving review blocks promotion outright: no branch is pushed and no PR is opened. When review approves (auto-review is on by default), the change is committed, pushed, and opened as a draft PR marked ready for human review.
Promote
A human reviewer merges the PR. There is no auto-merge mode: a human approves every change before it ships, and every merge is bound to the exact GitHub account that performed it.
Close
Worktree, branch, and execution state are cleaned up. Every commit is durably checkpointed the moment it is created, before the branch ref is even published, so a crash mid-promotion can always resume from a known state. The run is finalized for audit: every stage attempt is persisted on the workflow execution record, and validation outputs, diffs, and PR decisions are captured in a durable run-bundle artifact.
The platform decides how hard to test based on what you touched
Every proposed change is auto-classified into a validation tier from its file list. Docs and Markdown tweaks ride the fast shadow pass. Touching high-risk paths automatically escalates to the full matrix. No human picks the tier, and no fix sneaks through with weak validation.
Shadow
Changes touch only docs/ or Markdown files
Scoped ESLint plus a TypeScript type-check and the full Vitest suite, which always runs and is never skipped. Runtime and promotion gates still run after the shadow pass.
Baseline
Default tier for everything else
Unit, integration, static analysis, security checks.
Full
Changes touch high-risk paths (api/, core/, db/, docker/, migrations/, dependency manifests)
Adds system, load, and end-to-end tests on top of the baseline.
Matrix is a hard gate. Passing test and security evidence carries a 12-field attestation before it counts as passing, so a mismatched or forged result invalidates itself. Those fields include the exact run, candidate tree hash, command line, exit code, and a recomputed report hash.
If any required check fails, the workflow halts at Validate Matrix, no PR is opened, and the run is recorded with a verifiable failure reason.
Every candidate is compared to the exact code it would replace
Beyond passing its own tests, every self-repair candidate is scored against its exact trusted parent across nine tracked dimensions. Three are live, per-run diffs against the parent: test evidence coverage, external exposure, and database schema shape. The rest, including quality debt and resource bounds, are recorded as preserved by construction, because separate hard gates already block a candidate from touching those surfaces.
Each comparison is captured in a durable, hash-verified record attached to the run for audit. Automatic promotion is still governed by the hard gates: the incumbent-attested test matrix, protected platform-authority paths that always require operator review, and the durable pre-publication checkpoint.
- The quality gate does not just check the candidate in isolation. It exports the exact parent commit and diffs the two, so a change that adds a new lint, type-check, or security suppression to quiet a failing check is caught and blocks promotion.
- The candidate’s effective HTTP surface (routes, methods, middleware) and database schema (tables, columns, constraints, indexes, enums) are diffed against the parent using a dedicated probe that loads the platform’s real application object and schema metadata for both trees. The result becomes part of the run’s audit trail.
- The pre-publication checkpoint refuses to let a candidate advance toward a commit or pull request unless the full nine-dimension comparison is present and matches the recorded validation result exactly.
- Merge attribution is enforced: a merge reported without an identifiable approving GitHub account is treated as unresolved and never silently accepted.
Safety-first by default
Off by default
The lane must be explicitly enabled, and its only modes are PR-only and disabled. No direct merges: every change is PR-only.
Bounded by budget and cooldown
Manual launches are admin-triggered; the platform’s own auto-trigger path is a separate opt-in that ships off by default. Either way, every run stays inside the same budget and cooldown limits described above.
Write-scope gate
A fail-closed write-scope gate enforces the declared target files for each fix, and any change to a protected platform-authority path is routed to mandatory operator review before a matrix runs. A run that produces no material change fails rather than opening an empty PR.
No shared credentials
Validation containers that execute candidate code never receive platform service credentials.
Failed attempts are discarded
A failed validation attempt is discarded with its isolated worktree, and the incumbent build is never touched.
Fully auditable
All actions, health changes, and run metadata are auditable.
Full visibility into every autonomous decision
Platform self-repair integrates with the same visibility model as the rest of CrewWork: explicit status, recovery points, and clear degraded paths.
- Self-repair run history with status, duration, and validation outputs.
- A retained evidence record for every run, openable from the CrewWork Control console: workflow stage, execution and promotion validation results, a diff summary with changed-file count, the exact commit, and retained artifacts with their expiry.
- Threshold and cooldown telemetry from the self-repair loop.
- Integration health status with staged visibility and remediation guidance.
- PR auto-review latency and outcome metrics exported to Prometheus, plus per-stage run timelines reconstructed from workflow execution records.
Want to compare with project HotFix?
The two lanes share a guardrail philosophy but run on different machinery. Project HotFix launches remediation programs through the Infinite Coder delivery-runtime engine with its acceptance and completion gates: fixes land on isolated local delivery branches, and push stays disabled by default, so nothing leaves your environment until you opt in.
Platform self-repair runs the loop described above instead. Either way, nothing merges without your review. The distinction is scope: your applications versus the CrewWork platform itself.
Bring your next piece of work.
Discuss what you want to build, repair, or improve, along with your deployment needs and access to CrewWork.
Or view the architecture for the full technical picture.