@mulmoclaude/core 0.14.0 → 0.18.0

package/assets/helps/collection-skills.md

@@ -148,7 +148,7 @@ skipped, never crashes the host):
 
 `string` · `text` (multi-line) · `email` · `number` · `date` (`YYYY-MM-DD`) ·
 `datetime` (`YYYY-MM-DDTHH:MM`) · `boolean` · `markdown` · `money` · `enum` ·
-`ref` · `embed` · `table` · `derived` · `image` · `file` · `toggle`
+`ref` · `embed` · `backlinks` · `rollup` · `table` · `derived` · `image` · `file` · `toggle`
 
 Every field spec needs a `type` and a `label`. Extra keys by type:
 
@@ -179,9 +179,41 @@ Every field spec needs a `type` and a `label`. Extra keys by type:
   sibling as a dropdown picker in the editor and hides its own cell (the embed
   owns it). E.g. a multi-issuer invoice: a `ref` field `issuerId → profile`
   plus `{ "type": "embed", "to": "profile", "idField": "issuerId" }`.
+- **`backlinks`** — `from: "<source-slug>"`, `via: "<ref-field-in-source>"`,
+  `display: ["<source-col>", ...]`, optional `filter: { "field": ..., "in": [...] }`.
+  The **reverse** side of a `ref`: a read-only sub-table (detail view only) of
+  the records in `from` whose `via` ref points at this record — each row links
+  to that record. **Nothing is stored** on this record (like `derived`/`embed`);
+  you never write it, and the rows update whenever the source records change.
+  `display` names the source columns to show — a derived source column works
+  when its formula is self-contained (e.g. an invoice `total` summing its own
+  line items), but one that derefs yet another collection renders em-dash;
+  `filter` narrows rows by a source field's value, same shape as `when`. E.g. a
+  client's open invoices:
+  `{ "type": "backlinks", "label": "Invoices", "from": "invoice", "via": "clientId", "display": ["issueDate", "total", "status"], "filter": { "field": "status", "in": ["draft", "sent"] } }`.
+  Resolution is fail-soft: an unknown `from` / `via` / `display` column just
+  renders an empty sub-table — no error, so author the `ref` side first.
+- **`rollup`** — `from: "<source-slug>"`, `via: "<ref-field-in-source>"`,
+  `op: "sum" | "count"`, `column: "<source-col>"` (required for `sum`, omitted
+  for `count`), optional `filter` (same shape as `when`, against the source).
+  A **cross-collection aggregate**: a computed number — never stored — summed
+  (or counted) over the records in `from` whose `via` ref points at this
+  record. Backlinks show the rows; rollup collapses them to a scalar that
+  renders everywhere a number does (list column included). E.g. a client's
+  unbilled hours:
+  `{ "type": "rollup", "label": "Unbilled hours", "from": "worklog", "via": "clientId", "op": "sum", "column": "hours", "filter": { "field": "billed", "in": ["false"] } }`.
+  Fail-soft: an unresolvable `from` renders em-dash; an empty match set is a
+  real 0. Summing a source `derived` column works when its formula is
+  self-contained; non-numeric values are skipped. A `derived` formula ON THE
+  SAME schema may reference rollup fields as plain identifiers — rollups
+  resolve before the formula pass — e.g. two one-sided counts combined:
+  `"played": { "type": "derived", "formula": "homePlayed + awayPlayed" }`.
+  (Caveat: that works on the collection's own rows; a `<refField>.<col>`
+  deref FROM another collection reads the target without its rollups, so a
+  rollup-fed derived column is em-dash when viewed through a ref.)
 - **`table`** — `of: { <col>: <sub-field-spec>, ... }`. An array of rows. Each
-  sub-field is a flat spec; sub-fields **cannot** be `table` or `derived`
-  (no nested tables, no computed columns).
+  sub-field is a flat spec; sub-fields **cannot** be `table`, `derived`,
+  `backlinks`, or `rollup` (no nested tables, no computed columns).
 - **`derived`** — `formula: "<expr>"`, optional `display` (`number` default, or
   `money` / `string` / `date`) and `currency`. **Read-only, host-computed** —
   you NEVER write derived values into the JSON; the host recomputes them on
