fix(parser): refuse malformed RENAMED pairs

[dwin-gharibi]

Closes #1805.

Why

parseRenamedPairs walked ## RENAMED Requirements carrying a single mutable
{ from, to } and dropped whatever did not fit:

• a second FROM: overwrote an unpaired first one
• a TO: with no pending FROM: was discarded
• a trailing FROM: was forgotten when the section ended

Nothing recorded any of it, and validateChangeDeltaSpecs only ever iterates
plan.renamed — the pairs that did form — so the validator structurally could
not see the dropped lines. Two outcomes, both silent:

• A requested rename never happens. TO: written before its FROM: yields
  no pair at all; validate reports the change valid and archive exits 0
  having renamed nothing.
• The wrong requirement is renamed. With FROM/FROM/TO/TO — a natural way to
  write a batch rename, listing the old names then the new ones — the second
  FROM pairs with the first TO. Archive renames a requirement the delta
  never named, under a name the author wrote for a different one, and reports
  → 1 as though exactly one intended rename occurred.

Verified against a project built entirely by openspec init + openspec new change: the body under the renamed header was the other requirement's body.

What Changes

• A rename pair is a FROM: followed by a TO: with no second FROM: between
  them — the shape the documented format uses.
• Every FROM:/TO: line that never formed a pair is recorded in a new
  DeltaPlan.unpairedRenames entry (side, name, 1-based line).
• validate <change> reports each one as an ERROR with its line number, so
  the author learns at authoring time.
• buildUpdatedSpec throws on any unpaired entry, so archive refuses rather
  than applying a pairing it guessed. This is deliberate: with interleaved lines
  the guessed pairing rewrites the wrong requirement, and a spec rewrite is not
  something to do on a guess.

Well-formed renames are unaffected, including several consecutive pairs and the
no-bullet form.

Testing

test/core/parsers/renamed-pair-integrity.test.ts — 15 tests, written first and
watched fail (13 failed / 2 passed before, 15 passed after).

Edge cases covered:

• the documented order, and several consecutive pairs (controls)
• TO: before FROM:; a FROM: displaced by another FROM:; a trailing
  FROM:; fully interleaved FROM/FROM/TO/TO
• exact line numbers on every reported entry
• FROM/TO inside a code fence are ignored, and report nothing
• a RENAMED section with no FROM/TO lines, and a delta with no RENAMED section,
  both report nothing
• buildUpdatedSpec still applies a well-formed rename, and throws with the
  offending line number for each malformed shape
• validate reports the ERROR, and leaves a well-formed rename clean

Full suite green on this branch.

Changeset

Not added. Per .changeset/README.md the default path is the normal release
cadence. Worth noting for release notes if one is added: this turns a previously
silent mis-apply into a hard error, so a change carrying a malformed RENAMED
section that used to archive will now be rejected until the pairing is fixed.

Summary by CodeRabbit

• Bug Fixes
  • Detects incomplete, reversed, or incorrectly ordered requirement rename entries instead of silently ignoring or misapplying them.
  • Reports clear validation errors identifying the missing FROM: or TO: entry and the required consecutive format.
  • Prevents malformed rename sections from being applied when rebuilding specifications.
  • Continues to process valid consecutive rename pairs successfully.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: 24f7b8d0-aa83-4226-93b6-2ccbe550be45

📥 Commits

Reviewing files that changed from the base of the PR and between 9cc3cb8 and ce686b5.

📒 Files selected for processing (1)

• test/core/parsers/renamed-pair-integrity.test.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• test/core/parsers/renamed-pair-integrity.test.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review.

---

📝 Walkthrough

Walkthrough

The parser now records unpaired FROM: and TO: entries. Spec rebuilding rejects malformed rename sections. Change validation reports each unpaired entry. Tests cover valid, malformed, reordered, and incomplete rename cases.

Changes

RENAMED Pair Integrity

Layer / File(s)	Summary
Record unpaired rename entries src/core/parsers/requirement-blocks.ts	DeltaPlan now exposes unpairedRenames. The parser records displaced, orphaned, and trailing rename entries.
Reject and report malformed pairs src/core/specs-apply.ts, src/core/validation/validator.ts	Spec rebuilding rejects incomplete pairs. Change validation reports each unpaired entry and its missing counterpart.
Validate rename integrity test/core/parsers/renamed-pair-integrity.test.ts	Tests cover parsing, successful renames, malformed ordering, code fences, incomplete entries, and validation errors.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to ce686

Malformed RENAMED pairs are rejected rather than guessed, while valid rename syntax remains supported. No unresolved merge-readiness risk is identified.

Sequence Diagram(s)

sequenceDiagram
  participant DeltaSpec
  participant parseDeltaSpec
  participant buildUpdatedSpec
  participant validateChangeDeltaSpecs
  DeltaSpec->>parseDeltaSpec: provide RENAMED entries
  parseDeltaSpec-->>buildUpdatedSpec: unpairedRenames
  buildUpdatedSpec-->>DeltaSpec: reject malformed rename
  parseDeltaSpec-->>validateChangeDeltaSpecs: unpairedRenames
  validateChangeDeltaSpecs-->>DeltaSpec: report missing counterpart

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the primary change: rejecting malformed RENAMED pairs.
Linked Issues check	✅ Passed	The changes satisfy issue #1805. They record unpaired FROM/TO entries, report validation errors, reject malformed renames during spec rebuilding, preserve valid pairs, and add coverage for the identif…
Out of Scope Changes check	✅ Passed	The parser, validation, archive behavior, and tests are directly related to preventing malformed RENAMED pairs from being silently dropped or misapplied. No unrelated changes are identified.
Docstring Coverage	✅ Passed	Docstring coverage is 83.33% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 6 functions across 4 files.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[alfred-openspec]

Reviewed rename pairing, validation, and archive refusal behavior and ran the focused 15-test suite locally. Malformed pairs now fail safely while valid consecutive pairs remain unchanged. Approved.