@rubytech/create-sitedesk-code 0.1.523 → 0.1.525

package/payload/platform/plugins/admin/hooks/mailbox-inject.sh

@@ -0,0 +1,299 @@
+#!/usr/bin/env bash
+# Task 2157 — UserPromptSubmit hook: inject a <mailboxes> block as
+# additionalContext on every turn, naming the Outlook mailboxes attached to this
+# account and the plugin that holds each, so a session never learns attachment
+# state by polling one mail plugin and reading that plugin's miss as an
+# account-wide fact (Task 2156's incident).
+#
+# Per-turn, not spawn-time: the delegated attach in that incident landed 27
+# minutes after the session spawned, so an env stamp would have been stale in the
+# very case this exists for.
+#
+# The hook is a READ-ONLY observer of the outlook plugin's store. It never writes
+# there, and in particular never performs the rename MailboxRegistry.migrateLegacy
+# does. Three fields leave the decrypt — mail, graphUserId, refreshTokenExpiry —
+# and no other blob field reaches stdout, stderr or the log.
+#
+# Mirrors datetime-inject.sh: drain stdin first, node for the reading, python3 for
+# the JSON envelope, exit 0 on every path, breadcrumb last. UserPromptSubmit
+# output is ADDED to the prompt, never substituted.
+#
+# Input  (stdin, UserPromptSubmit contract): { "session_id": "...", ... } —
+#         session_id is used only for the breadcrumb; the block is standing and
+#         prompt-independent.
+# Output (stdout JSON):
+#   { "hookSpecificOutput": { "hookEventName": "UserPromptSubmit",
+#                             "additionalContext": "<mailboxes>...</mailboxes>" } }
+
+set -uo pipefail
+
+# Drain stdin FIRST, before any exit path. Claude Code writes the full payload to
+# our stdin; exiting before reading it leaves the parent blocked on write and then
+# hit with EPIPE. Same reason the two sibling hooks drain first.
+HOOK_INPUT=$(cat 2>/dev/null || true)
+
+command -v python3 >/dev/null 2>&1 || exit 0
+command -v node >/dev/null 2>&1 || exit 0
+
+# --- account dir -----------------------------------------------------------
+# ACCOUNT_DIR is stamped unconditionally on the rc-spawn path (rc-daemon.ts
+# buildRcChildEnv) but only for admin/specialist on the pty-spawner path
+# (pty-spawner.ts, the `isSpecialistSpawn || role === admin` gate), so a
+# role:public webchat or passive WhatsApp spawn has none. The spawn cwd IS the
+# account dir on both paths (config.ts: spawnCwd defaults to accountDir), which
+# is how fs-schema-guard.sh already resolves it.
+ACCT=""
+if [ -n "${ACCOUNT_DIR:-}" ] && [ -d "${ACCOUNT_DIR}" ]; then
+  ACCT="$ACCOUNT_DIR"
+elif [ -f "$PWD/.claude/settings.json" ] && [ -d "$PWD/secrets" ]; then
+  ACCT="$PWD"
+fi
+
+# --- log dir ---------------------------------------------------------------
+# LOG_DIR is stamped ONLY on the rc-spawn path; pty-spawner never sets it and the
+# systemd unit does not carry it. CLAUDE_SESSION_MANAGER_PERSIST_DIR is on the
+# unit, and the manager itself derives its log dir as <persistDir>/logs, so that
+# fallback resolves to the same directory. Task 2173 covers the sibling hooks,
+# which have no such ladder and are silent on that path.
+LOGD=""
+if [ -n "${LOG_DIR:-}" ] && [ -d "${LOG_DIR}" ]; then
+  LOGD="$LOG_DIR"
+elif [ -n "${CLAUDE_SESSION_MANAGER_PERSIST_DIR:-}" ] && [ -d "${CLAUDE_SESSION_MANAGER_PERSIST_DIR}/logs" ]; then
+  LOGD="$CLAUDE_SESSION_MANAGER_PERSIST_DIR/logs"
+elif [ -n "$ACCT" ] && [ -d "$ACCT/logs" ]; then
+  LOGD="$ACCT/logs"
+fi
+
+SID=$(printf '%s' "$HOOK_INPUT" | python3 -c 'import json,sys
+try:
+    print(json.load(sys.stdin).get("session_id","") or "?")
+except Exception:
+    print("?")' 2>/dev/null)
+SID=${SID:-?}
+NOW_ISO=$(date -u +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || echo "?")
+
+emit_log() {
+  local line="$NOW_ISO [mailbox-inject] $1 session=$SID"
+  if [ -n "$LOGD" ]; then
+    # stderr redirect FIRST: with the append first, bash emits its own
+    # "Permission denied" on an unwritable log before 2>/dev/null takes effect,
+    # and that escapes to the hook's stderr on every turn.
+    printf '%s\n' "$line" 2>/dev/null >> "$LOGD/mailbox-inject.log" || true
+  fi
+  echo "$line" >&2 || true
+}
+
+if [ -z "$ACCT" ]; then
+  emit_log "op=skip reason=no-account-dir"
+  exit 0
+fi
+ACCT_ID="$(basename "$ACCT")"
+
+# --- read the store --------------------------------------------------------
+# stderr is discarded because node prints the ENTIRE parsed source text on an
+# uncaught exception, which for a decrypted blob is the live access and refresh
+# tokens. The reader also try/catches every read and parse, so this is the second
+# of two independent guards, not the only one.
+READ_OUT=$(MBX_ACCOUNT_DIR="$ACCT" node -e '
+const fs=require("node:fs"),p=require("node:path"),c=require("node:crypto");
+const A=process.env.MBX_ACCOUNT_DIR||"";
+const OD=p.join(A,"secrets","outlook");
+const MD=p.join(OD,"mailboxes");
+const KP=p.join(OD,".key");
+const LP=p.join(OD,"tokens.enc");
+function probe(x){try{fs.statSync(x);return "present";}catch(e){return e.code==="ENOENT"?"absent":"error";}}
+function fail(r){process.stdout.write("skip\treason="+r+"\t");process.exit(0);}
+if(probe(OD)==="error")fail("unreadable-source");
+
+// The AES key is account-level and shared by every mailbox in the account. An
+// absent or malformed key is not a skip: it makes every blob unreadable, which
+// is a real state the block reports rather than hides.
+let key=null;
+if(probe(KP)==="present"){
+  try{const k=Buffer.from(fs.readFileSync(KP,"utf8").trim(),"base64");if(k.length===32)key=k;}catch(e){key=null;}
+}
+
+// Only mail, graphUserId and refreshTokenExpiry survive this function. The
+// decrypted blob goes out of scope with the tokens still inside it, and no error
+// object is ever printed: a JSON.parse SyntaxError message can quote its input.
+function readBlob(f){
+  if(!key)return null;
+  try{
+    const raw=fs.readFileSync(f,"utf8").trim();
+    if(!raw)return null;
+    const i=raw.indexOf(":");
+    if(i<1)return null;
+    const d=c.createDecipheriv("aes-256-cbc",key,Buffer.from(raw.slice(0,i),"hex"));
+    let s=d.update(raw.slice(i+1),"hex","utf8");s+=d.final("utf8");
+    const b=JSON.parse(s);
+    if(!b||typeof b!=="object")return null;
+    return {mail:(typeof b.mail==="string"&&b.mail.trim())?b.mail.trim():null,
+            gid:(typeof b.graphUserId==="string"&&b.graphUserId.trim())?b.graphUserId.trim():null,
+            rte:(typeof b.refreshTokenExpiry==="number")?b.refreshTokenExpiry:null};
+  }catch(e){return null;}
+}
+
+// mailboxStatus precedence: unreadable, blank-email, refresh-expired, ok.
+function classify(v){
+  if(!v)return "unreadable";
+  if(!v.mail)return "blank-email";
+  if(v.rte!==null&&Date.now()>v.rte)return "refresh-expired";
+  return "ok";
+}
+const boxes=[];
+function addBox(k,f){const v=readBlob(f);boxes.push({key:k,mail:v?v.mail:null,gid:v?v.gid:null,status:classify(v)});return v;}
+// sanitizeMailboxKey, verbatim from token-store.ts, so the legacy-dedupe test
+// below compares the same folded form the plugin would have written.
+function sanKey(k){return String(k).replace(/[^A-Za-z0-9._-]/g,"_");}
+
+// Keep only directories containing tokens.enc, exactly the registry gate. A
+// directory without one is what the revocation path leaves behind.
+const mdState=probe(MD);
+if(mdState==="error")fail("unreadable-source");
+if(mdState==="present"){
+  let ents=null;
+  try{ents=fs.readdirSync(MD,{withFileTypes:true});}catch(e){ents=null;}
+  if(ents===null)fail("unreadable-source");
+  for(const e of ents){
+    if(!e.isDirectory())continue;
+    const tf=p.join(MD,e.name,"tokens.enc");
+    if(probe(tf)!=="present")continue;
+    addBox(e.name,tf);
+  }
+}
+// The pre-migration single-mailbox layout. Read, never moved.
+//
+// migrateLegacy() moves it to mailboxes/<sanitizeMailboxKey(graphUserId)>/ and,
+// when that destination ALREADY holds a blob, unlinks the legacy copy instead.
+// A register writes through storeFor() without calling list(), so both files can
+// sit on disk at once until some outlook tool triggers the migration. Listing the
+// legacy file unconditionally would then show one mailbox twice, and count it
+// twice, where the plugin shows it once. Mirror the destination test as a
+// read-only skip: same key derivation, no rename, no unlink.
+if(probe(LP)==="present"){
+  const lv=addBox("legacy tokens.enc",LP);
+  const lkey=sanKey(lv?(lv.gid||"unknown"):"legacy-unreadable");
+  for(let i=0;i<boxes.length-1;i++){
+    if(boxes[i].key===lkey){boxes.pop();break;}
+  }
+}
+
+// Control characters and the angle brackets that frame the block can never
+// appear in a subject: the frame holds by construction, not by the invariants
+// that currently keep them out (sanitizeMailboxKey folds directory names, mail
+// comes from Graph, and shared-mailbox-add probes an address against Graph
+// before persisting it). Bounded length for the same reason.
+function clean(s){
+  const t=String(s).replace(/[\u0000-\u001f\u007f<>]/g," ").trim();
+  return t.length?t.slice(0,120):"(unnamed)";
+}
+function subject(b){return clean(b.mail||b.gid||b.key);}
+const readable=new Map();
+for(const b of boxes)if(b.status!=="unreadable")readable.set(b.key,b);
+
+const DP=p.join(OD,"delegated.json");
+// Mirrors DelegatedStore.read(): an absent or unparseable file means zero
+// entries, never zero block; per-entry drops for a non-string viaMailboxKey or a
+// non-number addedAt; keys normalised with trim+toLowerCase.
+// A Map, not an array: read() assigns into an object keyed by the NORMALISED
+// address, so two keys differing only in case or surrounding space collapse to
+// one record there. Pushing to an array would render such a mailbox once per key.
+const delegMap=new Map();
+let degraded=false;
+const dState=probe(DP);
+if(dState==="error")degraded=true;
+else if(dState==="present"){
+  try{
+    const o=JSON.parse(fs.readFileSync(DP,"utf8"));
+    if(o&&typeof o==="object"&&!Array.isArray(o)){
+      for(const kv of Object.entries(o)){
+        const a=kv[0],e=kv[1];
+        if(!e||typeof e!=="object")continue;
+        if(typeof e.viaMailboxKey!=="string")continue;
+        if(typeof e.addedAt!=="number")continue;
+        delegMap.set(String(a).trim().toLowerCase(),e.viaMailboxKey);
+      }
+    }else{degraded=true;}
+  }catch(e){degraded=true;}
+}
+const deleg=Array.from(delegMap,function(kv){return {addr:kv[0],via:kv[1]};});
+
+const SUFFIX={"ok":"signed in",
+  "refresh-expired":"signed in, needs re-authorising",
+  "blank-email":"signed in, no address on record — internal handle",
+  "unreadable":"attached, unreadable — internal handle"};
+const lines=[];
+for(const b of boxes.slice().sort(function(x,y){return subject(x).localeCompare(subject(y));})){
+  lines.push("- "+subject(b)+" — outlook plugin ("+SUFFIX[b.status]+")");
+}
+// A delegated entry is connected only when its viaMailboxKey names a mailbox
+// whose blob DECRYPTS, exactly the predicate MailboxRegistry.resolve() uses.
+// Matching directory presence would promise a mailbox every call refuses.
+for(const d of deleg.slice().sort(function(x,y){return x.addr.localeCompare(y.addr);})){
+  const g=readable.get(d.via);
+  lines.push(g
+    ? "- "+clean(d.addr)+" — outlook plugin (delegated via "+subject(g)+")"
+    : "- "+clean(d.addr)+" — outlook plugin (delegated, delegator no longer connected)");
+}
+
+const now=new Date().toISOString();
+const head="Outlook mailboxes attached to this account, read at "+now+". Read this rather than polling the plugin. Only the most recent <mailboxes> block is current.";
+const tail=["This list is internal. Use it to decide which tool to call; do not recite it to whoever is on the other end of a channel conversation.","This list covers the outlook plugin only. IMAP mailboxes are not listed here, so their absence above is not evidence they are unattached — call email-status for those.","Tools: outlook-* for outlook-plugin mailboxes, email-* for email-plugin mailboxes."];
+const body=[head].concat(lines.length?lines:["None attached."]).concat(tail).join("\n");
+
+// blank-email counts as usable: resolve() addresses a sole blank-email mailbox
+// through /me, filtering on readable rather than on status === ok.
+let usable=0,exp=0,unr=0;
+for(const b of boxes){
+  if(b.status==="ok"||b.status==="blank-email")usable++;
+  else if(b.status==="refresh-expired")exp++;
+  else unr++;
+}
+const m="outlook="+boxes.length+" delegated="+deleg.length+" usable="+usable+" expired="+exp+" unreadable="+unr+" degraded="+(degraded?"yes":"no");
+process.stdout.write("ok\t"+m+"\t"+body);
+' 2>/dev/null) || READ_OUT=""
+
+if [ -z "$READ_OUT" ]; then
+  emit_log "op=skip reason=reader-failed account=$ACCT_ID"
+  exit 0
+fi
+
+VERDICT="${READ_OUT%%$'\t'*}"
+REST="${READ_OUT#*$'\t'}"
+METRICS="${REST%%$'\t'*}"
+BODY="${REST#*$'\t'}"
+
+# Exhaustive on purpose. The shipped reader writes only the two-tab `ok` and
+# `skip` shapes, but if anything else ever reached this stdout the fall-through
+# would inject it as the block body AND interpolate it into the breadcrumb, where
+# an address would land in a log the admin route serves unauthenticated. Anything
+# that is not exactly `ok` is a skip, with a fixed reason rather than the payload.
+case "$VERDICT" in
+  skip) emit_log "op=skip ${METRICS} account=$ACCT_ID"; exit 0 ;;
+  ok)   : ;;
+  *)    emit_log "op=skip reason=reader-malformed account=$ACCT_ID"; exit 0 ;;
+esac
+
+CONTEXT="<mailboxes>
+$BODY
+</mailboxes>"
+
+ENVELOPE=$(printf '%s' "$CONTEXT" | python3 -c '
+import json, sys
+ctx = sys.stdin.read()
+print(json.dumps({
+    "hookSpecificOutput": {
+        "hookEventName": "UserPromptSubmit",
+        "additionalContext": ctx,
+    }
+}))
+' 2>/dev/null) || exit 0
+
+[ -n "$ENVELOPE" ] || exit 0
+printf '%s\n' "$ENVELOPE"
+
+case "$METRICS" in
+  *degraded=yes*) emit_log "op=degrade reason=delegated-unreadable account=$ACCT_ID" ;;
+esac
+emit_log "injected account=$ACCT_ID $METRICS imap=not-read source=disk refresh=per-turn"
+exit 0

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what SiteDesk ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:3c774bc07fd9321ebc739551ae7e7288d6995c368d7fb3f87dcd096359419a65
+content-hash: sha256:c1dc0d24b2faa821b80ec583a83b5828393886fbda1963cfb874401d4137cd03
 brand: sitedesk-code
 product-name: SiteDesk
 ---
