---
name: alarm-port-deferred-arrangement
description: "/spt:new-alarm durable scheduler stays DEFERRED — operator has a superseding \"arrangement\" system in mind; don't dispatch the port or a stopgap"
metadata: 
  node_type: memory
  type: project
  originSessionId: 7f5a5890-9c8c-4043-bcb6-647b6f7a36d7
---

`/spt:new-alarm` (durable one-shot alarm scheduler) is an ACCEPTED, KNOWN parity gap — NOT an oversight. spt-core has only the alarm event *shape* (spt-proto) + relay handling (psyrelay.rs:93) + a test fixture; the real "fire at target-time → TIMED PULSE" timer still lives in **legacy owl listener in-memory**. The durable in-daemon scheduler is deferred at DEFERRED.md:43 (ADR-0018 Q4/V3) — deferred because the daemon had no one-shot consumer (building pre-consumer = untested dead code, violates activate-don't-pre-fail). The one-shot RULE is locked (persist target-time, fire-if-due on every brain start, survive crash+update); the periodic half shipped in restoration D5 (disk-deadline pattern the port would reuse).

**Operator ruling 2026-06-15: KEEP DEFERRED.** He has a more robust **"arrangement" system** in mind that would SUPERSEDE the alarm port — not ready to discuss yet.

**How to apply:** When new-alarm surfaces as a parity delta (perri's claude-spt audit raised it), do NOT mint a REQ, do NOT dispatch the port to todlando, do NOT build an adapter-side stopgap timer (throwaway against the coming arrangement model). Log it as deferred-pending-arrangement-system. Revisit only when the operator surfaces the arrangement design. Relates to spt-core-never-caters-to-a-harness boundary [[spt-core-harness-boundary-and-grounding]] — the scheduler is a core daemon primitive, not adapter glue.