@murphai/murph 1.3.0 → 1.3.2

package/node_modules/@murphai/assistant-engine/skills/automatic-meal-capture/SKILL.md

@@ -132,15 +132,44 @@ When enriching a captured meal:
    estimates. For mixed evidence, describe both and set confidence from the
    weakest material assumption. Preserve the meal's occurred-at time and
    source. Keep the photo until saved structure has been read back.
-6. Read the edited meal back before claiming it was logged.
+6. If the edit fails or the read-back does not prove the intended structure,
+   run one fresh bounded meal list for the capture date, re-identify the exact
+   photo-backed device meal from its returned id, source, occurred-at time, and
+   attachment, inspect it, and retry `meal edit` once with corrected arguments.
+   Never switch to `meal add`, guess a nearby record, or retry past that one
+   correction. If the retry or its read-back fails, keep the photo and report or
+   fail the unresolved work instead of claiming enrichment.
+7. Read the edited meal back before claiming it was logged.
 
 Do not run `meal add` for a captured photo that already has a meal id. The
 automatic import is the meal log; `meal edit` adds the useful structure. By
 default, save a bounded photo estimate without asking for confirmation on every
-meal, but the estimate must retain provenance and uncertainty. If the photo
-cannot support a meaningful estimate, leave the photo-only meal intact and ask
-one narrow portion or identity question only when the member is present and the
-answer would materially help.
+meal. Retain provenance, uncertainty, and assumptions; a visible food or drink
+category with a defensible portion range is enough even when the exact recipe,
+ingredients, or serving is uncertain. If the photo cannot support a meaningful
+numeric estimate, do not leave a model-reviewed capture blank. When its note is
+empty, save a concise `--note` describing only the visible meal or food form and
+material uncertainty; never replace a member-written note. Add `--ingredient`
+values only for identities the photo supports. If even a broad food observation
+is not defensible and the note is empty, record only that the retained image was
+reviewed and the meal could not be identified. Read the preserved or new
+observation back. Clarification is a last resort, not a confidence check: ask
+one narrow identity or portion question only when actual attachment inspection
+leaves identity or amount too indeterminate for any meaningful bounded estimate
+and the answer would materially help.
+
+A recent device meal remains unresolved after its attachment becomes a privacy
+tombstone when its saved identity, amount or ingredients, and nutrition cannot
+support the member's current request. When the member answers a capture question
+or asks for totals or a card that meal blocks, match the existing meal from the
+current conversation, device source, capture date, and capture time with bounded
+`meal list` and `meal show` reads; never add a replacement or restore the photo.
+Apply the estimation-eligibility rule above before recovery. When estimation is
+skipped, do not ask for identity or amount merely to enable nutrition estimates.
+Otherwise, ask instead of refusing or inventing totals only when the saved facts
+still fail that last-resort threshold. With enough facts, edit and read back the
+existing meal, then use fresh food-journal totals and any eligible card. Never
+calculate around it or reuse pre-edit totals.
 
 Do not surface calorie numbers for intuitive-eating contexts, eating-disorder
 risk, or number-sensitive members.
@@ -168,17 +197,156 @@ On a scheduled run:
 4. Run `vault-cli meal show <meal-id> --format json` for each selected meal and
    inspect the actual attachment for a photo-backed selection. For
    same-occurrence retry evidence, use only the already-saved structured fields
-   and uncertainty. Enrich the existing meal when supported and read it back.
-5. Run `vault-cli meal remove-photo <meal-id>` and read the meal back again.
+   and uncertainty. Enrich the existing meal when supported, apply the bounded
+   re-identification and single-retry rule above after a failed edit, and read
+   the result back. When numeric nutrition is unsupported, save and read back
+   the evidence-based observation fallback above. A meal with neither saved
+   nutrition nor that observation is not ready for cleanup.
+5. Only after the read-back proves saved nutrition or the observation fallback,
+   run `vault-cli meal remove-photo <meal-id>` and read the meal back again.
    This automatic-capture-only command preserves the structured meal and
    replaces retained image bytes with a privacy tombstone. Any removal failure
    fails the run. On retry, combine photos that remain with same-occurrence
    removal revisions so a provider or partial-cleanup failure loses no meal.
