A generated diff leaves several questions unanswered. Which revision did the model see? Does the reported problem still exist? Did the patch apply to the intended files? Did a test fail because of the candidate or because the baseline was already broken?

ECAI's repair components retain source identity, check whether a finding is still relevant, validate a candidate in a separate Git worktree and preserve a review record. A worktree is another checkout of the same repository, so the candidate can be applied without changing the developer's active files.

Consider a fix for a timeout. The reviewer needs the failing case, the code the model saw, the proposed diff and the commands used to check it. If the baseline already fails to compile, that fact needs to remain visible beside the candidate's result. The workflow gives those details a place to live.

The adoption goal is a review package whose assumptions can be checked. Human acceptance should depend on the actual diff and validation evidence.

The Damage log bridge prepares bounded, redacted observations for an incident learner. It reduces selected metadata and checks that the receiving services are available before forwarding an observation.

At the referenced revision, the bridge calls ecai_log_learning, but that module is absent from the tracked repository. Automatic log-to-incident learning therefore needs a complete matching implementation before it can serve as the entry point for a repair pilot. The patch manager, preflight, verifier and capsule code can still be inspected as separate components.

Begin with a known issue whose diagnosis and expected behavior are already recorded. This lets a team evaluate candidate review without depending on automatic incident diagnosis. Add the log-learning path once its missing service and integration tests are available.

The bridge's redaction covers known credential patterns, including bearer values and common password/token labels. It cannot identify every sensitive fact in an application log. Synthetic incidents make it easier to inspect exactly what the configured model receives before using production material.

The repair preflight compares finding versions and source snapshots. It can mark a stale finding as superseded or block a structurally inconsistent snapshot. The manager tracks queue and active-worker state separately from cumulative counters and includes retry handling.

These are useful controls for long-running work: a finding from yesterday should not silently be treated as today's source. However, the inspected preflight also has explicit allow/deferred paths for missing analysis and some internal failures. It is not a universal fail-closed gate. A deployment must decide how those states affect admission and human review.

The patch verifier checks diff structure and file paths, rejects binary patches, and restricts paths to the DamageBDD, ECAI and erm application trees. It uses Git worktrees and supports compile, EUnit and optional Common Test commands. Integrity checks and baseline comparison help distinguish a candidate change from unrelated working-tree or existing-build problems.

An isolated worktree protects the original checkout from routine patch application. It is not a security sandbox: builds and tests execute code and need an appropriate runtime boundary when candidates are untrusted.

Read the validation steps, warnings and configuration together. Some candidate-neutral baseline failures can be retained as warnings in a result. An accepted disposition is therefore not automatically a clean compile and test run. A baseline problem must remain visible to the person deciding whether the candidate is useful.

The repair capsule includes repository state, problem fingerprint, context, policy and invariants in a deterministic payload. Its content-derived identity lets another process check that it is examining the same package. Local checkout paths are excluded from the stable repository identity.

This is useful for handoffs and retry correlation. The portable commitment is SHA-256; native point mapping is optional. The identity proves neither that the diagnosis is correct nor that the patch repairs every possible failure. Those conclusions depend on the observation, reviewer and tests.

Select a small known bug with a reproducer. Retain the baseline revision, incident input, candidate diff, verification configuration and command output. Ask a second reviewer to reconstruct the decision from that package.

Then change the source so the original finding is stale, and repeat with an independently failing baseline. The workflow should show those conditions explicitly. Record time spent reviewing and explaining a candidate, along with false diagnoses and rejected patches. This produces an adoption measure for the maintenance work your team actually does.

• Incident observation and redaction bridge
• Repair queue and worker management
• Source freshness and preflight decisions
• Candidate and baseline validation
• Persistent review capsule
• ECAI repair and integrity tests

The linked revision contains dedicated repair and integrity tests. They were not executed as part of this prose update. Review the actual command output from your release when deciding whether a candidate is ready to accept.

• Keep the source knowledge behind an answer
• Make the reproducer an acceptance scenario
• Choose a first pilot