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
- Make an empty directory with
openspec/config.yaml containing schema: renamed.
- 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].
openspec schema validate renamed → ✓ Schema 'renamed' is valid
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.
openspec validate demo → Change 'demo' is valid
openspec status --change demo --json → {"id":"spec","status":"done","outputPath":"specs/**/*.md"}
openspec instructions apply --change demo --json → contextFiles has a spec key and no specs key (output above).
- 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
What happened
The verify workflow template (
src/core/templates/workflows/verify-change.ts, shipped in 1.13.2 as/opsx:verifyand theopenspec-verify-changeskill) says itself thatcontextFilesis keyed by the active schema's artifact ids:Then it hardcodes the id
specs. Design Adherence does the same withcontextFiles.design.The CLI does not identify spec artifacts by id.
isSpecsArtifactPath(src/core/artifact-graph/outputs.ts) matches ongeneratesunderspecs/, andskip_specshandling and the apply warnings ininstructionsboth use it. So a valid project-local schema whose spec artifact has another id, herespec, 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 thandesignhas the same problem.apply --jsonoutput 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.specskey, 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.specsandIf contextFiles.design existsalready 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 onmain.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:
artifactPaths.<id>.outputPath(fromopenspec status --json) is underspecs/, the ruleisSpecsArtifactPathalready uses. Their files come fromcontextFiles.<id>.outputPathisdesign.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
openspec/config.yamlcontainingschema: renamed.schemas/spec-driven/(schema.yaml and templates) toopenspec/schemas/renamed/. Inschema.yaml, setname: renamed, rename the artifactid: specstoid: spec, and updatetasks.requiresto[spec, design].openspec schema validate renamed→✓ Schema 'renamed' is validopenspec new change demo, then addproposal.md,design.md,tasks.md(- [ ] 1.1 Greet) andspecs/demo/spec.mdwith one## ADDED Requirementsrequirement and scenario.openspec validate demo→Change 'demo' is validopenspec status --change demo --json→{"id":"spec","status":"done","outputPath":"specs/**/*.md"}openspec instructions apply --change demo --json→contextFileshas aspeckey and nospecskey (output above)./opsx:verify demo. The template sends the agent down the "contextFiles.specsis 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