Seed logged interactions so the lead Activity tab demonstrates something out of the box

[os-zhuang]

Seed logged interactions so the lead Activity tab demonstrates something out of the box

Why now

#1209 fixed the Activity tab to filter to real interactions (types: ['task']) instead of rendering the database audit stream. That was correct — but it exposes an empty tab, because the demo dataset contains no interactions at all.

Measured on a seeded instance:

sys_activity: 200 rows
  updated: 116
  created:  83
  deleted:   1
  (completed / scheduled: 0)

Every row is an audit entry. The three writers that produce real interaction rows — log_call, log_meeting, send_email in src/actions/global.actions.ts and src/actions/contact.actions.ts — are action bodies, and nothing in the seed path calls them. So on a fresh pnpm demo:reset, a rep opening any lead's 活动 / Activity tab sees 暂无活动记录.

Why it matters for this repo specifically

The charter is 「hotcrm 主要是展现平台能力」. An Activity tab that is honest and empty demonstrates less than one that is honest and populated: the timeline component, the interaction model, and the "what did we do with this lead" workflow are all real platform capabilities that the exemplar currently ships switched off in its own demo data.

This is the tab a salesperson opens before every follow-up call. Shipping it blank is the difference between a demo that shows a working CRM and one that shows an empty shell.

Scope

A handful of sys_activity rows for the demo leads/accounts that already carry a narrative — enough that the tab reads like a CRM someone has used, not a fixture. Notes:

• Do not invent a fourth writer. If the rows must come from the action bodies to be honest, say so — that changes the shape of this card and is worth reporting rather than working around.
• crm_forecast's precedent is relevant: demo-bootstrap.flow.ts claims owner-scoped seeded objects, and forecast_snapshot 与启动重播种的互动:每次 dev 重启后,当季出现一条无 owner 的幻影快照行与 owner 键控行并存 #702 ruled the current-quarter window has exactly one producer. Check whether sys_activity has the same ownership/visibility constraints before assuming plain seed rows are enough.
• Keep it proportionate — 「不扩散需求」. This is demo data, not a feature.

Provenance