@@ -302,11 +334,50 @@ Rules and limits:
 
 ### Actions (per-record buttons)
 
-Each entry in `actions` renders a button in the read-only detail view. The only
-`kind` today is `"chat"`: clicking it starts a **new chat in a role**, seeded
-with a template + the record data — the role then does the work with its tools.
-This is how hard logic the schema can't express (PDF generation, bookkeeping
-journals, drafting an email) gets delegated to natural language.
+Each entry in `actions` renders a button in the read-only detail view. Three
+kinds:
+
+- **`"chat"`** — clicking it starts a **new visible chat in a role**, seeded
+  with a template + the record data — the role then does the work with its
+  tools. Pick it when the output IS the conversation or the user may need to
+  steer: PDF generation, bookkeeping journals, drafting an email.
+- **`"agent"`** — clicking it dispatches a **hidden background worker** with
+  the SAME seed; the worker edits the record via `manageCollection` and
+  finishes silently — no chat window, the record just updates. Pick it for
+  mechanical enrichment where a transcript would be noise: refresh a price,
+  fetch metadata, look something up and write it back. The button shows a
+  spinner while the worker runs; a failed run raises one bell notification
+  (cleared by the next success). **End an agent template with**: "edit the
+  record via manageCollection and stop — do not present anything."
+- **`"mutate"`** — **no LLM at all**: the host applies a declarative write the
+  moment the button is clicked (after an optional mini-form). Pick it when the
+  write needs zero judgment — "Mark paid", "Assign", any fixed state
+  transition. Instant and token-free. Shape (no `role`/`template`):
+
+  ```json
+  {
+    "id": "assign", "label": "Assign", "icon": "person_add",
+    "kind": "mutate",
+    "require": { "field": "status", "in": ["open"] },
+    "params": { "assignee": { "type": "string", "label": "Assignee", "required": true } },
+    "set": { "assignee": "$params.assignee", "status": "assigned" }
+  }
+  ```
+
+  `set` merges into the record (only the named fields change) — values are
+  literals or `$params.<name>` references. `require` replaces `when` (same
+  shape, same visibility-is-authorization rule, re-checked server-side).
+  `params` declares an optional mini-form using the table sub-field DSL; the
+  submitted values are validated like record fields, and the write itself runs
+  through the same gate as `putItems` (a rejected write shows the `problem`).
+  Constraints (schema-validated): `set` keys must name declared, non-computed
+  fields (never the primaryKey); every `$params` reference must name a
+  declared param; mutate is **record-level only** (not in `collectionActions`).
+  Group several fields in one `set` so "paid" can mean `status` + `paidDate`
+  written together. `toggle` stays the right tool for a single checkbox.
+
+This is how hard logic that the schema can't express gets delegated to natural
+language (and, for `"mutate"`, how the schema-expressible part stays free).
 
 ```json
 {
@@ -350,7 +421,11 @@ text / markdown / html / file fields are left out, so the prompt stays small).
 ```
 
 - Same `id` uniqueness rule (within `collectionActions`); same path-safe
-  `template`; same `role`-seeds-a-new-chat behavior.
+  `template`; same `role` + kind behavior (`"chat"` seeds a visible chat,
+  `"agent"` dispatches a silent worker over the whole collection — e.g. a
+  "Sync" button that pushes records to an external system via MCP; the
+  known-good sync recipe, including the snapshot-diff state file and the
+  `externalId` write-back, is **`config/helps/egress-sync.md`**).
 - `when` is **ignored** here — there is no record to gate on. Always shown.
 
 ### Completion tracking (bell notifications)
@@ -778,6 +853,13 @@ records through **`manageCollection`**, not raw file I/O:
   / `fields` on large collections to keep the result small — e.g.
   `fields: ["id"]` to check for an id collision before an add.
 - **Delete** — remove the record file (`manageCollection` has no delete).
+- **Cross-collection questions — `getOntology`.** Returns every collection in
+  the workspace with its `primaryKey`, effective `displayField`, record count,
+  and its `ref` / `embed` / `backlinks` / `rollup` relations (field → related slug, including refs
+  inside `table` columns as `lines.clientId`). When a question spans
+  collections ("which clients have unpaid invoices AND unlogged hours?"),
+  call it first to see which collections exist and how they join, then
+  `getItems` only the ones involved — instead of reading every schema.json.
 - **Id charset** (enforced by `safeRecordId` in
   `packages/core/src/collection/server/paths.ts` — the single source of
   truth; `manageCollection` rejects ids that fail it): start and end with a
@@ -789,8 +871,9 @@ records through **`manageCollection`**, not raw file I/O:
   enforces this on every targeted read/write, so an id that only _looks_ fine in
   a full `getItems` listing but violates the rule can't be updated or deleted by
   id — fix the id, don't work around it with raw file I/O.
-- **Never write `derived` fields**, and never write an `embed` field — both are
-  display-only / host-computed (`putItems` rejects rows that carry them).
+- **Never write `derived` fields**, and never write an `embed`, `backlinks`,
+  or `rollup` field — all are display-only / host-computed (`putItems`
+  rejects rows that carry them).
 - Leave optional fields out of the row entirely rather than writing empty
   strings.
 - For a `ref` field, write the raw target slug, and make sure that record

package/assets/helps/custom-view.md

@@ -123,6 +123,34 @@ const { written, rejected } = await res.json(); // fix & re-send any rejected ro
 Surface any `rejected` rows to the user with their `problem` text — don't fail
 silently.
 
+### Invoking a `kind: "mutate"` action (only with the `write` capability)
+
+If the schema declares a `kind: "mutate"` action (a declarative state
+transition — e.g. an `assign` button with `require`/`params`/`set`), invoke it
+instead of re-encoding the same field writes as a PUT: the server re-checks the
+action's `require` gate, validates the `params`, and applies the `set`
+atomically — one source of truth for the transition, in the schema.
+
+```js
+const res = await fetch(dataUrl + "/actions/assign", {
+  method: "POST",
+  headers: { Authorization: "Bearer " + token, "Content-Type": "application/json" },
+  body: JSON.stringify({ itemId: "task-3", params: { assignee: "kai" } }),
+});
+if (res.ok) {
+  const { item } = await res.json(); // the written record
+} else {
+  const { error } = await res.json(); // 400 bad param / 409 require not met — show it
+}
+```
+
+- `itemId` is the record's primary-key value; `params` only if the action
+  declares them.
+- **Mutate kind only.** `chat` / `agent` actions can never be invoked with a
+  view token (they start LLM work) — you get a 403.
+- A 409 means the record's current state fails the action's `require` — treat
+  it as "button disabled", not an error to retry.
+
 ### Staying live — `onChange`
 
 By default a view paints once, on load. To keep it fresh, register a callback —

package/assets/helps/egress-sync.md

