sdcorejs-repair-loop

name	sdcorejs-repair-loop
description	Repair workflow for findings from sdcorejs-review or sdcorejs-ship verify-before-done. Use for fix findings/review issues/critical issues, or auto after findings. Verifies each finding, fixes systematically, re-runs source-specific verification, and iterates until resolved or deferred. Applies to angular, nestjs, nextjs. Runtime-localized.

Codex path resolution: Resolve ../_refs/... relative to this SKILL.md. Resolve another SDCoreJS skill by opening the sibling folder ../<skill-name>/SKILL.md.

Repair Loop

Shared Protocols

Before executing this skill:

1. Read and apply ../_refs/shared/tasklist.md for non-trivial execution tasks.
2. Read and apply ../_refs/shared/persona.md if a project persona exists.
3. Read and apply ../_refs/shared/project-context.md for project memory, resume checkpoints, summaries, specs/plans, tasks, and relevant memories.
4. Current user request, current files, diffs, logs, failing tests, and command output override stored context.
5. Before presenting user-facing choices, approval gates, yes/no questions, or mode selections, read and apply ../_refs/shared/user-choice-prompt.md so options are presented as sequential numbered choices.

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

Workflow

1. Determine and preserve the source of findings: review-code, 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.
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, or UNCLEAR.
6. Categorize valid findings into auto, confirm, or user-decision tiers.
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 the allowed tier for the current pass, then re-run the verification required by the preserved source context.
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.

Handoff

• After convergence, return to the caller's tail chain.
• If invoked from a finish-gate review, complete write-producing documentation, auto-docs, user guide, task tracker, and memory steps first, then run sdcorejs-ship (verify-before-done mode) and sdcorejs-ship (branch-ready mode) as the final read-only gate over the final diff. No writes after branch-ready unless branch-ready is run again.
• If invoked directly by the user, run discovered verification commands and offer explicit numbered next steps: run sdcorejs-ship (verify-before-done mode), stop after the repair summary, or prepare a commit only after ship and branch-ready pass for the current HEAD or diff.
• If sdcorejs-debug was used inside the loop, carry its debug_context into the repair summary and subsequent ship gates.
• If findings do not converge after the capped loop, stop and ask the user to choose the next direction.
• Do not hand off directly to sdcorejs-git (commit mode) by default. A commit is allowed only after ship verification and branch-ready passed in the current session for the current HEAD or diff, or after the caller explicitly requested a commit after those gates with any verification deferral recorded.

Rules

• Silence is not approval.
• Do not silently apply user-decision findings.
• Do not edit tests merely to make production code pass.
• Do not hide stale, mis-scoped, redundant, or unclear findings; report them separately.
• Do not claim convergence without re-running the source-specific verification.
• Do not downgrade or reclassify the original review_context; repair-loop must not change a plain-* review into an SDCoreJS-specific review during re-verification.