Repository navigation
openspec new change prints Schema: spec-driven even when config.yaml selects a custom schema #2117
Description
Version
1.14.3 (also present on main @ c794978f)
What happens
With schema: <custom-schema> set in openspec/config.yaml, openspec new change <id> prints
Schema: spec-driven
even though artifact resolution (instructions, status) correctly uses the custom schema.
Why (two root causes)
src/commands/workflow/new-change.tscomputes the resolved value but persists the raw flag instead:
146: const resolvedSchema = options.schema ?? root.defaultSchema; // spinner only
152: schema: options.schema, // undefined when no --schema- Fixing line 152 alone is not enough:
root.defaultSchemais hardcoded to'spec-driven'and never reflectsconfig.yaml:
// src/core/root-selection.ts:66 (type at :64, same literal at :127)
defaultSchema: 'spec-driven',The schema configured in config.yaml is only reachable via readProjectConfig(projectRoot)?.schema, the route instructions.ts already takes.
Fix
Resolve from the project config and persist the resolved value:
const projectConfig = readProjectConfig(projectRoot);
const resolvedSchema = options.schema ?? projectConfig?.schema ?? root.defaultSchema;
...
schema: resolvedSchema,Cosmetic only, but it misleads agents (and humans) auditing which schema a change was created under; I hit exactly that during a custom-schema run. A version-pinned patch with this fix (verified end to end: JSON payload, persisted .openspec.yaml, and text output) lives at https://github.com/cabi/openspec-cdd (patches/ + smoke test S26).
Activity
surlymochan commentedon Oct 19, 2026
I tried this on 1.14.3 and it looks narrower than described: only the spinner line is wrong. The
Schema:line,--json, and.openspec.yamlall already show the custom schema.Repro:
openspec init --tools none, thenopenspec schema fork spec-driven my-flow, setschema: my-flowinopenspec/config.yaml, and runopenspec new change add-thing:.openspec.yamlhasschema: my-flow, and--jsongives"schema": "my-flow".That matches the code on
main.createChange(src/utils/change-utils.tsaround line 146) already resolves explicit option, thenreadProjectConfig(projectRoot)?.schema, thendefaultSchema. It persists that value and returns it asresult.schema, andprintCreatedChangeHumanprints that. Passingschema: options.schemaon line 152 is what lets the config fallback work. OnlyresolvedSchemaon line 146, used just for the spinner text, skips the config.So I think the minimal fix is to give the spinner the same resolution (or drop the schema from the spinner message). Changing what gets persisted, or
root.defaultSchema, shouldn't be needed. One thing I didn't test is a--store-selected root, in case that's the path where you saw the wrong value persisted.fix(new-change): name the configured schema in the progress line (Fis…