Skip to content

fix(verify): verify workflow hardcodes contextFiles.specs / contextFiles.design, so since 1.13.2 a custom schema's renamed artifacts read as missing #2027

Description

@blackakula

What happened

The verify workflow template (src/core/templates/workflows/verify-change.ts, shipped in 1.13.2 as /opsx:verify and the openspec-verify-change skill) says itself that contextFiles is keyed by the active schema's artifact ids:

Otherwise, contextFiles is keyed by artifact id, and artifact ids come from the active schema. If contextFiles.specs is absent or empty, mark Spec Coverage, Requirement Implementation Mapping, and Scenario Coverage as not verified; do not treat any of them as clean.

  • If delta specs exist in contextFiles.specs:

Then it hardcodes the id specs. Design Adherence does the same with contextFiles.design.

The CLI does not identify spec artifacts by id. isSpecsArtifactPath (src/core/artifact-graph/outputs.ts) matches on generates under specs/, and skip_specs handling and the apply warnings in instructions both use it. So a valid project-local schema whose spec artifact has another id, here spec, works everywhere in the CLI but breaks the verify prompt. Following the prompt literally, the agent marks Spec Coverage, Requirement Implementation Mapping and Scenario Coverage as Not verified even though readable delta specs are present. A design artifact with any id other than design has the same problem.

apply --json output from the reproduction below (paths shortened):

{
  "schemaName": "renamed",
  "contextFiles": {
    "proposal": [".../changes/demo/proposal.md"],
    "spec": [".../changes/demo/specs/demo/spec.md"],
    "design": [".../changes/demo/design.md"],
    "tasks": [".../changes/demo/tasks.md"]
  },
  "taskTrackingConfigured": true
}

There is no contextFiles.specs key, so the prompt's "absent or empty" branch applies.

Regression in 1.13.2. The hardcoded keys are older: If delta specs exist in contextFiles.specs and If contextFiles.design exists already appear in the templates generated by 1.9.0, 1.13.0 and 1.13.1. What 1.13.2 changed is what happens when the key is missing. Up to 1.13.1, a missing key fell through to the "Graceful Degradation" rules ("If tasks + specs exist… skip design", "Always note which checks were skipped"), so the checks were skipped but the change could still be reported ready. 1.13.2 removed that section and made a missing key mean Not verified, and with a skipped check the final assessment must not claim readiness. So on 1.13.2 a custom schema with renamed artifacts can no longer get a clean verify report, however complete the change is. This seems to have come in with the verification-status rework (#1732), and the wording is unchanged on main.

What you expected instead

The verify workflow should find the spec and design artifacts the same way the CLI does, not by hardcoded ids. For example:

  • Spec artifacts: every artifact whose artifactPaths.<id>.outputPath (from openspec status --json) is under specs/, the rule isSpecsArtifactPath already uses. Their files come from contextFiles.<id>.
  • Design: the schema's design artifact, whatever its id. Or, if there is no reliable way to tell which one that is, fall back to "the artifact(s) whose outputPath is design.md".

The same applies to the "the schema defines no spec artifact" check just above it, which presumably should use the same path-based rule.

Minimal steps to reproduce

  1. Make an empty directory with openspec/config.yaml containing schema: renamed.
  2. Copy the built-in schemas/spec-driven/ (schema.yaml and templates) to openspec/schemas/renamed/. In schema.yaml, set name: renamed, rename the artifact id: specs to id: spec, and update tasks.requires to [spec, design].
  3. openspec schema validate renamed → ✓ Schema 'renamed' is valid
  4. openspec new change demo, then add proposal.md, design.md, tasks.md (- [ ] 1.1 Greet) and specs/demo/spec.md with one ## ADDED Requirements requirement and scenario.
  5. openspec validate demo → Change 'demo' is valid
  6. openspec status --change demo --json → {"id":"spec","status":"done","outputPath":"specs/**/*.md"}
  7. openspec instructions apply --change demo --json → contextFiles has a spec key and no specs key (output above).
  8. Run /opsx:verify demo. The template sends the agent down the "contextFiles.specs is absent or empty → not verified" branch even though the delta specs are readable.

OpenSpec version

1.13.2

Coding agent and model

Claude Code, Opus 5.5

OS and Node version

macOS Tahoe 26.7, Node 24.15.0

Activity

  1. added a commit that references this issue on Oct 5, 2026
    43d23cc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingneeds-triageAwaiting triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions