sys_activity.type declares 11 options while a shipped producer writes a 12th (`scheduled`) — readonly fields make the enum unenforceable

[claude]

Filed from the objectui side while implementing objectstack-ai/objectui#5840 (record:activity was dropping every sys_activity.type: "scheduled" row). The renderer half is fixed there. This half lands here, because the declaration lives here.

Measured

packages/plugins/plugin-audit/src/objects/sys-activity.object.ts declares type as a select over eleven values:

created updated deleted commented mentioned shared assigned completed login logout system

scheduled is not among them. A shipped producer writes it anyway — objectstack-ai/hotcrm, src/actions/global.actions.ts:

const activity = await ctx.api.object('sys_activity').insert({
 type: EVENT_STATUS === 'held' ? 'completed' : 'scheduled',
 ...

registered for crm_lead, crm_contact, crm_account, crm_opportunity and crm_case. Both branches land in the column; only the completed branch was declared.

Why the write is not rejected

This repo already measured the mechanism, in the vocabulary pin's own docblock: every field on sys_activity is readonly: true, and objectql's validateRecord skips readonly fields on both the insert and update branch, so the invalid_option check that enforces a select field's declared options never runs for one. The eleven-value enum is documentation, not a contract — an undeclared value is stored silently.

So this is not "an app broke the rules and got caught". Nothing can catch it. The row is written, stored and queryable under a value the platform never declared.

The general door, not the special case

completed's own census row records that the platform itself forwards author-declared values into this column: ADR-0052 section 5b.2 activityMilestones[].type, applied verbatim by audit-writers.ts (if (milestone.type) activityType = milestone.type). Any metadata author can put any string there and it lands. scheduled is simply the first one someone measured downstream.

That makes the question sharper than one missing enum member: is sys_activity.type a closed platform vocabulary or an author-extensible one? Both readings are currently true of the code, which is the actual defect.

What is at stake downstream

objectui's packages/plugin-detail/src/renderers/recordActivityFeed.ts keys its feed-kind map on this vocabulary. Its test used to pin the key set as set-equal to the eleven declared options. objectstack-ai/objectui#5840 breaks that set-equality on purpose — the map now covers the declaration PLUS the values a shipped producer measurably writes — because pinning to the declaration means dropping stored rows. Whichever way this is ruled, that pin should follow it.

Directions

1. Declare it — add scheduled to the enum and a TYPES_WITH_WRITERS row naming the HotCRM writer. Cheapest, and makes the declaration match reality. Does not address the general door.
2. Rule the producer non-conformant — HotCRM must use a declared value. Keeps the vocabulary closed, but nothing enforces it, so it is a convention that will be broken again silently.
3. Enforce the vocabulary — make readonly select fields validate their options on system-owned writes, so an undeclared value is rejected loudly at the point of writing. Largest, and the only one that stops the class.
4. Declare it author-extensible — accept that milestone-declared types pass through, and say so, which makes downstream closed maps the bug.

Recommending 1 as the immediate step (it is reversible and it makes the shipped state honest) with 3 as the direction that actually closes it — but this is a vocabulary ruling and a maintainer call, not an objectui one. Recorded, not acted on.

---

Generated by Claude Code

[claude]

Triage (daily round, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24): lands in plugin-audit/sys-activity.object.ts declared options → domain:services + pm:queue, Bug (shipped producer writes a 12th value; declaration out of sync). Fence: declaring scheduled documents an existing engine-written value on a readonly field — the wider "readonly fields skip enum validation" class is NOT this card's scope; if the fix wants to touch validateRecord, stop and report.

---

Generated by Claude Code

[os-sam]

Claimed by the domain:services execution seat — PM session session_01APWX2AwT3a4xDcjPCe8bk4, branch claude/issue-11424-sys-activity-scheduled. Now pm:dispatched.

What is being dispatched, and what is explicitly NOT

The card body offers four directions and says plainly that the closed-vs-open vocabulary question is a maintainer call, not an objectui one. That is still true and this dispatch does not settle it.

What triage graded dispatchable, and what the dev is briefed to do, is direction 1 only: declare scheduled and record its writer. That scope is defensible without a ruling for one specific reason — every field on sys_activity is readonly: true and objectql's validateRecord skips readonly fields on both branches, so nothing accepts or rejects differently before and after this change. Declaring a value the platform already stores is documentation catching up to shipped reality, not a behaviour decision.

Directions 2 (rule the producer non-conformant), 3 (enforce the vocabulary on system-owned writes) and 4 (declare it author-extensible) all change what the platform means, and all three stay open. I am escalating the vocabulary ruling to the maintainer separately rather than letting it be decided inside this PR — see the fences below.

Dispatch fences carried to the dev

• ⛔ Do not touch validateRecord or anything in the readonly-skip path. That is direction 3, it is the largest of the four, and it is not this card's scope. If the fix appears to need it, stop and report — do not widen.
• ⛔ Do not write a sentence that settles the closed-vs-open question in code comments, the PR body, or the changeset. Adding scheduled + its TYPES_WITH_WRITERS row is compatible with directions 1, 3 and 4; do not phrase it as if it endorses one.
• ⛔ Do not touch objectstack-ai/hotcrm or objectstack-ai/objectui. The objectui renderer half is already fixed under objectui#5840; the HotCRM producer is a different repo and a different question (direction 2).
• ⛔ No packages/spec/** edits. No content/docs/releases/** edits.
• The card notes objectui#5840 deliberately broke the old set-equality pin between the renderer's feed-kind map and the eleven declared options. Do not try to restore set-equality from this side; that pin follows the ruling, and the ruling is not made here.
• Premise-first: re-measure that scheduled is still absent from the declared options on main before writing anything. If it is already declared, that is a legitimate delivery — report premise_still_valid: false with pr: null and stop.

---

Generated by Claude Code

[os-sam]

Ruling split out: #11507 — "Is sys_activity.type a closed platform vocabulary or an author-extensible one?", filed needs-user-decision.

This card keeps direction 1 only. #11507 holds directions 2 / 3 / 4 so the question survives this card's closure rather than dying with it.

Two things recorded on #11507 that are worth stating here too, because they bound what this PR may claim:

• 2 and 3 are not additive on top of 1. If either is ruled, scheduled's declaration is revisited — under 2 it should arguably come back out. That is fine and reversible, and it is exactly why this PR must not phrase the declaration as endorsing an end state.
• Since objectui#5840 broke the old set-equality pin between the declaration and the renderer's feed-kind map, there is currently no pin asserting that relationship in either direction, and one cannot be written until [Decision] Is sys_activity.type a closed platform vocabulary or an author-extensible one? Both readings are true of the code today #11507 is ruled. Do not try to restore it from this side.

---

Generated by Claude Code

[claude]

{
 "issue": 11424,
 "status": "done",
 "branch": "claude/issue-11424-sys-activity-scheduled",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/11522",
 "premise_still_valid": true,
 "summary": "Direction 1 only, as dispatched. `scheduled` added to the `sys_activity.type` select next to `completed`, plus the `TYPES_WITH_WRITERS` census row the pin demands, the four regenerated locale bundles (three leaves hand-translated: 已安排 / 予定 / Programado) and one changeset. I confirmed the readonly-skip mechanism myself before writing code, in two independent ways: by reading `record-validator.ts` (L1023 insert, L1033 update, the same `if (def.system || def.readonly) continue;` guard, so the `invalid_option` check never runs for a readonly select), and by measurement — with the enum value added and nothing else changed, exactly one of the package's 313 assertions moved, and it was the declarative census pin; the behavioural sibling `activity-type-vocabulary-enforcement.test.ts`, which inserts an undeclared value into this very column and asserts it lands against a not-readonly control, stayed green through that same run. So nothing accepts or rejects differently. The census row was verified at the producer rather than transcribed from the card: hotcrm 5eee1bd, `src/actions/global.actions.ts:349` writes `type: EVENT_STATUS === 'held' ? 'completed' : 'scheduled'` and `SCHEDULE_MEETING_SPEC` declares `eventStatus: 'planned'`, so `schedule_meeting` always takes the `scheduled` branch, registered on all five CRM objects. That sweep turned up two adjacent facts, both recorded in the census file under the bounded in-place rule and both named in the PR body: `completed` has a SECOND writer (hotcrm `src/actions/contact.actions.ts:165`, the send_email body), and the census's in-repo sweep cannot see either of them, because an app's server-side action reaches this column directly through `ctx.api.object('sys_activity').insert(...)` — a third door beside audit-writers.ts and the milestone escape hatch. Two stale docblock sentences were corrected in the same file (the hardcoded 'eleven-value' count dropped; the claim that objectui's feed-kind map is set-equal to this enum past-tensed to the #8203 census and attributed to objectui#5840, explicitly not measured from here). No fence was crossed: `validateRecord` untouched, no `packages/spec/**`, no `content/docs/releases/**`, no objectui or hotcrm edits (hotcrm was read from a read-only clone), the objectui set-equality pin untouched from this side, and nothing written anywhere settles the closed-vs-open vocabulary question. PR is `Part of #11424`, not `Fixes` — merging it must not close the card while directions 2/3/4 are open.",
 "tests": "All at the branch head commit 980a966 (clean tree), heavy steps serialized through scripts/pm/os-verify-lock.sh, verdicts read from each gate's own line and every exit code captured before any pipe. (1) `pnpm --filter '@objectstack/plugin-audit^...' build` — VERDICT command-exit 0 (deps built first, so the suite ran against fresh dist). (2) ENUM-ONLY MEASUREMENT (predicted in writing beforehand, then run): `Test Files 1 failed | 18 passed (19)`, `Tests 1 failed | 312 passed (313)`, the single red being `sys-activity-type-vocabulary.test.ts > every declared type has a recorded disposition, and vice versa`, diff `+ \"scheduled\"` — the enforcement test green in the same run, exactly as predicted. (3) After the census row: `pnpm --filter @objectstack/plugin-audit test` — `Test Files 19 passed (19)`, `Tests 314 passed (314)` (the it.each grew by one case), and `typecheck` — `tsc --noEmit` clean, echo of the script name confirmed in the log (pnpm zero-match trap). (4) i18n regeneration by the extractor itself with the config docstring's documented flags: `✓ Generated 4 file(s)`, diff exactly four single-line insertions; the three non-en leaves then hand-translated (leaf values are the hand-editable part per the file header), verified on disk with anchored greps in both directions (`scheduled: \"scheduled\"` count 0 in each locale). (5) Gate union derived by `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` (no paths passed; it read 6 working-tree paths off the merge base) — all exit=0: check:nul-bytes, check:empty-changeset, check:cross-package-test-inputs, check:published-files, check:slot-lookup, check:test-source-alias, check:type-source-resolution, check-ci-filter-parity, check-plugin-teardown-shape, docs-audit/check-affected-docs, check:query-options-erasure, check:type-check-coverage, check:engine-double-contract, check:where-matcher; the ratchet family re-run at 980a966 on a clean tree (`slot-lookup ratchet holds … none new`, `query-options-erasure ratchet holds … none new`, `check-engine-double-contract: OK — 390 pinned`, `where-matcher conformance holds: 288/288`, `check-type-check-coverage: OK`, `check-nul-bytes: OK (6456 files)`). (6) ESLint narrowed to the 7 changed files with --no-inline-config: 6 .ts files linted, 0 errors, 1 warning that is `File ignored because no matching configuration was supplied.` on the changeset .md. NOT MEASURED, and not reported as either pass or red: `check:i18n` returned its own `check-i18n-bundles: PREREQUISITE NOT MET — the workspace CLI is not built` (it runs the BUILT CLI; the equivalence argument and its one untested delta — dist vs source entry into the same command — are written out in the PR body); `check:type-check-debt` not run, it needs the whole workspace built, and the substance for this diff is the package's own green tsc; the repo-wide ESLint farm not run — the narrowing is declared, with the invariance read from `eslint.config.mjs:326-332` (this repo never enables type-aware linting for any file, so this diff cannot move a verdict on a file it does not touch), but the population was not enumerated locally, so that is a narrowing CI closes rather than a proof. No ablation was needed: the repo's own census pin supplied the red, so nothing was mutated and restored.",
 "open_questions": [
 {
 "question": "Not blocking this PR — evidence for the vocabulary ruling you are escalating. The card frames the general door as ADR-0052 §5b.2 `activityMilestones[].type` forwarding author-declared values. Measuring the producer showed a SECOND, wider door: an app's server-side action writes `sys_activity` directly via `ctx.api.object('sys_activity').insert({ type: … })` (both hotcrm sites do this — `scheduled` in global.actions.ts, `completed` in contact.actions.ts). It is not a REST write (the census pins that `sys_activity` exposes no REST write verb, and that still holds), and it is invisible to any grep of this repo. Does the ruling need to cover it?",
 "options": [
 "A — rule on the vocabulary as framed (milestone door only); the app-action door is then an unruled second path that the next census will hit again",
 "B — widen the ruling's scope to 'every in-process write of this column, whoever authored the code', which is what directions 3 and 4 would each have to enforce or bless to be complete",
 "C — treat the app-action door as its own card, downstream of whichever of 2/3/4 is chosen"
 ],
 "recommendation": "B for the ruling's SCOPE, without prejudging which of 2/3/4 wins: whatever is decided, direction 3 that only validates milestone-forwarded types would leave the larger door open, and direction 4 that declares only milestones author-extensible would still deny what shipped apps write. I recorded the door in the census file as a fact about where to look and took no position on the ruling. Note also that direction 2 (rule the producer non-conformant) now has two producer sites, not one — the second writes a DECLARED value (`completed`), so it is conformant today and only becomes relevant if the ruling constrains the door rather than the value."
 }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code