mirror of
https://github.com/Fission-AI/OpenSpec.git
synced 2026-10-02 05:24:34 +08:00
336414665f
* fix(verify): stop reporting removed requirements as missing Verify walked every "### Requirement:" in the delta specs and looked for an implementation of each one, whatever section it sat under. A REMOVED requirement that the change had removed correctly came back as CRITICAL "Requirement not found", with a recommendation to implement it. An agent that follows the report puts back the behavior the change just deleted. Verify now notes the delta section of each requirement first. ADDED and MODIFIED keep the existing checks. REMOVED is checked the other way round: finding nothing is the expected result, and it is only critical while the behavior is still in the code. RENAMED only changes a name, so the old name is not reported as missing. Scenario coverage skips removed requirements, since there is nothing left to cover. Archive and sync already handle each section on its own terms; verify was the one step in the loop that did not. Closes #1959 * docs(specs): scope the general verify scenarios to ADDED and MODIFIED The Spec coverage, Requirement implementation mapping and Scenario coverage scenarios still told the verifier to check every requirement in the delta specs, which contradicts the Removed requirement scenario added in the previous commit. A verifier following them would repeat the #1959 failure. * fix(verify): report a removal-only change as ready when nothing remains With #1732 merged, a change whose delta specs only remove or rename requirements left Requirement Implementation Mapping and Scenario Coverage with nothing to check. The "no usable requirements" rule then marked them not verified, so verify never reported the change ready, the exact case #1959 describes. Those two checks are now not applicable when the readable delta specs hold REMOVED or RENAMED requirements and no ADDED or MODIFIED ones. An empty or unparseable delta still marks them not verified. Keyword matches in openspec/ artifacts, docs, or code that serves only the Migration note or an ADDED requirement are no longer evidence by themselves that a removed requirement is still implemented; a code path that still delivers the removed behavior is reported even when shared. The summary counts removals separately from covered requirements. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(verify): check a renamed requirement's behavior against its baseline A RENAMED entry only told verify not to report the FROM name as missing, and a rename-only change marked the correctness checks not applicable. Nothing checked that the renamed requirement's behavior was still implemented, so verify could report readiness unchecked. Spec Coverage now reads the baseline requirement from the main spec (under the FROM name, or the TO name once synced) and checks that its behavior is still implemented, without requiring code symbols to be renamed. A missing behavior is CRITICAL "Renamed requirement not found"; an unreadable baseline marks the entry not verified. A TO name that also appears under MODIFIED is still checked there. Regression tests cover the skill template, the command template, and the committed skills/ mirror. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>