spec: `CacheWarmup.strategy` keeps the `'scheduled'` member after its cron left — a declared warmup cadence with no key and no engine (ADR-0049 enum residue of #16320)

[os-bill]

What

CacheWarmupSchema.strategy (packages/spec/src/system/cache.zod.ts:199-200) keeps the enum member 'scheduled', and its describe still reads "scheduled (cron)":

strategy: z.enum(['eager', 'lazy', 'scheduled']).default('lazy')
  .describe('Warmup strategy: eager (at startup), lazy (on first access), scheduled (cron)'),

#16320 (PR #17146, executing the #15954 ruling) retired CacheWarmup.schedule — the cron the member pointed at. After it, strategy: 'scheduled' still parses green and declares a warmup cadence mechanism that has no cadence key to carry and no engine to run it. No cache-warmup engine exists on the platform: CacheWarmupSchema has zero consumers outside its declaring file (evidence below), so the value was inert before the retirement and is self-contradictory after it.

Why a card, not a PR note

Category (b), contract violation: a .describe() on an authorable VALUE promises "(cron)" while nothing evaluates a cron for it — declared, not enforced (ADR-0049; Prime Directive 10's corollary, never advertise a capability the runtime doesn't deliver). It is a value, not one of the seven POSITIONS the #15954 ruling names, so #17146 deliberately left it: the tombstone comment and the D3 entry cache-warmup-schedule-retired both record the member as "a value, not a position the ruling names, and exactly as inert before". Enum-value narrowing is invisible to all four ratchets (authorable-surface rows key on positions, the D7 expression ledger on expression-typed slots, api-surface/ and json-schema.manifest/ on names), so nothing reds on it by itself — the pre-dispatch reading on #16320 flagged it "invisible to all four ratchets", and the contract review on #17146 asked for a card rather than 承接者:无.

Evidence (every zero beside a lit control; #17146 branch at 90377d224)

• Readers of the schema: git grep -n -P '\bCacheWarmupSchema\b' -- . ':!packages/spec/src/system/cache.zod.ts' ':!packages/spec/api-surface/**' ':!packages/spec/authorable-surface/**' → the generated reference page's import line, the declaration-map / export-origins catalogues, the spec: retire the seven cron-typed positions nothing reads — export schedules, ScheduleState.cronExpression, DataSyncConfig.schedule, CacheWarmup.schedule, backup/DR schedules — under ADR-0049 (#15954 ruling, option A per family) #16320 pin test and the two spec: retire the seven cron-typed positions nothing reads — export schedules, ScheduleState.cronExpression, DataSyncConfig.schedule, CacheWarmup.schedule, backup/DR schedules — under ADR-0049 (#15954 ruling, option A per family) #16320 ledger entries. Zero runtime readers. Control: ConnectorSchema outside its own file = 48 files.
• Readers of the value: git grep -n -P "'scheduled'" -- packages ':!packages/spec/src/system/cache.zod.ts' ':!**/*.test.ts' → data/feed.zod.ts:102 (a feed-item status enum, a different vocabulary) and two plugin-audit CHANGELOG lines about sys_activity.type. Nothing branches on a warmup strategy. Control: 'lazy' in cache.zod.ts = 1.

Options (not decided here)

1. Retire the member under ADR-0049 — the 17.apimethod-enum-shrink D3 precedent: an enum shrink is a D3 semantic entry, no D2 conversion, no os migrate meta sentence; on a non-strict object a removed enum member is a parse refusal naming eager / lazy, not a silent strip, so no retiredKey() form applies.
2. Keep the member and mark its describe [EXPERIMENTAL — not enforced], the form [Decision] nine cron- and template-typed keys in packages/spec are published, documented and read by nothing — retire them under ADR-0049 (the #14477 / #15513 shape), mark them experimental, or leave them? #15954 chose for the PromptTemplate pair — honest, cheaper, keeps the vocabulary for a future warmup engine.

Either is bookkeeping with no runtime effect, since nothing reads CacheWarmupSchema. The larger question — whether CacheWarmup / DistributedCacheConfig.warmup should exist at all — is the same family-level ADR-0049 question as the export-contracts decision card filed alongside this one.

Found while executing #16320 (PR #17146); outside that card's scope by the ruling's letter.

---

Generated by Claude Code