@@ -622,11 +622,13 @@ Tell SiteDesk naturally:
 
 - "List my workflows."
 - "Show me the follow-up workflow."
-- "Pause the new-lead workflow." or "Turn the new-lead workflow back on."
+- "Stop running the new-lead workflow." or "Start running the new-lead workflow again."
 - "Change the follow-up workflow so it also messages me."
 - "Delete the old onboarding workflow."
 
-Pausing keeps a workflow but stops it running. Editing replaces the steps or the inputs with the new version you describe. Deleting removes the workflow and its run history, so SiteDesk confirms with you first.
+Stopping a workflow keeps it but stops it running. Editing replaces the steps or the inputs with the new version you describe. Deleting removes the workflow and its run history, so SiteDesk confirms with you first.
+
+A workflow is not a routine. "Pause the morning routine" is about a scheduled trigger, not about a workflow, so say routine when you mean the scheduled thing and SiteDesk will reach for the right one.
 
 ## Scheduling a Workflow
 
@@ -3320,10 +3322,34 @@ dispatches, which the Calendar surface deliberately excludes (`calendar.ts`
 unions only appointment events, `actionPlugin IS NULL`). It renders one card per
 routine (title, human-readable schedule, next run, channel/destination or tool,
 status); a card opens a detail modal modeled on the calendar `EventDetailModal`.
