[dmccoystephenson]

Summary

Two structural additions to the generated dev-loop template, grounded in RESEARCH.md §3 (localization is the real bottleneck on uncontaminated benchmarks):

1. Phase 3 — Localization verification. Before writing any code, list the target files and verify each with test -f + a grep for the named surface area from the issue. If the issue says the bug is in validatePermission and grep finds nothing, the localization is wrong — stop and re-triage.

2. Phase 8 — Regression gate. For each Closes #N that describes a bug or incorrect behavior, require a new/modified test (or validation step, for projects whose external anchor is manual validation) in the diff. Hardens the Phase 4 Tests-fix rubric item into a merge-time gate.

Generalized cleanly with the {{EXTERNAL_SIGNAL_LABEL}} infrastructure shipped in PR #28: test-having repos check for a new test, no-CI repos check for a new validation step.

Closes #18

Test plan

• Phase 3 begins with a "Localization verification" step listing 2 sub-steps (existence + surface-area grep) with a concrete example (RESEARCH.md §3 cross-reference)
• Phase 8 has a regression-test gate as the first block, before the do-not-auto-merge check
• No new {{placeholders}} (placeholder count unchanged); the regression gate reuses {{EXTERNAL_SIGNAL_LABEL}} indirectly via the prose
• This PR's own localization was verified: target file create-dev-loop.md exists, contains "Phase 3 — Implementation" and "Phase 8 — Merge" headings
• Diff size 12 LOC across 2 files — well under the soft ceiling (400 LOC / 10 files) shipped in PR Add hard PR scope gates: LOC ceiling, do-not-auto-merge paths #30
• Per the rule shipped in PR Promote 'verify each Closes #N' to template Phase 4 #26, ran gh issue view 18 and confirmed title/body match
• Per the rule shipped in PR Track implementation outcomes back into RESEARCH.md #27, added an Implementations entry under RESEARCH.md §3
• Per the gate shipped in PR Add hard PR scope gates: LOC ceiling, do-not-auto-merge paths #30, ran git diff --name-only origin/main...HEAD and confirmed no matches against do-not-auto-merge list

Fixture-validation note

#18's test plan asks for "a fixture issue where the agent would naively localize to the wrong file" — same as #17's fixture ask, this requires fixture tooling that doesn't exist. The localization check is currently authority-based, not enforced. A pre-edit check could be wired into a hook in the future.

---

drafted by Claude on behalf of Daniel Stephenson

[dmccoystephenson]

Self-review rubric:

• Scope: PASS — 2 files (create-dev-loop.md, RESEARCH.md); each line directly maps to an AC item or the CLAUDE.md PR-27 Implementations rule.
• Tests-new: PASS — the localization step is exercised by this PR's own pre-edit verification (grep for Phase 3 — Implementation and Phase 8 — Merge headings before editing).
• Tests-fix: N/A — not a bug fix.
• Sibling structure: PASS — new Phase 3 localization block matches the 'Bold label. explanation + numbered list' pattern of other Phase 3 sub-blocks; new Phase 8 regression gate matches the bold-label structure of the do-not-auto-merge sibling below it.
• Sibling renames: N/A — no identifiers renamed.
• Docs: PASS — Phase 7 sources of truth (create-dev-loop.md, README.md) reviewed; README doesn't enumerate inner Phase steps at this granularity (correctly stays high-level). RESEARCH.md §3 gets an Implementations entry per the CLAUDE.md PR-27 rule.
• Issue resolution: PASS-with-deferral — AC 1 (Phase 3 localization step) met; AC 2 (Phase 8 regression gate) met; AC 3 (fixture test) explicitly deferred in PR body, same reason as PR #30.
• Validation: PASS — placeholder count unchanged; new content uses only inline backticks (no new fenced blocks to escape); phase numbering unchanged.
• Placeholder-consistency: N/A — no new placeholders.
• Escaping: N/A — no fenced code blocks added.

Adversarial probe — 'Does the regression gate work for test-less repos like create-dev-loop itself?' The gate prose says '(or, for projects whose external anchor is manual validation, a new validation step)'. Confirmed by re-reading the new text: the OR clause keeps the gate applicable to projects without a test suite — verifiable by checking whether the diff adds a new test-plan checkbox or updates the project's manual-validation guidance. The generalization works.