Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
  • Qualcosa non va?
#2,098 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
markdown, typescript
Ambito
devtools

Direzione di ricerca

La formulazione errata si trova nel passaggio 5 (Spec Coverage) di .claude/commands/opsx/verify.md, nel punto elenco che inizia con "If that file holds no such requirement under this or a near-equivalent name". Lo stesso testo è riportato in .claude/skills/openspec-verify-change/SKILL.md ed è generato da dist/core/templates/workflows/verify-change.js, quindi controlla anche il template sorgente. Il lavoro è completo quando i requisiti REMOVED vengono associati solo tramite intestazione normalizzata, quando si ricorre alla cronologia git nel caso in cui tale intestazione manchi e quando i file generati vengono aggiornati di conseguenza.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
71.6k
Fork
4.9k
Merge medio
2g 6h
PR unite (30g)
82

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Fission-AI/OpenSpec

Tutte le issue di Fission-AI/OpenSpec

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.