record:activity drops every `sys_activity.type: "scheduled"` row, and 10 of FeedItemType's 13 kinds have no producer at all

[claude]

Rebuilt transfer (transfer API unavailable in this session). Origin: objectstack-ai/objectstack#11306, filed by os-zhuang at 2026-08-23T09:50:07Z. Moved by the triage seat (session session_01LsWeHbPzR3i6mmonFfGykk, 2026-08-23) under file-at-destination: record:activity is a console/UI renderer (source lives in this repo; packages/console in objectstack is its built artifact).

record:activity maps sys_activity.type onto feed-item kinds through a hardcoded table, and scheduled has no entry — so a scheduled (not-yet-held) meeting is discarded before any filter runs and can never appear on any activity timeline, whatever the page authors.

Measured

From the shipped bundle (@objectstack/console 17.1.0, dist/assets/plugins-views-BaBStVok.js):

Ya = { created:'field_change', updated:'field_change', deleted:'field_change',
 assigned:'field_change', shared:'field_change', system:'system',
 completed:'task',
 commented:undefined, mentioned:undefined, login:undefined, logout:undefined };

function to(e,t){ let n = Ya[String(e?.type)]; return n ? {…} : null; } // unmapped -> dropped

'scheduled' is not a key, so Ya['scheduled'] is undefined and the row is dropped by to() — upstream of showCompleted, upstream of types, upstream of everything a page can configure.

Executed over a lead's real rows:

created -> field_change
updated -> field_change
completed -> task
scheduled -> undefined <- dropped, 1 of 6 rows never reaches the timeline
system -> system

Who writes scheduled

HotCRM's schedule_meeting action — shipped for crm_lead, crm_contact, crm_account, crm_opportunity and crm_case — writes sys_activity rows with type: EVENT_STATUS === 'held' ? 'completed' : 'scheduled'. The held branch reaches the timeline; the scheduled branch is written, stored, queryable, and invisible on the surface built to display it. commented and mentioned are unmapped the same way, which is more surprising still on a component whose own props include showCommentInput / enableMentions.

The other half: declared kinds nothing can produce

FeedItemType (@objectstack/spec/ui) publishes 13 kinds:

comment | field_change | task | event | email | call | note | file |
record_create | record_delete | approval | sharing | system

Only three are reachable through Ya from sys_activity: field_change, task, system. The other ten are authorable — they parse, they typecheck, build accepts them — and no data path produces them. An author filtering to types: ['event'] to show meetings gets an empty tab and no diagnostic; that is a declared surface enforced by nothing, and it reads to an author (or to an AI writing metadata) as a working feature.

Suggested direction

Either extend the map so the vocabulary sys_activity actually stores reaches the timeline (scheduled → event is the obvious pairing and would make the declared event kind reachable at the same time), or narrow FeedItemType to the kinds a producer exists for. The present state is the worst of both: the enum promises ten kinds that cannot arrive, and a real stored row silently does not.

Found while fixing objectstack-ai/hotcrm#1209; not worked around there, per 「平台相关的功能应该在平台中实现」.

---

Generated by Claude Code

[claude]

Triage (rebuilt from objectstack, see body header): pm:queue, domain:ui, Bug. Landing: the record:activity renderer (plugin-views source). Family note: #5841 is the same renderer's widen-on-bad-filter defect — same file, different defect shape (dropped kind-map entry vs filter sanitisation), so answer fold-or-serial per the five gates before dispatching either; if not folded, hard-serial on the shared file.

---

Generated by Claude Code

[claude]

Claiming this card.

• session id: 01EuPCi56cnGyykygi3z9w4m (domain:ui dev seat)
• branch: claude/issue-5840-activity-scheduled-kind

PM ruling carried into this run: implement the first direction only — extend the sys_activity.type -> feed-kind map so the vocabulary the store actually holds reaches the timeline. Narrowing FeedItemType is out of surface (that enum is published by @objectstack/spec in the objectstack repo; retiring kinds there carries ADR-0087 registry obligations) and will be recorded as a separate unassigned finding.

Note for whoever takes #5841: same renderer file, different defect. Hard-serial on packages/plugin-detail/src/renderers/recordActivityFeed.ts if it is dispatched before this PR lands.

---

Generated by Claude Code

[claude]

os-dev-report

