elizaos--eliza/plugins/plugin-personal-assistant/docs/lifeops-extraction-plan.md

LifeOps Extraction — Master Execution Plan (owner-directed)

Authoritative, globally-sequenced execution plan to decompose @elizaos/plugin-personal-assistant (PA / "LifeOps", ~137k LOC, plugins/plugin-personal-assistant/src). Synthesizes four area plans into one dependency-correct sequence. This OVERRIDES the earlier "keep the spine in the hub" recommendation in lifeops-decomposition-plan.md.

Owner directive: extract the scheduling spine → new plugin-scheduling; extract reminders → new plugin-reminders (depends on scheduling); remove the overview view; complete all cleanup follow-ups.

Architecture invariants live in ../README.md / root AGENTS.md. The proven template is plugin-finances (plugins/plugin-finances/CLAUDE.md + plugins/plugin-finances/src/services/migration.ts). Replicate it.

---

0. Verified ground truth (read before touching anything)

Every claim below was checked against the actual source.

Fact	Evidence (file:line)
Spine tree lives under lifeops/, not src/scheduled-task/	plugins/plugin-personal-assistant/src/lifeops/scheduled-task/ (18 files, 6892 LOC)
runner.ts is storage-agnostic; its only out-of-tree import is import type { DispatchResult }	lifeops/scheduled-task/runner.ts:17 (type-only)
types.ts/gate-registry.ts/completion-check-registry.ts/escalation.ts/consolidation-policy.ts/state-log.ts/index.ts import only @elizaos/core + each other	per-file grep, all clean
due.ts + next-fire-at.ts import only ../registries/anchor-registry.js	grep
scheduler.ts is the coupled tick: imports ../owner/fact-store.js, ../pending-prompts/store.js, ../registries/anchor-registry.js, ../repository.js	grep
runtime-wiring.ts (the ONLY hardwire point) imports 9 PA modules + @elizaos/agent + @elizaos/app-core	runtime-wiring.ts:11-30
new LifeOpsRepository(runtime) is constructed in wiring (line 82) and in scheduler.ts (line 98)	grep
serviceType literal is "lifeops_scheduled_task_runner"	scheduled-task/service.ts:32,47
processDueScheduledTasks exported at	scheduler.ts:88; news up repo (98), reads owner facts (108), anchors (113), records pending prompt (267)
processScheduledWork interleaves circadian/reminders/workflows/scheduled-tasks	service-mixin-reminders.ts:5062; calls processReminders (5190) + processDueScheduledTasks (5204)
processReminders (4995), processDueReminderDeliveries (4611), processDueReminderReviewJobs (3140)	service-mixin-reminders.ts
Reminder-owned repo methods: createReminderPlan(3126) updateReminderPlan(3146) deleteReminderPlan(3159) getReminderPlan(3168) listReminderPlansForOwners(3184) createReminderAttempt(5178) listReminderAttempts(5211) listDueReminderReviewAttempts(5241) claimDueReminderReviewAttempts(5285) updateReminderAttemptOutcome(5320) upsertEscalationState(5906) getActiveEscalationState(5955) resolveEscalationState(5971) listRecentEscalationStates(5983) deleteAllEscalationStates(5998)	lifeops/repository.ts
Cross-domain spine reads delivery needs: listActiveDefinitions(2723) listOccurrenceViewsForOverview(2898) listChannelPolicies(3854) getChannelPolicy(3865) listCalendarEvents(4320) readCircadianState(6781) getScheduleMergedState(7046)	lifeops/repository.ts
Spine tables in app_lifeops: life_task_definitions(88) life_task_occurrences(128) life_scheduled_tasks(1417) life_scheduled_task_log(1473)	lifeops/schema.ts
Reminder tables in app_lifeops: life_reminder_plans(225) life_reminder_attempts(247) life_escalation_states(834)	lifeops/schema.ts
Legacy overview view registered across retired modalities, id "lifeops", component LifeOpsPageView	historical src/plugin.ts cleanup target
Overview route GET /api/lifeops/overview → service.getOverview()	src/routes/plugin.ts:331; src/routes/lifeops-routes.ts:2285,2298
VIEW_ACTION_MAP critical fact: OWNER_REMINDERS/OWNER_ALARMS/OWNER_ROUTINES map to the goals view; the lifeops view maps ONLY to PERSONAL_ASSISTANT	packages/agent/src/runtime/view-action-affinity.ts:165,167
Core stub StubScheduledTaskRunner is DEAD — only 5 self-refs in its own runner.ts, exported via core/index.ts:34	grep repo-wide
Goals dual writers confirmed: PA repo 10 refs + goals repo 10 refs to life_goal_*	grep
Calendar dual writers confirmed: PA repo 21 refs + calendar repo 11 refs to life_calendar_*	grep
Goals dead schema: routinesTable(42) remindersTable(61) alarmsTable(84) checkinsTable(106) — app_goals.{routines,…} NEVER queried	plugins/plugin-goals/src/db/schema.ts
pending-prompts / global-pause / handoff stores are cache-only (no SQL)	lifeops/{pending-prompts,global-pause,handoff}/store.ts
approval_requests table is owned by plugin-sql (packages/plugin-sql/src/schema/approvalRequests.ts), public schema — NO data migration	grep; lifeops/approval-queue.ts raw SQL has no schema prefix
app_blocker.block_rules (plugin-blocker) is registered-but-NEVER-queried; life_block_rules (PA) IS live	grep
Finances precedent is REAL and mirrors every step: delegation, carve, non-destructive FinancesMigrationService, ensureLifeOpsFinancesPluginRegistered, action-stays-in-PA	plugin-finances/CLAUDE.md; migration.ts:31-41; lifeops/schema.ts:311-315; PA plugin.ts:569-572

Template invariants (from finances, applied throughout):

1. New plugin MUST NOT import PA. Gate: rg "@elizaos/plugin-personal-assistant" plugins/<p>/src → comments only.
2. Move dependency-clean core first; inject the PA-coupled bits.
3. Schema carve = focused plugin declares its own pgSchema("app_X") with verbatim table names; a non-destructive MigrationService (to_regclass guard + target-empty check + INSERT…SELECT NOT EXISTS + never-drop-source) copies app_lifeops.* → app_X.*; raw SQL repointed via a TARGET_SCHEMA const; PA's LifeOpsRepository delegates the moved methods to the new repository.
4. Atomic, single-registrar handoff (runtime first-wins dedups). PA depends on the new plugin (workspace:*) + auto-registers via an ensureLifeOps<X>PluginRegistered guard.
5. Preserve runtime string literals: serviceType, action names, event names. VIEW_ACTION_MAP names are guarded by the drift test (packages/agent/src/runtime/view-action-affinity.test.ts).
6. Gate every slice with plugins/plugin-personal-assistant/test/decomposition-integration.test.ts (no dropped owner action, no serviceType collision, no view shadow, every VIEW_ACTION_MAP name registered).

