finding: showcase seed assigns tasks to non-user emails — a stock reassignment lands an inbox row nobody can read

[huangyiirene]

Symptom

The stock showcase seed assigns tasks to ada@example.com / linus@example.com / sam@example.com, which are not sys_user rows and resolve verbatim to non-users. A stock reassignment through the notify path therefore lands a sys_inbox_message row that nobody can read (its user_id is a non-resolving email). The runner had to sign up real personas and use their emails instead to test the notify path at all.

Root cause

examples/app-showcase/src/data/seed/index.ts seeds task assignee / owner as bare email strings (e.g. ~line 161 assignee: 'sam@example.com', ~lines 159-160 ada@example.com) that never correspond to sys_user records. Split from the run's "Notes worth keeping" #1 as a real defect: the stock action (reassignment) produces a persisted-but-unreadable inbox row. Fix at the seed (assign to real seeded users); the notify/assignment path additionally not validating that an assignee resolves to a real user before creating the inbox row is a related, arguably deeper gap worth considering (packages/services).

Stale-premise check: present on origin/main (seed still assigns the non-user emails).

Reproduction

1. Boot the stock showcase and let the seed run.
2. Reassign a seeded task to its seeded assignee email (e.g. ada@example.com) through the notify path.
3. Look for the resulting sys_inbox_message, then try to read it as any real user.

Expected: the assignee resolves to a real user who can read the inbox row (or the assignment is refused). Actual: an inbox row is written keyed to a non-resolving email that no authenticated user can read.

Source

Extracted from the QA run #7690 (framework 92f26f7, console 09987b680).

[claude]

Findings triage (grade): promoted — finding removed, pm:queue stays (resolves the filed dual pm-state).

Why queue: concrete defect with a named landing, re-verified on origin/main @ 8f1851e — examples/app-showcase/src/data/seed/index.ts still seeds assignee/owner as bare non-user emails (ada@example.com at :146/:149/:159-160, sam@example.com in the same block), so a stock reassignment persists a sys_inbox_message row addressed to a non-resolving user. Fix at the seed is scoped; the deeper assignee-resolution validation the card mentions is correctly flagged as related-but-separate.

Not target:v17: demo-fixture polish — the stock action misfires silently but breaks no published capability a user is counting on.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 5 (devx seat, 2026-08-11 term) — wave 5 unit C
Session: session_01GZKbx4xyF7U5WXj6ch49BM
Branch: claude/issue-7746-showcase-seed-assignees
Worktree: cloud dev session(独立容器)
Domain: devx
File surface: examples/app-showcase/src/data/seed/index.ts(assignee/owner 改指真实种子用户)。notify 路径缺少 assignee 解析校验的深层缺口(packages/services)report-don't-fix
Container & model: mode:cloud / claude-opus-5
Serial constraints: 无共享文件

---

Generated by Claude Code

[huangyiirene]

os-dev report · issue #7746 · PR #7789 (draft) · branch claude/issue-7746-showcase-seed-assignees · session session_01VmrcDvZTRsNPixiGzg7aad

premise_still_valid: true

Re-verified on origin/main @ 7a8476f: examples/app-showcase/src/data/seed/index.ts still seeded owner/assignee as bare non-user emails at the triaged anchors (:146/:149 project owners, :159-160 task assignees, plus sam@example.com at :161-162). Reproduced end-to-end on a real boot before fixing — see Verification.

One correction to the card's framing, load-bearing for scope: the mechanism is not limited to assignee. showcase_project.owner reaches the same notify recipients (showcase_project_escalation, the red-health alert), so both fields carried the defect and both are fixed.

Landing

file	change
src/security/demo-personas.ts	new — single registry of the identities the app actually provisions, with the trade-offs documented
src/data/seed/index.ts	10 task assignee + 5 project owner values repointed at those identities
src/security/seed-approval-demo.ts	persona constants moved out to the registry (no behaviour change)
test/inert-wirings.test.ts	new §5 regression guard, derived from the flows

