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.
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.
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. Failure halts the workflow here, and no PR is opened.
Review
PR auto-review evaluates the change against per-domain policy before anything leaves the worktree. A non-approving review blocks promotion: no branch is pushed. When review approves (on by default), the change is committed, pushed, and opened as a draft PR.
Promote
A human reviewer merges the PR, 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.
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. A failed check 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. Promotion is still governed by the hard gates: the incumbent-attested test matrix and the protected platform-authority paths that always require operator review.
- 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.
- A 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.
Safety-first by default
Off by default
The lane must be explicitly enabled, and its only modes are PR-only and disabled. There is no auto-merge.
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.
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.
- A retained evidence record for every run, openable from the CrewWork Control console: status, duration, workflow stage, execution and promotion validation results, a diff summary with changed-file count, the exact commit, and retained artifacts with their expiry.
- Trigger threshold and cooldown telemetry from the self-repair loop.
- 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, and lands fixes on isolated local delivery branches.
Platform self-repair runs the loop described above instead. The distinction is scope: your applications versus the CrewWork platform itself.
Run CrewWork on your own repository.
We are onboarding a small number of design partners. Bring a real repository, your own hardware, and candid feedback.
Or view the architecture for the full technical picture.