-The modal edits the prose instruction (`agentPrompt`, agent-dispatch routines
-only) and the schedule via a friendly builder (frequency daily/weekly/monthly,
-day-of-week, day-of-month, time) that falls back to a raw-cron field for patterns
-it cannot represent.
+The modal edits the prose instruction (`agentPrompt`), the dispatch binding
+(`agentChannel` and `agentDestination`, chosen from a server-supplied roster
+rather than typed), and the schedule via a friendly builder (frequency
+daily/weekly/monthly, day-of-week, day-of-month, time) that falls back to a
+raw-cron field for patterns it cannot represent. The binding control appears on
+an agent routine and on a routine with no dispatch at all; a tool-action
+routine's dispatch stays read-only, because an agent binding takes precedence at
+fire time and would stop the tool running.
+
+**The status dot.** The card and the modal each carry a dot ahead of
+the raw status word, so a grid of eight routines can be read without reading
+eight words. `app/routines/types.ts` holds the whole mapping and both surfaces
+render it through one `RoutineStatusDot`, which is what stops them drifting:
+
+| `eventStatus` | dot | meaning |
+|---|---|---|
+| `scheduled`, `due` | green (`--session-live`) | armed, the sweep will fire it |
+| `suspended` | amber (`--color-alias-status-warning-solid`) | stood down, nothing runs until resumed |
+| `cancelled`, `completed` | solid grey (`--text-tertiary`) | deliberately stopped or finished |
+| anything else, and `null` | grey ring, no fill | no reading taken |
+
+The unrecognised case is a state of its own, never a fallback into green: `GET
+/api/admin/routines` projects `eventStatus` verbatim, so a value outside the set
+can reach the card at any time, and a stood-down routine showing green is a
+failure the operator only learns about when the work does not happen. The
+enumerate-every-status test in `app/routines/__tests__/routine-status-dot.test.tsx`
+is the only place the mapping's domain and the writers' status set get compared,
+so a status added to the scheduling plugin without being added here fails there.
 
 The route (`server/routes/admin/routines.ts`) is account-scoped like `calendar.ts`
 (a foreign-account or non-automation `eventId` 404s):
