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)

[os-zhuang]

Work card for the #15954 ruling (director seat, decision batch #56, maintainer 「其他同意」 on the per-family recommendation, 2026-09-06). This card carries the retire half; the PromptTemplate marking half is its sibling card (linked from #15954). Sequencing: after the #15028 / #15035 narrowing PR on shared/expression.zod.ts lands.

Positions to retire (seven positions, six key names)

file:Schema.field	line (at origin/main f1e91595f, re-locate by text)	reachable from a stack manifest
api/export.zod.ts ScheduledExport.schedule.cronExpression	:576	no — API contract
api/export.zod.ts ScheduleExportRequest.schedule.cronExpression	:706	no — API request
automation/execution.zod.ts ScheduleState.cronExpression	:454	no — runtime state
integration/connector.zod.ts DataSyncConfig.schedule	:257	yes — Connector.syncConfig, defineStack({ connectors })
system/cache.zod.ts CacheWarmup.schedule	:156	no
system/disaster-recovery.zod.ts BackupConfig.schedule	:57	no
system/disaster-recovery.zod.ts DisasterRecoveryPlan.testing.schedule	:238	no

Not in scope: system/job.zod.ts CronSchedule.expression (read by croner), ai/knowledge-source.zod.ts KnowledgeRefreshPolicy.cron (experimental-marked), Object.titleFormat (read by objectui; #15947), and the PromptTemplate pair (sibling card).

Shape — the #14477 / PR #15514 precedent, spec-property-retirement playbook

• RETIRED_KEYS_BY_MAJOR[18] entries + retiredKey() tombstones at each position; refusal pins (an author who writes the key gets the tombstone's did-you-mean, never silent acceptance).
• One ADR-0087 D3 semantic entry per family: export API schedules; automation ScheduleState; connector sync schedule; cache warmup; backup / DR testing. The connector entry states the measured population (zero in-repo authors — examples, docs, skills, objectui pin all swept with controls; out-of-repo stacks NOT MEASURED) since it is the only stack-collection member.
• Regenerate: authorable-surface shards, JSON schema, api-surface, reference pages; retire the D7 cron-declared-unwired ledger rows for these positions (packages/qa/dogfood/test/expression-conformance.ledger.ts).
• Changeset: @objectstack/spec minor, **BREAKING** banner, <!-- adr-0087: registered <entry-ids> -->. Immediate retirement, no deprecation window (2026-08-27 ruling).
• Clause-②: yes on both carriers; contract review at tier.

Re-check before claiming

git grep -n "CronExpressionInputSchema" origin/main -- packages/spec/src | grep -v test
git grep -n "cron-declared-unwired" origin/main -- packages/qa/dogfood/test/expression-conformance.ledger.ts

[os-trump]

Deferred this round on a SERIAL constraint, not on merit — and the pit is recorded now rather than when someone next picks it up

domain:spec seat, session session_01F8SRGcf2eKTK7RRpWCGxwf, R1, 2026-09-07T14:22Z. Readings against origin/main (fetched 14:19Z). The card stays pm:queue, unassigned — ⛔ nothing about its state changes here, and no Blocked-by: is owed because the dependency is a file, not an issue.

This card ranked into consideration on the lane's ordering (p2, and it carries a ruling — #15954 option A per family — so it is dispatch-ready on merit). It was not dispatched, for one reason:

The blocker is file ownership

The seven cron-typed positions do not live in one place. Measured:

git grep -lnE "cronExpression|CacheWarmup|DataSyncConfig" origin/main -- 'packages/spec/src/**/*.zod.ts'
  packages/spec/src/api/export.zod.ts
  packages/spec/src/automation/execution.zod.ts     ← COLLISION
  packages/spec/src/integration/connector.zod.ts
  packages/spec/src/shared/expression.zod.ts
  packages/spec/src/system/cache.zod.ts

packages/spec/src/automation/execution.zod.ts is held by this seat's in-flight #15617 (branch claude/issue-15617-execution-step-metrics-failure-slot, dispatched 13:42Z, actively pushing — remote head 27fa9f89 at 14:10Z). #15617's ruling reconciles the FlowRunSummary paragraphs and adds a failure slot to ExecutionStepMetricsSchema in that same file.

⇒ Under 「同文件单跨轮硬串行」 this is a serial, not a fold: the five fold gates are not met either (different defect shape — an ADR-0049 retirement vs a contract reconciliation — and different rulings). Dispatching now would put two writers on one file.

Release condition: #15617's PR merges (or its dev releases automation/execution.zod.ts). This seat re-ranks the card the round after that.

Pits the next dispatcher should not have to rediscover

1. ⚠️ The file surface is FIVE files, not one, and only one of them collides. Whoever picks this up should re-derive the list on the merged ref rather than trusting the five above — spec: FlowRunSummary's two paragraphs disagree for a subflow parent — failed is declared a node fold, while the summary is declared to answer "what did this run cause" and roll a child's totals up #15617 is actively rewriting one of them, so both the line numbers and possibly the enclosing shapes in execution.zod.ts will have moved.
2. ⚠️ shared/expression.zod.ts is in the list and is a high-traffic file — check it against the hot-file serial queue at dispatch time, not just against spec: FlowRunSummary's two paragraphs disagree for a subflow parent — failed is declared a node fold, while the summary is declared to answer "what did this run cause" and roll a child's totals up #15617.
3. The ruling is option A per family, so the seven positions may not all take the same treatment; the per-family split is part of the work, ⛔ not an assumption to inherit.
4. This is a retirement ⇒ it wants the spec-property-retirement playbook, ⛔ not a freehand removal, and it is Clause-② (narrowing the authorable surface) ⇒ contract-review tier at dispatch.

---

Generated by Claude Code