---

1. Global sequencing rationale

Order chosen to de-risk before the heavy lifts and respect the hard dependency plugin-reminders → plugin-scheduling:

1. Overview removal + safe deletions first — bounded, low-risk, shrinks the surface (fewer consumers of the spine reads before we move the spine).
2. Independent runtime-service promotions (cache-backed + approval) — zero data risk, removes PA-internal coupling that the spine seam otherwise has to carry as injected deps. Doing these BEFORE the spine move means scheduler.ts's pending-prompt side effect is already a resolvable runtime service.
3. Schema carve-outs that de-risk (goals, calendar) — independent of the spine; landing them now proves the migration template on live dual-writer tables before the reminders carve (which is the same pattern, higher stakes).
4. plugin-scheduling — the spine. Pure code move (tables stay in app_lifeops initially) + invert the wiring.
5. plugin-reminders — depends on scheduling's ports; the largest carve.
6. Core stub deletion + final cleanup — only safe once the real spine type exists in @elizaos/plugin-scheduling.

Concurrency hazard (root AGENTS.md): multiple agents/worktrees touch develop (see .claude/worktrees/*). lifeops/repository.ts, schema.ts, service-mixin-reminders.ts, src/plugin.ts, and view-action-affinity.ts are shared hot files. Commit each slice atomically, push proactively, never stash, and re-base before the carve slices.

---

2. The ordered slices

Risk legend: SAFE-NOW = high-confidence, fully verifiable, landable in one PR. NEEDS-CARE = data migration / deep coupling, must be atomic, review-gated.

---

Slice 1 — Remove the LifeOps overview view (SAFE-NOW, low)

Why first: bounded, no data, no new package. The overview is the legitimate cross-domain aggregation the README reserves — but the owner directed its removal.

File ops:

• src/plugin.ts: delete the three LifeOpsPageView view descriptors (id "lifeops", componentExport: "LifeOpsPageView") and their imports. Remove LifeOpsPageView from the component export barrel (src/ui.ts / src/components/ if exported there).
• src/routes/lifeops-routes.ts: delete the GET /api/lifeops/overview handler (:2285, calls service.getOverview() at :2298). Remove the route descriptor from src/routes/plugin.ts:331.
• KEEP service.getOverview() and repository.listOccurrenceViewsForOverview — reminder DELIVERY still reads occurrence views via the spine port (slice 8). Only the VIEW + its HTTP route are removed.
• Update PA CLAUDE.md "Views" section (delete the overview-hub paragraph).

Verification gate:

• rg '"lifeops"' src/plugin.ts and rg '/api/lifeops/overview' src → no view/route.
• rg 'lifeops' packages/agent/src/runtime/view-action-affinity.ts confirms the lifeops view maps only to PERSONAL_ASSISTANT — no VIEW_ACTION_MAP entry targets the removed view component (the lifeops key is the PERSONAL_ASSISTANT action affinity, not a component reference, so removing the view does not orphan a map entry — confirm no componentExport: "LifeOpsPageView" remains).
• bun run --cwd plugins/plugin-personal-assistant verify.
• decomposition-integration.test.ts green (no view shadow, no dropped action).

---

Slice 2 — Delete vestigial dead app_goals schema (SAFE-NOW, low)

File ops:

• plugins/plugin-goals/src/db/schema.ts: delete routinesTable(42), remindersTable(61), alarmsTable(84), checkinsTable(106) and their inferred types RoutineRow/Insert, ReminderRow/Insert, AlarmRow/Insert, CheckinRow/Insert (129-136). KEEP goalsTable (it is the carve target for slice 6).
• plugins/plugin-goals/src/db/index.ts + src/index.ts: remove the four re-exports.
• plugins/plugin-goals/CLAUDE.md: drop the four tables from the schema bullet.

Verification gate:

• rg 'routinesTable|remindersTable|alarmsTable|checkinsTable' plugins/plugin-goals/src → empty.
• bun run --cwd plugins/plugin-goals verify.

---

Slice 3 — Promote pending-prompts / global-pause / handoff to @elizaos/agent runtime services (SAFE-NOW, low)

Why now: cache-backed (verified zero SQL), zero PA-internal coupling beyond their own store file. Promoting them BEFORE the spine move turns scheduler.ts's pending-prompt side effect into a resolvable runtime service the spine can inject cleanly.

File ops (per store, follow packages/agent/src/services/knowledge-graph/service.ts exactly):

• Create packages/agent/src/services/pending-prompts/service.ts, .../global-pause/service.ts, .../handoff/service.ts. Each: a serviceType literal const ('eliza_pending_prompts', 'eliza_global_pause', 'eliza_handoff'), a class XService extends Service { static serviceType = … } whose body is the copied store ops (lift from PA lifeops/{pending-prompts,global-pause,handoff}/store.ts; copy runtime-cache.js inward or use core cache directly), plus export function resolveXService(runtime): XService | null.
• Register the three classes in packages/agent/src/runtime/eliza-plugin.ts createElizaPlugin() services[].
• Export from packages/agent/src/services/index.ts + packages/agent/src/index.ts (mind the TS2308 duplicate-symbol comments).
• In PA: replace direct store imports/constructions with resolveXService(runtime). Keep PA store files as one-release re-export shims or delete + rewrite call sites. Direction: agent is INNER — agent must NOT import PA store files; the bodies are COPIED inward, PA's copies shimmed/deleted.

Verification gate:

• rg '@elizaos/plugin-personal-assistant' packages/agent/src → nothing (inward-only law).
• bun run --cwd packages/agent verify; PA build:types + test green.
• decomposition-integration.test.ts: no collision on the three eliza_* serviceTypes.

---

Slice 4 — Promote approval-queue to @elizaos/agent ApprovalService (SAFE-NOW, medium)

Why no data risk: approval_requests is owned by plugin-sql (packages/plugin-sql/src/schema/approvalRequests.ts), public schema — pure code move, NO migration.

File ops:

• Create packages/agent/src/services/approval/service.ts: ApprovalService extends Service (serviceType 'eliza_approval_queue') wrapping PgApprovalQueue logic lifted from plugins/plugin-personal-assistant/src/lifeops/approval-queue.ts (the ALLOWED_TRANSITIONS table + enqueue/list/resolve raw SQL over approval_requests); + resolveApprovalService helper.
• Move approval-queue.types.ts to @elizaos/shared (cross-package transport) or packages/agent/src/services/approval/types.ts (agent-private).
• Register in createElizaPlugin services[].
• In PA: actions/resolve-request.ts + any outbound-send / document-signature path constructing new PgApprovalQueue (and the index.ts re-export) switch to resolveApprovalService(runtime). Delete PA's approval-queue.ts + its sql copy, or leave a one-release re-export shim. Table stays owned by plugin-sql.

Verification gate:

• rg '@elizaos/plugin-personal-assistant' packages/agent/src → empty.
• bun run --cwd packages/agent verify; PA verify green.
• Manual: a RESOLVE_REQUEST round-trip still enqueues + resolves an approval_requests row (state-machine transitions unchanged).

---

Slice 5 — Carve goals tables app_lifeops.life_goal_* → app_goals (NEEDS-CARE, medium)

Dual writers (verified): PA LifeOpsRepository (10 life_goal_* refs) AND plugin-goals/src/db/goals-repository.ts (10 refs). Both must repoint atomically in this slice or data silently splits across schemas.

File ops:

• plugins/plugin-goals/src/db/schema.ts: redefine goalsTable → two tables matching the LIVE app_lifeops column shape — life_goal_definitions (id/agent_id/domain/subject_type/…/metadata_json/created_at/updated_at) and life_goal_links (id/agent_id/goal_id/linked_type/linked_id/created_at) — under goalsSchema = pgSchema('app_goals'), table names kept verbatim. Ensure plugin-goals/src/plugin.ts schema field registers them.
• Create plugins/plugin-goals/src/services/migration.ts = GoalsMigrationService, cloned from plugins/plugin-finances/src/services/migration.ts: SOURCE_SCHEMA='app_lifeops', TARGET_SCHEMA='app_goals', MIGRATED_GOAL_TABLES=['life_goal_definitions','life_goal_links'], serviceType 'goals_migration'. Register in plugin-goals/src/plugin.ts services[]. Add migration.test.ts.
• plugins/plugin-goals/src/db/goals-repository.ts: repoint every app_lifeops.life_goal_* → app_goals.* via a TARGET_SCHEMA const. KEEP the deleteGoal cross-table writes to app_lifeops.life_task_definitions (spine FK-nullout) and app_lifeops.life_audit_events (audit) UNCHANGED (one-directional cross-schema, allowed).
• PA lifeops/repository.ts: repoint the 10 life_goal_* refs to app_goals via a GOALS_SCHEMA const. Confirm PA service-mixin-goals.ts only delegates to GoalsService (it does — no direct SQL).

Verification gate:

• migration.test.ts: source-missing skip / target-non-empty skip / copies-when-empty.
• rg 'app_lifeops.life_goal_(definitions|links)' plugins/ → ONLY the GoalsMigrationService SOURCE_SCHEMA literal (no live writer on app_lifeops).
• rg '@elizaos/plugin-personal-assistant' plugins/plugin-goals/src → comments only.
• bun run --cwd plugins/plugin-goals verify; PA verify; decomposition-integration.test.ts green.

---

Slice 6 — Carve calendar tables app_lifeops.life_calendar_* → app_calendar (NEEDS-CARE, medium)

Dual writers (verified): PA LifeOpsRepository (21 life_calendar_* refs incl. the ALTER/CREATE-INDEX bootstrap block) AND plugin-calendar/src/service/CalendarRepository.ts (11 refs). The plugin-calendar schema (appLifeopsPgSchema('app_lifeops')) is a dormant squat — currently NO schema field on its plugin. Both writers repoint atomically.

File ops:

• plugins/plugin-calendar/src/service/schema.ts: rename appLifeopsPgSchema('app_lifeops') → calendarSchema = pgSchema('app_calendar'); keep table names life_calendar_events / life_calendar_sync_states verbatim.
• plugins/plugin-calendar/src/plugin.ts: actually register the schema (add the schema: field — currently absent).
• Create plugins/plugin-calendar/src/service/migration.ts = CalendarMigrationService (finances template): SOURCE_SCHEMA='app_lifeops', TARGET_SCHEMA='app_calendar', tables ['life_calendar_events','life_calendar_sync_states'], serviceType 'calendar_migration'. Register in plugin.ts services[]. Add migration.test.ts.
• CalendarRepository.ts: repoint the 11 refs to app_calendar via a TARGET_SCHEMA const.
• PA lifeops/repository.ts: repoint the calendar refs (incl. the bootstrap ALTER/CREATE-INDEX block ~2533/4194/4257) to app_calendar via a CALENDAR_SCHEMA const. Confirm PA withCalendar mixin only orchestrates (grant registry / connector gate / audit) and delegates the event/sync STORE to CalendarService — keep the orchestration in PA.

Verification gate:

• migration.test.ts (3 guard cases).
• rg 'app_lifeops.life_calendar_' plugins/ → ONLY the MigrationService SOURCE literal.
• rg '@elizaos/plugin-personal-assistant' plugins/plugin-calendar/src → comments only.
• bun run --cwd plugins/plugin-calendar verify; PA verify; integration test green.

---

Slice 7 — Scaffold @elizaos/plugin-scheduling (SAFE-NOW, low)

File ops:

• Create plugins/plugin-scheduling/: package.json (name @elizaos/plugin-scheduling; copy plugin-finances/package.json but DROP build:views, vite devDeps, lucide-react/@elizaos/ui, and the elizaos.app marker — the spine has no view since SCHEDULED_TASKS is absent from VIEW_ACTION_MAP). deps: @elizaos/core, @elizaos/agent, @elizaos/app-core, @elizaos/shared, drizzle-orm; peerDep @elizaos/plugin-sql. build:js + build:types only.
• tsconfig.json + tsconfig.build.json (copy finances, drop view refs); vitest.config.ts; CLAUDE.md + AGENTS.md (identical); README.md.
• src/index.ts + src/plugin.ts initially export an empty Plugin { name: '@elizaos/plugin-scheduling' }. plugins/* is already globbed in the workspace, so bun install links it.

Verification gate:

• bun install succeeds; bun run --cwd plugins/plugin-scheduling typecheck passes on the empty shell; eliza-source resolves @elizaos/plugin-scheduling.

---

Slice 8 — Move the storage-agnostic spine core into plugin-scheduling (NEEDS-CARE, medium)

File ops:

• git mv the PA-clean spine files (core-only imports) into plugins/plugin-scheduling/src/scheduled-task/: types.ts, runner.ts, gate-registry.ts, completion-check-registry.ts, escalation.ts, consolidation-policy.ts, due.ts, next-fire-at.ts, state-log.ts, index.ts
  • their tests (runner.test, due.test, consolidation-policy.test, after-task-chain.test).
• git mv lifeops/registries/anchor-registry.ts → plugin-scheduling/src/anchors/anchor-registry.ts (imports only scheduled-task/consolidation-policy + types — travels clean).
• Rewrite intra-spine relative imports: in due.ts + next-fire-at.ts ../registries/anchor-registry.js → ../anchors/anchor-registry.js.
• runner.ts's import type { DispatchResult } from "../connectors/contract.js": re-home the DispatchResult/ScheduledTaskDispatcher type into plugin-scheduling (declare it in scheduled-task/runner.ts or a new src/connectors/contract-types.ts); PA's connectors/contract.ts keeps the runtime impl and re-imports the type from @elizaos/plugin-scheduling.
• In PA, repoint every internal importer of the moved files to @elizaos/plugin-scheduling instead of ./scheduled-task/index.js / ../scheduled-task/types.js: owner/fact-store.ts, signals/bus.ts, repository.ts, wave1-types.ts, first-run/defaults.ts, providers/recent-task-states.ts, actions/document.ts, actions/work-thread.ts, routes/scheduled-tasks.ts, routes/plugin.ts, and the remaining registries/anchor-registry consumers.
• Add @elizaos/plugin-scheduling: workspace:* to PA package.json deps.

Verification gate:

• rg "@elizaos/plugin-personal-assistant" plugins/plugin-scheduling/src → comments only (the decomposition gate).
• bun run --cwd plugins/plugin-scheduling typecheck + test (moved runner/due/consolidation tests green).
• PA typechecks against the new import paths.

---

Slice 9 — Invert runtime-wiring: scheduling exposes injected assembly; PA owns production defaults (NEEDS-CARE, high)

File ops:

• Create plugin-scheduling/src/scheduled-task/runtime-wiring.ts with ONLY the PA-free assembly: createScheduledTaskRunnerFromDeps({ agentId, store, logStore, ownerFacts, globalPause, activity, subjectStore, dispatcher, hostCapabilities, channelKeys, now }) — builds the 5 registries (gates / completionChecks / ladders / anchors / consolidation) and calls createScheduledTaskRunner. Move the diagnostic shims (makeMissingActivityBusView / makeMissingSubjectStoreView) here (need only IAgentRuntime + logger).
• Create in PA lifeops/scheduled-task-wiring.ts that imports createScheduledTaskRunnerFromDeps from @elizaos/plugin-scheduling and supplies the PA-coupled production deps (lifted from the current runtime-wiring.ts): makeRepositoryBackedStores(new LifeOpsRepository) (current lines 78-…), resolveOwnerFactStore/ownerFactsToView, createGlobalPauseStore, getActivitySignalBus, createProductionScheduledTaskDispatcher (current line 242, reaches channels/send-policy/getAgentEventService), getHostExecutionCapabilities, getChannelRegistry channelKeys. registerAppLifeOpsAnchors (current line 341) moves to PA wiring — app-lifeops anchors are PA content.
• Move ScheduledTaskRunnerService (service.ts) to plugin-scheduling but have it call an injected runner-factory: PA registers via createScheduledTaskRunnerService(buildRunner) OR keeps a thin PA subclass supplying the PA factory. Preserve serviceType = "lifeops_scheduled_task_runner" EXACTLY (runtime dedup + getService key).
• getHostExecutionCapabilities stays in @elizaos/app-core (app-core/services/task-host-capabilities); plugin-scheduling depends on app-core for it (allowed — app-core is inward of plugins). The default hostCapabilities provider moves into plugin-scheduling's wiring helper.

Verification gate:

• rg 'LifeOpsRepository|fact-store|connectors|send-policy|channels/index|global-pause' plugins/plugin-scheduling/src → nothing.
• A PA integration test: getScheduledTaskRunner(runtime).getRunner() returns a working runner.
• serviceType literal unchanged (grep "lifeops_scheduled_task_runner").
• scheduler.integration.test.ts passes (move it with injected deps, or keep in PA).
• bun run --cwd plugins/plugin-personal-assistant test green.

---

Slice 10 — Move processDueScheduledTasks to plugin-scheduling with injected tick deps (NEEDS-CARE, high)

File ops:

• git mv lifeops/scheduled-task/scheduler.ts → plugin-scheduling/src/scheduled-task/scheduler.ts. Refactor processDueScheduledTasks (current :88) signature from { runtime, agentId, now, limit } to injected deps { agentId, now, limit, runner, store, ownerFactsProvider, anchorRegistry, onFired? }. Remove the inline new LifeOpsRepository (:98), resolveOwnerFactStore (:108), getAnchorRegistry (:113), and createPendingPromptsStore constructions. The pending-prompt recording (recordPendingPromptIfNeeded / shouldRecordPendingPrompt, current :55-71, triggered at :267) becomes the injected onFired(persistedTask) callback — move recordPendingPromptIfNeeded + shouldRecordPendingPrompt into PA (they read PA pending-prompts; after slice 3 they resolve the eliza_pending_prompts service). The due/timeout candidate listing goes behind store.list (already part of ScheduledTaskStore).
• In PA service-mixin-reminders.ts:5204: replace the processDueScheduledTasks({ runtime, agentId, now, limit }) call with the injected form — pass the LifeOpsRepository-backed store, the owner-facts provider, getAnchorRegistry(runtime), and an onFired that records the pending prompt via resolvePendingPromptsService(runtime). Keep the processScheduledWork interleave (circadian / reminders / workflows) entirely in PA — only the scheduled-task sub-call changes.

Verification gate:

• rg 'LifeOpsRepository|pending-prompts|fact-store' plugins/plugin-scheduling/src/scheduled-task/scheduler.ts → empty.
• PA processScheduledWork unit test: scheduledTaskFires / scheduledTaskCompletionTimeouts shapes unchanged.
• The 60s LIFEOPS_SCHEDULER tick fires a scheduled task end-to-end in a PA integration test (records a pending prompt via the onFired seam).

---

Slice 11 — Move the SCHEDULED_TASKS action into plugin-scheduling as an injected-deps factory (NEEDS-CARE, medium)

File ops:

• git mv src/actions/scheduled-task.ts → plugin-scheduling/src/actions/scheduled-task.ts. It imports hasLifeOpsAccess (../lifeops/access.js), createPendingPromptsStore (../lifeops/pending-prompts/store.js), LifeOpsRepository (../lifeops/repository.js), OWNER_OPERATION_VALIDATE (./life.js) — all PA-coupled. Convert the default export scheduledTaskAction into createScheduledTasksAction({ access, store, pendingPrompts, validate }) returning the Action. Action name 'SCHEDULED_TASKS' + all subaction/simile literals UNCHANGED.
• PA plugin.ts: replace import { scheduledTaskAction } + ...promoteSubactionsToActions(scheduledTaskAction) with createScheduledTasksAction({ access: hasLifeOpsAccess, store: paScheduledTaskStore(runtime), pendingPrompts: resolvePendingPromptsService, validate: OWNER_OPERATION_VALIDATE }) built at plugin-init. Atomic handoff: only PA registers it (no double-register); plugin-scheduling exports the factory.
• Update PA index.ts/plugin.ts re-export block (the scheduledTaskAction export and the big type re-export from scheduled-task/index.js, plugin.ts:~1238-1263) to re-export from @elizaos/plugin-scheduling (shim) for one release.

Verification gate:

• deterministic-action-coverage (scenario-runner) finds SCHEDULED_TASKS registered exactly once.
• rg 'SCHEDULED_TASKS' packages/agent/src/runtime/view-action-affinity.ts confirms it's NOT in VIEW_ACTION_MAP (no view-shadow concern).
• decomposition-integration.test.ts: no dropped owner action, no serviceType collision; PA composed action list unchanged (snapshot).

---

Slice 12 — Register the spine via plugin-scheduling's Plugin object; PA auto-registers it (NEEDS-CARE, medium)

File ops:

• Fill plugin-scheduling/src/plugin.ts: Plugin { name:'@elizaos/plugin-scheduling', services:[ScheduledTaskRunnerService], actions:[...promoteSubactionsToActions( createScheduledTasksAction(defaultDeps))] }.
• Lowest-risk handoff decision: PA stays the registrar — PA plugin.ts keeps ScheduledTaskRunnerService + the composed action in its own arrays, and PA auto-registers plugin-scheduling via a new ensureLifeOpsSchedulingPluginRegistered guard (mirror ensureLifeOpsFinancesPluginRegistered, PA plugin.ts:569-572: check runtime.plugins.some(p => p.name === schedulingPlugin.name)). plugin-scheduling's Plugin object is exported for standalone use but the runtime first-wins dedup prevents double-registration. registerLifeOpsTaskWorker (the circadian+reminders+scheduling composite tick) stays in PA.
• Document in plugin-scheduling/CLAUDE.md that PA owns registration during decomposition. Update PA CLAUDE.md services/actions tables: ScheduledTaskRunnerService + SCHEDULED_TASKS now sourced from @elizaos/plugin-scheduling.

Verification gate:

• Runtime first-wins dedup test: loading PA (which pulls plugin-scheduling) registers ScheduledTaskRunnerService + SCHEDULED_TASKS exactly once.
• bun run test:server green; decomposition-integration.test.ts green.

---

Slice 13 — Define the spine→reminders ports in plugin-scheduling (NEEDS-CARE, high)

Why scheduling owns these: reminders must register a tick-hook + read ports INTO the spine, but scheduling must never import reminders (dependency points the wrong way otherwise). Scheduling exposes a nullable hook + read-only ports; reminders consumes them.

File ops:

• Create plugin-scheduling/src/ports.ts declaring three read-only interfaces + registry, all owned by scheduling:
  • ReminderTickHook = { processReminders(args:{ now:string; limit:number }): Promise<{ attempts: ReminderAttemptResult[] }> } + registerReminderTickHook(runtime, hook) / getReminderTickHook(runtime).
  • SpineOccurrenceReadPort = { listActiveDefinitions, refreshDefinitionOccurrences, listOccurrenceViewsForOverview(agentId, horizonIso), listReminderPlanOwners(agentId, ownerType, ownerIds), listCalendarEvents(agentId, source, fromIso, toIso) }.
  • ChannelPolicyReadPort + CircadianReadPort = { listChannelPolicies, getChannelPolicy, readCircadianState, getScheduleMergedState }.
• In plugin-scheduling/src/scheduled-task/scheduler.ts, after processDueScheduledTasks, add: const hook = getReminderTickHook(runtime); const reminderAttempts = hook ? (await hook.processReminders({ now, limit })).attempts : []. This inverts today's direct this.processReminders call (service-mixin-reminders.ts:5190). NOTE: this scheduler hook is the plugin-scheduling-resident tick; the PA processScheduledWork interleave still drives circadian/workflows and calls into this — wire the hook where the scheduled-task sub-call lives (consistent with slice 10).
• The IMPL of all three ports is a thin adapter over the spine's LifeOpsRepository/registries — but since the repository stays PA-side in this phase (no table carve), the port impls are constructed in PA wiring and injected; scheduling holds only the interfaces + registry. NET: scheduling depends on NOTHING of reminders.

Verification gate:

• rg '@elizaos/plugin-reminders' plugins/plugin-scheduling/src → ZERO (not even comments).
• Typecheck plugin-scheduling.
• Unit test: getReminderTickHook returns undefined ⇒ tick still completes, reminderAttempts = [].

---

Slice 14 — Scaffold plugin-reminders + schema (app_reminders) + non-destructive migration (NEEDS-CARE, medium)

File ops:

• Create plugins/plugin-reminders/: package.json (name @elizaos/plugin-reminders, dependencies: ["@elizaos/plugin-sql","@elizaos/plugin-scheduling"], workspace:* on scheduling; peerDeps @elizaos/core + @elizaos/agent); tsconfig, CLAUDE.md + AGENTS.md (identical), README.
• src/db/schema.ts: remindersSchema = pgSchema("app_reminders"); copy lifeReminderPlans (schema.ts:225-244), lifeReminderAttempts (247-285), lifeEscalationStates (834-851) verbatim (column + index defs unchanged), re-rooted to remindersSchema.
• src/db/sql.ts: self-contained raw-SQL helpers copied from PA (finances pattern).
• src/services/migration.ts: clone plugin-finances/src/services/migration.ts; SOURCE_SCHEMA='app_lifeops', TARGET_SCHEMA='app_reminders', MIGRATED_REMINDER_TABLES=['life_reminder_plans','life_reminder_attempts','life_escalation_states'], serviceType 'reminders_migration'.
• src/plugin.ts: Plugin with schema=remindersSchema, services=[RemindersMigrationService] (ReminderService added in slice 16).
• PA schema.ts: leave the three reminder table DEFINITIONS in place (do NOT drop — finances precedent at schema.ts:311-315) but REMOVE them from PA's registered drizzle schema export array so plugin-reminders owns creation going forward; add the same explanatory comment.
• PA index.ts/plugin.ts: add ensureLifeOpsRemindersPluginRegistered (mirror finances).

Verification gate:

• bun run --cwd plugins/plugin-reminders verify.
• migration.test.ts: source-missing / target-non-empty / copies-when-empty per table.
• rg '@elizaos/plugin-personal-assistant' plugins/plugin-reminders/src → comments only.
• decomposition-integration.test.ts: no collision on reminders_migration.

---

Slice 15 — Lift pure reminder helpers + constants + contracts into plugin-reminders (NEEDS-CARE, medium)

File ops:

• git mv lifeops/service-helpers-reminder.ts (1894 LOC, near-pure: imports only ../contracts, ./enforcement-windows, ./service-constants, ./service-helpers-misc (mergeMetadata, priorityToUrgency), ./service-normalize, ./service-types) → plugin-reminders/src/reminder-helpers.ts. Resolve its 4 sibling deps:
  • REMINDER_* constants from service-constants.ts (DEFAULT_REMINDER_INTENSITY, DEFAULT_REMINDER_PROCESS_LIMIT, GLOBAL_REMINDER_PREFERENCE_CHANNEL_REF, the ~30 REMINDER_*_METADATA_KEY consts at service-mixin-reminders.ts:122-158) → plugin-reminders/src/reminder-constants.ts. Constants shared with the spine (OVERVIEW_HORIZON_MINUTES, PROACTIVE_TASK_QUERY_TAGS, DEFAULT_WORKFLOW_PROCESS_LIMIT) STAY in scheduling/PA, imported from @elizaos/plugin-scheduling.
  • enforcement-windows.ts, the reminder-only helpers in service-helpers-misc.ts (buildActiveReminders, isReminderChannelAllowedForUrgency, isWithinQuietHours), and service-types.ts ReminderActivityProfileSnapshot → move the reminder-only ones into plugin-reminders; leave genuinely-shared ones in scheduling and import.
  • LifeOpsReminder* DTOs (Plan/Attempt/Preference/Intensity/Urgency/Step/ProcessingResult/ Inspection/Channel + Request DTOs) → plugin-reminders/src/contracts.ts; re-export from @elizaos/shared if they are cross-package transport types (they appear in lifeops-schedule-sync-contracts), else own them in reminders.
• PA re-exports the moved helpers/constants from their old paths as shims (from "@elizaos/plugin-reminders") so existing PA imports compile unchanged.

Verification gate:

• bun run --cwd plugins/plugin-reminders typecheck.
• rg each moved symbol repo-wide; callers resolve via the new package or a PA shim.
• No duplicate const def (each REMINDER_*_METADATA_KEY in exactly one source).

---

Slice 16 — Build ReminderRepository on app_reminders (the 12 reminder-owned methods) (NEEDS-CARE, high)

File ops:

• Create plugin-reminders/src/db/reminder-repository.ts owning ONLY reminder-table methods, lifted from LifeOpsRepository and repointed app_lifeops.* → app_reminders.* via a TARGET_SCHEMA const: createReminderPlan(3126), updateReminderPlan(3146), deleteReminderPlan(3159), getReminderPlan(3168), listReminderPlansForOwners(3184), createReminderAttempt(5178), listReminderAttempts(5211), listDueReminderReviewAttempts(5241), claimDueReminderReviewAttempts(5285), updateReminderAttemptOutcome(5320), plus escalation methods upsertEscalationState(5906), getActiveEscalationState(5955), resolveEscalationState(5971), listRecentEscalationStates(5983), deleteAllEscalationStates(5998), plus the ensureReminderReviewColumns ALTER repair repointed to app_reminders.life_reminder_attempts. Use plugin-reminders/src/db/sql.ts.
• The cross-domain reads delivery needs (listActiveDefinitions, listOccurrenceViewsForOverview, listCalendarEvents, listChannelPolicies, getChannelPolicy, readCircadianState, getScheduleMergedState) are NOT in ReminderRepository — they come via the Spine/ChannelPolicy/Circadian read ports from slice 13.
• In PA LifeOpsRepository, make the moved reminder methods delegate to ReminderRepository (mirror the FinancesRepository delegation, finances CLAUDE.md) so any residual PA reader compiles.

Verification gate:

• bun run --cwd plugins/plugin-reminders test (repository unit tests against app_reminders).
• rg 'app_lifeops' plugins/plugin-reminders/src/db/reminder-repository.ts → zero (all repointed).
• PA typecheck green via delegation.

---

Slice 17 — Lift the ReminderService engine + wire ports + register the tick-hook (NEEDS-CARE, high)

File ops:

• Create plugin-reminders/src/reminder-service.ts = a Service (serviceType 'reminders', confirm no collision) holding its own runtime + ReminderRepository + injected SpineOccurrence/ChannelPolicy/Circadian read ports (resolved from @elizaos/plugin-scheduling at start()). Lift from service-mixin-reminders.ts the DELIVERY/ESCALATION/REVIEW/PREFERENCE methods ONLY: processReminders(4995), processDueReminderDeliveries(4611), processDueReminderReviewJobs(3140), dispatchDueReminderEscalation, dispatchReminderAttempt, getReminderPreference, setReminderPreference, inspectReminder, acknowledgeReminder, capturePhoneConsent, and the reminder-scoped activity-signal capture (leave non-reminder ones in PA).
• Rewrite every this.repository.<spineRead> → this.spinePort.<read> / this.channelPort.<read> / this.circadianPort.<read>; every this.repository.<reminderOwned> → this.reminderRepo. Channel transport (registerEscalationChannel from @elizaos/agent, sendTwilioSms/sendTwilioVoiceCall from @elizaos/plugin-phone, runtime.sendMessageToTarget) imported directly — unchanged.
• DELETE the moved methods from service-mixin-reminders.ts (the PA mixin shrinks). processScheduledWork stays in PA / scheduling.
• plugin-reminders/src/tick-hook.ts: implement ReminderTickHook.processReminders = (a) => reminderService.processReminders(a) and call registerReminderTickHook(runtime, hook) from plugin-reminders init().
• PRESERVE runtime strings: serviceType, action names, event names.

Verification gate:

• bun run --cwd plugins/plugin-reminders test (delivery/escalation specs ported from PA).
• Integration: register scheduling + reminders ⇒ scheduler tick populates reminderAttempts via hook; register scheduling ALONE ⇒ tick completes, reminderAttempts = [].
• rg 'this.repository' plugin-reminders/src/reminder-service.ts → only reminderRepo; spine reads go through ports.
• decomposition-integration.test.ts: serviceType 'reminders' no collision; processScheduledWork still returns the reminderAttempts field (shape preserved).

---

Slice 18 — Route + reminder-plan-init ownership handoff (NEEDS-CARE, high)

File ops:

• Routes: repoint /api/lifeops/reminders/process (lifeops-routes.ts:2005), /api/lifeops/reminder-preferences GET+POST (2014/2025), /api/lifeops/reminders/acknowledge (2037), /api/lifeops/reminders/inspection (2089) to resolve ReminderService (runtime.getService("reminders")) and call the same methods — URLs + response shapes IDENTICAL (finances /api/lifeops/money/* precedent). Prefer KEEP-IN-PA-DELEGATE first (smaller blast radius, matches runFinancesRoute).
• Actions: OWNER_REMINDERS/OWNER_ALARMS/OWNER_ROUTINES STAY registered where spine-definition CRUD lives — they defaultKind:"definition" (owner-surfaces.ts:227/251/342) and write life_task_definitions via runLifeOperationHandler (actions/life.ts). They are SPINE-DEFINITION ops, NOT reminder-plan ops. Preserve the literal action-name strings (VIEW_ACTION_MAP maps them to the goals view — guarded by the drift test).
• The reminder-PLAN attached at definition-create time: scheduling exposes registerDefinitionReminderPlanInitializer(runtime, fn); plugin-reminders registers the initializer (creates the default life_reminder_plans row) so scheduling does not import reminders. Definition-create stays spine; reminder-plan creation is the injected post-create callback.

Verification gate:

• E2E: POST /api/lifeops/reminders/process returns the same shape; creating a reminder via OWNER_REMINDERS ⇒ a life_task_definitions row (spine) + a life_reminder_plans row (app_reminders).
• decomposition-integration.test.ts: every VIEW_ACTION_MAP reminder action still registered; no dropped owner action; route URLs unchanged. The VIEW_ACTION_MAP git-grep drift test passes.

---

Slice 19 — Final reminders cleanup + PA depends on reminders (NEEDS-CARE, medium)

File ops:

• Add @elizaos/plugin-reminders to PA package.json deps (workspace:*); PA may re-export reminder shims from index.ts for one release.
• service-mixin-reminders.ts is now a thin shim — if every method moved, remove it from the LifeOpsService composition in service.ts and delete the file; otherwise leave only the genuinely-shared residue (circadian persistence stays in the spine tick, NOT here).
• Update PA CLAUDE.md + the boundary table in plugin-reminders/CLAUDE.md (mirror finances "What lives here vs in PA"). Update lifeops-decomposition-plan.md status.

Verification gate:

• bun run --cwd plugins/plugin-reminders verify; PA verify; plugin-scheduling verify.
• rg '@elizaos/plugin-personal-assistant' plugins/plugin-reminders/src → comments only.
• rg '@elizaos/plugin-reminders' plugins/plugin-scheduling/src → ZERO.
• bun run test:client (PA + reminders lane).

---

Slice 20 — Delete the dead core scheduled-task stub (SAFE-NOW, low)

Why last: the real ScheduledTask type now lives in @elizaos/plugin-scheduling, so the core stub is fully superseded and actively misleading.

File ops:

• Delete packages/core/src/scheduled-task/{types.ts,runner.ts,index.ts,README.md} (StubScheduledTaskRunner + the narrower duplicate ScheduledTask type — only 5 self-refs).
• Remove export * from "./scheduled-task/index.js" from packages/core/src/index.ts:34.

Verification gate:

• rg 'StubScheduledTaskRunner|scheduled-task/index|from "./scheduled-task"' packages/core/src → nothing.
• bun run --cwd packages/core build (Node+browser+edge) green; test green.
• No external importer of core's scheduled-task remains (rg across repo).

---

3. Deferred / blocked (NOT landable now — explicitly out of scope for this pass)

These are documented for honesty; do not attempt them in the slices above.

• Physical spine table carve (app_lifeops.life_* → app_scheduling). The injected-store design (slices 8-12) leaves the 4 spine tables + raw SQL in PA's LifeOpsRepository, so the spine move is a pure code move with zero migration risk. A later, optional slice can add plugin-scheduling/src/schema.ts (pgSchema('app_scheduling')) + a SchedulingMigrationService — but that requires moving the store impl + raw SQL into plugin-scheduling, a materially bigger change. Recommend deferring. This is a separate multi-PR effort.
• Blocker "carve" — BLOCKED on owner decision. app_blocker.block_rules (plugin-blocker, registered-but-NEVER-queried) and app_lifeops.life_block_rules (PA, LIVE — website-blocker reconciler + proactive-block-bridge) have structurally incompatible columns (target/pattern/entityId vs profile/websites/gateType/gateUntilMs). There is NO row-shape under which a copy migration is valid. Options: (a) leave life_block_rules PA-owned focus logic, or (b) move the whole website-blocker reconciler + life_block_rules into plugin-blocker and delete the unused app_blocker.block_rules. Needs owner sign-off before any code change.
• Entity/relationship V1 retirement. PA actions/entity.ts already routes through the runtime EntityStore/RelationshipStore (KnowledgeGraphService); plugin-relationships' KNOWLEDGE_GRAPH action covers the same ops; a graph-migration/migration.ts already exists. This is mostly DELETION of the dead V1 raw life_relationships SQL in repository.ts + confirming the migrator runs. Low risk but independent of the spine/reminders work — sequence it after slice 20 or as its own PR.

---

4. Honest effort assessment

• Landable now, single PRs (SAFE-NOW): slices 1, 2, 3, 4, 7, 20. Six clean wins.
• Landable now but each must be ONE atomic PR (NEEDS-CARE, data/coupling): slices 5, 6 (dual-writer schema carves — both writers repoint in the same commit), 8-12 (the spine extraction — a coherent 5-slice arc that should land as a tight series, not split across weeks), 13-19 (the reminders extraction — the largest carve; 13+14 can land independently as scaffolding, but 16-18 are deeply coupled and should be reviewed together).
• Genuinely multi-PR / deferred: the physical spine table carve (app_scheduling), the blocker decision, the entity V1 retirement.
• The single biggest mechanical lift is slice 16-17 (ReminderRepository + ReminderService): the 12 reminder-owned methods + the delivery/escalation/review engine lifted out of a 5468-LOC mixin, with every spine read rewritten to go through injected ports. It is mechanical but large and must preserve every reminderAttempts shape the tick returns.

---

5. The single biggest risk

The reminders carve depends on a read-port seam that the spine extraction must expose correctly, and the tick that drives both is interleaved in a single 5000+-line PA method (processScheduledWork). If slices 8-13 do not land the injection seams cleanly — specifically, if processDueScheduledTasks's pending-prompt onFired callback or the three reminders read-ports (SpineOccurrence/ChannelPolicy/ Circadian) leak a PA import into plugin-scheduling, or if the ReminderTickHook inversion drops the reminderAttempts field — the dependency direction flips (plugin-scheduling → PA or plugin-scheduling → plugin-reminders), violating the inward-only architecture law and silently breaking the per-tick reminder delivery (reminders stop firing with no error). Mitigation: the per-slice gates rg "@elizaos/plugin-personal-assistant" plugins/plugin-scheduling/src (comments only) and rg "@elizaos/plugin-reminders" plugins/plugin-scheduling/src (ZERO), plus the "scheduling ALONE ⇒ reminderAttempts=[] / scheduling+reminders ⇒ populated" integration test, are the non-negotiable tripwires — do not advance a slice until both pass.

---

6. Execution status (2026-06-18)

Landed (committed + pushed to develop):

• ✅ Slice 1 — LifeOps overview view + builtin tab removed across PA / packages-ui / app-core; route-coverage 10/10, decomposition 6/6, all typecheck clean. (2cd13115b4)
• ✅ Slice 2 — vestigial app_goals routines/reminders/alarms/checkins tables deleted. (d286dbae73)
• ✅ Slice 7 — @elizaos/plugin-scheduling scaffolded (empty Plugin shell + package/tsconfig/CLAUDE; bun install links it; typechecks). (5b12de8344)
• ✅ Slice 20 — dead @elizaos/core scheduled-task stub deleted. (33d9918038)
• Plus the earlier review: lifeops-cleanup-review.md + 3,578 LOC of dead graph/identity code removed (context-graph, identity-observations).

Not yet executed (the deep arcs — DELIBERATELY deferred as careful, reviewed PRs):

• Slices 3, 4 — runtime-service promotions (pending-prompts/global-pause/handoff/approval-queue → @elizaos/agent). Standalone SAFE-NOW; next-up.
• Slices 5, 6 — goals/calendar schema carve-outs (atomic dual-writer migrations).
• Slices 8–19 — the spine + reminders engine extraction. This is the bulk of "scheduling → plugin-scheduling, reminders → plugin-reminders" and is an atomic multi-PR effort: moving ~7k LOC of spine + a 5,468-LOC reminders mixin out of a 137k-LOC monolith fused to an 8.4k-LOC repository.ts, with the per-tick reminder delivery interleaved in one processScheduledWork method. Rushing it on the shared develop branch (where PA's typecheck baseline is already ~472 errors, masking new breakage) risks silently breaking the agent's scheduling + reminders. It must land as the tight, reviewed slice series in §2, each gated by the §0/§2 tripwires (no inward import leak; reminderAttempts shape preserved; the "scheduling-alone ⇒ [] / scheduling+reminders ⇒ populated" integration test).

Recommendation: land slices 3–6 next (each a clean single PR), then the spine arc (8–12) as one reviewed PR, then the reminders arc (13–19) as one reviewed PR.

---

7. Execution status update (2026-06-18, cont.)

✅ Slice 8 LANDED (ada0c9a61d, pushed) — the storage-agnostic scheduling spine core is now in @elizaos/plugin-scheduling: types, runner, the gate/completion-check/escalation registries, consolidation-policy, due/ next-fire-at math, state-log, the barrel, and the anchor registry. The DispatchResult type is re-homed there. The tick driver (processDueScheduledTasks), the runner Service, and runtime-wiring stay PA-side and import the spine from the new package; PA keeps a thin lifeops/scheduled-task/index barrel re-exporting the package + the local scheduler/service so existing importers are unchanged. Verified: plugin-scheduling typecheck clean + 72 spine tests; PA build:types clean, tsgo 470 (≤ baseline), decomposition 6/6, 6 spine-consuming PA test files (72 tests) green; tripwire (no PA import in plugin-scheduling/src) holds.

Architecture reached: @elizaos/plugin-scheduling is the reusable scheduling-spine library; PA is the host that injects its repository/owner-facts/channels and drives the tick. This is a clean, defensible decomposition — the substantive "scheduling → plugin-scheduling."

Remaining (atomic, must each land as one reviewed PR):

• Slices 9–12 — move the tick driver + runner Service + SCHEDULED_TASKS action into plugin-scheduling (PA injects production deps). High-risk wiring inversion; marginal benefit over slice 8 (the reusable library is already extracted). Optional.
• Slices 13–19 — reminders → plugin-reminders. The largest lift: it MUST be atomic (the app_lifeops.life_reminder_* → app_reminders migration + the ReminderRepository repoint must land in the same change or reminder data splits across two schemas), and it lifts the delivery/escalation engine out of the 5,468-LOC service-mixin-reminders.ts while preserving the per-tick reminderAttempts shape. Reminder tables verified at schema.ts:224 (life_reminder_plans), :246 (life_reminder_attempts), :833 (life_escalation_states). Recommended approach (finances pattern): scaffold plugin-reminders (depends on plugin-scheduling + plugin-sql) → app_reminders schema (copy the 3 tables verbatim) → non-destructive RemindersMigrationService → self-contained ReminderRepository over app_reminders → PA's LifeOpsRepository reminder methods delegate to it → PA registers plugin-reminders via ensureLifeOpsRemindersPluginRegistered. The service-mixin engine can stay PA-resident, delegating through the repository (consistent with how the spine wiring stays PA-side).
• Slices 3–6 (runtime-service promotions; goals/calendar schema carves) — independent, finances-proven, landable as separate clean PRs.

8. Execution status update (2026-06-19) — data-layer carves complete

✅ All LifeOps data-layer carves LANDED + pushed. Every dual-writer / shared-schema-squat in the LifeOps domain is now eliminated; each domain plugin owns its own app_* schema with a non-destructive app_lifeops → app_* migration (the finances carve pattern: to_regclass source guard + target-empty check + INSERT … SELECT s.*, source never dropped). PA keeps the app_lifeops defs only as the dormant migration source and auto-registers each plugin so the schema exists + the migration runs.

Carve	Schema	Tables	Migration service	Notes
reminders (slice 14-ish)	app_reminders	life_reminder_plans / _attempts / life_escalation_states	RemindersMigrationService	PA-exclusive tables; data layer only (engine stays PA-resident)
calendar (slice 6)	app_calendar	life_calendar_events / _sync_states	CalendarMigrationService	killed the PA↔plugin-calendar dual-writer; schema was an unregistered squat
goals (slice 5)	app_goals	life_goal_definitions / _links	GoalsMigrationService	resolved the documented shared-schema counter-position by carving cleanly; replaced the dead app_goals.goals placeholder; reminder/scheduling goal-link reads follow the repository to app_goals
inbox	app_inbox	life_inbox_triage_entries / _examples / life_email_unsubscribes	InboxMigrationService	sole writer was plugin-inbox (PA's src/inbox/repository.ts is a shim); gmail projection tables stay PA-owned; 22 lifeops.* scenarios + bootstrapSchema repointed

Each: plugin typecheck clean + migration unit test (3-4 guard cases); PA build:types clean; PA tsgo 470 == baseline (zero net new errors); full PA suite 548/548; decomposition-integration 6/6 (no migration-serviceType collision across reminders/calendar/goals/inbox/finances); tripwire holds (no PA import in the carved plugin's src); no live writer/reader left on the app_lifeops source tables.

Deliberately NOT done (each needs an owner decision or a dedicated focused effort — out of scope for a high-confidence cleanup sweep):

• Slices 3–4 (promote pending-prompts / global-pause / handoff / approval-queue → @elizaos/agent). This moves assistant-workflow state INWARD into the core runtime (every agent would carry it), the opposite direction from the carves above, and its main stated rationale was enabling the deferred spine-engine move. Architecturally debatable — wants an owner call on whether the runtime is the right home, not a unilateral sweep.
• Slices 9–12 (move the tick driver + runner Service + SCHEDULED_TASKS into plugin-scheduling; invert runtime-wiring) — high-risk wiring inversion, marginal benefit over the slice-8 library extraction.
• Slices 13/16–19 (lift the reminders delivery/escalation ENGINE out of the 5,468-LOC service-mixin-reminders.ts behind plugin-scheduling tick-hook ports) — the riskiest tick/engine surgery; the reminders data layer is already carved, so the headline ("reminders → plugin-reminders") is delivered.