Parent: #1936
Problem
worker-configuration.d.ts is generated from wrangler.jsonc bindings via npm run cf-typegen — but unlike its sibling generated artifact apps/gittensory-ui/public/openapi.json (protected by ui:openapi:check, already in the test:ci chain), there is no cf-typegen:check (or equivalent) anywhere in CI. Two PRs that each independently add a new wrangler binding (KV namespace, D1 database, queue, R2 bucket, Durable Object) can both pass CI individually — each PR's own cf-typegen output is internally consistent in isolation — then merge sequentially and leave a stale/inconsistent committed worker-configuration.d.ts, silently, with zero gate signal. This is the same staleness-risk class the migrations directory and OpenAPI spec are both already guarded against.
Requirements
- Add a
cf-typegen:check script following the exact ui:openapi:check pattern: regenerate worker-configuration.d.ts via npm run cf-typegen, then git diff --exit-code against the committed version, failing CI on drift.
- Wire the new script into the
test:ci chain and the relevant CI workflow job.
- Document the requirement (regenerate + commit
worker-configuration.d.ts after any wrangler.jsonc binding change) in the contributing skill/reference docs, matching how OpenAPI/migration regeneration is already documented.
Deliverables
- A new
cf-typegen:check npm script.
- CI wiring (added to
test:ci and the relevant GitHub Actions job).
- A short addition to the contributing-to-gittensory skill's reference table of "you changed X, run Y, commit Z" generated-artifact rules.
Acceptance criteria
- A PR that changes
wrangler.jsonc bindings without regenerating worker-configuration.d.ts fails CI with a clear message.
- A PR that correctly regenerates and commits the file passes.
- No false positives against the current, already-consistent committed state.
Expected outcome
worker-configuration.d.ts gets the same staleness protection its generated-artifact siblings (openapi.json, migrations) already have — closing a silent gap where two independently-valid binding additions could merge sequentially and leave the committed types wrong with no CI signal.
Parent: #1936
Problem
worker-configuration.d.tsis generated fromwrangler.jsoncbindings vianpm run cf-typegen— but unlike its sibling generated artifactapps/gittensory-ui/public/openapi.json(protected byui:openapi:check, already in thetest:cichain), there is nocf-typegen:check(or equivalent) anywhere in CI. Two PRs that each independently add a new wrangler binding (KV namespace, D1 database, queue, R2 bucket, Durable Object) can both pass CI individually — each PR's owncf-typegenoutput is internally consistent in isolation — then merge sequentially and leave a stale/inconsistent committedworker-configuration.d.ts, silently, with zero gate signal. This is the same staleness-risk class the migrations directory and OpenAPI spec are both already guarded against.Requirements
cf-typegen:checkscript following the exactui:openapi:checkpattern: regenerateworker-configuration.d.tsvianpm run cf-typegen, thengit diff --exit-codeagainst the committed version, failing CI on drift.test:cichain and the relevant CI workflow job.worker-configuration.d.tsafter anywrangler.jsoncbinding change) in the contributing skill/reference docs, matching how OpenAPI/migration regeneration is already documented.Deliverables
cf-typegen:checknpm script.test:ciand the relevant GitHub Actions job).Acceptance criteria
wrangler.jsoncbindings without regeneratingworker-configuration.d.tsfails CI with a clear message.Expected outcome
worker-configuration.d.tsgets the same staleness protection its generated-artifact siblings (openapi.json, migrations) already have — closing a silent gap where two independently-valid binding additions could merge sequentially and leave the committed types wrong with no CI signal.