@@ -0,0 +1,158 @@
+# Egress sync — push collection records to an external system
+
+Read this when the user asks to **sync a collection outward** — "push my
+invoices to freee", "mirror my clients into Notion", "keep this list in a
+Google Sheet". It is the write-back counterpart of feeds (which pull data IN):
+a **prose pattern**, not a host feature. There is no `egress` schema block, no
+sync engine, no connector registry — you are the sync engine, and this file is
+the known-good way to be one.
+
+Read `config/helps/collection-skills.md` first for the schema DSL and the
+actions system; this file assumes both.
+
+## Why this is a pattern, not host machinery
+
+A host-side sync engine needs lifecycle triggers, debounce, retries, and —
+hardest of all — a loop guard that can tell "the sync worker wrote this"
+apart from "the user edited this". In this workspace that guard is
+unimplementable: records are plain files with no provenance, and raw file
+writes bypass any tool-layer flag. Meanwhile every judgment-shaped part of a
+sync (which changes matter, how fields map to the remote system, what to do
+on conflict) is exactly what you handle well and a schema can't express.
+
+So the architecture is: **the host provides the trigger and the state
+substrate; you provide the sync logic; this recipe keeps it correct.**
+
+- Trigger — a collection-level `kind: "agent"` action (a "Sync" button), or
+  a scheduled skill for periodic sync.
+- State — a snapshot file kept **inside the collection's skill dir** (the
+  workspace is the database; sync state is just another file).
+- Transport — whatever MCP tool reaches the remote system (Notion, Google
+  Sheets/Drive, GitHub, a REST API via Bash+curl…).
+
+## The pattern in five rules
+
+1. **Diff against a snapshot, never "sync everything".** Keep
+   `data/skills/<slug>/sync/last-synced.json` — a map of record id →
+   the record as of the last successful push. On each run: read current
+   records (`manageCollection` getItems with `fields` — EXCLUDE computed
+   fields like `derived`/`rollup` unless the remote actually wants them),
+   compare against the snapshot, and push only creates / updates / deletes.
+   No snapshot file yet ⇒ first run ⇒ everything is a create.
+2. **Record remote identity on the record.** Add an `externalId` field
+   (plain `string`) to the schema. When the remote system assigns an id
+   (a Notion page id, a row number, an issue URL), write it back to the
+   record with `putItems` `mode: "merge"`. That write is the ONLY write
+   back into the collection a sync run may make — never round-trip remote
+   field values back into local records (the local collection is the
+   source of truth; pulling remote edits back is a *feed*, a different
+   pattern, and mixing the two directions in one worker is how sync loops
+   are born).
+3. **Update the snapshot per record, after each successful push — not once
+   at the end.** If the run dies halfway, the snapshot then reflects
+   exactly what was pushed, and the next run resumes with the remainder
+   instead of re-pushing everything (duplicates) or skipping the tail
+   (silent loss).
+4. **Fail partially, report honestly.** One record failing to push must not
+   abort the rest. Count pushed / failed / skipped; if anything failed,
+   leave it OUT of the snapshot so the next run retries it.
+5. **Deletes are opt-in.** A record present in the snapshot but missing from
+   the collection was deleted locally. Only propagate the delete if the
+   user asked for mirror semantics; the safer default is to leave the
+   remote row and note it in the run summary. (Say which behaviour you
+   chose in the template.)
+
+## Setting it up
+
+1. Make sure the schema has `externalId` (add it via `putSchema` if
+   missing): `{ "type": "string", "label": "External ID" }`.
+2. Add a collection-level agent action:
+
+```jsonc
+"collectionActions": [{
+  "id": "sync", "label": "Sync to Notion", "icon": "cloud_upload",
+  "kind": "agent", "role": "general", "template": "templates/sync.md"
+}]
+```
+
+3. Write `data/skills/<slug>/templates/sync.md` from the reference template
+   below, filling in the remote system's specifics (which MCP tool, the
+   field mapping, create-vs-update calls).
+4. For periodic sync, schedule it instead of (or in addition to) the
+   button — but start with the button: sync templates need a few visible
+   runs before they've earned a schedule.
+
+## Reference template (`templates/sync.md`)
+
+Adapt the bracketed parts; keep the structure — every line of it exists
+because of a failure mode.
+
+```markdown
+# Sync <collection title> to <remote system>
+
+You are a background worker. Push local changes in the `<slug>` collection
+to <remote system>, then stop. Nobody is watching — do not call present*
+tools, do not post a summary to the chat.
+
+## Steps
+
+1. Read the snapshot `data/skills/<slug>/sync/last-synced.json` (id → record
+   as of the last successful push). If the file does not exist, this is the
+   first run: treat every record as new, and create the `sync/` directory.
+
+2. Read the current records: `manageCollection` getItems (slug `<slug>`,
+   `fields`: [<the stored fields the remote needs — no derived/rollup>]).
+
+3. Diff current vs snapshot:
+   - id not in snapshot            → CREATE remotely
+   - id in both, fields differ     → UPDATE remotely (use the record's
+                                     `externalId` to address the remote row)
+   - id only in snapshot           → deleted locally. [Choose one:]
+                                     [mirror: DELETE remotely] /
+                                     [default: leave the remote row; count it]
+   - id in both, fields identical  → skip
+
+4. For each create/update, via <MCP tool>:
+   - Map fields: [<local field> → <remote property>, …]
+   - On CREATE, take the remote id from the response and write it back:
+     `putItems` `mode: "merge"` with `{ "<primaryKey>": "<id>",
+     "externalId": "<remote id>" }`. This is the only collection write
+     you may make — never copy remote values into local records.
+   - After EACH successful push, update `last-synced.json` with that
+     record's current values (atomic-ish: rewrite the whole file each time;
+     it is small). A failed push leaves that id untouched in the snapshot.
+
+5. If a push fails, log it and continue with the remaining records. Retry
+   nothing within this run.
+
+6. When done: if anything failed, raise ONE short error so the failure bell
+   fires (e.g. exit with an error message counting failures). If everything
+   succeeded, just stop — silently.
+
+## Rules
+
+- Never write remote data back into local records (except `externalId`).
+- Never push computed fields; the remote gets stored values only.
+- Do not create duplicate remote rows: a record with an `externalId` is
+  always an UPDATE, even if it is missing from the snapshot.
+- Keep `last-synced.json` valid JSON at all times.
+```
+
+## Caveats
+
+- **Interactively-authenticated MCP servers may be absent for hidden
+  workers.** Connectors authenticated through the claude.ai UI (Notion,
+  Gmail, Google Drive as claude.ai connectors) are not necessarily
+  available in a hidden/headless worker session. Test the Sync button
+  once; if the MCP tool is missing, either use a server-configured MCP
+  (API-key based), or fall back to Bash + the remote's REST API with a
+  workspace-stored token.
+- **The remote is a mirror, not a second master.** If the user wants
+  remote edits to flow back, that is a separate *feed* (`ingest`) reading
+  the remote into a different collection — or a deliberate two-way design
+  they should ask for explicitly. Do not improvise bidirectional sync
+  inside a sync template.
+- **`externalId` makes re-linking survivable.** Even if the snapshot is
+  lost, records with an `externalId` update their existing remote rows
+  instead of duplicating them; only snapshot-less records without an
+  `externalId` risk a duplicate create.

