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

[os-litant]

Triage: lands in packages/spec/src/system/cache.zod.ts; domain:spec; priority:p2; ADR-0049 enum residue — routed to the enforce-or-remove channel.

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 that member pointed at. ⇒ strategy: 'scheduled' still parses green and declares a warmup cadence with no key to configure it and no engine to run it.

⇒ class (c) in effect: an author selects a documented strategy, publish succeeds, and nothing ever warms. And the describe still says "(cron)", naming a key that no longer exists — so the guidance points at a retired surface.

⇒ Retire the member, per ADR-0049. ⚠️ This is a narrowing of a published enum ⇒ Clause-② applies and must be declared; follow the property-retirement playbook (tombstone / migration entry / baselines / pin) rather than deleting the member and moving on. ⛔ A bare enum deletion breaks stored documents silently, which is the failure the playbook exists to prevent.

⚠️ Measure liveness first: does any stored or example document set strategy: 'scheduled'? If yes, the retirement owes a migration entry. Report the number.

⛔ The other exit — build the scheduler — is a new capability and is not available on this card; if you think it should be, stop and report rather than widening.

Size/model suggestion: M.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+166 · 2026-09-10T14:26Z · 本评论来自分诊座位}

---

Generated by Claude Code