-6. Send one compact closeout covering the selected dates. Include supported
-   calorie and macro totals by default; label partial totals as partial. Never
-   surface numbers in intuitive-eating, eating-disorder-risk, or number-sensitive
-   context, and never attach the photos. Suppress the message only when neither
-   a retained photo nor a same-occurrence removal revision is selected.
+
+Before step 6, apply the estimation-eligibility rule above. When estimation is
+skipped, complete photo cleanup and stop with the established non-numeric
+closeout: ask no estimate-enabling question and run no Goal, totals, or card
+work. Otherwise, after cleaning each capture that still fails the last-resort
+threshold, send one compact question for only those meals and stop before Goal,
+totals, or card work. Use local time when all share the occurrence date; include
+date and time for any historical or multi-date set. Ask only for missing identity
+and amount, expose no meal ids, and do not substitute ordinary closeout or a
+dashboard refusal. This is the sole scheduled-question exception; its answer
+uses the existing-meal recovery above.
+
+6. After inspection, enrichment, read-back, and photo cleanup, first prove the
+   cheap read-only active Goal discovery is complete. Run `vault-cli goal list --status active
+   --limit 200 --format json`. If it returns 200 records, fail closed with the
+   ordinary compact closeout: run no Goal detail reads, perform no Goal or
+   measurement mutation, ask no question, and attach no card. Otherwise, run
+   `vault-cli goal show <goal-id> --format json` for every returned active Goal
+   whose list item reports a nonzero `data.metricTargetsCount`. Do not select
+   detail reads by title, slug, domain, context-snapshot visibility, or the
+   default list prefix. Resolve metric identity, unit, comparator, effective
+   date, conflicts, and the 1,200-kcal boundary only after inspecting that
+   complete detail set. This active-target authority read is separate from any
+   all-status Goal lookup used to reuse or honor Murph's managed paused or
+   abandoned proposal; never substitute that lookup here. If active authority
+   is ambiguous, unit-incompatible, comparator-incompatible, or otherwise
+   cannot support either a card or responsible proposal, keep the ordinary
+   compact closeout without the unrelated safety fanout. Only when compatible
+   authority is incomplete after those reads does the first eligible managed
+   closeout have one proposal-only exception. Read and follow
+   `$MURPH_ASSISTANT_SKILLS_ROOT/nutrition-strategy/references/daily-nutrition-card-goals.md`,
+   then run `vault-cli goal list --limit 200 --format json` and detail-read only
+   candidate managed records. If that read fails, is unreadable, is saturated,
+   or finds any Goal with slug `murph-daily-nutrition-starting-targets` in any
+   status, do not create, change, or automatically repeat a numeric proposal.
+   Keep the ordinary compact closeout and attach no card. The absence of that
+   managed Goal is the first-run authority; add no flag or second state owner.
+   If responsible inputs are missing or the bundle is infeasible, write nothing
+   and keep the ordinary closeout. When either one complete accepted card bundle
+   or this responsible first-run proposal candidate remains, apply the concise
+   known-context numeric-suitability rule in the
+   `murph.attach_response_card` prompt before deriving or presenting numeric
+   values, any Goal write, totals, or a card. Do not run a universal medical
+   history or measurement checklist. When known context suppresses numeric
+   output or suitability remains unresolved, keep the ordinary compact closeout,
+   perform no Goal or measurement mutation, ask no question, and attach no card.
+   When the complete all-status
+   lookup proves absence, known context permits numeric guidance, compatible
+   explicit targets are unambiguous,
+   and already-known inputs prove one responsible five-target bundle, create
+   that single canonical Goal as
+   `paused`, with `window.startAt` equal to the selected capture/card local date.
+   Read it back, then explain all five provisional values, their material facts
+   and assumptions, and the effective date in ordinary text. Ask no question,
+   attach no card, and never activate it on the scheduled turn. Member
+   correction, acceptance, or decline remains an
+   interactive turn. If numeric presentation is suppressed, or the active
+   target bundle is ambiguous, unit-incompatible, or comparator-incompatible,
+   retain the ordinary compact closeout and do not attach a card. Keep the occurrence
+   local date from step 1 only as the work and retry boundary. Resolve target
+   applicability against the single selected card `localDate`: the capture date
+   whose totals and card are being closed out, including a historical catch-up
+   date. A target
+   qualifies only when that card date is on or after the containing Goal's
+   `window.startAt`, on or before its optional `window.targetAt`, and inside the
+   target's optional inclusive `startAt`/`targetAt` interval. Ignore an
+   out-of-window target for current authority and conflict resolution; never
+   copy, expose, derive from, or mutate a Goal because of it. If fewer than five
+   applicable targets remain, ask no question and use ordinary closeout text.
+   New authoring uses `dietary-calories`. Resolve that canonical owner first;
+   when it exists, use it and ignore every globally ambiguous `calories`
+   target. Only without a canonical owner may an applicable exact-point
+   `calories` target in `kcal` fill the card's calorie slot when its
+   `targetId` is `daily-calories`. Its same containing Goal must own exactly one
+   applicable compatible point for every historical id, metric, and unit pair:
+   `daily-protein` / `protein-grams` / `g`, `daily-carbohydrates` /
+   `carbs-grams` / `g`, `daily-fat` / `fat-grams` / `g`, and `daily-fiber` /
+   `fiber-grams` / `g`. Require one complete historical set. Any other
+   `calories` target is not dietary authority even when the four nutrition
+   metrics share its Goal; never combine the historical set with another Goal
+   or managed proposal. Never infer ownership from a title, slug, domain, or
+   description, and never rename or mutate a Goal just to repair this key.
+   A target in another unit remains authoritative, but never compare, convert,
+   or copy its raw value into this fixed-unit card; on a scheduled occurrence,
+   ask no question and use ordinary closeout text. Never infer a target from
+   this day's meal total or one wearable day. A card-qualifying target must also
+   be an exact point with comparator `between` and identical numeric `value` and
+   `highValue`. Accept `selected-value` evaluation normally. The complete
+   same-Goal historical `daily-*` set above may instead use the read-only
+   rolling-mean plus daily-aggregate-mean display compatibility in the shared
+   daily-card reference; preserve the Goal and do not extend that exception. A
+   mixed evaluation bundle or another rolling-window or daily-aggregate
+   statistic is incompatible. A one-sided `<`, `<=`, `>`, or `>=` threshold,
+   non-identical range, or other shape remains authoritative but is incompatible
+   with this point-target card.
+   Never expose, compare, copy, or derive from its bound, and never create,
+   replace, or remove a managed target around it. On a scheduled occurrence,
+   ask no question, perform no Goal or measurement mutation, and use ordinary
+   closeout text without a card.
+7. Only when the complete target-authority read in step 6 resolves one
+   unambiguous card-authorizing bundle, run the exact canonical
+   `vault-cli meal totals --from <date> --to <date>` read for the selected date
+   range immediately before any response-card attachment; do not reuse an
+   earlier total or calculate nutrition independently. On an interactive card
+   request, apply food-journal's selected-date incomplete-meal recovery to
+   every saved meal whose nutrition coverage blocks the card, including a
+   manual, conversation, provider, or device meal not selected by this
+   closeout. Do not widen the scheduled-question exception above: a scheduled
+   run follows its existing compact closeout when an unselected meal remains
+   incomplete. When the run covers
+   exactly one local date, the canonical read includes a calorie total, and
+   the card-time safety gate from step 6 still passes, call
+   `murph.attach_response_card` with this exact mapping:
+   `card: { kind: "daily_nutrition", version: 2, localDate: <the single
+   selected date>, mealCount: <top-level mealCount>, totals: { calories,
+   proteinGrams, carbsGrams, fatGrams, fiberGrams }, goals: { calories,
+   proteinGrams, carbsGrams, fatGrams, fiberGrams } }`. Copy every metric's
+   complete `{ total, mealCount }` pair unchanged from the canonical read,
+   including `fiberGrams`. Each goal entry is
+   `{ target: <exact canonical daily target>, status: <assessment> }`. Never
+   translate a threshold or range comparator into this point-target payload.
+   The assessment must be one of `far_under_target`, `under_target`, `on_target`,
+   `over_target`, `far_over_target`, or `unavailable`. A metric whose total is
+   missing or whose `mealCount` is below the top-level `mealCount` must use
+   `unavailable`; do not color an incomplete total as under, on, or over target.
+   Use the member's explicit tolerance or intensity when present. Otherwise
+   make a forgiving, context-aware assessment: broadly aligned is `on_target`,
+   a modest miss is `under_target` or `over_target`, and only a clearly material
+   miss is `far_under_target` or `far_over_target`. There is no universal
+   percentage threshold. After the tool succeeds, return a `send_message`
+   decision without repeating nutrition values in its text; the runtime
+   replaces that text with the deterministic closeout derived from the card.
+   Do not author a second nutrition summary. The runtime labels partial totals
+   as partial and identifies missing or under-supported nutrition honestly. For
+   multi-date catch-up, missing calories, an incomplete or conflicting active
+   target bundle, or numerical suppression, retain the current compact text,
+   one-question, or non-numeric behavior and do not attach a card. Never attach
+   the photos. Suppress the message only when neither a retained photo nor a
+   same-occurrence removal revision is selected.
 
 ## Handle edge cases
 

