feat(schedules): a schedule that names a user runs as that seat — reads and writes their memory (abilityai/trinity-enterprise#637)

[dolho]

Fixes abilityai/trinity-enterprise#637 (R26). OSS-core, on the same line as ent#498 (§10.18) and MEM-001 — same as #498's gating.

What

A role companion's proactive brief is a scheduled run, and a scheduled run could not touch an individual user's memory: write_user_memory refused every schedule trigger. Now a schedule that names a user (ent#498's deliver_to_workspace_email — the same field, no second address) runs as that seat.

The seat is read off the row, never sent. ent#498's resolve_and_stamp already writes source_channel='portal' + source_channel_client=<email> after the roster/block checks. services/schedule_seat_memory.seat_for_execution reads that back for a schedule-origin row (real schedule_id; cron / Run now / webhook — the operator who presses Run now is not the addressee) and nothing else; routers/public_memory.py accepts the write for exactly that case. source_user_email is deliberately not stamped: client_portal/work reads it as "work I started" and two stream-ownership checks key on it. No address → refused as before, now saying "names no one" (AC 5).

The run reads before it writes. The tool is whole-blob replace, so the internal dispatch composes the seat's MEM-001 memory block + a seat note into execute_task(system_prompt=…) on both branches, only after the stamp landed. The #1205 public persona prompt is not folded in.

One boundary, now with history (AC 2 + AC 3). db.write_public_user_memory_agent_notes replaces the notes and records public_user_memory_writes (previous + new, execution, trigger, schedule) in one transaction — the ent#419 screen lands there once and covers scheduled writes by construction; ent#419's rollback layer is this table. The Workspace agent details (Info tab) gain "What it remembers about you" (PortalAgentMemory.vue, GET /api/enterprise/client-portal/agents/{name}/memory) listing each change with schedule name + time + what it left, and Undo (POST …/memory/writes/{id}/undo) — latest-first (409 not_latest / already_undone named), uniform 404 for a foreign id, roster-gated, keyed on the principal so only the viewer's own memory is ever served.

One run, one seat (AC 4) by construction — the seat is the single source_channel_client on the row and memory is UNIQUE(agent_name, user_email).

Schema: public_user_memory_writes on both tracks (SQLite public_user_memory_writes_table + Alembic 0065_public_user_memory_writes), CASCADE in AGENT_REFS. MCP write_user_memory description + the platform prompt's memory guidance updated.

⚠️ Alembic: #2920 also adds a 0065_* off 0064. Whichever lands second must re-chain its down_revision (alembic-head-watch will flag the fork).

Acceptance criteria

• AC 1 — addressed schedule writes that user's memory; no address writes none — test_an_addressed_scheduled_run_writes_the_seats_memory, test_a_scheduled_run_with_no_address_is_refused_as_before, test_every_way_a_schedule_fires_serves_the_same_seat
• AC 2 — same gate as chat, not a back door — test_there_is_one_write_boundary_for_every_trigger (+ every trigger's write goes through the one writer)
• AC 3 — the person sees what/when/which run and can undo — test_every_write_is_recorded_with_what_when_and_which_run, test_undo_restores_what_the_notes_were_before_that_write, test_undo_is_latest_first…, test_the_person_sees_a_run_now_fire_as_a_scheduled_run; portalAgentMemory.spec.js mounts the component and drives Undo + its refusal (Safety-critical UI logic keeps landing in the one tier with no executable coverage — and the stated reason is false #2918)
• AC 4 — seats stay separate — test_a_companion_serving_two_seats_keeps_them_apart, test_undo_cannot_reach_another_persons_write
• AC 5 — unchanged for schedules that name no user — refusal + system_prompt=None on both dispatch branches (test_the_seat_prompt_reaches_execute_task_on_both_dispatch_branches)

Verification

pytest unit/test_ent637_schedule_seat_memory.py            39 passed
pytest test_ent498 + schema_parity + alembic guards + auth wiring + models_centralized   162 passed
-k "cleanup|agent_refs|rename_cascade|portal_agent_page|…"  150 passed
full unit (xdist):  16732 passed, 28 skipped, 16 failed — the same 16 pre-existing on base (IPv6-mapped SSRF params, 2814 parity); none in scope
check_alembic_heads → 1 head; check_alembic_parity → PASS; SQLite migration applied twice on a fresh file (idempotent)
vitest: 142 files / 3242 pass (incl. portalAgentMemory.spec.js 5, ratchets); check:tokens OK; vite build OK
mcp-server: tsc clean, 439 pass
/verify-local --skip-unit --skip-agent → PASS (build, boot+health, integration)

Live (dev stack, PostgreSQL, agent sidekick, this branch mounted): Alembic 0065_public_user_memory_writes applied at boot; created a disabled schedule addressed to my Workspace email; Run now → scheduler → /api/internal/execute-task: the row is stamped portal + seat + schedule_id (PG), the failed terminal landed in my Main (the model turn itself failed — sidekick's OAuth token is expired on this instance, unrelated). Then, with sidekick's own MCP key, POST /api/agents/sidekick/user-memory for that execution (what the tool does) → success, memory written for the seat, write_id returned; an unaddressed run → 422 naming why. GET …/memory → notes + one write (scheduled_run · ent637 seat brief probe, undoable). Workspace Info tab, light + dark: section renders, Undo click → notes revert to empty, row marked undone (PG: undone_by = me), no Undo left. Found live and fixed: a Run-now write was labelled "In a conversation" (kind keyed on triggered_by); now keyed on schedule_id + pinned by test.

Docs

docs/memory/requirements/scheduling.md §10.19 (new), public-access.md MEM-001 pointer, feature-flows/schedule-workspace-delivery.md (seat section, schema, testing), architecture/{database,workspace,backend,api-endpoints}.md.

🤖 Generated with Claude Code

[dolho]

Screenshots — Workspace › sidekick › Info rail (local dev, PostgreSQL, PR branch mounted)

1 · Before Undo — "What it remembers about you" shows the notes a seat run wrote (open loops / commitments / context, Updated just now); under Changes the latest entry reads Scheduled run · ent637 seat brief probe · just now with Undo; earlier entries are marked undone and carry no button (latest-first).

2 · After Undo — notes revert to what they were before that write (nothing, here → "Nothing yet. When it learns something about you — in a chat, or in a scheduled run addressed to you — it shows here."), the entry reads · undone, no Undo left. PG: undone_at set, undone_by = the viewer.

Dark theme — same section on the dark rail.

Capture note: the seat run's write_user_memory call was issued with sidekick's own MCP key against the run's execution id (what the MCP tool does), because the instance's model credential is expired; the row stamp, the endpoint, the history row and Undo are the real path. A header that truncated the time / undone mark was fixed in b9015ed after the first capture.

[dolho]

merge-train prep (mechanical): rebased onto fix/2914-skill-name-conflict and retargeted to it — the three 2026-09-21 schema PRs (#2920 → #2924 → #2927) are now a stack so dev never carries two Alembic heads off 0064. This revision is 0066_public_user_memory_writes off 0065_agent_skills_delivery_status (7610a1206); the migrations.py list-tail collision was resolved keep-both, #2920's first. Merge order: after #2920. Retarget to dev once it lands.

[vybe]

Migration numbering heads-up (orchestrator, 2026-09-22): PR #2942 (ent#477 declared-metric registry) lands ahead of this PR by operator ruling and carries 0066_metric_definitions ← 0065_agent_skills_delivery_status. This PR's Alembic revision must renumber behind it before merge — 0067_public_user_memory_writes ← 0066_metric_definitions for #2924 and 0068_agent_role_readiness ← 0067_public_user_memory_writes for #2927 — and run scripts/ci/check_alembic_heads.py src/backend/migrations/versions on the merged graph (the head-watch job is advisory). Recorded on ent#476.

[vybe]

Correction to the numbering note above (orchestrator, 2026-09-22): ent#478 (0067_metric_points) lands right behind ent#477 as part of the same stacked chain, so this PR renumbers behind 0067, not 0066 — #2924 → 0068_public_user_memory_writes ← 0067_metric_points, #2927 → 0069_agent_role_readiness ← 0068_public_user_memory_writes. Same pre-merge check: scripts/ci/check_alembic_heads.py src/backend/migrations/versions on the merged graph. Sorry for the two-step.

[vybe]

merge-train (2026-09-22) — what was pushed to this branch, and why

Validated at lane C + schema (/validate-pr, /review, /cso --diff): no CRITICAL, every changed path executed by tests. Two mechanical commits pushed here so they survive to the squash:

1. f2b60e9db merge of origin/dev — the base (fix/2914-skill-name-conflict) had already squash-merged as fix(skills): refuse to overwrite an agent-authored skill of the same name (#2914) #2920, so migrations.py and learnings.md echo-conflicted on fix(skills): refuse to overwrite an agent-authored skill of the same name (#2914) #2920's own text. Resolved to dev's text plus this PR's 0066 append; learnings.md delta vs dev is now empty (this PR never touched it). Retargeted to dev.
2. bfc2a04d5 agent-self gate on POST /api/agents/{name}/user-memory — /cso --diff F1 (MEDIUM 8/10, verified): an agent-scoped key resolves to its owner carrying the owner's role, so assert_agent_access alone let a sibling agent under the same owner name this agent's finished seat run and replace that person's notes. Pre-existing MEM-001 gap that this PR widened to seats who never opened a chat. Three lines mirroring reminders._self_gate, plus test_a_sibling_agents_key_cannot_write_this_agents_seat_memory; human principals unaffected.

Alembic numbering: the 0068/0069 renumber ruled earlier is not applicable yet — #2942 / #2948 are still drafts and dev's head is 0065, so this lands as 0066 ← 0065 and the metric-registry pair re-chains behind it. Merged graph checked: 1 head.

Left for the author (need intent, not blocking): (a) a finished seat run's execution_id stays a permanent write capability — liveness belongs to the open ent#629 ruling; (b) write_user_memory_agent_notes reads previous_notes without a row lock, so two concurrent writes on PostgreSQL can record the same previous_notes (.with_for_update() would close it); (c) build_seat_caller_prompt returning None on an unreadable memory does not stop the write it was guarding against; (d) update_public_user_memory_agent_notes / update_user_memory_agent_notes no longer have a caller. Body patched to Fixes abilityai/trinity-enterprise#637; status-in-dev on ent#637 will be set by hand after merge.

[vybe]

merge-train (2026-09-22): validated at lane C + schema (/validate-pr, /review, /cso --diff), no CRITICAL; dev merged on the branch, self-gate landed, all checks green on bfc2a04.