Maintainer decision in session, verbatim (未译): 「加种子互动，顺带把 #1257 排了」 — taken after seeing the before/after in a browser: the tab went 活动 (3) → 活动 (0) on the same record once #1209 landed.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 3 (hotcrm seat)
Session: session_61f28fb9-8e31-4a6f-b4d8-10f749a092d2
Branch: claude/issue-1258-seed-interactions
Worktree: hotcrm-issue-1258
Domain: (hotcrm has no domain:* taxonomy — repo-wide seat)
File surface: src/data/** (+ one test if a guard fits); read-only on src/actions/*.actions.ts and src/flows/demo-bootstrap.flow.ts (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — demo seed data only.
Serial constraints cleared: #856/PR#1232 in flight on AGENTS.md (disjoint). os-sam's #856 surface is AGENTS.md only; no in-flight claim touches src/data/.

Authorization — maintainer direct-dispatch, verbatim (未译): 「加种子互动，顺带把 #1257 排了」

[os-zhuang]

{
  "issue": 1258,
  "status": "needs_decision",
  "branch": "claude/issue-1258-seed-interactions",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1260",
  "premise_still_valid": false,
  "summary": "The card's route is impossible and I measured it rather than inferring it. sys_activity IS seedable in the narrow sense — I authored the exact rows the card asked for (3 'completed' interactions on the seeded lead Lisa Thompson), and they load: build is silent, the boot banner counts them (345 rows, up from 342), and every column lands including readonly ones (seeds write under isSystem, and sys_activity declares every field readonly; type 'completed' accepted, cel temporals resolve, mode 'upsert' accepted despite managedBy 'append-only'). But the rows attach to NOTHING: sys_activity.record_id is Field.text(), not a lookup, and the loader resolves natural keys only for lookup/master_detail fields, so it stores the literal string while the lead's id is a runtime nanoid. Using the filter the shipped console bundle actually issues ({object_name, record_id}, read out of the bundle, not inferred): the real lead id tgIjpNhjlfmWU8YF returns 0 rows, the literal key 'Lisa Thompson' returns 3. So a seed-only route leaves the tab empty while the seed book looks populated. Ownership is NOT the obstacle (unlike the crm_forecast precedent the card pointed at): sys_activity declares no owner_id at all and the rows read back fine over REST. Two more facts against the route: sys_activity is lifecycle.class 'telemetry' with retention maxAge 14d and day-shard rotation, so demo history older than a fortnight is reaped by design; and interaction rows have exactly two writer sites in src/ (the log_call/log_meeting factory in global.actions.ts, send_email in contact.actions.ts), so any bootstrap hook writing pointer rows would be the #702 two-producer conflict one object over. I did NOT fake rows through a back door and did NOT add a fourth writer. Shipped instead: one guard block in test/seed-consistency.test.ts holding seeds inside the app's own object graph, with the full measurement written into the comment so the next author inherits it. Filed the platform gap upstream as objectstack#11339. The Activity tab is still empty on a fresh demo:reset — that is the honest state, and which route fixes it needs a decision.",
  "tests": "All at 86fd1e49 (final commit). pnpm typecheck -> exit 0, 'tsc --noEmit' clean. pnpm validate -> exit 0 (only pre-existing colSpan/props warnings on views this PR does not touch). pnpm build -> printed '(check) Build complete (952ms)'. pnpm test -> printed 'Test Files 120 passed (120)' / 'Tests 2841 passed | 2 skipped (2843)'; case-sla-matrix.test.ts passed here rather than flaking. Reverse verification of the new guard, predicted direction RED, observed RED: re-registering the sys_activity seed failed exactly one test with \"expected [ 'sys_activity' ] to deeply equal []\" while the other 36 in the file stayed green, so the guard is specific rather than a blanket break. Mutation confirmed ON DISK before the run by grepping the injected import, the array entry and the seed file's own sys_activity line (all non-zero); restore leg confirmed the same way (file absent, 0 mentions in index.ts); the script carried trap '<restore>' EXIT INT TERM. No rebuild leg applies: the test imports ../src/data/index and ../objectstack.config as source through vitest's transform, not across a package exports -> dist/ boundary. Boot-level measurement ran twice on a real server (rm -rf .objectstack/data && pnpm build && pnpm dev, port 4002), reading sys_activity through both sqlite and the authenticated REST API; both dev servers were stopped by PID. NOTE: scripts/pm/os-verify-lock.sh refuses on this macOS host -- flock is absent and the entry point itself prints VERDICT lock-unusable -- so heavy commands ran unserialised; declaring that rather than hand-rolling a substitute lock.",
  "open_questions": [
    {
      "question": "The Activity tab cannot be populated from seed data. Which route should this card become?",
      "options": [
        "A. Wait for the upstream fix (objectstack#11339) making the ActivityPointer pair seedable, and keep the tab honestly empty until then.",
        "B. A post-boot script that drives the shipped log_call/log_meeting/send_email actions over HTTP, mirroring the existing 'pnpm demo:staff' precedent for things a seed cannot express.",
        "C. A bootstrap hook/flow on crm_event that writes the sys_activity pointer row for seeded interactions.",
        "D. Drop the ambition: leave the tab empty and let crm_event (already richly seeded, 20+ events) carry the interaction story on the Sales Activity dashboard and calendar."
      ],
      "recommendation": "A, with B as the interim if the maintainer wants the tab non-empty before the platform lands. Real business need: the interaction narrative ALREADY exists in the demo data as crm_event rows -- what is missing is only the platform's pointer row, so this is a platform capability gap, not an unmet CRM need; that is exactly the shape the charter sends upstream rather than working around. Long-term soundness: A is contract-first (fix the producer/spec, not the consumer); C is a workaround that manufactures the #702 two-producer conflict on a second object, and its cost is permanent -- every action-created interaction would carry two rows forever. Hard-to-get-wrong for AI-authored metadata: A plus the guard already shipped is the only option where the failure is refused rather than silently accepted; C actively teaches the wrong pattern (a fourth writer) and B leaves 'demo:reset' alone producing an empty tab, which is the same success-receipt-for-nothing shape the guard exists to prevent. Startup scope discipline: A costs this repo nothing beyond the card already filed, D costs nothing at all; B is a new script to maintain and C is new runtime metadata shipped in the artifact for a demo-only concern -- both widen the surface for a demo nicety, which is what the charter's 'hotcrm 主要是展现平台能力，并且不扩散需求' rules against. If the tab must be non-empty this quarter, B is the least-bad because it ships nothing in the artifact; C should be refused on all four axes."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectstack#11339: seeds cannot address an ActivityPointer -- sys_activity.record_id is plain text, so a packaged app loads timeline rows that attach to nothing, at every gate green. Includes the cheap half (refuse the unresolvable write) as an option independent of the full fix.",
    "not filed, noted only: the boot log carries a pre-existing tenancy warning (metadata-protocol #8686) that six crm_* autonumber counters run split global/org counters because sys_organization holds 0 rows on a fresh demo install. Unrelated to this card, visible on plain origin/main, and it names its own upstream issue -- flagging rather than filing so PM can decide whether hotcrm owns a demo-install answer."
  ]
}

[os-zhuang]

PM review — ACCEPT the measurement; the card's premise (mine) is dead. → needs-user-decision with the dev's four options. The guard PR stands on its own.

Reviewed against the running server's metadata and GitHub, not against the report.

I verified the two load-bearing facts myself

From the live instance's /api/v1/meta/object:

sys_activity.record_id → type: "text", reference_to: null
sys_activity.lifecycle → class: "telemetry", retention.maxAge: "14d"

record_id is plain text, so the seed loader's natural-key resolution (lookup/master_detail only) never fires — a seeded row stores the literal string while the real lead id is a runtime nanoid, and the console's {object_name, record_id} filter finds nothing. Independently, telemetry-class retention reaps demo history after a fortnight. Either fact alone kills the route I wrote into this card; the dev found both, faked nothing through a back door, and refused to add a fourth writer (which would have been the #702 two-producer conflict one object over).

The dev's measurement discipline is worth naming: rows were actually authored and loaded (342 → 345 at boot), read back over REST, and shown to attach to nothing — "the seed book looks populated while the tab stays empty" is exactly the success-receipt-for-nothing failure shape, demonstrated rather than asserted.

What ships regardless of the decision

PR #1260 (guard only: test/seed-consistency.test.ts refuses sys_* seeds outside the app's object graph, reverse-verified red on exactly one test). This is compatible with routes A, B and D, and it is what makes route C impossible to ship by accident. Recommending merge independent of the route choice.

Disposition

• pm:dispatched → needs-user-decision; assignee cleared. The four routes and the dev's four-axis recommendation (A, with B as interim) are in the report comment above; the choice is the maintainer's.
• objectstack#11339 verified: open, unassigned, no pm-state labels, back-linked — the platform half (ActivityPointer not seedable; includes the cheap refuse-the-unresolvable-write option).
• The tenancy-warning note (autonumber counters split on 0-org installs, metadata-protocol#8686) is flagged, not filed — correctly, since it names its own upstream issue; left for triage's judgement.

[os-zhuang]

Maintainer decision — Route A

Verbatim (未译, in-session 2026-08-23): 「1258 A，11339 你可以直接处理。」

Route A: wait for the upstream fix (objectstack-ai/objectstack#11339 — seeds cannot address an ActivityPointer) and keep the Activity tab honestly empty until it lands. No interim script (B not taken), no bootstrap writer (C refused on all four axes in the dev report), ambition not dropped (D not taken).

Consequences applied:

• Guard PR test(seed): guard that seeds stay inside the app's own object graph (#1258) #1260 merges now — Route A presumes it (the failure stays refused, not silently accepted, until the platform makes the pointer seedable).
• This card → pm:blocked, unassigned.

Blocked-by: objectstack-ai/objectstack#11339

When #11339 closes, the unlock scan returns this card to the queue; the then-current dispatch re-verifies the seed shape against whatever resolution mechanism the platform shipped, and the demo interactions get authored at that point.

The second half of the ruling — handling #11339 itself — proceeds under the same direct-dispatch authorization on that card's thread.

[os-zhuang]

Unlock scan — upstream closed, but the runnable condition is a RELEASE, not the merge. → pm:on-hold with a machine-readable restart line.

objectstack#11339 closed via objectstack#11388 (merged 8d237b40): text fields may declare referenceVia: '<sibling>', the seed loader resolves declared pointer pairs per row and refuses unresolvable ones loudly, and sys_activity adopts both pairs — the exact mechanism this card's Route A waits for.

Flipping straight back to pm:queue would burn a dev run: hotcrm consumes published @objectstack/* packages (currently 17.1.0), and the merge is not yet in any release. Releases are human acts. So per the state model this becomes a made-decision hold with an executable exit:

Restart-when: hotcrm's installed @objectstack/spec resolves a version whose FieldSchema accepts referenceVia (ships in the first platform release containing objectstack 8d237b40; verify with node -e "require('@objectstack/spec')"-level probe or the liveness ledger's field.json gaining the key)

When that fires, the dispatch is already shaped (recorded here so the next seat inherits it, whoever it is):

1. Delete test/seed-consistency.test.ts's sys_ guard block deliberately* — its own comment instructs exactly this ("if a future platform release makes an ActivityPointer target seedable, delete this test deliberately — do not widen it").
2. Author the demo interactions the original card asked for, now with record_id resolving through object_name — re-verify the shape against the shipped resolution mechanism rather than this comment.
3. Note the 14d telemetry retention when choosing seeded timestamps (daysAgo(n) with n < 14, or the rows are reaped before anyone demos them).

Maintainer lever, stated plainly: the platform release that carries 8d237b40, then hotcrm's dep bump, are both human acts. This card wakes on the bump.