package/node_modules/@murphai/assistant-engine/skills/behavior-followthrough/SKILL.md

@@ -108,7 +108,7 @@ going,” “continue,” or another reply that only advances an intake or setup
 - Prefer one concrete default the user can edit over a menu of options.
 - Formal tone is not quiet support. Useful reminders and the text celebration still deliver.
 - Do not increase reminder frequency after non-response.
-- Do not repeat stale reminder copy.
+- Reuse a good concise reminder cue when context has not changed; do not force novelty.
 - Use social, visual, or voice support only when the medium adds something useful.
 - Protect privacy in shared channels. Do not expose sensitive health details, private struggles, or inferred psychology in group chats unless the user explicitly asked and the content is safe.
 - Do not store sensitive psychological interpretations as facts. Save durable preferences or concrete support details only when useful and clearly grounded.
@@ -372,107 +372,150 @@ Memory is for durable user preferences or broad context, not the source of truth
 
 When the user asks about a current plan, today's target, a ramp, routine, or habit, read the relevant active goal/regimen/automation records before reconstructing details. A compact snapshot or truncated regimen list is navigation only: read the full current regimen note and any linked records before advising, repairing, or closing the plan. If the baseline, ladder, or target date was not saved, say what is missing and update the plan once confirmed instead of inventing it.
 
