Skip to content

test(generate): derive shared-file writers from the registry and enforce declarations - #2109

Merged
dyoshikawa merged 1 commit into
dyoshikawa:mainfrom
saitota:m3i1
Jul 3, 2026
Merged

test(generate): derive shared-file writers from the registry and enforce declarations#2109
dyoshikawa merged 1 commit into
dyoshikawa:mainfrom
saitota:m3i1

Conversation

@saitota

@saitota saitota commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Background

Which config file each feature read-modify-writes is known in two places. The tool classes know their real write targets through getSettablePaths() and their implementations; GENERATION_STEP_GRAPH re-declares the same knowledge as opaque tokens ("reasonix-config", ...). Nothing — no type, no test — connects the two: generate.test.ts only checks the graph's internal consistency (are dependsOn edges justified for duplicated tokens), never whether the token set matches reality.

So assertSharedFilesOrdered can only order writers that are declared. An undeclared second writer passes silently and looks safe only while the execution order happens to be correct. And a tool adder has no reason to open generate.ts: the code compiles, tests pass, and output is correct under the current order — the drift surfaces only in review (e.g. ab61e38).

Changes

  • Derive the multi-writer set from PROCESSOR_REGISTRY × getSettablePaths (both scopes) plus a getExtraSharedWritePaths contract for writes not visible as settable paths, and assert it matches the graph — a missing declaration now fails CI, not review.
  • Replace opaque tokens with real dir/file keys so declarations and derivation share one namespace.
  • Fixes surfaced by the derivation: register .takt/config.yaml; drop permissions from kilo.json (it writes kilo.jsonc); cover the global-only .config/devin/config.json writer.

No change to generated output.

Test Plan

  • pnpm cicheck green (6740 tests).

Refs #2081

…rce declarations

GENERATION_STEP_GRAPH declared each step's shared-file writers by hand; a missing writer passed CI silently and was caught only in review (e.g. codexcli/vibe config.toml in ab61e38).

Derive the multi-writer set from PROCESSOR_REGISTRY x getSettablePaths across both project and global scope, plus a getExtraSharedWritePaths contract for writes not visible as settable paths, and assert it matches the step graph so a missing declaration fails CI instead of review.

Deriving surfaced three drifted declarations, now fixed: .takt/config.yaml was unregistered; permissions was wrongly listed as a kilo.json writer (it writes kilo.jsonc); and the global-only .config/devin/config.json shared write was covered only by chance.

Refs dyoshikawa#2081
@dyoshikawa
dyoshikawa merged commit 82ca7c1 into dyoshikawa:main Jul 3, 2026
5 checks passed
@dyoshikawa

Copy link
Copy Markdown
Owner

@saitota Thank you!

@dyoshikawa dyoshikawa mentioned this pull request Jul 3, 2026
rudironsoni pushed a commit to rudironsoni/rulesync that referenced this pull request Jul 10, 2026
Address the two `mid` follow-ups from PR dyoshikawa#2109 review (dyoshikawa#2110):

mid#1: SHARED_WRITE_FEATURE_ORDER is hand-maintained, so a feature that later
starts writing a shared config file could be silently forgotten. Add an
explicit NON_SHARED_WRITE_FEATURES exclusion list (commands, skills — each
writes its own dedicated per-item artifact) plus a test asserting the two
lists partition ALL_FEATURES exactly. Adding a new Feature now fails the test
until it is consciously classified as a shared writer or an excluded one.

mid#2: settablePathsForScope early-returned from the getSettablePaths catch,
which skipped the subsequent getExtraSharedWritePaths collection. A tool whose
global getSettablePaths throws while it also has a global-only extra shared
path would silently drop that path. Collect extra paths independently of
getSettablePaths success (still fail-open per hook), and cover it with a test.

Closes dyoshikawa#2110

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants