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

validate: a scenario with no WHEN/GIVEN or THEN step counts as a scenario and passes

Open
  • Is something wrong?
#2,078 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

@artemasmith is already working on this.

Since Oct 13, 2026.

  • #2079 by @artemasmith — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
testing

Research direction

Read the existing validate checks for empty scenario bodies and the containsShallOrMust convention, along with extractRequirementBody and the delta and main spec readers. Add focused coverage for trigger and outcome keywords, including fenced examples, on both delta and main spec paths. Done means normal validation warns and strict validation fails for scenarios missing both halves, while valid scenarios and keywords inside fences are handled as described.

Written by the indexing model from the issue text.

Description

Description

validate checks that a requirement has at least one scenario, and (since #1857) that a scenario's body is not empty. Nothing checks what the body contains: a scenario whose steps assert nothing passes everywhere.

### Requirement: Credit Notes
The system SHALL issue a credit note when an invoice is voided.

#### Scenario: Invoice voided
- **AND** the ledger is balanced

This validates (--strict included), archives, and lands in the main spec — and it can never fail a test built from it: no step triggers it (no **WHEN**/**GIVEN**) and no step asserts an outcome (no **THEN**). Those are the two halves the canonical format in docs/concepts.md and the generated templates always include, and the two halves the empty-scenario hint already prescribes ("add its steps, e.g. - **WHEN** ... and - **THEN** ...").

Reproduction

In a project created with openspec init + openspec new change edit, with a valid proposal and tasks, the delta openspec/changes/edit/specs/billing/spec.md:

## ADDED Requirements
### Requirement: Credit Notes
The system SHALL issue a credit note when an invoice is voided.

#### Scenario: Invoice voided
- **AND** the ledger is balanced

openspec validate edit --strict --json   # "valid": true
openspec archive edit --yes              # succeeds

Control: adding - **WHEN** an invoice is voided / - **THEN** a credit note is issued is of course valid too — the point is that the first form is indistinguishable to every gate.

Expected

A scenario with neither a trigger step nor an outcome step is reported at authoring time. Proposal:

  • WARNING in normal mode — the same posture as the missing SHALL/MUST keyword: guidance, not a verdict change (so plain validate and archive keep agreeing).
  • Fails --strict, which already fails on any warning.
  • Both paths: delta ADDED/MODIFIED blocks and main specs, so the delta and spec readers stay in parity.
  • Fence-aware: a WHEN inside a fenced example is documentation, not a step — the masking extractRequirementBody already applies to requirement text.
  • Uppercase, word-bounded keyword matching, exactly the containsShallOrMust convention.

Positioning

  • Not #1720 (pre-generation quality gate: EARS grammar, ambiguity, cross-requirement consistency — in design review). This is the minimal deterministic slice — does the scenario have its two halves at all — with no grammar and no judgment.
  • Not the soft "specs define measurable scenarios" check in the /opsx:refine work (#783 / #893), which runs across all artifacts after drafting. This is a form check at authoring time, next to the scenario-shape checks validate already does.
  • The natural continuation of #1857: that issue made "a scenario must have a body" true on both paths; this one makes "the body must be a scenario" true.

We hit this maintaining a spec contour on top of OpenSpec: a note-shaped scenario passes every gate, and only a human reading the spec notices it asserts nothing.

Dominant language
TypeScript
Stars
71.6k
Forks
4.9k
Avg merge
1d 20h
Merged PRs (30d)
63

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.