-When creating automations, make instructions context-aware. A future notification turn may not read this skill, so include the compact support loop directly in the automation instructions.
+A clarification that only names the current target authorizes only the current completion write, and only when the existing canonical records already resolve one owner and one per-occurrence standard. It does not authorize editing a regimen, experiment, automation, or plan. Repair saved plan state only when the user explicitly asks for that repair or affirmatively accepts a concrete proposed repair. After an authorized repair, re-read the changed canonical plan before logging any completion. If no existing owner or standard can be recovered, explain that the completion cannot yet be logged canonically, ask whether the user wants to repair the plan, and write no completion.
 
-Automation instructions may duplicate the compact support loop so scheduled turns have local context, but the habit regimen remains the source of truth.
+In a group conversation, do not perform the private routine lookup or write a private completion. Acknowledge briefly and ask the speaker to continue in their private Murph conversation.
 
-Every automation owned by a non-experiment habit plan must set `supportSeriesId: "habit:<regimenId>"` and persist the exact accepted purpose as `supportKind: "reminder"`, `"check_in"`, or `"review"` when the automation is saved or patched, where `<regimenId>` is the canonical habit-regimen id. The active canonical automation is the exact persisted support-consent record for that purpose; pausing or archiving it withdraws scheduled delivery. Never pass a raw `system:support-series:*` tag; `tags` are only for ordinary descriptive values. Keep the support-series id stable, and do not key lifecycle cleanup only by a mutable slug, title, or reminder text.
+When creating automations, keep their instructions to the durable user request
+and request-specific context. The scheduled runtime owns generic recurring
+reminder cadence, including how it reacts to a prior delivered reminder and
+later conversation while the immediately prior confirmed output remains inside
+the existing evidence horizon. A longer cadence or unusual delay sends normally
+when that evidence has expired instead of guessing silence. Do not copy that
+execution policy into every automation. The habit regimen remains the source of
+truth for the plan.
 
-Support kind also bounds the user-facing message shape. `reminder` authorizes a cue or skip, never a proactive repair/accountability question. `check_in` authorizes one narrow current-state or repair question. `review` authorizes the bounded review and next-decision question. Put that exact authorized shape in the automation instructions; do not let a scheduled turn widen consent because the generic notification policy can generate questions.
+Every automation owned by a non-experiment habit plan must set `supportSeriesId: "habit:<regimenId>"` and persist the exact accepted purpose as `supportKind: "reminder"`, `"check_in"`, or `"review"` when the automation is saved or patched, where `<regimenId>` is the canonical habit-regimen id. The active canonical automation is the exact persisted support-consent record for that purpose; pausing or archiving it withdraws scheduled delivery. Never pass a raw `system:support-series:*` tag; `tags` are only for ordinary descriptive values. Keep the support-series id stable, and do not key lifecycle cleanup only by a mutable slug, title, or reminder text.
 
