ECAI Repair Workflows: Make a Generated Patch Easier to Review

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.

The source reviewed on 7 October includes ecai_log_learning and its focused tests. The existing code-security supervisor starts it after the learning store and codebase learner. The bridge forwards eligible observations through observe/1 and retains pending entries when that handoff reports an error.

The learner correlates a fingerprinted event with module analysis and the current knowledge card, then asks the model pool's audit role for a bounded incident record. That record retains the observation, analysis/source digests, model metadata, suggested causes and proposed verification steps. It explicitly records automatic_execution => false. Producing an incident record does not execute a command, apply a repair or prove the model's diagnosis.

Queue state and the active item are checkpointed through the disk-backed ecai_learning_store. Restart recovery puts the interrupted item back into pending work. Admission checks the checkpoint result before replying with success. Fingerprint deduplication and retry limits help control repeated work, while queue overflow can evict older pending entries. Checkpointing is therefore not a guarantee that every observed incident will be processed.

This closes the earlier source-availability gap, but the learner and its test files are still absent from the verified public revision. Their paths and fingerprints appear in the dated integration review. Confirm that a deployment contains them before using incident learning as its entry point.

The review also found a concrete input-validation mismatch: the normaliser accepts any atom as a module, including undefined, while the test expects an undefined module to be rejected. That condition needs correction and a passing test before describing direct learner admission as enforcing a concrete target. The bridge's own target checks do not replace validation at the learner API.

Begin with a known issue whose diagnosis and expected behaviour are already recorded. Check the incident card and its source identity before evaluating a candidate patch. Model suggestions remain hypotheses until an appropriate reproducer and validation run support them.

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. The 7 October review also inspected ecai_log_learning_tests.erl and damage_ecai_log_bridge_tests.erl in the current source. They cover normalisation, redaction, bounded model-card output, prompt construction and bridge helper behaviour. They do not establish a complete model-backed incident-to-repair run or recovery result, and none were executed for this documentation update. Review 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