The three identities a stock dev boot really creates: admin@objectos.ai (plugin-auth dev-admin seed) and usr_showcase_phone_demo / usr_showcase_auditor_demo (provisioned by seed-approval-demo.ts on kernel:bootstrapped). Three distinct values, so the Kanban/gallery/list spread is unchanged.

Trade-offs declared (also in the PR body): the two personas hold no better-auth credential, so they cannot sign in — enough to make the recipient resolve and the row addressable, not enough to log in as them. And all three are dev-only; a non-dev showcase boot has zero users, which no seed value can repair.

showcase_invoice.owner deliberately NOT changed. It does reach a notify recipient (showcase_invoice_lifecycle → {record.owner}), so it is the same defect class — but those emails are the fixture for the ADR-0055 controlled-by-parent isolation demo, where an operator signs up as ada@example.com; showcase-invoice-seed-isolation.dogfood.test.ts does exactly that and pins the owners. Repointing it at credential-less personas would delete that demo rather than fix it. Needs a separate decision (make personas loginable, or give the showcase real signup-able contributor accounts) — flagged, not guessed. showcase_team.lead is display-only and untouched.

Verification — the issue's own three steps, on a real pnpm dev boot

Wiped datastore, objectstack build, pnpm dev (full plugin set: automation, record-change triggers, messaging, approvals).

1. Seed ran — all 10 task assignees + 5 project owners resolve to sys_user; unresolvable recipients 15 → 0. sys_user on a fresh boot is exactly the three rows above.
2. Reassigned a seeded task through the notify path (PATCH /data/showcase_task/:id → showcase_task_assigned_notify).
3. Read sys_inbox_message — from the datastore directly, because inbox reads are user-scoped and the bad rows are invisible over REST, which is the issue's complaint:

('usr_showcase_auditor_demo', 'New task assigned: Ingest pipeline')   <- after fix, real user id
('usr_showcase_phone_demo',   'New task assigned: Ingest pipeline')   <- after fix, real user id
('ada@example.com',           'New task assigned: Warehouse schema')  <- CONTROL: old value

The control also reproduces the mechanism in the server log — WARN [recipients] no 'sys_user' matched email 'ada@example.com'; keeping verbatim.

Regression guard proven by negative control (reverting one assignee fails the new test with the offending value named). Also green: showcase suite 20 files / 190 tests, tsc --noEmit, objectstack validate (warnings pre-existing), ESLint on changed files, and the invoice-isolation dogfood test (4 tests) I was careful not to break.

Report-don't-fix — the deeper gap (packages/services)

RecipientResolver.resolveEmail (service-messaging/src/recipient-resolver.ts:200-212) looks the email up in sys_user and on a miss logs a warning and returns the raw email, which the inbox channel then persists as user_id. Nothing on the notify/assignment path validates that a recipient resolves before the row is written, so the write succeeds and the row is unreadable by construction. Seed data was only the loudest way to reach it — any user-entered assignee does the same.

Note for whoever picks this up: the current behaviour is already pinned by two existing tests (examples/app-showcase/test/approval-resume-relation-expand.test.ts:266 asserts notice.user_id === 'grace@example.com'), so closing the gap means changing those expectations too. Options are refuse-the-assignment vs drop-the-unresolvable-recipient — a deliberate platform decision, out of scope here per the issue's own split.

Release / changeset

No changeset file. The diff is examples/app-showcase/** only and @objectstack/example-showcase is private, so it releases nothing. The repo's own gate prescribes the label over an empty changeset — pr-automation.yml: "examples/, tests-only, and the like -> apply the 'skip-changeset' label. <<< PREFERRED", and check-empty-changeset.mjs rejects a newly added empty-frontmatter changeset (#5471). I applied skip-changeset to #7789 accordingly.

Constraints honoured

Draft PR, not merged, no auto-merge, merge queue untouched. No content/docs/releases/**. No git stash. Work done in a dedicated worktree (../objectstack-7746). CI convergence / flip / merge left to PM — not waited on. Known-red base check:platform-checklist (coverage.json · qa: UNCLASSIFIED, #7347) is unrelated to this diff.

---

Generated by Claude Code