bounded-code-repair

Bounded code repair

Make the smallest patch that resolves one defined behavior, then prove the affected behavior with observed checks. A green command, a diff marker, or a model statement alone is not completion evidence.

When to Use

Should trigger

• “Fix the focused failing test in this named module and add a regression test.”
• “Make this small behavior-preserving refactor without changing the public API.”
• “Repair this parser result in the two named files, then run its targeted checks.”

Should not trigger

• “Design and deliver a new multi-area feature.”
• “Audit the repository for security issues.”
• “Update prose only, with no code behavior change.”
• “Explain an unfamiliar repository without requesting a modification.”

Invocation Design

• Invocation mode: model-invoked for a focused code patch with an inspectable target.
• Leading concept: one behavioral objective inside one explicit write boundary.
• Default scope: at most three files and one behavior; a user or governing workflow must explicitly widen it.
• Completion criterion: a minimal in-scope diff and fresh, relevant observed validation both support the stated acceptance criteria.

Inputs and Assumptions

Establish the failing or desired behavior, acceptance criteria, allowed write paths, forbidden/shared paths, relevant symbols and callers, existing tests, exact validation commands, and any version-sensitive dependency surface. Repository instructions, user requirements, observed tool results, and model hypotheses remain separate trust sources.

Portable Workflow

1. State one bug or bounded behavior and its acceptance criteria.
   • Completion criterion: the desired outcome is observable, not merely “improve” or “clean up.”
2. Inspect the target, callers, tests, and relevant configuration before mutation.
   • Completion criterion: the patch target and its expected effect are evidence-backed.
3. Declare the write boundary and forbidden/shared paths.
   • Completion criterion: a path outside the boundary has an escalation path rather than an implicit exception.
4. Check version-sensitive dependencies when the patch relies on a framework, library, runtime, CLI, API, or schema.
   • Completion criterion: advice is tied to the exact installed version and source, or the work stops as unknown.
5. Implement the smallest patch that satisfies the objective.
   • Completion criterion: the final diff has no unrelated cleanup, weakened tests, or broadened behavior without authorization.
6. Run targeted checks, then affected broader checks when warranted.
   • Completion criterion: a host-observed result supports each material criterion; unavailable checks remain unknown.
7. Inspect the final diff and retry at most twice after validation failure.
   • Completion criterion: each retry follows an observed failure; architecture, security, migration, dependency, or multi-subsystem decisions escalate.