@@ -3332,7 +3358,10 @@ The route (`server/routes/admin/routines.ts`) is account-scoped like `calendar.t
 |-------|-----------|
 | `GET /api/admin/routines` | Lists automation Events: `recurrence IS NOT NULL OR agentChannel IS NOT NULL OR actionPlugin IS NOT NULL`. Keyed by the `eventId` property. |
 | `GET /api/admin/routines/:eventId` | One routine, same automation+account guard. |
-| `PATCH /api/admin/routines/:eventId` | Edits `agentPrompt` and/or `recurrence`. Cron validation and the timezone-aware `nextRun` recompute copy the scheduling plugin's `schedule-update` tool. An invalid cron is rejected 400 with no write. Only creation and deletion stay agent-only (`schedule-event`/`schedule-cancel`). |
+| `GET /api/admin/routines/:eventId/runs` | One routine's `:RoutineRun` history, newest first. `limit` clamps to 1..500 and defaults to 50, so a caller that wants the full page must ask for it. |
+| `GET /api/admin/routines/:eventId/runs.csv` | The same projection as a `text/csv` attachment with `Content-Disposition`, and **no** limit, so it is not the same row set as a clamped `/runs` call. Re-parses its own output and returns 500 rather than serving a document with fewer rows than the query returned. Zero rows is 404, not a header-only file: the query cannot tell a routine with no runs from an `eventId` on another account. |
+| `PATCH /api/admin/routines/:eventId` | Edits `agentPrompt`, `recurrence`, and the `agentChannel`/`agentDestination` pair. Cron validation and the timezone-aware `nextRun` recompute copy the scheduling plugin's `schedule-update` tool. The binding is revalidated against the same house-authority rule, shared as `platform/lib/agent-dispatch-rule`; it is refused `partial-binding`, `invalid-channel`, `no-prompt`, `not-registered`, `cross-account`, `action-routine` (a routine that runs a tool keeps it — an agent binding outranks the action at fire time) or `clear-would-orphan` (clearing the only field holding a one-time routine inside the automation filter would hide it from every routines surface), and no refusal writes. Both fields as `null` clears the binding. An invalid cron is rejected 400 with no write. Only creation and deletion stay agent-only (`schedule-event`/`schedule-cancel`). |
+| `GET /api/admin/dispatch-destinations` | Every destination the session's account may bind a routine to, across both channels, each labelled by the authoritative list it came from (`House admin`, `Account manager`, `Telegram admin`). Computed from the same lists the validator reads and filtered by the same rule, so the picker cannot offer what the save refuses. |
 | `POST /api/admin/routines/:eventId/suspend` | Writes `eventStatus = 'suspended'` on a routine currently `'scheduled'`. 404s otherwise, so a second suspend is not a silent no-op. |
 | `POST /api/admin/routines/:eventId/resume` | Returns a suspended routine to `'scheduled'`. 404s if it is not suspended, 409s if it cannot be resumed. |
 | `POST /api/admin/routines/suspend-all` | Suspends every routine currently `'scheduled'` and marks each one. Returns the count. |
@@ -3388,14 +3417,14 @@ the standing reconciliation: the named buckets are the whole shipped status enum
 plus `suspended`, so they sum to `routines` by construction and `other` above
 zero means a routine carries a status the system does not handle — nothing else
 would say so. `completed` gets its own bucket even though no code path writes it
-today, because `schedule-update` takes `eventStatus` as an unvalidated string and
-one completed routine would otherwise pin `other` above zero forever and kill the
-alarm.
-
-**The shipped roster.** Every account starts with ten routines — `start-of-day`,
-`inbound-check`, `end-of-day`, `appointment-reminder`, `commitment-chase`,
-`calendar-reconcile`, `contact-reconcile`, `crm-reconcile`, `finance-reconcile`,
-`weekly-digest` — seeded `eventStatus:'suspended'` with `nextRun` NULL and no
+today, because it remains part of the shipped enum and one row carrying it would
+otherwise pin `other` above zero forever and kill the alarm.
+
+**The shipped roster.** Every account starts with eleven routines —
+`start-of-day`, `inbound-check`, `end-of-day`, `appointment-reminder`,
+`commitment-chase`, `calendar-reconcile`, `contact-reconcile`, `crm-reconcile`,
+`finance-reconcile`, `channel-link-check`, `weekly-digest` — seeded
+`eventStatus:'suspended'` with `nextRun` NULL and no
 channel or destination, so `/routines` is a catalogue to enable rather than a
 blank page. The list query applies no status filter and `AUTOMATION_WHERE`
 admits them on `recurrence IS NOT NULL`, so they render with no change here.
@@ -3403,11 +3432,15 @@ They cannot fire: every dispatch query in `check-due-events.ts` selects
 `eventStatus = 'scheduled'`, and the recurring one additionally requires
 `nextRun IS NOT NULL`.
 
-Enabling one is `schedule-update {eventId, eventStatus:'scheduled', recurrence,
-timezone}` — all four arguments. `eventStatus` on its own does not touch
-`nextRun`, so the row would read enabled and never fire; omitting `timezone`
-recomputes `nextRun` in the server's zone rather than the operator's, so it
-fires at the wrong hour and still looks healthy. Binding a channel and a
+Enabling one is `schedule-update {eventId, eventStatus:'scheduled', timezone}`.
+The status change arms the row on its own: the resume recomputes `nextRun`
+forward from now in the routine's **stored** `timezone`, so a seeded row with a
+NULL `nextRun` does not need `recurrence` restated to start firing. `timezone` is
+still required on a seeded routine, because the roster seeds none and a resume
+with no stored zone resolves the cron in the server's zone; that row then fires
+at the wrong hour and looks healthy, which is the case the standing
+`[schedule-audit] op=null-timezone` alarm exists to name. Pass `recurrence` only
+to change it. Binding a channel and a
 destination is separate and equally required: `chooseDispatchMode` returns
 `{kind:'none'}` unless `agentChannel`, `agentDestination` and `agentPrompt` are
 all present, and a destination cannot be seeded because

package/payload/platform/plugins/admin/skills/superpowers-sprint/SKILL.md

@@ -11,6 +11,23 @@ A structured workflow for executing development work — features, bug fixes, re
 
 This skill is the maxy-code counterpart to `sprint`. The phase chain is identical in spirit; the difference is the skill at each phase. If both `gstack` and superpowers are installed and the project is set up for it, prefer `sprint` — its plan reviews are richer. Use this skill when `gstack` is not available.
 
+## Execution model: inline only, never subagents
+
+Every phase of this sprint runs in the current session, in the main agent's own context. No phase dispatches a subagent, and no phase delegates work to the Agent tool, `superpowers:subagent-driven-development`, or `superpowers:dispatching-parallel-agents`.
+
+Several of the chained superpowers skills offer or recommend a subagent path. In this sprint, take the inline path at each of them:
+
+| Chained skill | Its subagent offer | What this sprint does |
+|---|---|---|
+| `superpowers:brainstorming` | dispatches a spec document reviewer subagent | review the spec yourself, against the same template |
+| `superpowers:writing-plans` | dispatches a plan document reviewer subagent, and offers "Subagent-Driven (recommended)" as the implementation mode | review the plan yourself; choose the `superpowers:executing-plans` mode, never subagent-driven |
+| `superpowers:executing-plans` | tells you to switch to `superpowers:subagent-driven-development` where subagents exist | ignore that instruction and stay in `executing-plans` |
+| `superpowers:requesting-code-review` | dispatches a `general-purpose` code reviewer subagent | apply the reviewer template to the diff yourself, in this session |
+
+A review done inline still uses the chained skill's reviewer template verbatim — the checklist is what makes the review real, not the isolation. The cost of inline is that the reviewer shares the sprint's context and therefore its assumptions; the operator accepts that in exchange for a single visible transcript.
+
+Dispatching a subagent from any phase is a defect, not an optimisation.
+
 ## Output discipline (applies to every emission in this skill)
 
 Every message the sprint writes — plan summaries, change logs, status tables, the final summary — is written `/plainly`. That means:
@@ -54,18 +71,24 @@ Read the task file or operator brief first, then enter brainstorming with what y
 
 If the operator hands over a fully-formed plan that is already broken into specific files and behaviours, brainstorming can be a fast confirmation rather than an open exploration — but it still runs, because skipping it is the failure mode the phase exists to prevent.
 
+When the skill reaches its spec document review, run that review inline against `spec-document-reviewer-prompt.md`. Do not dispatch the reviewer subagent.
+
 ### Phase 2: Plan — `superpowers:writing-plans`
 
 Invoke `superpowers:writing-plans` against the brainstorm output. The skill produces a single written plan: the files to touch, the behaviours to add or change, the edge cases, the test coverage, the deployment story. This is the artefact Phase 6 (Plan Conformity) checks the implementation against.
 
 This is a deliberate downgrade from `sprint`'s separate CEO and Eng reviews — multi-approach architecture review is out of scope for the superpowers chain. One reviewed plan is the baseline.
 
+Two of the skill's steps offer a subagent; take neither. Review the finished plan inline against `plan-document-reviewer-prompt.md`. When the skill asks which implementation mode to use, choose `superpowers:executing-plans`, never "Subagent-Driven".
+
 Present the final plan to the operator and get explicit confirmation before writing any production code.
 
 ### Phase 3: Implement — `superpowers:executing-plans` + `superpowers:test-driven-development`
 
 Invoke `superpowers:executing-plans` to drive execution against the Phase 2 plan. Within each step, follow `superpowers:test-driven-development` — RED-GREEN-REFACTOR for every behaviour change.
 
+`superpowers:executing-plans` opens by telling you to switch to `superpowers:subagent-driven-development` when subagents are available. Ignore that line; this sprint runs every task inline in the current session.
+
 Tests are ephemeral: design and run them to prove the implementation works during the sprint, then discard them. They are not committed to the repository unless the project's own test suite already lives in the tree and the new behaviour belongs in it. Their purpose is to enforce thinking through behaviour before writing production code, not to build a permanent regression suite.
 
 - **Test first.** Write a failing test for each behaviour before implementing it. Watch it fail. Write minimal code to pass. Refactor.
@@ -94,6 +117,8 @@ If verification fails, return to Phase 3.
 
 Invoke `superpowers:requesting-code-review` to frame the review request. Then run `code-review:code-review` against the sprint's diff. Process the response through `superpowers:receiving-code-review`, which gates whether each finding is accepted, contested, or filed as follow-up.
 
+`superpowers:requesting-code-review` dispatches a `general-purpose` reviewer subagent. Do not dispatch it. Fill its `code-reviewer.md` template with the sprint's context and diff, then work through it inline as the reviewer. `code-review:code-review` likewise runs in this session against the diff, not as a delegated agent.
+
 Findings that are accepted and trivial are fixed before proceeding. Findings that are accepted but out-of-scope for this sprint become new `.tasks/NNN-*.md` files (the same deferral rule as Phase 6 — prose deferrals are banned). Findings that are contested get a one-line rebuttal in the debrief.
 
 ### Phase 6: Land
@@ -355,6 +380,7 @@ Session: <session-id>
 
 ## Principles
 
+- **Inline, always.** Every phase runs in the current session. No subagents, no parallel agent dispatch, no delegated reviewers, whatever the chained skills recommend.
 - **Ship complete.** A sprint is not done until the debrief and the final-status block are delivered. Code without documentation is unfinished work.
 - **Explain the why.** Every change has a reason. "Refactored for clarity" is not a reason. "Extracted to avoid duplicate route derivation across WhatsApp and iMessage" is.
 - **Operator perspective.** Testing instructions are written for the person running the product. If the operator is non-technical, instructions are UI-based.

package/payload/platform/plugins/admin/skills/whats-new/SKILL.md

@@ -9,6 +9,18 @@ Invoked by the admin agent directly.
 
 This is the platform's release timeline, newest first. Each entry shows the date it shipped and the version it shipped in, so you can tell the operator how current their install is. To compare, read the installed version from `capabilities-here` and match it against the versions below. Keep answers high level and in plain English; this is a summary, not a full commit log.
 
+## 2026-07-29 (0.1.525)
+
+- A repeating routine whose start date had already gone by now runs on its next due occurrence instead of sitting silent forever. There is also a standing check that tells you when a routine has a start date that never fired.
+- Saving a memory no longer rewrites the date and time on a meeting into plain text, so meeting times stay comparable and sortable afterwards.
+- Internal engineering documents are no longer included in what gets installed on a customer device, and the check that scans installed text now reads exactly what ships rather than an out-of-date copy of the list.
+
+## 2026-07-29 (0.1.524)
+
+- Routines are properly editable now. You can pick where a routine sends its result from the routine window, which previously could not be set at all, so the routines that ship with the platform were impossible to make work from the dashboard. Stopping a routine from chat also no longer means cancelling it outright.
+- The dashboard cards have been redesigned to match the rest of the product.
+- When the assistant cannot see one of your mailboxes, it now says which mailbox and why, instead of telling you that no mailbox is connected at all. Shared and delegated mailboxes are reachable again.
+
 ## 2026-07-29 (0.1.523)
 
 - You can now switch off an agent you created yourself. Until now that was refused, while switching off a built-in agent was offered instead, which was the wrong way round. You can also suspend a routine, or all of them at once, without deleting it.

package/payload/platform/plugins/docs/references/admin-ui.md

@@ -97,10 +97,34 @@ dispatches, which the Calendar surface deliberately excludes (`calendar.ts`
 unions only appointment events, `actionPlugin IS NULL`). It renders one card per
 routine (title, human-readable schedule, next run, channel/destination or tool,
 status); a card opens a detail modal modeled on the calendar `EventDetailModal`.
-The modal edits the prose instruction (`agentPrompt`, agent-dispatch routines
-only) and the schedule via a friendly builder (frequency daily/weekly/monthly,
-day-of-week, day-of-month, time) that falls back to a raw-cron field for patterns
-it cannot represent.
+The modal edits the prose instruction (`agentPrompt`), the dispatch binding
+(`agentChannel` and `agentDestination`, chosen from a server-supplied roster
+rather than typed), and the schedule via a friendly builder (frequency
+daily/weekly/monthly, day-of-week, day-of-month, time) that falls back to a
+raw-cron field for patterns it cannot represent. The binding control appears on
+an agent routine and on a routine with no dispatch at all; a tool-action
+routine's dispatch stays read-only, because an agent binding takes precedence at
+fire time and would stop the tool running.
+
+**The status dot.** The card and the modal each carry a dot ahead of
+the raw status word, so a grid of eight routines can be read without reading
+eight words. `app/routines/types.ts` holds the whole mapping and both surfaces
+render it through one `RoutineStatusDot`, which is what stops them drifting:
+
+| `eventStatus` | dot | meaning |
+|---|---|---|
+| `scheduled`, `due` | green (`--session-live`) | armed, the sweep will fire it |
+| `suspended` | amber (`--color-alias-status-warning-solid`) | stood down, nothing runs until resumed |
+| `cancelled`, `completed` | solid grey (`--text-tertiary`) | deliberately stopped or finished |
+| anything else, and `null` | grey ring, no fill | no reading taken |
+
+The unrecognised case is a state of its own, never a fallback into green: `GET
+/api/admin/routines` projects `eventStatus` verbatim, so a value outside the set
+can reach the card at any time, and a stood-down routine showing green is a
+failure the operator only learns about when the work does not happen. The
+enumerate-every-status test in `app/routines/__tests__/routine-status-dot.test.tsx`
+is the only place the mapping's domain and the writers' status set get compared,
+so a status added to the scheduling plugin without being added here fails there.
 
 The route (`server/routes/admin/routines.ts`) is account-scoped like `calendar.ts`
 (a foreign-account or non-automation `eventId` 404s):
@@ -109,7 +133,10 @@ The route (`server/routes/admin/routines.ts`) is account-scoped like `calendar.t
 |-------|-----------|
 | `GET /api/admin/routines` | Lists automation Events: `recurrence IS NOT NULL OR agentChannel IS NOT NULL OR actionPlugin IS NOT NULL`. Keyed by the `eventId` property. |
 | `GET /api/admin/routines/:eventId` | One routine, same automation+account guard. |
