validate accepts a MODIFIED requirement whose header matches no requirement in the target spec

[rafica11]

openspec 1.5.0.

validate checks a MODIFIED delta's SHAPE but never that its ### Requirement: header matches anything in the target spec. A header typo, or a requirement renamed upstream after the delta was written, passes validation and is then applied by archive as an ADDITION — so the original requirement survives alongside its replacement, and the spec ends up holding two contradictory SHALL statements with nothing recording which one won. Silent, and permanent once archived.

REPRO

1. openspec/specs/example-cap/spec.md:

   Requirements

   Requirement: Widgets are validated

   The system SHALL validate widgets.

   Scenario: A widget is validated

   • WHEN a widget arrives
   • THEN it is validated

2. openspec new change fix-widgets

3. openspec/changes/fix-widgets/specs/example-cap/spec.md:

   MODIFIED Requirements

   Requirement: Widgets are validated thoroughly

   The system SHALL validate widgets thoroughly.

   Scenario: A widget is validated

   • WHEN a widget arrives
   • THEN it is validated thoroughly

   (header deliberately does not match the baseline)

4. openspec validate fix-widgets -> "Change 'fix-widgets' is valid"
   openspec validate fix-widgets --strict -> "Change 'fix-widgets' is valid"
   openspec archive fix-widgets -y -> applied as an addition

RESULT: example-cap/spec.md now contains both "Widgets are validated" and
"Widgets are validated thoroughly".

EXPECTED: validate fails, naming the header that matches nothing. The intent
already exists in the docs — openspec instructions specs says "Common pitfall:
Using MODIFIED with partial content loses detail at archive time" and "Ensure
header text matches exactly" — there is just no check behind it.

Two adjacent cases worth the same treatment: a MODIFIED block byte-identical to
its baseline (a copy-paste that forgot the edit, archives as a no-op but reads as
a decision), and an ADDED header that collides with an existing requirement,
which reaches the same duplicate end state from the other direction.

SECONDARY REQUEST
openspec show <change> --json --deltas-only omits the requirement header:
deltas[].requirement has only text and scenarios, and description is
"Modify requirement: ". Since header matching is what MODIFIED depends on,
external tooling cannot match a delta to its baseline requirement from the JSON
and has to re-parse the markdown. Exposing the header/name would let people build
delta review on the CLI's own parser instead of a second implementation.

CONTEXT
Hit this while reviewing a change with a MODIFIED delta. A delta file is a new
file, so every diff view renders it all-added and the modification is invisible;
reviewers cannot see which words moved without reconstructing the before-state by
hand. A --diff-style view over deltas plus the validation above would cover
both problems. Happy to contribute a PR if the approach sounds right.

---

Unrelated, found while reporting this: openspec feedback "<msg>" --body "<text>" fails with could not add label: 'feedback' not found and creates nothing. This repo's labels are bug / documentation / duplicate / enhancement / …, with no feedback label, so the CLI's own feedback path is unusable. Hence the manual issue.

[rafica11]

Two more findings from the same area, both about archive vs the openspec-sync-specs skill. openspec 1.5.0.

1. archive cannot archive a change whose deltas were already synced.

The sync skill's closing output says "Main specs are now updated. The change remains active — archive when implementation is complete." But archive re-applies the deltas, so every ADDED requirement sync already promoted collides:

<capability> ADDED failed for header "### Requirement: <name>" - already exists
Aborted. No files were changed.

Nothing is corrupted — it aborts cleanly — but the advertised path dead-ends: sync now, and the change can never be archived as written. That also contradicts the sync skill's own guardrail, "The operation should be idempotent - running twice should give same result."

Repro: create a change with an ## ADDED Requirements delta → apply it with the sync skill (or hand-edit the main spec to match) → openspec archive <change> --yes.

Workaround, for the record: relabel the delta's ## ADDED Requirements heading to ## MODIFIED Requirements. The content is already correct; only the operation name is stale. Archive then succeeds — ~ N modified, + 0 added, requirement counts unchanged, change moved to changes/archive/.

Suggested fix: treat an ADDED requirement whose header already exists and whose content matches as satisfied rather than a collision — which is what the sync skill already does ("If requirement already exists → update it to match (treat as implicit MODIFIED)").

2. Two of your own surfaces disagree on whether MODIFIED may be partial.

openspec instructions specs says a MODIFIED block "MUST include full updated content" and warns "Common pitfall: Using MODIFIED with partial content loses detail at archive time."

The openspec-sync-specs skill says the opposite: "To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios. The delta represents intent, not a wholesale replacement."

Both are reachable by an agent in the same repo, and which one is correct depends on whether a human/agent applies the delta or archive does. Worth making one of them authoritative, or scoping each explicitly to its applier.

[ryandemelo]

I reran this repro on current main (1.13.2) and most of it has changed since 1.5.0.

Archive no longer applies the mismatched MODIFIED block as an addition. It stops with MODIFIED failed for header "### Requirement: Widgets are validated thoroughly" - not found, leaves the spec alone, and exits 1. So the duplicate requirement from step 4 can't happen anymore.

Validate now sees it too. Since #1710 it runs archive's merge in memory and prints:

ℹ [INFO] example-cap/spec.md: Archive would refuse this delta: example-cap MODIFIED failed for header "### Requirement: Widgets are validated thoroughly" - not found

It stays INFO and exits 0, even with --strict, on purpose. A MODIFIED header can legitimately point at a requirement another active change adds, which only exists once that change archives first (#1112). Failing validate there would block a valid stack of changes. Whether a lone typo should fail, and how to tell it apart from that case, is the open question in #1112.

Your secondary request is #1971: show --json now names every requirement and scenario, so tools can match a delta to its baseline without parsing the markdown again. The fix is in #1972.

[clay-good]

Closing as a duplicate of #1112. Thanks for the detailed repro. As @ryandemelo confirmed above on main (1.13.2), the data-loss half is fixed: archive now refuses a MODIFIED header that matches nothing, and validate reports it at INFO level (#1710). What's left, making validate fail on a lone typo without blocking valid stacked changes, is exactly the open question in #1112, so let's continue there. The JSON-names request is tracked in #1971 / #1972.