Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug] /opsx:verify accepts a near-equivalent heading as the REMOVED baseline, so a replacement requirement is reported as still implemented

Open Beginner friendly
  • Is something wrong?
#2,098 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
markdown, typescript
Domain
devtools

Research direction

The faulty wording is in step 5 (Spec Coverage) of .claude/commands/opsx/verify.md, in the bullet that begins "If that file holds no such requirement under this or a near-equivalent name". The same text is mirrored in .claude/skills/openspec-verify-change/SKILL.md and generated from dist/core/templates/workflows/verify-change.js, so check the source template as well. Done means REMOVED requirements are matched only by normalized heading, with the git-history fallback taken when that heading is absent, and the generated files are updated to match.

Written by the indexing model from the issue text.

Description

Summary

Since the fix for #2067, /opsx:verify reads the baseline of a REMOVED requirement from the main spec before searching the codebase. The new text accepts a "near-equivalent" heading as the baseline. When the REMOVED requirement has been replaced by a similarly named ADDED requirement and /opsx:sync has already updated the main spec, the near-equivalent heading is the replacement, not the removed requirement. The verifier then searches for the replacement's behavior, finds it, and reports the removed requirement as still implemented.

Version

@fission-ai/openspec 1.14.2, Claude Code delivery (skills + commands), spec-driven schema.

Where

.claude/commands/opsx/verify.md, step 5 Spec Coverage, the "For each REMOVED requirement" bullet that begins "If that file holds no such requirement under this or a near-equivalent name", and the mirrored .claude/skills/openspec-verify-change/SKILL.md. In the package the text comes from dist/core/templates/workflows/verify-change.js.

The bullet before it already says to match "by normalized name"; the "near-equivalent" wording in the next bullet contradicts that and decides the fallback to history.

Repro

  1. Main spec has ### Requirement: Monthly export in xlsx.
  2. A change has a delta with ## REMOVED Requirements for Monthly export in xlsx and ## ADDED Requirements for Monthly export in xlsx as attendance sheet.
  3. /opsx:sync is run, so the main spec now holds only Monthly export in xlsx as attendance sheet.
  4. Run /opsx:verify.

Expected: the exact normalized REMOVED heading is absent from the main spec, so the baseline is recovered from the file's git history (the removed requirement's own body and scenarios), and the search is for that behavior.

Actual: the replacement heading counts as a near-equivalent name, so its body is used as the baseline. The code legitimately implements it, so the removal is reported as not done.

Why it matters

The failure is a false "still implemented" on a removal that was done correctly, driven by a legitimate pattern (replace a requirement by a more specific one). It only appears after a sync, which is exactly the case the history fallback was added for.

Suggested fix

Match the REMOVED heading by its normalized name only. If the main spec has no requirement with that normalized heading, go to the history fallback; do not accept a similarly named heading. If a rename is involved, that is the RENAMED operation's job.

Dominant language
TypeScript
Stars
71.6k
Forks
4.9k
Avg merge
2d 6h
Merged PRs (30d)
82

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Fission-AI/OpenSpec

All issues in Fission-AI/OpenSpec

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.