sdcorejs-repair-loop

Repair Loop

Shared Protocols

Read _refs/shared/runtime-protocols.md and load only the references needed by the scoped finding.

Thin dispatch skill for applying findings and re-verifying them. The detailed loop lives in _refs/orchestration/tail/repair-loop.md.

Resolve supported tracks from _refs/shared/system-registry.json; do not keep a framework-only enum. Validate every repair with _refs/orchestration/repair-contract.mjs, which binds the original evidence, artifact/implementation owner, execution host, approved write scope, bounded attempts, and repaired evidence linkage.

Workflow

1. Determine and preserve the source of findings: review-code, external-review-feedback, verify-before-done, linter, typecheck, test, or manual.
2. Read _refs/orchestration/tail/repair-loop.md completely.
3. If the source is sdcorejs-review, preserve the original review_context exactly, including track, track_profile, dimensions, mode, file_scope, refs loaded/skipped, probes run/skipped, and package manager. Preserve any test_context, test_status, test_evidence, ui_capture_context, ai_agent_context, simplify_context, convention_context, and artifact_context exactly as source evidence; append new run/case evidence after repair instead of overwriting or upgrading stale/blocked results.
4. Record the working-tree baseline and a visible Repair ledger before edits.
5. Verify each finding is genuine before changing code and classify it as VALID, STALE, MIS-SCOPED, REDUNDANT, UNCLEAR, or CONFLICTING. For external feedback, preserve review ID/reviewer/base revision/file scope and sanitized original feedback, re-read current evidence, then use evaluateExternalReviewFeedback; evidence must bind repository, current revision, safe path, locator, and content hash through the trusted snapshot. Classification fields, normalized conflicts, proposed-change kind, and any migration-decision identity must match a canonical repair-review-assessment:v1 artifact from the independent verifier. Caller relabeling or decision substitution invalidates write eligibility. An incorrect claim receives cited technical pushback and no write.
6. Categorize valid findings into auto, confirm, or user-decision tiers. A review finding must also be explicitly selected for repair and carry matching artifact-backed write authority; confirm and user-decision tiers require their own actor-, finding-, revision-, kind-, and scope-bound approval. Resolve {artifact_ref, approval_hash} only from the trusted approval_artifacts loader and verify its canonical artifact hash; a nonexistent reference, inline body, review output, or boolean is not authorization.
7. For a single VALID finding that becomes a concrete bug investigation, call sdcorejs-debug with the preserved repair_source, review_context, finding ID/source, original commands, and package-manager evidence; consume its redacted debug_context before continuing.
8. Apply only inside the intersection of feedback, finding, and owner-approved scopes. Resolve current and repaired paths, locators, revisions, and hashes from a canonical trusted repository-snapshot artifact. Record a nonempty pre/post hash manifest and independently compared test-contract hashes/ assertion IDs, then derive validation status from a canonical trusted command receipt for the exact source-specific command. Use the smallest relevant discovered command first and associate new evidence with the repaired diff.
9. Iterate until blocking findings are fixed, explicitly deferred, or the reference's 3-pass convergence cap is reached. Blocking means Critical/Important in the default review format, or BLOCKER/REQUIRED in Angular/NestJS code-review table mode.