fix(config): stop warning about rules keys that belong to another schema#1377
Conversation
The global rules: map is validated against only the current change's schema, so a key valid for a different schema prints a spurious "Unknown artifact ID" warning on every command in multi-schema projects. Validate against the union of artifact IDs across all available schemas; warn only when a key matches no schema. Fixes #1322. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
|
Caution Review failedAn error occurred during the review process. Please try again later. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Status: Ready for review. Surgical fix, verified end-to-end.
What was wrong
openspec/config.yamlhas a single globalrules:map keyed by artifact ID, but each change can use a different schema. The validation only checked keys against the schema of the change currently being loaded, so any rules key that's legitimate for a different schema printed:on every command in a multi-schema project (e.g.
spec-drivenfor features + a lighter schema for fixes). The warning was pure noise — rules are applied per-artifact (rules?.[artifactId]), so a cross-schema key is simply unused for that change; nothing was ever misapplied.How it's fixed
Validate rules keys against the union of artifact IDs across every available schema (built-in, user, and project-local) via the existing
listSchemasWithInfo(). A key now warns only when it matches no artifact in any schema; keys valid for another schema are silent. The warning message drops its single-schema framing accordingly.Two files, ~15 lines:
src/core/artifact-graph/instruction-loader.ts— build the valid-ID set from all schemas instead of justcontext.graph.src/core/project-config.ts—validateConfigRulesno longer takes aschemaName; message reworded to "matches no artifact in any available schema."Replication / proof
Repro: a project with a project-local
lightschema (artifactissue) +schema: spec-driven, and arules:map containingissue. Before this change, loading anyspec-drivenchange warns aboutissue.End-to-end after the fix (temp project, real
dist/):issue(valid only inlight) no longer warns; a genuinely-unknown key (totally-bogus) still does.New regression test in
test/core/project-config.test.tscovers the union case.npm run buildgreen; full suite passes (only the 17 documented environment-onlyzsh-installertests fail locally, CI unaffected).Notes
schemaNameparameter ofvalidateConfigRuleswas unused after this change and removed; the one caller and unit tests are updated.Fixes #1322.
🤖 Generated with Claude Code