-Keep the habit support series finite. Prefer bounded one-shot automations. If the user explicitly accepts a recurring automation, set `activeUntil: "<ISO timestamp>"` no later than the accepted review or support-window end; do not create an evergreen recurrence.
+Support kind also bounds the user-facing message shape. `reminder` authorizes a
+cue or skip. Its only question exception is runtime-owned cadence
+administration: after one delivered recurring cue whose confirmed output is
+still available receives no relevant reply, Murph may ask once whether to keep,
+change, or pause the interruption. It does not authorize a completion, repair,
+accountability, or reflection question. This cadence exception is limited to
+ordinary non-clinical reminders.
+Medication, prescribed treatment, clinician-directed care, clinical monitoring,
+and safety-critical reminders continue the saved cue after silence; only the
+user's explicit change or pause or an existing authoritative skip condition may
+stop them.
+`check_in` authorizes one narrow current-state or repair question. `review`
+authorizes the bounded review and next-decision question. Put only the
+request-specific authorized shape in the automation instructions; generic
+recurrence policy stays with the runtime.
+
+These attended follow-up rules apply only in a private member conversation or
+to support that is explicitly room-owned under current room authority.
+Never use a group participant's message to read or mutate that participant's
+private automation, memory, preference, plan, goal, or health context. Move
+personal support changes to a private conversation; in a group, act only on
+room-owned support within the room's current authority.
+
+When Murph proposes one exact finite support package in an attended
+conversation, that proposal remains the authorization boundary for a later
+reply. A clear yes authorizes only the named plan and support writes; apply
+them in that attended turn without a second confirmation. If the user edits
+the package, use only the edited scope. An ambiguous reply does not authorize
+writes.
+
+Natural requests to stop asking about a topic, ask less, pause check-ins, or
+stop reminders are action requests. Read current matching support first, then
+pause or archive the narrowest matching automation while
+preserving unrelated support. When no matching active automation exists, or
+the request covers future offers, save the exact topic-specific no-proactive-support boundary
+through the canonical memory or preference surface. Confirm the exact change
+and clear only that boundary after the user explicitly reopens the topic.
+
+Keep Murph-designed habit support finite and prefer bounded one-shot
+automations. When the user explicitly requests an ongoing recurring cue, it
+may omit `activeUntil`; for an ordinary non-clinical reminder, the runtime's
+quiet-after-silence behavior and the user's pause, change, and stop controls
+remain its off-ramp. Do not add a finite check-in or review lifecycle merely
+because the reminder recurs. Never use silence to stop clinical or
+safety-critical support.
 
 When support is replaced or repaired, keep only the intended active automation ids through the current shared automation action surface: in a hosted turn use `murph.automation` action `reconcile` with `supportSeriesId: "habit:<regimenId>"` and exact `desiredAutomationIds`; use `vault-cli automation reconcile-support-series` only in a privileged local route. Use the read-only `vault-cli automation list --support-series-id habit:<regimenId>` when the plan does not already store the ids needed to reconcile safely. Never infer membership from text or a title.
 
-Automation instructions should include:
-- target behavior
-- standard/tiny/fallback versions
-- anchor or likely action window
-- support style and privacy boundary
-- whether this occurrence is a cue-only reminder or an explicitly authorized accountability check-in
-- skip conditions
-- repair-after policy
-- review point
-- for an accountability check-in, the action window, completion evidence to inspect, expected data freshness, and complete/already-reported/unknown behavior
-- whether visual or voice support is welcome, what it should add, and any shared-channel permission
+Ordinary recurring reminder instructions should include only:
+- the concise cue or durable target
+- request-specific context, tone, and privacy boundary
+- one exact availability line: `Availability conflict policy: fixed` or `Availability conflict policy: skip-when-busy`
+- any request-specific authoritative safety or skip condition
+- whether visual or voice support is welcome and what it should add
+
+For Murph-designed habit support or an explicitly consented `check_in` or
+`review`, also include the request-specific standard/tiny/fallback versions,
+anchor or action window, authorized support shape, skip conditions,
+repair-after policy, review point, and shared-channel permission. For an
+accountability check-in, include the completion evidence to inspect, expected
+data freshness, and complete/already-reported/unknown behavior. Never copy
+these generic repair or review requirements into an ordinary recurring
+reminder.
+
+Use `Availability conflict policy: fixed` by default and always for an exact
+user-directed time, medication or clinician-directed support, safety-critical
+support, or any automation without explicit calendar-aware-delivery consent.
+Use `skip-when-busy` only after the user explicitly accepts calendar-aware
+delivery for this support or grants a durable general preference. Calendar
+connection alone is not consent. Before changing the policy, list configured
+Google Calendar and Outlook accounts. With none, keep the reminder fixed and
+offer the connection step. With more than one, keep it fixed until the user
+chooses one. A `skip-when-busy` automation must include exactly one source
+line, `Availability source policy: calendar-only`, plus one exact account line,
+`Availability calendar account: <toolkit> / <account-id>`, using the selected
+account's returned stable id. After saving, explain that Murph will refresh the
+policy in the background, usually within a day, and that the reminder sends
+normally until one succeeds. A successful refresh is a short evidence lease
+for occurrences scheduled within 24 hours. Disconnecting the calendar stops
+future refreshes but can take up to one day to stop skips from that lease.
 
 Automation instructions should not include:
-- fixed copy to repeat every time
 - guilt or pressure
 - a long read list
 - sensitive details for shared channels
 - instructions to nag harder after non-response
 
