tap-triggerslisted

# tap-triggers — the trigger layer above plans ## What this is (and the one-sentence why) A Plan answers **what** and encodes **verification**; it deliberately does not answer **when**. Cloud "routines" bundle all three but pay an agent session per fire. Tap's distillation asymmetry demands the opposite: compile once, replay free — so the trigger layer must also be zero-token. The OS already ships a world-class trigger engine (launchd); this skill owns only the **deterministic compile** from a versionable declaration to a launchd artifact. > Derivation (engineering-philosophy, 2026-07-12): trigger-in-engine is > structurally impossible — the NM host's lifetime is bound to Chrome's SW > (ADR 2026-05-30), and a scheduler that dies with the browser is not a > scheduler. Trigger-in-plan breaks the unit (a shared plan must not carry my > crontab; one plan ↔ N triggers). Hence a separate declaration, systemd > service/timer isomorphism: plan = service, trigger = timer. ## Declaration format `~/.tap/triggers/<site>/<name>[.<slot>].trigger.json` — one file, one trigger. Slot (optional third filename segment) gives one plan several independent triggers (`visibility-recheck.am.trigger.json`, `…pm.trigger.json`). ```jsonc { "ref": "xhs/visibility-recheck", // or tap://xhs/visibility-recheck "args": { "note_url": "…", "note_id": "…" }, // optional, verbatim → tap --args "when": { // EXACTLY ONE of: "calendar": { "Hour": 10, "Minute"