spec/ai: KnowledgeRefreshPolicy.cron's docblock, shipped describe and test comments attribute the cron syntax verdict to @objectstack/formula's cron-engine "when the expression is evaluated" — nothing evaluates that slot, and that engine has no caller outside formula #15867

Activity

1. os-project-manager

   added a parent issue on Sep 5, 2026

   • [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 #15035
2. os-zhuang

   added

   bugSomething isn't workingSomething isn't working

   documentationImprovements or additions to documentationImprovements or additions to documentation

   pm:queueReady for the PM dispatch loopReady for the PM dispatch loop

   domain:specDomain lane — seat card indexed by label:pm:seatDomain lane — seat card indexed by label:pm:seat

   findingRecorded observation — held, not dispatchable until the findings triage round grades itRecorded observation — held, not dispatchable until the findings triage round grades it

   priority:p3

   on Sep 6, 2026
3. os-zhuang commented on Sep 6, 2026

   

   os-zhuang

   on Sep 6, 2026 – with Claude

   Contributor

   More actions

   分诊：domain:spec / documentation + bug + finding / pm:queue / priority:p3

   ⭐ 最重要的一条：本卡在等的那个答案，已经在树上写好了

   卡片说它挂在 #15035 下面，因为「where does the cron syntax verdict live」要在那里决定，而这个 describe 得说出那个答案。#15035 已关闭，而 #15527 的更正已经落地——正确的句子就在 packages/spec/src/shared/expression.zod.ts 里：

   :22   * | `cron`     | none at parse time — `croner` fires it at schedule time, on the one wired slot | job schedules |
   :25   * No cron syntax is judged at parse time: `croner` evaluates a cron slot only
   :28-30* … cron-typed slot is parsed and reaches no engine, and `@objectstack/formula`'s
          * registered `cron` engine has no caller outside that package.
   :267  * No cron syntax is judged at parse time — `'not a cron'` normalizes like any …
   

   ⇒ expression.zod.ts:28-30 逐字说出了本卡要求 knowledge-source.zod.ts 说的那件事：cron 槽被 parse 之后到不了任何引擎，而 @objectstack/formula 注册的 cron 引擎在该包之外没有调用方。

   ⇒ 本卡不是「等一个未决的裁决」，而是「一次已完成的更正没有覆盖到的最后一处」。 ⛔ 因此不挂 pm:blocked，直接 pm:queue。

   落点核实（origin/main）

   packages/spec/src/ai/knowledge-source.zod.ts:36    * syntax: that verdict is the `cron` dialect engine's (`@objectstack/formula`
   packages/spec/src/ai/knowledge-source.zod.ts:49      + 'the `cron` dialect engine\'s verdict when the expression is evaluated, not checked here. '
   

   ⇒ 档头（:36 起）与 .describe()（:49）都还带着旧归因，与同仓 expression.zod.ts 已更正的说法直接矛盾。⇒ main 上有东西是假的 ⇒ bug。

   ⚠️ 卡片列的两处测试注释（knowledge-source.test.ts:17-20 / :96-98）本席未逐字核对，⛔ 但它们在同一份交付里，请一并改。

   为什么这条散文的错法值得一个 bug 而不是一次措辞润色

   卡片说得准：两半都错了。

   1. 「when the expression is evaluated」命名了一个不发生的事件——refresh.cron 被任何东西求值过吗？没有。service-knowledge 读的是 refresh.onRecordChange，从不读 refresh.cron（D7 账本行 cron-knowledge-refresh 记着，describe 自己的后半段也说这个值只是surfaced 给一个外部调度器）。
   2. 即使它发生了，被命名的求值者也是错的——任何 spec cron 槽真正会遇到的唯一求值者是 croner，在 CronSchedule.expression 上，不是这个槽。

   ⭐ 而它面向客户：这个 .describe() 就是 content/docs/references/ai/knowledge-source.mdx（:68 与 :133）里的 cron 行。⇒ 一个作者被告知哪个引擎会判他的语法、以及何时判——两半都是假的。

   定级理由

   • domain:spec：packages/spec ⇒ domain:spec。
   • bug + documentation：见上。修复不拓宽任何接受集（parse 行为一字不动）⇒ Bug/tidy 侧，无人工地板。
   • p3：无运行期后果（refresh.cron 本来就到不了任何引擎）；损害是发布文档里的一句错误归因。⛔ 不升 p2：作者据它写出的 cron 仍然会被外部调度器判，只是判它的不是文档说的那个东西。⛔ 不降更低：它是一次已完成更正的最后一处残留，且是 customer-facing。

   交付物

   按 expression.zod.ts:22-30 的现有措辞，改写 knowledge-source.zod.ts 的档头（:36 起）、.describe()（:49）与两处测试注释，说出今天为真的事：没有引擎求值 refresh.cron；语法由作者把这个值交给的那个外部调度器判。 然后 pnpm --filter @objectstack/spec gen:docs + 一个 @objectstack/spec 的 patch changeset。

   ⭐ 卡片自己划出的两条边界，本席原样背书：

   • describe 的前半段是准确的（「not checked here」：一个非空字符串或一个信封，归一成信封）——⛔ 不要动它。
   • pin 测试的行为是对的（parse 不拒绝 'not a cron'）——⛔ 只有它的注释是错的。

   ⚠️ 卡片说「若 #15035 落地了 parse 期或 lint 期的判决，这句话还要再改一次」。本席核实：没有落地——expression.zod.ts:25 与 :267 都仍然写着 No cron syntax is judged at parse time。⇒ 现在改是安全的，不会很快作废。

   去重

   ⭐ 本席见过的最扎实的一次去重之一，直接继承：

   REST issues?state=open&since=2026-09-04, 5 pages, 394 open issues, grepped locally … controls #15527, #15035 and #15028 all present in the read

   ⇒ 它枚举了整个开放集（不是 search_issues，纪律⑪），并且在同一次读取里验证了三个已知必中的控制都在结果里 ⇒ 空结果本会是有意义的。穷尽证明成立。

   Refs：#15527（已落地的姊妹更正）· #15035（父卡，已关闭）· #15028 · #14825 · ADR-0049 · ADR-0058。

   ---

   ⛔ 本席为 triage 席位：不认领、不派单、不写码、不合并、不裁决 decision-box（本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

   ---

   Generated by Claude Code
4. huangyiirene

   added

   pm:dispatchedDispatched to a dev agent by /pm-dispatchDispatched to a dev agent by /pm-dispatch

   and removed

   pm:queueReady for the PM dispatch loopReady for the PM dispatch loop

   on Sep 7, 2026
5. huangyiirene

   self-assigned this

   on Sep 7, 2026
6. huangyiirene commented on Sep 7, 2026

   

   huangyiirene

   on Sep 7, 2026 – with Claude

   Collaborator

   More actions

   Claim:

   • session: session_01T6HeZvT9wdSJD1ZxJb5Eno (PM dispatch, domain:spec execution seat)
   • branch: claude/issue-15867-knowledge-refresh-cron-attribution
   • dispatched: 2026-09-07T06:12Z

   The dev inherits this claim and the assignee. ⛔ It posts no second Claim:, and never writes the assignee field.

   ---

   PM verification before dispatch — triage's one unverified claim is CONFIRMED, and it drifted

   Triage (5557145943) flagged its own gap honestly:

   ⚠️ 卡片列的两处测试注释(knowledge-source.test.ts:17-20 / :96-98)本席未逐字核对

   I closed it. Anchored to the literal sha c383352cb752245899b6ca7e2dc7d233405113ee (⚠️ origin/main moves under sibling fetches in this container — never anchor by name):

   site	card said	actually on this sha
   docblock	:35-38	:36	✅ stale attribution present
   .describe()	:45-49	:49	✅ stale attribution present
   test comment 1	:17-20	:21	✅ present, drifted
   test comment 2	:96-98	:106	✅ present, drifted ~10 lines

   ⇒ All four sites exist. The population is 4, as the card said. ⛔ Re-locate by symbol/phrase, not by these line numbers — they have already drifted once.

   Triage's load-bearing claim also re-confirmed: expression.zod.ts:25 and :267 both still read No cron syntax is judged at parse time, so no parse-time verdict has landed and the correction is safe to write now.

   ⚠️ A censored reading of my own, recorded rather than buried

   My first probe grepped the full phrase when the expression is evaluated and returned zero for the test file — with the file-exists control lit (131 lines). I did not publish that zero. The phrase is wrapped across comment lines, so it exists on no single line; the single-line grep could not have found it however true it was. Re-probed with the single-line-safe anchor dialect engine, all four sites appeared at once.

   ⇒ Same trap #16409's dev recorded on a template-literal concatenation. A zero from a search whose target may span lines is not a reading, control lit or not — the control proves the search reached the file, not that the pattern could match.

   ⭐ One thing neither the card nor triage mentions — do NOT delete the comment block

   The test comment at :21 sits inside a block that ends with a self-maintaining rule:

   "That pin is deliberate: it is what keeps the schema's describe honest. If the shared dialect ever gains parse-time syntax validation, this pin flips, and the describe on the slot must be …"

   That rule is true and worth keeping. Only the attribution half of the block is false. This is the same shape as the two boundaries triage endorsed (the describe's first half is accurate; the pin's behaviour is correct — only its comment is wrong): surgically correct the attribution, ⛔ do not remove the surrounding reasoning.

   ---

   Generated by Claude Code
7. huangyiirene commented on Sep 7, 2026

   

   huangyiirene

   on Sep 7, 2026 – with Claude

   Collaborator

   More actions

   os-dev-report

   {
   "issue": 15867,
   "status": "done",
   "branch": "claude/issue-15867-knowledge-refresh-cron-attribution",
   "pr": "#16527",
   "premise_still_valid": true,
   "summary": "Corrected the false cron-syntax attribution at all four sites in packages/spec/src/ai/knowledge-source.zod.ts (docblock, .describe()) and packages/spec/src/ai/knowledge-source.test.ts (two pin-test comments), matching the already-landed sibling wording in packages/spec/src/shared/expression.zod.ts:25-30: no engine evaluates refresh.cron; croner judges a cron pattern only where a schedule is wired (CronSchedule.expression, a different slot); formula's registered cron engine has no caller outside that package; so the verdict belongs to whatever external scheduler the author hands the value to. Regenerated with check:generated --fix and added an @objectstack/spec patch changeset. All four sites were RE-LOCATED BY PHRASE, not by line number, with the single-line-safe anchor 'dialect engine'; on my base a5eccf9 they sit at zod.ts:36, zod.ts:49, test.ts:21, test.ts:106 -- exactly the PM's corrected readings, and NOT the card's (:35-38 / :45-49 / :17-20 / :96-98). A deliberate multi-line scan (comment markers stripped, whitespace collapsed, whole tree) confirms the population is exactly those four source sites plus the two generated .mdx rows; packages/spec/CHANGELOG.md:2195 carries the old wording and was deliberately left alone as a record of what shipped. All three surgical boundaries held: the describe's accurate first half is untouched, the pin's behaviour is untouched (only its comments changed), and the self-maintaining rule ending the :21 block is preserved verbatim. Assignee was already set by the PM and I never wrote it; the newest Claim: comment 5565903212 names my branch, and I posted no second claim. MEASURED generated set my regeneration moves: 1 TRACKED (content/docs/references/ai/knowledge-source.mdx) + 3 GITIGNORED under packages/spec/json-schema/ (ai/KnowledgeRefreshPolicy.json, ai/KnowledgeSource.json, objectstack.json) = 4 files; that gitignored tree's population is unchanged at 1576 files. Clause 2 confirmed NO: check:api-surface and check:authorable-surface both exit 0 AND both were ablated to prove they can go red, so neither green is a bare reading. PR body read back in full from the rendered page: intact; GitHub appended one bare attribution footer beside my session-URL footer, the documented POST /pulls behaviour -- not repaired, not re-posted.",
   "tests": "ALL readings from final commit f7a9b0f; every exit code captured BEFORE any pipe (cmd > log 2>&1; EXIT=$?), and gate verdicts quoted from the gate's own printed line. BUILD: pnpm --filter '@objectstack/spec^...' build printed 'No projects matched the filters' -- NOT a silent miss: @objectstack/spec has zero workspace dependencies (verified from its package.json), so the closure is genuinely empty. pnpm --filter @objectstack/spec build then ran under the shared lock -> 'VERDICT command-exit 0 - held the lock 161s'. TESTS: pnpm --filter @objectstack/spec test under the lock -> 'VERDICT command-exit 0 - held the lock 384s - waited 128s'; 'Test Files 483 passed (483)', 'Tests 13136 passed (13136)'. TYPES: pnpm --filter @objectstack/spec typecheck -> exit 0; its check:test-typecheck leg prints 'OK -- @objectstack/spec's test layer compiles under packages/spec/tsconfig.test.json; 54 file(s) / 261 error(s) / 145 pinned signature(s)', so the edited test file is genuinely type-checked, not silently excluded (NOT the unmeasured case). AFFECTED SET: TURBO_SCM_BASE=a5eccf9257 turbo ls --affected returns 76 packages -- the whole farm, because everything depends on @objectstack/spec. DECLARED NARROWING: I ran @objectstack/spec's own test+typecheck; the other 75 are reached only through the spec dependency edge and my diff moves no exported symbol, no type and no parse behaviour (proved by the two ablated gates below), so their re-run is CI's. GATES: derived mechanically with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (change set from the merge base a5eccf9, three-dot, includes uncommitted+untracked) -> 91 commands; re-derived after the changeset existed -> 6 more; 97 total, ALL RUN. 95 exit 0 (including check:generated's 15 artifacts, check:nul-bytes, check:api-surface, check:authorable-surface, check:docs, check:type-check-coverage, check:cross-package-test-inputs, check:test-source-alias, and the four changeset families); plus two roster-block gates run on top, check-changeset-fixed.mjs and check-skills-token-ratchet.mjs, both exit 0. check:skill-examples first exited 1 on a PREREQUISITE (packages/client-react/dist held no .d.ts) -- I built @objectstack/client-react and its closure under the lock ('VERDICT command-exit 0 - held the lock 321s - waited 338s') and re-ran it: exit 0, '257 prose examples type-check across 3 surface(s)', which includes the 'spec source TSDoc' surface my diff touches. check:doc-formula-expressions, check:doc-security-posture and check:docs-transcript-drift each exited 3 PREREQUISITE NOT MET before that build and exit 0 after it. LINT: full repo-wide pnpm lint (eslint . --no-inline-config --format json) completed in-budget -- NO narrowing was needed: 6273 files linted, 0 errors, 0 warnings, exit 0. NOT MEASURED (read as neither pass nor finding): check:dual-build-cjs-loads exit 3 'PREREQUISITE NOT MET -- this gate reads built output, and some package has no dist/'; check:type-check-debt did not finish inside the foreground budget (exit 124 from my own timeout, not a verdict) -- it is a whole-farm aggregate and is CI's; check:react-declaration-parity cannot run here at all (needs objectui's sdui.manifest.json). Two commands I first spelled wrong returned exit 254 'Command not found' -- that is a typo, not a red gate; re-run with the right spellings (pnpm --filter @objectstack/spec check:strictness-ledger, node scripts/check-skills-token-ratchet.mjs) both exit 0. ABLATION 1 (check:api-surface): removed the single line '"KnowledgeSource (type)",' from packages/spec/api-surface/ai.json. On-disk proof BEFORE reading any result: matching lines 4 -> 3 and blob hash 9d7c970b3d -> 1be427f1b1. Gate then exited 1: '@objectstack/spec public API changed: 0 breaking (removed/narrowed), 1 added.' Restore leg: git checkout HEAD -- ABSOLUTE_PATH (never bare checkout), proven by hash back to 9d7c970b3d AND empty git diff HEAD for that path; gate re-ran at exit 0. ABLATION 2 (check:authorable-surface): removed '"ai/KnowledgeRefreshPolicy:cron",' from packages/spec/authorable-surface/ai.json. On-disk proof: matching lines 1 -> 0, blob hash aad48547be -> 40a06af4a2. Gate exited 1 and named the movement: '+ ai/KnowledgeRefreshPolicy:cron' -- i.e. exactly an accept-set movement is what it catches. Restore proven the same two ways; gate re-ran at exit 0. Both ablations ran inside a script carrying trap RESTORE EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel, and every hash compared against the path's HEAD blob (an empty hash would have been read as FAILURE, not as nothing-to-compare). GENERATED-SET MEASUREMENT (same discipline): mutated the source back to base a5eccf9 (on-disk proof: 'dialect engine' count 2, 'reaches no engine' count 0; hash moved), ran gen:schema, snapshotted 1576 json-schema file hashes; restored to HEAD (hash equal to the HEAD blob 4d8eb8d1dd AND empty git diff HEAD), ran gen:schema again, snapshotted again. Exactly 3 gitignored files differ, plus the 1 tracked .mdx that check:generated proved stale and --fix regenerated. BYTE DISCIPLINE: grep -naP over both edited source files and the changeset for control characters -> exit 1 (no hits); pnpm check:nul-bytes exit 0.",
   "mcp_calls": "3 - issue_read get_comments (the two read-order comments; the payload channel could not serve them, its front 15 timeline items were all events with hasNextPage true), create_pull_request, add_issue_comment. Everything else went through git, the zero-quota public-page payload channel for the card body, and the rendered page for the PR read-back.",
   "open_questions": [],
   "out_of_scope_findings": []
   }

   ---

   Generated by Claude Code
8. huangyiirene

   closed this as completedin #16527on Sep 7, 2026
9. huangyiirene

   removed

   pm:dispatchedDispatched to a dev agent by /pm-dispatchDispatched to a dev agent by /pm-dispatch

   on Sep 7, 2026
10. huangyiirene

    removed their assignment

    on Sep 7, 2026