-Prefer bounded support. Never create open-ended nag loops. If the user wants ongoing support, agree on a finite window and review point; continuing beyond that window requires fresh consent.
-
-### Reminder density and reply loop
-
-For private personal support, prefer one useful interruption over several. When
-the current request or recent conversation reveals same-purpose reminders in
-one practical action window, offer one combined interruption before saving.
-Do not silently alter requested timing. Keep them separate when exact timing
-changes the action or the user prefers separate messages.
-
-Treat a cadence as dense when it would interrupt the person several times in
-one day or every few hours and a reply could usefully resolve the preceding
-action. This is a judgment, not a fixed interval threshold. Do not apply this
-reply loop to one-time or low-frequency informational reminders, passive
-monitoring, group-wide prompts that should not depend on one participant, or
-clinical or safety-critical reminders.
-
-Do not save a dense personal action cadence as an evergreen cue-only
-`reminder`. Offer a finite `check_in` with `continuityPolicy: preserve`, an
-`activeUntil` review boundary, and one clear conversational expectation. In
-the setup offer, explain naturally that Murph will ask how the previous round
-went when the next one arrives and the user can answer however they normally
-would. Never prescribe keywords, status syntax, or a menu of canned replies.
-If one occurrence is unresolved, the next message asks about it and includes
-the current action; if that combined grace message also gets no related reply,
-later dense occurrences stay quiet until the user re-engages, changes, or
-restarts the loop. A separately authorized bounded review may still ask once
-whether to change or pause the support; it does not restart the dense cadence
-without a reply. A clear yes to that exact package authorizes it.
-
-Put the execution rule in the automation instructions because a scheduled turn
-may not reload this skill:
-
-- Inspect the recent relevant conversation and reliable completion evidence.
-- If the immediately preceding occurrence is resolved, do not ask about it;
-  send only the current occurrence's cue or check-in.
-- The current action window may still be opening. Ask an outcome question only
-  about the immediately preceding occurrence whose action window has ended.
-- If it is unresolved and the preceding scheduled message was not already a
-  carry-forward grace, lead with one short, ordinary question about that
-  occurrence and include the current action in the same message. Write it as
-  conversation, not a status interface; never ask for a prescribed keyword.
-- Keep internal terms out of user-facing copy: do not say occurrence,
-  unresolved, grace, status, or `check_in`. Ask about the last round in normal
-  language, then name what is due now.
-- If the preceding scheduled message already combined an unresolved prior
-  occurrence with the then-current action and no related reply followed,
-  return `skip`. Do not send a separate pause warning.
-- Only a confirmed delivery failure that proves the message was not accepted
-  or sent preserves the grace occurrence. Provider acceptance or `sent`
-  dispatch consumes it even when the channel provides no handset receipt; an
-  ambiguous post-dispatch failure also consumes it to avoid duplicate nags.
-  Silence still is not evidence of a miss, ignore, or refusal.
-- Carry forward at most the immediately preceding occurrence. Never mention
-  older unresolved occurrences, count them as debt, or send a separate
-  catch-up message.
-
-The carry-forward is a new scheduled occurrence, not a second follow-up for the
-same occurrence. A related reply may use any natural wording that answers,
-defers, declines, changes, pauses, or ends this support loop; unrelated
-conversation does not keep it alive. Backing off protects the conversation
-cadence and is not evidence that the behavior was missed.
+Prefer bounded support, and never increase frequency or add messages after
+non-response. An explicitly requested ongoing reminder may stay active. For
+normal daily and weekly reminders, the resident runtime asks once whether to
+keep, change, or pause after a delivered cue receives no relevant reply, then
+stays quiet if that question is also unanswered. A longer or unusually delayed
+cadence sends normally after its prior confirmed-output evidence expires.
+
+### Repair a mistimed interruption
+
+When the user replies to recent proactive support with a concrete reason the
+moment is unavailable or inappropriate—such as a meeting, flight, driving,
+sleep, illness, work, or a social obligation—treat it as feedback about the
+support loop, not as a miss or a motivation problem.
+
+- Briefly own the mistiming before answering an adjacent literal question.
+- Resolve the current occurrence. Do not push the standard or tiny version when
+  the context itself makes the action inappropriate, and do not carry it as
+  reminder debt.
+- A one-off conflict changes only this occurrence. A stated bounded period may
+  justify a bounded pause. A recurring conflict repairs the anchor, schedule,
+  or support instructions.
+- If the owning support can be repaired under current authorization, do that
+  before discussing optional integrations. Claim a change only after the
+  canonical tool result proves it.
+- If calendar-aware delivery would prevent recurrence and is not connected or
+  authorized, offer that one specific improvement after handling the current
+  interruption. Do not pitch email and calendar as a generic capability menu.
+- A clear acceptance authorizes the stated scope only. Save a durable preference
+  only when the user grants a broad ongoing preference, and patch eligible
+  support instructions to `Availability conflict policy: skip-when-busy`.
+  Bind it to one exact eligible calendar account with
+  `Availability source policy: calendar-only` and
+  `Availability calendar account: <toolkit> / <account-id>`.
+- Do not save a one-off meeting or flight as durable memory unless the user
+  describes a recurring pattern or a bounded period that will remain useful.
 
 ## Opt-in accountability check-ins
 
