docs(spec): the dialect table's cron row names what fires a schedule — cron-parser is not in the product

.changeset/cron-dialect-row-names-croner.md

@@ -0,0 +1,7 @@
+---
+"@objectstack/spec": patch
+---
+
+The Expression Protocol dialect table no longer names `cron-parser` as the `cron` engine. That package is not a dependency of any ObjectStack package; the row shipped to authors through the generated reference page (`content/docs/references/shared/expression.mdx`) and pointed them at the wrong library for field counts, alias vocabulary and second-field semantics.
+
+The row now says what the code does: no cron syntax is judged at parse time; `croner` evaluates a cron expression 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. Documentation only — no schema, accept set or behaviour changes.

content/docs/references/shared/expression.mdx

@@ -21,9 +21,15 @@ envelope.
 | dialect | engine | use |
 |:---|:---|:---|
 | `cel`      | `@objectstack/formula` (cel-js + ObjectStack stdlib) | formulas, predicates, seed dynamic values |
-| `cron`     | `cron-parser` | job schedules |
+| `cron`     | none at parse time — `croner` fires it at schedule time, on the one wired slot | job schedules |
 | `template` | `{{var}}` interpolation at evaluate time (same variable scope as CEL) | notification subjects/bodies, `titleFormat`, prompt templates |
 
+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.
+
 Those three are the whole list — it is exactly the `ExpressionDialect` enum
 below. Procedural JavaScript is **not** a dialect: it is the L2 authoring
 surface, the sandboxed, capability-gated `ScriptBody { language: 'js' }` in

packages/spec/src/shared/expression.zod.ts

@@ -19,9 +19,15 @@ import { z } from 'zod';
  * | dialect | engine | use |
  * |:---|:---|:---|
  * | `cel`      | `@objectstack/formula` (cel-js + ObjectStack stdlib) | formulas, predicates, seed dynamic values |
- * | `cron`     | `cron-parser` | job schedules |
+ * | `cron`     | none at parse time — `croner` fires it at schedule time, on the one wired slot | job schedules |
  * | `template` | `{{var}}` interpolation at evaluate time (same variable scope as CEL) | notification subjects/bodies, `titleFormat`, prompt templates |
  *
+ * 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.
+ *
  * Those three are the whole list — it is exactly the `ExpressionDialect` enum
  * below. Procedural JavaScript is **not** a dialect: it is the L2 authoring
  * surface, the sandboxed, capability-gated `ScriptBody { language: 'js' }` in