package/assets/helps/index.md

@@ -81,6 +81,7 @@ See [Wiki](config/helps/wiki.md) for details on how it works.
 - [Clients + Worklog](config/helps/billing-clients-worklog.md) — recipe for a client database and a per-client timesheet (Bundle A of the billing suite); set this up before invoicing
 - [Invoicing](config/helps/billing-invoice.md) — recipe for an invoice ledger + business profile with line items, host-computed totals, and PDF / bookkeeping action buttons (Bundle B; references the clients + worklog from Bundle A)
 - [Portfolio tracker](config/helps/portfolio-tracker.md) — recipe for a paired stock-quotes watchlist + holdings portfolio whose price/value are computed live from the quotes via a cross-collection derived ref
+- [Egress sync](config/helps/egress-sync.md) — push a collection's records OUT to an external system (Notion, Sheets, a REST API): the snapshot-diff pattern for a collection-level agent "Sync" action, `externalId` write-back, and a reference `templates/sync.md`
 
 ## Workspace Layout
 

package/dist/{calendarGrid-kO6rGfm0.js → calendarGrid-B3dtFN-m.js}

@@ -23,6 +23,19 @@ var FEED_SCHEDULES = [
 	"weekly",
 	"on-demand"
 ];
+/** derived/embed/backlinks/rollup/toggle are host-computed or projected —
+*  never written to the record JSON, so required / value checks and
+*  edit-draft slots must not apply to them. THE single source for
+*  "computed" — lives here (zod-free at runtime) so browser code
+*  (`./draft`) and the zod record compiler (`./recordZ`, which re-exports
+*  it) share one set instead of drifting copies. */
+var COMPUTED_TYPES = /* @__PURE__ */ new Set([
+	"derived",
+	"embed",
+	"backlinks",
+	"rollup",
+	"toggle"
+]);
 /** Narrowing guard: true when `every` is the field-driven arm. */
 function isFieldDrivenEvery(every) {
 	return "fromField" in every;
@@ -58,6 +71,96 @@ function isSafeRecordId(value) {
 	return !value.includes("..");
 }
 //#endregion
+//#region src/collection/core/actionVisible.ts
+/** Core matcher:
+*  - no `when` ⇒ always true (visible);
+*  - otherwise true only when `record[when.field]` is present and its
+*    stringified value is one of `when.in`.
+*  A missing/undefined/null field is treated as "not a match"
+*  (hidden), so a status-gated target never shows on a record that
+*  lacks the status. */
+function whenMatches(when, record) {
+	if (!when) return true;
+	const value = record[when.field];
+	if (value === void 0 || value === null) return false;
+	return when.in.includes(String(value));
+}
+/** True when the action's button should render against `record` — and,
+*  server-side, whether it may RUN (visibility is the authorization
+*  rule, for every kind). */
+function actionVisible(action, record) {
+	return whenMatches(action.when ?? action.require, record);
+}
+/** The run key naming one in-flight `kind: "agent"` action button —
+*  written by the server's dispatch guard, read back by the client from
+*  the detail response's `runningActions` to drive the spinner. ONE
+*  builder (isomorphic) so the two sides can't drift. Collection-level
+*  and per-record actions live in distinct namespaces so an id collision
+*  between `actions` and `collectionActions` can't alias. */
+function agentActionRunKey(actionId, itemId) {
+	return itemId === void 0 ? `collection/${actionId}` : `item/${itemId}/${actionId}`;
+}
+/** True when the field should render against `record`. A field with
+*  no `when` is always shown; otherwise it's shown only when the
+*  record matches (e.g. hide a rating field until `visited` is true).
+*  Purely presentational — a hidden field's stored value is never
+*  altered, so toggling the gate back on restores it. */
+function fieldVisible(field, record) {
+	return whenMatches(field.when, record);
+}
+//#endregion
+//#region src/collection/core/backlinks.ts
+/** The SOURCE records whose `via` field stores `recordId` (compared as
+*  strings, like every ref deref), with the optional `filter` applied —
+*  in the source items' given order. Fail-soft by construction: a `via`
+*  key that doesn't exist on the source records simply matches nothing.
+*  Callers pass DERIVED source records, so a `filter`/`display` on a
+*  derived column works when its formula is SELF-CONTAINED (an invoice
+*  `total` = sum over its own line items); a source column that derefs
+*  yet another collection stays absent — the same each-record-derives-
+*  against-itself rule ref targets follow. */
+function backlinkRows(spec, recordId, sourceItems) {
+	if (!recordId) return [];
+	return sourceItems.filter((item) => String(item[spec.via] ?? "") === recordId && whenMatches(spec.filter, item));
+}
+/** Project one backlink row to the keys consumers surface: the source
+*  collection's primaryKey (rows must stay addressable — it's the link
+*  target) plus the declared `display` columns. Keys the row doesn't
+*  carry are simply absent, mirroring `projectFields` in getItems. */
+function projectBacklinkRow(row, display, primaryKey) {
+	const keys = display.includes(primaryKey) ? display : [primaryKey, ...display];
+	return Object.fromEntries(keys.filter((key) => key in row).map((key) => [key, row[key]]));
+}
+/** Numeric coercion shared by the strict record lint (`./recordZ`) and
+*  rollup sums: a plain number, or a non-blank numeric string (renderers
+*  coerce those via `Number(...)`, so they display fine). Anything else —
+*  arrays (`[]` stringifies to `""` = 0, `[42]` to `"42"`), booleans,
+*  objects — is NaN. Lives here (zod-free) so both consumers share one
+*  definition of "numeric". */
+function coerceNumeric(value) {
+	if (typeof value === "number") return value;
+	if (typeof value === "string" && value.trim() !== "") return Number(value);
+	return NaN;
+}
+/** The rollup aggregate over the matching source rows (plan step ⑤):
+*  `count` = how many rows match; `sum` = the total of `column` over
+*  them, skipping non-numeric / absent values (a partially-filled source
+*  still sums what's there). An EMPTY match set is a real 0 — the
+*  fail-soft null lives at the caller, for a source collection that
+*  couldn't be resolved at all. Same derived-source-records contract as
+*  `backlinkRows`: pass records derived against themselves, so summing a
+*  self-contained derived column (an invoice `total`) works. */
+function rollupValue(spec, recordId, sourceItems) {
+	const rows = backlinkRows(spec, recordId, sourceItems);
+	if (spec.op === "count") return rows.length;
+	let total = 0;
+	for (const row of rows) {
+		const value = coerceNumeric(spec.column === void 0 ? void 0 : row[spec.column]);
+		if (Number.isFinite(value)) total += value;
+	}
+	return total;
+}
+//#endregion
 //#region src/collection/core/where.ts
 /** True when `record[field]` is absent (`undefined`/`null`) — the only case
 *  where `ne` and every other op disagree on the result. */
@@ -787,6 +890,6 @@ function monthAnchorDate(year, month) {
 	return new Date(Date.UTC(year, month - 1, 1));
 }
 //#endregion
-export { isFieldDrivenEvery as A, SAFE_SLUG_PATTERN as C, FEED_SCHEDULES as D, AGENT_INGEST_KIND as E, INGEST_KINDS as O, SAFE_RECORD_ID_PATTERN as S, isSafeSlug as T, evaluateDerived as _, compareYmd as a, selectDynamicRecord as b, monthAnchorDate as c, parseTimeRange as d, recordSpan as f, resolveRowRefs as g, deriveAll as h, buildMonthGrid as i, embedTargetId as k, parseIsoDate as l, ymdKey as m, assignLanes as n, dateOf as o, spanCoversDay as p, bucketRecords as r, daySlice as s, MINUTES_PER_DAY as t, parseIsoDateTime as u, firstDateField as v, isSafeRecordId as w, matchesWhere as x, resolveIcon as y };
+export { SAFE_RECORD_ID_PATTERN as A, coerceNumeric as C, agentActionRunKey as D, actionVisible as E, COMPUTED_TYPES as F, FEED_SCHEDULES as I, INGEST_KINDS as L, isSafeRecordId as M, isSafeSlug as N, fieldVisible as O, AGENT_INGEST_KIND as P, embedTargetId as R, backlinkRows as S, rollupValue as T, evaluateDerived as _, compareYmd as a, selectDynamicRecord as b, monthAnchorDate as c, parseTimeRange as d, recordSpan as f, resolveRowRefs as g, deriveAll as h, buildMonthGrid as i, SAFE_SLUG_PATTERN as j, whenMatches as k, parseIsoDate as l, ymdKey as m, assignLanes as n, dateOf as o, spanCoversDay as p, bucketRecords as r, daySlice as s, MINUTES_PER_DAY as t, parseIsoDateTime as u, firstDateField as v, projectBacklinkRow as w, matchesWhere as x, resolveIcon as y, isFieldDrivenEvery as z };
 
-//# sourceMappingURL=calendarGrid-kO6rGfm0.js.map
+//# sourceMappingURL=calendarGrid-B3dtFN-m.js.map