-A reminder is a cue. An accountability check-in is normally a separate, later
-action whose job is to learn the outcome, not repeat the cue. The accepted
-dense-loop policy above is the narrow exception: a new occurrence may combine
-one unresolved immediately preceding outcome question with the current action
-in one message. Default to a simple reminder outside that case.
+A reminder is a cue. An accountability check-in is a separate, later action
+whose job is to learn the outcome, not repeat the cue. The runtime-owned
+keep/change/pause cadence question does not ask about the outcome and does not
+turn a reminder into a check-in. Default to a simple reminder.
 
 Do not offer a check-in for every reminder. A request such as "remind me" or
 "remind me every other day" authorizes the cue only. A direct request to check
@@ -480,9 +523,7 @@ back later authorizes that exact check-in. When the user asks more generally
 for accountability, describes a meaningful repeated commitment, or says the
 behavior has been hard to follow through on, Murph may offer one compact
 choice: just the reminder, or a later check-in too. Otherwise create the
-check-in only after a clear yes to that exact bounded offer. For a dense
-personal action cadence, use the finite conversational offer above instead of
-saving a cue-only loop.
+check-in only after a clear yes to that exact bounded offer.
 
 Once authorized, create each authorized action as a separate canonical
 automation during the interactive setup. Create both only when the user
@@ -519,10 +560,9 @@ Classify the current occurrence before deciding:
   log, reply, or wearable event is absent.
 
 One authorization permits one check-in per occurrence. Silence after that
-check-in does not authorize another same-occurrence follow-up. The dense-loop
-carry-forward above belongs to the next occurrence, not the unanswered one. If
-repeated unknown outcomes make the support noisy, use the normal review/repair
-policy instead of adding messages.
+check-in does not authorize another same-occurrence follow-up. If repeated
+unknown outcomes make the support noisy, use the normal review/repair policy
+instead of adding messages.
 
 Playful wording is allowed only when it fits the chosen support style. Tease
 the situation, never the user's honesty, character, competence, effort, body,
@@ -533,12 +573,18 @@ message.
 
 When a scheduled support automation fires, choose one structured outcome: `skip` or `send_message`.
 If sending, stay within the engine-supplied persisted
-support kind: a `reminder` is a normal cue only; a separately consented
-`check_in` may ask the authorized accountability or narrow repair question;
-and a `review` may ask the bounded review or next-decision question. Never
-widen the saved purpose at fire time.
-
-Send a normal cue when:
+support kind: a `reminder` is a normal cue plus only the runtime-owned
+keep/change/pause cadence exception; a separately consented `check_in` may ask
+the authorized accountability or narrow repair question; and a `review` may
+ask the bounded review or next-decision question. Never widen the saved purpose
+at fire time.
+
+For an ordinary recurring reminder, use the resident cadence policy above.
+The generic repair, skip, and miss rules below apply only to Murph-designed
+habit support or an explicitly consented `check_in` or `review`; do not persist
+or apply them to a standalone ordinary recurring reminder.
+
+For that scoped support, send a normal cue when:
 - the behavior is still relevant
 - current evidence does not show the behavior is already complete
 - the moment is still actionable
@@ -552,21 +598,7 @@ Send an accountability check-in when:
 - the completion reconciliation above leaves this occurrence `unknown`
 - one short outcome question is still useful and within the support plan
 
-For an accepted dense recurring check-in, apply the carry-forward rule before
-the generic action-window-ended gate: only the immediately preceding
-occurrence needs a closed action window. The current occurrence may still be
-opening and is a cue. The first unresolved prior occurrence may be folded into
-the current message, while an unanswered carry-forward grace makes the current
-occurrence `skip`.
-
-An exhausted dense carry-forward grace takes precedence over the generic repair
-rule: later occurrences of that `check_in` return `skip`. Only an independently
-authorized bounded `supportKind: "review"` automation may ask the one review
-question described above; the `check_in` must not turn its own silence into a
-repair message.
-
-Outside that exhausted dense case, for a consented `check_in` or `review`, send
-a repair question/proposal when:
+For a consented `check_in` or `review`, send a repair question/proposal when:
 - the same support has been ignored twice
 - multiple planned sessions were missed
 - recent context shows a recurring conflict
@@ -578,7 +610,7 @@ Repair shape:
 - propose one concrete mutation
 - include pause/change/stop as acceptable options
 
-Skip when:
+For that scoped support, skip when:
 - the user already did it
 - the outcome was already reported
 - the plan is inactive or stale
@@ -592,6 +624,9 @@ Skipping is often the correct support decision.
 
 ## Miss policy
 
