fix(workflow): keep no-spec schema changes valid

[clay-good]

Status

LGTM. This is a surgical, backward-compatible fix for a reproduced CLI bug.

What was wrong

A custom schema with no artifact under specs/ created changes without the existing skip_specs marker. Those changes failed validation immediately even though their schema could never generate a spec delta, forcing users to edit every new .openspec.yaml by hand.

An adversarial review also found that checking schema paths without normalization could misclassify supported Windows-style paths such as specs***.md as no-spec schemas.

How it was fixed

Change creation resolves the selected schema and writes skip_specs: true only when none of its normalized artifact paths generate under specs/. The same small path predicate is shared with instruction loading so creation, status, instructions, and validation cannot drift on separator handling.

Spec-producing schemas keep their existing metadata unchanged. The existing duplicate-change error precedence is also preserved.

Replication / proof

• Reproduced on current main: creation exited 0, then validation exited 1 with "Change must have at least one delta."
• Added an end-to-end CLI regression proving a configured no-spec schema receives the marker and validates.
• Added an adversarial Windows-separator journey proving a spec artifact is not marked skip_specs, is resolved as done, and validates with a real delta.
• Added path-classification coverage for POSIX, Windows, dot-prefixed, redundant-separator, and non-spec paths.
• Three independent correctness, compatibility, and adversarial audits found the separator regression; all three re-reviewed the hardened diff with no remaining findings.
• pnpm run build passed.
• pnpm run lint passed.
• Hosted CI passed on Linux, macOS, and Windows.
• CodeQL, dependency review, security audit, and CodeRabbit passed with no actionable review comments.

Notes / nits

• No design, schema-format, or architecture changes.
• Unknown keys in schema.yaml remain permissive. Making schema parsing strict is intentionally out of scope because it could reject existing extension-bearing schemas and is not required to fix this bug.
• No changeset; this follows the documented normal cadence for routine bug fixes.

Fixes #1638

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 2c1415d7-d7e6-4237-bad6-a54e47aba9ac

📥 Commits

Reviewing files that changed from the base of the PR and between 8980c42 and 230d6ad.

📒 Files selected for processing (5)

• src/core/artifact-graph/instruction-loader.ts
• src/core/artifact-graph/outputs.ts
• src/utils/change-utils.ts
• test/commands/artifact-workflow.test.ts
• test/core/artifact-graph/outputs.test.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• src/utils/change-utils.ts

---

📝 Walkthrough

Walkthrough

createChange now resolves the selected schema and adds skip_specs: true when no artifact generates files under specs/. A shared helper recognizes POSIX and Windows-style paths. Tests cover metadata generation, status detection, and validation.

Changes

Schema-aware change creation

Layer / File(s)	Summary
Specification path classification src/core/artifact-graph/outputs.ts, src/core/artifact-graph/instruction-loader.ts, test/core/artifact-graph/outputs.test.ts	isSpecsArtifactPath normalizes generated paths and identifies files under specs/. Instruction loading uses the helper. Tests cover POSIX and Windows-style paths and reject unrelated paths.
Conditional change metadata and workflow validation src/utils/change-utils.ts, test/commands/artifact-workflow.test.ts	createChange resolves the selected schema and persists skip_specs: true when it has no specification artifact. Tests verify standard schemas omit the field, no-specification schemas validate, and Windows-style specification paths remain detected.

Estimated code review effort: 2 (Simple) | ~15 minutes

Merge Risk: ⚪ Minimal · up to 230d6

The change adds metadata for no-spec schemas while preserving existing behavior for schemas that generate specs; no actionable merge-blocking risk remains after normal checks and review.

Suggested reviewers: tabishb, alfred-openspec

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The changes implement issue #1638 by adding skip_specs for schemas without specs artifacts and validating both supported path formats.
Out of Scope Changes check	✅ Passed	The changes are limited to schema detection, artifact-path handling, and focused regression tests required by issue #1638.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: keeping changes valid for schemas without specification artifacts.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/fix-no-spec-schema-scaffold

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}