-| `PATCH /api/admin/routines/:eventId` | Edits `agentPrompt` and/or `recurrence`. Cron validation and the timezone-aware `nextRun` recompute copy the scheduling plugin's `schedule-update` tool. An invalid cron is rejected 400 with no write. Only creation and deletion stay agent-only (`schedule-event`/`schedule-cancel`). |
+| `GET /api/admin/routines/:eventId/runs` | One routine's `:RoutineRun` history, newest first. `limit` clamps to 1..500 and defaults to 50, so a caller that wants the full page must ask for it. |
+| `GET /api/admin/routines/:eventId/runs.csv` | The same projection as a `text/csv` attachment with `Content-Disposition`, and **no** limit, so it is not the same row set as a clamped `/runs` call. Re-parses its own output and returns 500 rather than serving a document with fewer rows than the query returned. Zero rows is 404, not a header-only file: the query cannot tell a routine with no runs from an `eventId` on another account. |
+| `PATCH /api/admin/routines/:eventId` | Edits `agentPrompt`, `recurrence`, and the `agentChannel`/`agentDestination` pair. Cron validation and the timezone-aware `nextRun` recompute copy the scheduling plugin's `schedule-update` tool. The binding is revalidated against the same house-authority rule, shared as `platform/lib/agent-dispatch-rule`; it is refused `partial-binding`, `invalid-channel`, `no-prompt`, `not-registered`, `cross-account`, `action-routine` (a routine that runs a tool keeps it — an agent binding outranks the action at fire time) or `clear-would-orphan` (clearing the only field holding a one-time routine inside the automation filter would hide it from every routines surface), and no refusal writes. Both fields as `null` clears the binding. An invalid cron is rejected 400 with no write. Only creation and deletion stay agent-only (`schedule-event`/`schedule-cancel`). |
+| `GET /api/admin/dispatch-destinations` | Every destination the session's account may bind a routine to, across both channels, each labelled by the authoritative list it came from (`House admin`, `Account manager`, `Telegram admin`). Computed from the same lists the validator reads and filtered by the same rule, so the picker cannot offer what the save refuses. |
 | `POST /api/admin/routines/:eventId/suspend` | Writes `eventStatus = 'suspended'` on a routine currently `'scheduled'`. 404s otherwise, so a second suspend is not a silent no-op. |
 | `POST /api/admin/routines/:eventId/resume` | Returns a suspended routine to `'scheduled'`. 404s if it is not suspended, 409s if it cannot be resumed. |
 | `POST /api/admin/routines/suspend-all` | Suspends every routine currently `'scheduled'` and marks each one. Returns the count. |