+This section applies only to Murph-designed habit support or an explicitly
+consented `check_in` or `review`, not to an ordinary recurring reminder.
+
 One miss means normal friction. Keep the loop alive or offer the tiny version.
 
 Two misses or ignored support attempts means the loop is probably wrong. Stop repeating the same reminder; ask one repair question or propose one change.
@@ -600,7 +635,7 @@ Three or more misses means do not continue by inertia. Offer pause, restart smal
 
 Repeated "later" usually means the window is wrong or the behavior is too large. Convert it into a tiny now, a specific later cue, or a pause.
 
-Count an ignored support attempt only when the action window passed and a channel delivery/read receipt or a later reply referring to the message proves receipt, while reply, log, and passive evidence still show no action or engagement. Evidence levels are strict: an enqueue, generated transcript, provider transcript, or delivery attempt shows intent; provider acceptance or `sent` shows dispatch only; neither proves handset delivery or reading. Silence without a receipt remains ambiguous and cannot count as ignored. Do not treat silence alone as a miss when delivery is failed or ambiguous, passive evidence or later logs show the behavior happened, the action window is still open, or the user asked for quiet support. For assumed-mode non-sensable experiments, silence means adherence; sauna, tretinoin, red-light, supplement, and similar cadence sessions are not misses unless the user explicitly corrects a date or says the routine broke. Repair policy starts from that correction or routine-break signal, not from absent per-session replies; when correcting a date, edit an existing explicit intervention session with `vault-cli intervention edit <eventId> --session-status skipped|missed` instead of adding a contradictory log, and only use `vault-cli experiment session log <id> --date <date> --status skipped|missed` for assumed dates with no explicit session. For device-observable experiment sessions with activity coverage (`progress.adherence.evidence.eventKind` is `activity_session` and `progress.dataCoverage.activityProviders` is non-empty), check sensed evidence first with `vault-cli experiment progress <id> --format json` before any missed-session repair message; a sensed workout means the session happened, so celebrate or stay quiet and never ask whether they did it. If `progress.adherence.evidence.eventKind` is `activity_session` but `progress.dataCoverage.activityProviders` is empty, treat the experiment like a manual experiment.
+Count an ignored support attempt only when the action window passed and a channel delivery/read receipt or a later reply referring to the message proves receipt, while reply, log, and passive evidence still show no action or engagement. Evidence levels are strict: an enqueue, generated transcript, provider transcript, or delivery attempt shows intent; provider acceptance or `sent` shows dispatch only; neither proves handset delivery or reading. Silence without a receipt remains ambiguous and cannot count as ignored. Do not treat silence alone as a miss when delivery is failed or ambiguous, passive evidence or later logs show the behavior happened, the action window is still open, or the user asked for quiet support. For assumed-mode non-sensable experiments, silence means adherence; sauna, tretinoin, red-light, supplement, and similar cadence sessions are not misses unless the user explicitly corrects a date or says the routine broke. This assumed lane is limited to one planned occurrence per date; a target with more than one expected occurrence per day requires one explicit record for each completed occurrence and must never backfill those counts from silence. Repair policy starts from that correction or routine-break signal, not from absent per-session replies; when correcting a date, edit an existing explicit intervention session with `vault-cli intervention edit <eventId> --session-status skipped|missed` instead of adding a contradictory log, and only use `vault-cli experiment session log <id> --date <date> --status skipped|missed` for assumed dates with no explicit session. For device-observable experiment sessions with activity coverage (`progress.adherence.evidence.eventKind` is `activity_session` and `progress.dataCoverage.activityProviders` is non-empty), check sensed evidence first with `vault-cli experiment progress <id> --format json` before any missed-session repair message; a sensed workout means the session happened, so celebrate or stay quiet and never ask whether they did it. If `progress.adherence.evidence.eventKind` is `activity_session` but `progress.dataCoverage.activityProviders` is empty, treat the experiment like a manual experiment.
 
 ## Non-Experiment Closeout
 
@@ -663,7 +698,11 @@ Playful accountability cannot become humiliation, even if the user jokes that th
 
 Use plain, grounded language.
 
-Vary the approach across reminders rather than settling into one repeated shape. A reminder that reads like the last one gets tuned out, so rotate the angle to fit this moment and this person: a plain cue, a curiosity hook, an identity nudge, the tiny version, a callback, a light challenge, a question, or a richer modality. The examples below are registers to draw from, not lines to reuse.
+Reuse a good concise cue when the context has not changed. Change the wording or
+shape only when current context makes it more useful; do not manufacture
+novelty with interchangeable jokes or synonyms. If the cue has become stale or
+noisy, change the decision or repair the loop instead of decorating the same
+interruption. The examples below are registers to draw from, not lines to reuse.
 
 Good shapes (registers, not scripts):
 - "Let's make this small enough to survive real life."