{
 "issue": 5840,
 "status": "done",
 "branch": "claude/issue-5840-activity-scheduled-kind",
 "pr": "https://github.com/objectstack-ai/objectui/pull/5886",
 "premise_still_valid": true,
 "summary": "Re-measured at live source (packages/plugin-detail/src/renderers/recordActivityFeed.ts, not the shipped bundle the card quotes) and the defect reproduces exactly: ACTIVITY_TYPE_TO_FEED_TYPE had no `scheduled` key, so activityRowToFeedItem returned null upstream of showCompleted, types and everything else a page can configure. Mapped `scheduled` -> `event` per the PM ruling, which also makes the declared `event` feed kind reachable for the first time. Did NOT narrow FeedItemType (cross-repo spec retirement, ADR-0087 obligations) and did NOT change the unknown-type default to a catch-all; instead the drop stopped being silent (one deduped console.warn per unmapped type, and none for types the table knows and deliberately excludes). commented/mentioned left UNMAPPED: no producer exists - objectstack's own writer census records both as 'no writer', a grep of hotcrm returns nothing, and mapping them would double-render against the sys_comment path. TWO CORRECTIONS TO THE CARD, both material. (1) Its 'ten unreachable kinds' counts only the sys_activity map; `comment` does have a producer (sys_comment via the host discussion context), so the true count after this PR is eight - filed as #5877. (2) More importantly, `scheduled` is NOT in the platform's declared vocabulary at all: plugin-audit declares eleven options without it, and it lands anyway because every sys_activity field is readonly and objectql's validateRecord skips readonly fields, so undeclared values are stored silently (measured upstream, in plugin-audit's own vocabulary pin). The platform also forwards author-declared values into the column via ADR-0052 activityMilestones[].type, so this is a general door, not one app misbehaving. That is why the test's key-set pin had to be restructured rather than just gain a row: it asserted set-equality with the declared options, and that premise is false. It now states both vocabularies, each naming its producer. Whether the enum should absorb `scheduled` is a platform ruling - filed as objectstack#11424 and raised in open_questions. One consequence I could not fix inside the fence: RecordDetailView hand-copies this map, so this PR creates a real divergence (scheduled renders in the block, still drops on the console record page). Filed as #5878 and called out in the docs page, the source comment and the PR rather than left to be discovered.",
 "tests": "All heavy legs through /home/user/objectstack/scripts/pm/os-verify-lock.sh; every claim quotes the verdict line the tool printed, exit codes captured before any pipe. Green union re-run on the FINAL commit 1df1c03d3 (tree byte-identical to HEAD, git diff HEAD --stat empty). DEPS: pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-detail^...' build -> 'VERDICT command-exit 0'. TESTS: pnpm exec vitest run packages/plugin-detail/src/renderers/__tests__/recordActivityFeed.test.ts packages/plugin-detail/src/renderers/__tests__/record-activity.test.tsx --maxWorkers=2 -> 'VERDICT command-exit 0', 'Test Files 2 passed (2)', 'Tests 49 passed (49)'. TYPECHECK: pnpm --filter @object-ui/plugin-detail type-check -> 'VERDICT command-exit 0', and the run echoed '> @object-ui/plugin-detail@17.6.0 type-check' / '> tsc --noEmit && tsc -p tsconfig.test.json', so it was not a zero-match pnpm no-op (the script is spelled type-check, hyphenated). GATES (each EXIT captured before any pipe, verdict line quoted): check-changeset-presence EXIT=0 '2 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'; check-changeset-no-major EXIT=0 'No changeset declares a major bump'; check-control-bytes EXIT=0 'OK (scanned 4890 tracked text file(s); skipped 85 binary)'; check-doc-links EXIT=0 'Links are valid across 13 scan roots'; check-doc-component-types EXIT=0 'Every documented component type is registered'; check-i18n-call-site-keys EXIT=0; check-i18n-en-drift EXIT=0 'No en value changed in this range'; check-package-self-import EXIT=0; check-spec-symbol-derivation EXIT=0. DECLARED NON-RESULT: check-doc-snippet-types EXIT=1 on a PREREQUISITE, not on content - 'The snippet program was NOT run: the packages it resolves against are not built', naming nine unbuilt packages. Running it locally means a full workspace build behind the shared lock; CI builds and runs it, and this change adds no doc snippet. Reported as not-run, not as green. LINT NARROWING (declared, with all three pieces of evidence): eslint --no-inline-config on the two changed TS files, exit 0, no output. (1) Population came from eslint's own config, not my guess - both paths appear in --format json with a verdict rather than being ignored; (2) count read from --format json: 2 files, errors=0 warnings=0 each; (3) invariance - eslint.config.js declares no parserOptions.project and no projectService, so type-aware linting is off and no rule reads across file boundaries, and no lint config or shared type changed, so this diff cannot move any untouched file's verdict. REVERSE VERIFICATION - two ablations, each discriminating its own hunk, both on a COMMITTED tree, both restored under trap '...' EXIT INT TERM. NO REBUILD WAS NEEDED AND HERE IS WHY: the test resolves the subject by relative import (from '../recordActivityFeed'), not through package exports, so vitest transforms the source directly and no dist is involved - verified by grepping the import specifier before running, since an ablation that silently ran against stale build output would stay green and prove nothing. MUTATION CONFIRMED ON DISK BY GREP, never by an editor exit code: ablation 1 removed only `scheduled: 'event',` (injected-text count 0, surrounding anchor `completed: 'task',` still 1); direction predicted BEFORE running and matched exactly - 'Tests 4 failed | 24 passed (28)', the four legs being the vocabulary pin, the producer-writes leg, the row-to-event-item leg and the spec-declares leg. Non-discriminating legs NAMED rather than counted: the three applyFeedConfig legs build an event item by hand to pin the pipeline and never touch the map; 'leaves every previously-mapped type pointing where it did' normalises scheduled away on purpose (it is the regression control for the OTHER entries); the drop/warn legs use an unknown type, not scheduled. Ablation 2 removed only the diagnostic, leaving the map entry (call count 0, `scheduled: 'event',` still 1) -> 'Tests 2 failed | 26 passed (28)', exactly the two warn-asserting legs, which is what shows the two probes are independent; the drop itself never regressed ('still DROPS a type nothing maps' went red on its console.warn assertion, not on its toBeNull()), and 'stays SILENT for the types it deliberately drops' stays green here by construction because it discriminates the OPPOSITE mutation. RESTORE LEGS both: git diff HEAD --stat empty, marker text back at count 1, full re-run green 49/49.",
 "open_questions": [
 {
 "question": "sys_activity.type declares eleven options, a shipped producer writes a twelfth (`scheduled`), and nothing can reject it because every field on the object is readonly and validateRecord skips readonly fields. ADR-0052 activityMilestones[].type also forwards author-declared values into the same column verbatim. So is sys_activity.type a CLOSED platform vocabulary or an AUTHOR-EXTENSIBLE one? Both readings are currently true of the code, and objectui's map has to key on one of them. Filed as objectstack#11424; this PR does not depend on the answer, but the test pin should follow it.",
 "options": [
 "A - Declare it: add `scheduled` to plugin-audit's enum plus a writer-census row naming the HotCRM writer. Cheapest, makes the shipped state honest, reversible. Does not close the general door.",
 "B - Rule the producer non-conformant: HotCRM must write a declared value. Keeps the vocabulary closed, but nothing enforces it, so it is a convention that will be broken again silently - and it would mean deliberately dropping rows that are already in customers' stores.",
 "C - Enforce the vocabulary: validate declared options on system-owned writes to readonly select fields, so an undeclared value is rejected loudly at write time. Largest, and the only one that stops the class rather than the instance.",
 "D - Declare it author-extensible: accept that milestone-declared types pass through, say so in the contract, and treat downstream closed maps (including this one) as the defect."
 ],
 "recommendation": "A now, C as the direction. On real business need, A is the only option backed by measured demand: a shipped app writes the value on five objects and the rows already exist. On long-term soundness, C is the contract-first answer - A alone leaves the enum as documentation rather than a contract, which is the actual defect, and B pretends an enforcement that demonstrably is not there. On making AI-authored metadata hard to get wrong, C is decisively best: today an author can put any string in activityMilestones[].type and get a row that is stored, queryable and invisible with no diagnostic anywhere - the exact shape an AI writing metadata produces and cannot detect. D is the honest alternative if extensibility is wanted, but it should then be a declared capability with a registration path, not the current accident. On startup scope discipline, that argues against D (an extensibility surface nobody has asked for) and against doing C immediately - hence A as the reversible step that makes today's state truthful, with C queued rather than bundled."
 },
 {
 "question": "This PR knowingly creates a user-visible divergence: `scheduled` now renders in the record:activity block but is still dropped by RecordDetailView's hand-copied map, so the same row behaves differently on a hand-authored record page and on the console record page. Fixing it means app-shell editing the second copy, which is outside this card's fence and a different package's verification surface. Should that be dispatched now rather than left as a finding?",
 "options": [
 "A - Dispatch #5878 next, as a follow-up on the same defect, so the divergence is short-lived.",
 "B - Fold it into this PR by widening the fence to app-shell.",
 "C - Leave it as a filed finding for normal triage."
 ],
 "recommendation": "A. B was considered and rejected against the bounded-in-place-fix test: the defect class matches and the correct shape is pinned by evidence, but it adds a whole second package's test surface and the PM fence said 'nothing else', so folding it would be undeclared scope creep. C alone leaves a real user-visible inconsistency standing on the merged result of this PR. The right fix is not copying the line across but making the second copy read the exported map, which is a small, self-contained follow-up worth dispatching promptly."
 }
 ],
 "out_of_scope_findings": [
 "filed as #5877: 8 of FeedItemType's 13 kinds still have no producer on any objectui surface (the card's second half; corrects its count of ten, since `comment` is produced via sys_comment and `event` gains a producer in this PR)",
 "filed as #5878: RecordDetailView hand-copies record:activity's sys_activity map and nothing fails when the two disagree - this PR creates the divergence, deliberately and declared",
 "filed as objectstack-ai/objectstack#11424: sys_activity.type declares 11 options while a shipped producer writes a 12th, and readonly fields make the enum unenforceable",
 "not filed, recorded here: plugin-audit's sys-activity-type-vocabulary.test.ts cites issue #8852 for the unguarded objectui mirror; that number returns 404 in objectstack today, so the reference is dangling. Noted inside #5878 rather than filed on its own."
 ]
}

---

Generated by Claude Code