test: add consistency checks for processor tool target schemas - #1859
Merged
Conversation
All 8 processor tool target schemas are now verified to be subsets of ALL_TOOL_TARGETS at test time, catching silent mismatches when a new tool is added to one list but not the other.
- Apply oxfmt formatting (filter callback collapsed to one line) - Export toolRuleFactories to enable runtime map-vs-schema comparison - Add test: RulesProcessorToolTargetSchema.options must equal toolRuleFactories keys, catching drift between the hardcoded enum array and the factory Map
Contributor
|
Thank you for your contribution! Unfortunately, you currently have 3 open PRs (including this one), which exceeds the limit of 2 for external contributors. Please wait for an existing PR to be reviewed/merged, or close one before opening a new one. See CONTRIBUTING.md for details. |
Owner
|
@saitota Thank you! |
rudironsoni
pushed a commit
to rudironsoni/rulesync
that referenced
this pull request
Jun 18, 2026
Follow-ups from PR dyoshikawa#1859. - Export the seven remaining `tool*Factories` maps (commands, hooks, ignore, mcp, permissions, skills, subagents) so tests can assert their keys, matching the visibility already given to `toolRuleFactories`. - Apply the strong bidirectional schema-vs-factory parity check (schema enum set-equals factory Map keys) to every processor, not just RulesProcessor, so drift in either direction is caught uniformly. - Clarify in comments that the subset check intentionally guards only the "target declared by a processor must exist in ALL_TOOL_TARGETS" direction, and that the reverse is not asserted because not every tool supports every feature. - Note that the hand-maintained `processors` list must be kept in sync as a known footgun until a central processor registry exists. Closes dyoshikawa#1866
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
The knowledge of which tools are supported by which processor feature is scattered across multiple places: each processor's hardcoded tool list (e.g. `rulesProcessorToolTargets` in `rules-processor.ts`), each processor's factory `Map`, and `ALL_TOOL_TARGETS` in `src/types/tool-targets.ts`. There was no runtime or test-time check that these lists stay in sync.
A concrete failure mode: adding a new tool to `ALL_TOOL_TARGETS` without updating a processor's schema list produces no type error and no test failure — the tool silently generates nothing for that feature.
Changes
No production behavior changes. Test-only addition (plus one `export` keyword on an existing constant).
Test plan