@@ -165,14 +192,14 @@ the standing reconciliation: the named buckets are the whole shipped status enum
 plus `suspended`, so they sum to `routines` by construction and `other` above
 zero means a routine carries a status the system does not handle — nothing else
 would say so. `completed` gets its own bucket even though no code path writes it
-today, because `schedule-update` takes `eventStatus` as an unvalidated string and
-one completed routine would otherwise pin `other` above zero forever and kill the
-alarm.
-
-**The shipped roster.** Every account starts with ten routines — `start-of-day`,
-`inbound-check`, `end-of-day`, `appointment-reminder`, `commitment-chase`,
-`calendar-reconcile`, `contact-reconcile`, `crm-reconcile`, `finance-reconcile`,
-`weekly-digest` — seeded `eventStatus:'suspended'` with `nextRun` NULL and no
+today, because it remains part of the shipped enum and one row carrying it would
+otherwise pin `other` above zero forever and kill the alarm.
+
+**The shipped roster.** Every account starts with eleven routines —
+`start-of-day`, `inbound-check`, `end-of-day`, `appointment-reminder`,
+`commitment-chase`, `calendar-reconcile`, `contact-reconcile`, `crm-reconcile`,
+`finance-reconcile`, `channel-link-check`, `weekly-digest` — seeded
+`eventStatus:'suspended'` with `nextRun` NULL and no
 channel or destination, so `/routines` is a catalogue to enable rather than a
 blank page. The list query applies no status filter and `AUTOMATION_WHERE`
 admits them on `recurrence IS NOT NULL`, so they render with no change here.
