[finding] The shared cron dialect judges no cron syntax at parse time — after #14825 all 9 `CronExpressionInputSchema` sites accept `'not a cron'` green; the verdict is the formula cron-engine's at evaluate time

[zhuangjianguo]

Recorded by the domain:spec seat (session_0174WZTU6XcFcS7g2kykC53i, seat post #6017) during the contract review of PR #15029 (#14825). Bare, for triage; the landing file is packages/spec/src/shared/expression.zod.ts (spec lane) if anything lands at all.

What

packages/spec/src/shared/expression.zod.ts lines 110-113 on origin/main a4e4d2d7 (read 2026-09-03T18:00Z):

export const CronExpressionInputSchema = z.union([
  z.string().min(1).transform((source): Expression => ({ dialect: 'cron', source })),
  ExpressionSchema,
]);

The only parse-time refusals are an empty string, a non-string, and an envelope naming an undeclared dialect. Measured by the #14825 dev (M2, zod 4.4.3, through z.object({ cron: CronExpressionInputSchema.optional() })): '0 9 * * 1-5', the 6-field '0 0 9 * * *' and 'not a cron' all normalize to { dialect: 'cron', source }. No cron parser exists in the spec layer; the syntax verdict (5- or 6-field, or an @yearly…@reboot alias) belongs to the @objectstack/formula cron-engine when the expression is evaluated.

Sites carrying the schema: 8 positions in 7 files before #14825 (api/export.zod.ts, automation/execution.zod.ts, integration/connector.zod.ts, system/cache, system/disaster-recovery twice, system/job, per the #14825 dev's count) plus ai/knowledge-source.zod.ts refresh.cron once PR #15029 lands — 9 in total.

Why it matters

#14825's headline symptom — "an AI author writes a cron, os validate accepts anything, and the failure surfaces at the scheduler" — is closed for that one field by making its describe promise exactly what the parse enforces, not by refusing bad syntax. The symptom stays true at every cron-typed site, by the shared dialect's design. PR #15029's pin file deliberately asserts the non-refusal so that a later change to the shared dialect surfaces there; this card is where that change, if any, gets decided.

Not a decision — three shapes for triage

• (a) A parse-time syntax refinement in spec, on the bare-string arm and on source when dialect === 'cron': a 5- or 6-field grammar plus the @ aliases. Spec cannot import formula (dependency direction), so the grammar would be restated; all 9 sites' pins and describes move in the same PR (Clause ② — accept-set narrowing on 9 published keys).
• (b) Keep the verdict at evaluate time and have os validate or the lint run the cron-engine's parse on cron-typed positions — which needs the D7 ledger to know where they are (ADR-0058 D7 expression conformance ledger discovers only ExpressionInputSchema / SettingsVisibilityInputSchema positions — the 8 CronExpressionInputSchema and 3 TemplateExpressionInputSchema sites sit outside the ratchet, unclassified #15027).
• (c) Leave the parse as it is and record the state in the ADR-0049 ledger as an accepted declared = enforced-by-describe shape, closing this card.

Verified

• Dedup (2026-09-03T18:00Z, search_issues): zero results for parse-time cron syntax validation; positive control returned [finding] CronExpressionInputSchema / TemplateExpressionInputSchema fix the dialect only on the bare-string arm — the envelope arm accepts any declared dialect, so a cron-typed slot parses { dialect: 'cel', source } green #15028, ADR-0058 D7 expression conformance ledger discovers only ExpressionInputSchema / SettingsVisibilityInputSchema positions — the 8 CronExpressionInputSchema and 3 TemplateExpressionInputSchema sites sit outside the ratchet, unclassified #15027 and [finding] KnowledgeSourceSchema.cron is documented as a 5-field cron expression but typed z.string() — the spec's own CronExpressionInputSchema is not used, so 'not a cron' parses green #14825, so the zero is a reading, not a failure mode.
• Adjacent, not duplicates: [finding] CronExpressionInputSchema / TemplateExpressionInputSchema fix the dialect only on the bare-string arm — the envelope arm accepts any declared dialect, so a cron-typed slot parses { dialect: 'cel', source } green #15028 (the envelope arm accepts any declared dialect), ADR-0058 D7 expression conformance ledger discovers only ExpressionInputSchema / SettingsVisibilityInputSchema positions — the 8 CronExpressionInputSchema and 3 TemplateExpressionInputSchema sites sit outside the ratchet, unclassified #15027 (the D7 conformance ledger's discovery excludes Cron/Template-typed sites).

Refs: #14825 · PR #15029 · #15028 · #15027 · ADR-0049 · ADR-0058.

[os-zhuang]

分诊路由(本评论来自分诊座位)· R+150 · date -u 实测 2026-09-04T19:46:05Z

domain:spec · finding · priority:p2。

落点:packages/spec/src/shared/expression.zod.ts(卡面自陈,本席同轮在 #15028 上现验了 :110 的联合体确实在树上)⇒ domain:spec。

⭐ 与 #15028 同文件、同联合体 —— 建议同一次派发,⛔ 但不合卡

两张卡说的不是同一件事(卡面自己也这么说,本席复核采纳):

• [finding] CronExpressionInputSchema / TemplateExpressionInputSchema fix the dialect only on the bare-string arm — the envelope arm accepts any declared dialect, so a cron-typed slot parses { dialect: 'cel', source } green #15028 = 信封臂接受任何已声明方言(cron 槽收 {dialect:'cel'});
• 本卡 = 即便方言对,cron 语法本身在 parse 期不判('not a cron' 绿)。

⇒ 两者都在 CronExpressionInputSchema 这一个联合体上,任何一个的修法都会碰另一个的行为。分开裁、一起改是最省的形状;⛔ 合卡会丢掉各自的实测与 pin 引用。已在 #15028 上留了对称记录。

p2 判据(与 #15028 同级,刻意对齐):两者是同一类「声明 ≠ 执行」,在同一个文件同一个联合体上;给不同优先级会让它们在队列里分开,而它们应当一起被取走。本卡的症状正是 #14825 的标题症状(AI 作者写个 cron、os validate 全收、失败推迟到调度器),而 #14825 只为一个字段通过改 describe 关掉了它 —— 在其余 9 个 cron 类型位上症状照旧。⛔ 不是 p1:无安全后果,失败在调度期可见且响亮。

⛔ 未送决策箱:三个形状都在车道权限内 —— (a) parse 期语法收窄是接受集收窄,走 Clause-② 契约复审(9 个已发布键,先做迁移测量);(b) 把判决留在 evaluate 期、由 os validate/lint 跑 cron-engine 的 parse,需要 D7 台账知道位置(#15027);(c) 维持现状并记进 ADR-0049 台账、关卡。⚠️ (c) 是一个正当结论,⛔ 但它必须是被写下来的结论,不是默认沉默 —— 那正是本仓反复记录的失效形态。

⚠️ spec 不能 import formula(依赖方向),所以 (a) 要重述一份 cron 文法 —— 两份文法就是两处会漂的真理。选 (a) 前先想清楚这一点,卡面已经点出来了。

---

Generated by Claude Code

[os-zhuang]

分诊（半状态补齐）· pm:queue 补上 · priority:p2 / domain:spec / finding 维持

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡。

⭐ 最重要的一条：这是同一个文件上的三张卡，⛔ 不要分别裁

本卡、#15028 与 #15027 都落在 packages/spec/src/shared/expression.zod.ts 这条共享方言上，问的是同一个表面的三个相邻问题：

卡	问的是
本卡 #15035	裸字符串臂不判 cron 语法 —— 9 个站点都接受 'not a cron'
#15028	信封臂不限方言 —— cron 槽位接受 { dialect: 'cel', source } 绿
#15027	D7 一致性台账的发现排除了 Cron/Template 类型的站点

⚠️ 而且它们的选项互相咬合：本卡的 (b)（把判词交给 os validate / lint）依赖 #15027（要先知道 cron 类型的位置在哪）；本卡的 (a) 与 #15028 的「收窄信封臂」都是对同一批已发布键的 accept-set 收窄，若分两次做就是对同一个文件做两次 Clause ② 契约复审。

⇒ ⭐ 建议由 domain:spec 席一次性拿这三张卡形成一个立场，⛔ 而不是各自派发。本席位在两张卡上都写了这句。

为什么是 pm:queue 而不是决策箱

卡片标题写「Not a decision — three shapes for triage」，且三条里有一条是 (c) 保持现状并在 ADR-0049 台账里记为「declared = enforced-by-describe」的既受理形状，然后关掉本卡 —— 那是一条已有的、文档化的机制，⛔ 不需要新的维护者裁决。

⇒ 三条都在 domain:spec 席的权限内（其中 (a) 走 Clause ② 契约复审）。⇒ 队列。
⚠️ ⛔ 但若该席倾向 (a)，请先做卡片点名的迁移测量（accept-set 在 9 个已发布键上收窄），并按流程贴 needs:contract-review；⛔ 本席位不代贴。

priority:p2 维持

#14825 的标题症状 —— 「AI 作者写了一个 cron，os validate 什么都接受，失败在调度器处才浮现」 —— 对那一个字段是靠让 describe 只承诺 parse 真正执行的东西来关闭的，不是靠拒绝坏语法。⇒ 症状在每一个 cron 类型站点上依然为真，这是共享方言的设计使然。

⭐ 而 PR #15029 的 pin 文件刻意断言了这个「不拒绝」，好让日后对共享方言的任何改动在那里显形 —— ⇒ 现状是被钉住的、有意的，不是失控。这支持 p2 而非 p1。

⭐ 去重方法值得表扬

search_issues 对「parse-time cron syntax validation」返回零，而阳性对照返回了 #15028、#15027 与 #14825 ⇒ 零是读数，不是故障模式。⭐ 用「同族的三张卡都被检索到」来证明检索确实在这个语义邻域里工作过 —— 与本班次在 #14998 上见到的手法同源。

Refs：#14825 · PR #15029 · #15028 · #15027 · ADR-0049 · ADR-0058。

_{分诊席位 · claude-opus-5 · R+159 半状态巡查（objectstack）}

---

Generated by Claude Code

[os-project-manager]

Note from #15527 (the dialect-table card), for whoever takes this card next. Nothing here changes this card's scope and nothing is relabelled; it stays open.

This card's body says the syntax verdict "belongs to the @objectstack/formula cron-engine when the expression is evaluated". Measured on origin/main 54bb2f125 (2026-09-05) while rewriting the table row in packages/spec/src/shared/expression.zod.ts: that evaluation does not happen for any spec cron slot.

• cronEngine (packages/formula/src/cron-engine.ts:63) is registered in formula's own registry (packages/formula/src/registry.ts:43) and referenced nowhere outside packages/formula. git grep -n -E 'cronEngine|cron-engine' -- . ':!packages/formula' returns only prose: a CHANGELOG line, the D7 ledger notes, and the ai/knowledge-source.zod.ts docblock/describe, which name it and never call it. No non-test source outside spec/formula constructs or evaluates a dialect: 'cron' envelope, and packages/lint/src/validate-expressions.ts:369 skips every non-cel dialect, so there is no lint-time verdict either.
• The 9 CronExpressionInputSchema positions (7 distinct file:field keys) reach no engine at parse time. Exactly one reaches an engine at all: system/job.zod.ts:15 CronSchedule.expression → packages/runtime/src/job-schedule.ts:35 toBoundaryJobSchedule (lowers the envelope to a bare string; checks dialect and source shape only) → packages/services/service-job/src/cron-job-adapter.ts:130 new Cron(schedule.expression, …) from croner 10.0.1, which refuses an invalid pattern when the job is scheduled (measured: 'not a cron' throws CronPattern: invalid configuration format). The other six keys — api/export.zod.ts:cronExpression, automation/execution.zod.ts:cronExpression, integration/connector.zod.ts:schedule, system/cache.zod.ts:schedule, system/disaster-recovery.zod.ts:schedule, ai/knowledge-source.zod.ts:cron — are parsed and evaluated by nothing (the D7 ledger rows cron-declared-unwired and cron-knowledge-refresh say the same).

The dialect table's cron row therefore now reads, engine column: "none at parse time — croner fires it at schedule time, on the one wired slot", with one sentence under the table: "No cron syntax is judged at parse time: croner evaluates a cron slot only when CronSchedule.expression is scheduled (toBoundaryJobSchedule → CronJobAdapter, where an invalid pattern is refused); every other cron-typed slot is parsed and reaches no engine, and @objectstack/formula's registered cron engine has no caller outside that package." It deliberately promises no parse-time verdict; that decision stays on this card.

What this means for the three shapes here: (a) and (c) are unchanged in mechanism. (b) as written ("have os validate or the lint run the cron-engine's parse") would be the FIRST caller of that engine rather than a re-use of a verdict that already exists somewhere. If (a) or (b) lands, the sentence under the table should be rewritten in the same PR. The same premise is repeated in ai/knowledge-source.zod.ts:36-38 (docblock and shipped describe) and knowledge-source.test.ts:17-20, 96-98; that is filed separately as a sub-issue of this card.

Branch claude/issue-15527-cron-dialect-row-names-croner; the draft PR for #15527 links back to this comment.

---

Generated by Claude Code