@@ -180,11 +207,15 @@ They cannot fire: every dispatch query in `check-due-events.ts` selects
 `eventStatus = 'scheduled'`, and the recurring one additionally requires
 `nextRun IS NOT NULL`.
 
-Enabling one is `schedule-update {eventId, eventStatus:'scheduled', recurrence,
-timezone}` — all four arguments. `eventStatus` on its own does not touch
-`nextRun`, so the row would read enabled and never fire; omitting `timezone`
-recomputes `nextRun` in the server's zone rather than the operator's, so it
-fires at the wrong hour and still looks healthy. Binding a channel and a
+Enabling one is `schedule-update {eventId, eventStatus:'scheduled', timezone}`.
+The status change arms the row on its own: the resume recomputes `nextRun`
+forward from now in the routine's **stored** `timezone`, so a seeded row with a
+NULL `nextRun` does not need `recurrence` restated to start firing. `timezone` is
+still required on a seeded routine, because the roster seeds none and a resume
+with no stored zone resolves the cron in the server's zone; that row then fires
+at the wrong hour and looks healthy, which is the case the standing
+`[schedule-audit] op=null-timezone` alarm exists to name. Pass `recurrence` only
+to change it. Binding a channel and a
 destination is separate and equally required: `chooseDispatchMode` returns
 `{kind:'none'}` unless `agentChannel`, `agentDestination` and `agentPrompt` are
 all present, and a destination cannot be seeded because

package/payload/platform/plugins/docs/references/workflows.md

@@ -50,11 +50,13 @@ Tell {{productName}} naturally:
 
 - "List my workflows."
 - "Show me the follow-up workflow."
-- "Pause the new-lead workflow." or "Turn the new-lead workflow back on."
+- "Stop running the new-lead workflow." or "Start running the new-lead workflow again."
 - "Change the follow-up workflow so it also messages me."
 - "Delete the old onboarding workflow."
 
-Pausing keeps a workflow but stops it running. Editing replaces the steps or the inputs with the new version you describe. Deleting removes the workflow and its run history, so {{productName}} confirms with you first.
+Stopping a workflow keeps it but stops it running. Editing replaces the steps or the inputs with the new version you describe. Deleting removes the workflow and its run history, so {{productName}} confirms with you first.
+
+A workflow is not a routine. "Pause the morning routine" is about a scheduled trigger, not about a workflow, so say routine when you mean the scheduled thing and {{productName}} will reach for the right one.
 
 ## Scheduling a Workflow