@murphai/murph 1.3.1 → 1.3.2

package/node_modules/@murphai/assistant-engine/skills/nutrition-strategy/SKILL.md

@@ -62,19 +62,25 @@ An explicit request for a numeric daily nutrition card supplies numeric intent
 for Murph's goal-aware card workflow. The first eligible managed automatic meal
 closeout may also propose once when complete all-status Goal discovery proves
 that no managed proposal has ever existed. Both paths authorize only the paused
-canonical proposal, subject to the safety rules below; neither activates or uses
-the provisional targets. Before every card,
-even when five active goals already exist, read and apply
-`references/daily-nutrition-card-safety.md`. When five usable daily goals are
-missing, also read and follow `references/daily-nutrition-card-goals.md`. The
-safety gate includes its bounded canonical procedure-event and
-encounter-diagnosis discovery plus the separate bounded `pregnancy-test`
-measurement and canonical test-event reads. It
-owns evidence-grounded default derivation, the single canonical Goal proposal,
-and the explanation-before-card sequence. Do not send a goal-less card, create
-a second goal store, or broaden the one scheduled exception into recurring
+canonical proposal; neither activates or uses provisional targets. The
+`murph.attach_response_card` prompt owns the numeric-suitability rule. Apply it
+from known context and do not add a universal medical-history or measurement
+preflight. It may ask one compact safety question before proposing new targets,
+but a routine card with accepted goals does not repeat screening without a new
+concern. Apply that rule only to the numeric target or guidance the known fact
+materially affects. An allergy, intolerance, dietary restriction, or
+clinician-directed diet is not by itself a reason to suppress benign totals or
+an accepted compatible target bundle. When five usable daily goals are missing,
+read and follow
+`references/daily-nutrition-card-goals.md`. That reference owns
+evidence-grounded default derivation, the single canonical Goal proposal, and
+the explanation-before-card sequence. Do not send a goal-less card, create a
+second goal store, or broaden the one scheduled exception into recurring
 unsolicited diet planning.
 
+A scheduled occurrence with unresolved suitability uses ordinary nonnumeric
+closeout text and makes no proposal, mutation, question, or card.
+
 ## Named Diets And Dietary Patterns
 
 A named diet is a rule package, not the user's goal. First identify the job the user is asking for - a definition, comparison, fit decision, practical adaptation, or troubleshooting - and the outcome they actually care about. Answer a direct factual question before asking about goals. Ask one focused question only when the answer would materially change for the user's goal, implementation, or safety.

package/node_modules/@murphai/assistant-engine/skills/nutrition-strategy/references/daily-nutrition-card-goals.md

@@ -15,15 +15,14 @@ card, and never activates the proposal. Once the managed Goal exists in any
 status, later scheduled closeouts may use an accepted active bundle but never
 create, change, or automatically repeat a numeric proposal.
 
-Before using this workflow, read and apply `daily-nutrition-card-safety.md`,
-including its complete canonical memory document, bounded active-condition and
-active-regimen discovery, lifetime procedure-event and encounter-diagnosis
-discovery, 45-day body-measurement read, separate 300-day `pregnancy-test`
-measurement read, and 300-day canonical test-event list plus required detail
-reads. The context snapshot is not completeness proof for any of these owners.
-If any required canonical read is saturated or unavailable,
-or the gate suppresses numeric goals, stop here with no Goal or measurement
-mutation and keep the owning non-numeric or clinical path.
+Start with the active target-authority read below. If it proves that no card or
+responsible proposal can be produced, stop on the owning non-numeric path.
+Apply the `murph.attach_response_card` prompt's concise numeric-suitability rule
+before deriving, surfacing, writing, or activating numeric goals, reading card
+totals, or attaching a card. Use context already known or read only what a
+concrete concern requires; do not fan out across unrelated clinical history.
+If known context suppresses numeric guidance, make no Goal or measurement
+mutation and leave an existing paused proposal unchanged.
 
 A numeric card request explicitly asks for Murph's goal-aware daily-card
 experience. It authorizes only the one paused canonical proposal below so the
@@ -32,8 +31,8 @@ activate, or use those targets. The explanation and explicit later acceptance
 remain required before the proposal can affect a card.
 
 An ordinary verified private meal log carries default attachment intent only.
-It may use an already accepted complete active bundle after every required safety,
-authority, and totals read, but it does not authorize this proposal workflow,
+It may use an already accepted complete active bundle after the known-context
+suitability rule, authority, and totals reads, but it does not authorize this proposal workflow,
 target setting, or any Goal mutation. When that accepted bundle is absent or any
 card gate fails, return the owning food-journal skill's short truthful fallback.
 
@@ -60,8 +59,16 @@ card gate fails, return the owning food-journal skill's short truthful fallback.
   target cannot be collapsed into the card's scalar target; ask one narrow
   question or use ordinary text instead.
 - Comparator compatibility is part of target authority. This point-target card
-  and its managed derivation accept a selected-value target only when its
-  comparator is `between` and its numeric `value` and `highValue` are identical.
+  and its managed derivation normally accept a target only when its evaluation
+  is `selected-value`, its comparator is `between`, and its numeric `value` and
+  `highValue` are identical. The complete same-Goal historical `daily-*`
+  nutrition set below has one read-only display-compatibility path when every
+  target instead uses `evaluation.kind: rolling-window` with `statistic: mean`
+  plus `selectionPolicyOverride.kind: daily-aggregate` with `statistic: mean`.
+  Copy each unchanged point bound into the card for the selected `localDate`,
+  preserve the Goal, and never extend this exception to another target identity
+  or workflow. A mixed evaluation bundle or any other rolling-window or
+  daily-aggregate statistic is incompatible.
   A one-sided `<`, `<=`, `>`, or `>=` threshold, a non-identical `between`
   range, or any other target shape remains authoritative canonical state but is
   incompatible with this workflow. Never translate its bound into a point:
@@ -71,9 +78,32 @@ card gate fails, return the owning food-journal skill's short truthful fallback.
   question without mutation; a scheduled closeout asks nothing and sends no
   card. Apply this rule before any low-energy check or derivation. Multiple
   active explicit owners are also ambiguous.
+- Calorie metric compatibility has one narrow read-only exception for an
+  existing complete nutrition Goal. New authoring uses `dietary-calories`.
+  First resolve applicable canonical `dietary-calories` authority under the
+  date, comparator, and unit rules here. When exactly one compatible canonical
+  owner remains, use it and ignore every `calories` target; that globally
+  ambiguous key neither overrides nor conflicts with canonical dietary
+  authority. Only when no canonical owner exists may the historical target
+  `daily-calories` with metric `calories` and unit `kcal` fill the card's calorie
+  slot. Its same containing Goal must also own exactly one applicable compatible
+  exact-point target for each 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 exactly one complete historical set. Any other
+  `calories` target is not dietary authority, even when co-located with all four
+  macro and fiber metrics. Never combine the historical calorie target with
+  targets from another Goal or a managed proposal. Multiple qualifying sets or
+  ambiguity or incompatibility inside the qualifying Goal means no card and no
+  managed Goal mutation. Do not use titles, slugs, domains, descriptions, or
+  guessed intent as authority. Apply the 1,200-kcal boundary and residual-energy
+  calculations to the one resolved calorie value exactly as if it came from
+  `dietary-calories`. Never rename or mutate the Goal, extend this exception to
+  another workflow, or author new `calories` targets.
 - Unit compatibility is part of target authority. This fixed-unit workflow
-  accepts only `dietary-calories` in `kcal`, and `protein-grams`, `carbs-grams`,
-  `fat-grams`, and `fiber-grams` in `g`. An explicit target in another unit
+  accepts the resolved calorie owner above in `kcal`, and `protein-grams`,
+  `carbs-grams`, `fat-grams`, and `fiber-grams` in `g`. An explicit target in
+  another unit
   remains authoritative and must not be overwritten, but its raw value must not
   be compared with the 1,200 kcal boundary, copied into a card, or used by the
   residual-energy or fiber calculations. Do not invent a card-specific
@@ -132,9 +162,8 @@ Keep population guidance separate from Murph's product judgment.
    judgment informed by limited athlete literature, not DRI prescriptions.
    Round the final target to the nearest 100 kcal and plan to adjust from a
    multi-week trend, training performance, hunger, and recovery.
-   If the adjusted or rounded target is below 1,200 kcal/day, stop under
-   `daily-nutrition-card-safety.md`; do not floor it upward, save a Goal, or
-   attach a goal-comparison card.
+   If the adjusted or rounded target is below 1,200 kcal/day, stop; do not floor
+   it upward, save a Goal, or attach a goal-comparison card.
 2. **Protein preference.** For a generally healthy adult with regular resistance
    training or a muscle-gain goal, start near 1.6 g/kg/day. Use about 1.4
    g/kg/day for other regularly exercising adults and 0.8 g/kg/day for a
@@ -238,14 +267,11 @@ Use the existing canonical Goal owner; add no new state surface.
    when it is historical or future. Call the values provisional and invite
    correction or acceptance. This explanation must happen before the first
    goal-aware card.
-5. When the member accepts the proposal, first re-run the complete
-   current-context gate in `daily-nutrition-card-safety.md`, including its bounded
-   canonical memory, active-condition, active-regimen, procedure-event,
-   encounter-diagnosis, body-measurement, `pregnancy-test` measurement, and
-   canonical test-event reads. If that gate suppresses numeric guidance, fails, or
-   cannot resolve a saturated read, leave the proposal paused and unchanged,
-   surface no target values, use ordinary non-numeric text, and attach no card.
-   Only after that gate passes, re-read target authority. If a metric has gained an explicit
+5. When the member accepts the proposal, reapply the card tool's known-context
+   numeric-suitability rule. If it suppresses numeric guidance, leave the
+   proposal paused and unchanged, surface no target values, use ordinary
+   non-numeric text, and attach no card. Otherwise re-read target authority. If
+   a metric has gained an explicit
    owner, remove it from the managed proposal by sending the complete intended
    post-update array and read the Goal back. Then run
    `vault-cli goal save "Daily nutrition targets" --id <goal-id> --status active`
@@ -260,17 +286,19 @@ Use the existing canonical Goal owner; add no new state surface.
    never edit the explicit Goal.
 6. The proposal turn never attaches a card. If an explicit card request caused
    the proposal, its next unambiguous acceptance may be the first later eligible
-   response: after the complete pre-activation safety gate in step 5 passes,
-   activate and read back the Goal, reuse those identical current-turn safety
-   reads, re-read same-date canonical meal totals, and attach exactly one card
+   response: after the known-context suitability rule in step 5 passes,
+   activate and read back the Goal, re-read same-date canonical meal totals,
+   and attach exactly one card
    in that acceptance response when the pending
    request is still unambiguous and the card alone completes it. A
    target-setting-only request, correction, decline, ambiguous acceptance, or
-   compound request remains ordinary text with no card. Otherwise, only a later
-   eligible response with five exact point values in the exact canonical
-   metric/unit pairs resolved from active canonical goals may attach the card.
-   On an interactive card request, explain an existing paused proposal again
-   unless the member is accepting or changing it.
+   compound request remains ordinary text with no card. Otherwise, a later
+   eligible response may attach the card only when the target-authority read
+   above resolves one complete, unambiguous card-authorizing bundle. Consume
+   that resolved bundle directly; do not restate accepted metric keys or require
+   a second `dietary-calories` owner after calorie resolution. On an interactive
+   card request, explain an existing paused proposal again unless the member is
+   accepting or changing it.
 
 ## Evidence register
 

package/node_modules/@murphai/assistant-engine/skills/physical-notes/SKILL.md

@@ -8,6 +8,53 @@ description: Generate and mail one expressive full-page Murph note through the e
 Use this flow only when a person explicitly wants Murph to send a real note in
 the mail. The product is one US-only, one-artwork-page, color First Class note.
 
+## Resolve an earlier uncertain submission
+
+When a person explicitly asks to cancel, clear, check, or resolve an earlier
+unresolved physical-note submission, call `murph.resolve_physical_note` exactly
+once with the exact current authorizing `message_ref`. When the earlier
+unresolved send or prior recovery result is known from the conversation or a
+tool result, also pass that earlier accepted Message ref as `target_message_ref`;
+pair it with `target_kind: "send"` for an original physical-note send or
+`target_kind: "recovery"` for a prior `murph.resolve_physical_note` result. The
+target pair identifies the checked effect only and does not authorize the
+action. This is a foreground reconciliation, not a send request: do not generate
+artwork, collect an address, or call `murph.send_physical_note` as part of
+recovery.
+
+Treat its result literally:
+
+- `accepted` means provider records prove the checked submission was accepted
+  for printing. It cannot be treated as canceled or recalled. Say accepted for
+  printing, not delivered, and say this recovery sent nothing new.
+- `clear` means the checked submission no longer blocks. When
+  `remainingUnresolved` is false, say no unresolved submission remains. When it
+  is true, say the checked submission cleared but a different unresolved
+  submission remains and needs another explicit recovery request. This recovery
+  sent nothing; a future note still needs a separate explicit send request.
+- `pending` means the outcome still cannot be safely resolved. If
+  `retryAfter` is present, state that Murph can check again after that time only
+  if the person explicitly asks. If the result includes `targetMessageRef` and
+  `targetKind`, preserve both for any later explicit recovery request about the
+  same submission. Never promise or schedule an automatic check.
+- `permission_denied` means the action was not authorized and nothing changed.
+  State the bounded reason and do not retry automatically.
+- For `unavailable`, follow the result's bounded explanation. A returned
+  provider/configuration unavailability can establish that no clear occurred,
+  while a lost or invalid response leaves the final state unconfirmed. Never
+  infer a state change or no-change from the status alone. Say nothing new was
+  sent, say no automatic retry is running, preserve any returned
+  `targetMessageRef` and `targetKind` for a later explicit recovery request
+  about the same submission, and do not retry automatically.
+
+For `accepted` or `clear`, `remainingUnresolved: true` is an independent
+member-wide blocker fact. Report it even though the checked submission reached
+a terminal outcome, and require another explicit recovery request before one
+more check. Never call the tool twice from one authorization.
+
+The recovery tool never sends a new note or recalls an accepted one. Never say
+“canceled” unless a future provider contract explicitly adds that outcome.
+
 ## Resolve before asking
 
 Identify one recipient name, the US street address the person supplied, and

package/node_modules/@murphai/assistant-engine/skills/shared/exercise-catalog-runtime.md

@@ -5,6 +5,12 @@ and safety boundaries fit. This reference owns catalog lookup and first-show
 presentation; it does not decide whether an exercise is clinically or
 programmatically appropriate.
 
+For a setup-only workout activation or logging turn, member-supplied exercise
+names are authoritative log input, not catalog selections. Preserve every
+distinct supplied name and follow the canonical workout owner without running
+`exercise list` or `exercise show`. A missing catalog match must never block,
+rename, merge, omit, or substitute a member-supplied exercise in the workout.
+
 1. Search with the smallest useful `vault-cli exercise list ... --format json`
    query. For each final movement, run `vault-cli exercise show <id-or-slug>
    --format json` so instructions reflect the reviewed steps, equipment, level,

package/node_modules/@murphai/assistant-engine/skills/signup-link/SKILL.md

@@ -10,7 +10,7 @@ link merely because someone mentions a friend, starts a group, asks about an
 earned group referral option, or agrees to introduce Murph.
 
 Only when the current member explicitly asks for a signup, invite, referral, or
-shareable link to forward, call `murph.group` with
+shareable link to forward, call `murph.group_usage` with
 `action="create_signup_referral_link"`. In a group, pass the exact accepted
 `message_ref` from the requester.
 

package/node_modules/@murphai/assistant-engine/skills/strength-training/SKILL.md

@@ -54,9 +54,9 @@ Apply only modifiers that change the plan:
 - `references/coaching.md` — adherence friction, habits, reminders, missed sessions, motivation, or reducing dependence on Murph
 - `references/safety.md` — pain, symptoms, health uncertainty, maximal or high-skill work, special populations, competition, or body-composition risk
 - `references/evidence.md` — source-level justification, disputed claims, confidence calibration, or maintenance of defaults
-- `$MURPH_ASSISTANT_SKILLS_ROOT/tracked-table/SKILL.md` — any private messaging request to start or resume a canonical live workout, update, finish, or correct it, or log or clear one of its sets. Read it again when the member continues one with a short follow-up, or asks to put a workout log in a table, preserve set-by-set notation, or refresh its workout card. On messaging routes, use its native compact-table flow instead of Markdown table syntax.
+- `$MURPH_ASSISTANT_SKILLS_ROOT/tracked-table/SKILL.md` — any private messaging request to start or resume a canonical live workout, update, finish, or correct it, or log or clear one of its sets. Read it again when the member continues one with a short follow-up, or asks to put a workout log in a table, preserve set-by-set notation, or refresh its workout card. Once an exact live workout owns the exchange, use only this execution owner for set confirmations. On messaging routes, use its native compact-table flow instead of Markdown table syntax.
 
-When presenting a named exercise, unfamiliar variation, or movement walkthrough, read `$MURPH_ASSISTANT_SKILLS_ROOT/shared/exercise-catalog-runtime.md` and follow its list/show, image-media, progressive-disclosure, and catalog-gap rules. This skill still owns exercise choice, programming, dose, progression, substitutions, and safety. If catalog media is unavailable, give compact form cues rather than inventing an image workflow.
+When selecting or teaching a named exercise, unfamiliar variation, or movement walkthrough, read `$MURPH_ASSISTANT_SKILLS_ROOT/shared/exercise-catalog-runtime.md` and follow its list/show, image-media, progressive-disclosure, and catalog-gap rules. A setup-only live-workout activation that preserves member-supplied exercise names is not selection or instruction: read `tracked-table` and do not read the catalog reference. This skill still owns exercise choice, programming, dose, progression, substitutions, and safety. If catalog media is unavailable, give compact form cues rather than inventing an image workflow.
 
 The boundaries below apply even when no reference is loaded.
 
@@ -82,11 +82,18 @@ Planning is not activation. Do not silently create a protocol, reminder, check-i
 
 Treat physique photos, body measurements, pain and symptom notes, training logs, and competition health data as private by default. Sharing requires explicit user intent.
 
-### Repeated-set logs and cumulative totals
+### Canonical owner for set confirmations
 
-Repeated-set logging is private-only. In a group conversation, do not read or mutate a participant's private routine or experiment; acknowledge briefly and ask them to continue in their private Murph conversation. In a verified private conversation with several small sets spread across a day, read `$MURPH_ASSISTANT_SKILLS_ROOT/behavior-followthrough/SKILL.md` to resolve the current routine and read `$MURPH_ASSISTANT_SKILLS_ROOT/experiment-onboarding/SKILL.md` when an experiment owns the schedule or records. A terse completion that omits the exercise is not permission to infer it from conversational recency or the previous logged set. Read the full canonical plan records and resolve the unique exercise, owner, and per-set standard for the current member-local date before writing anything. If canonical state does not resolve all three, ask one narrow clarification and do not log a set.
+Choose one canonical write path before loading an execution skill:
 
-Treat each completion reply to one reminder as one occurrence, not as confirmation of an entire day. When one message explicitly confirms multiple sets, write one occurrence per confirmed set against the same resolved exercise and owner, attach the current per-set quantity to every occurrence, then re-read that owner's canonical progress before replying.
+- A current workout command or structured card result, or a host-preserved exact `activity_session` reference from the immediately preceding assistant delivery, may identify one live-workout candidate. Read `tracked-table` and no repeated-routine execution skill. Before writing, require a current exact canonical read or a matching successful canonical mutation for that same session. A visible transcript marker, conversational recency, and the previously logged set never identify the owner. Terse wording, several sets across a day, or calling the set part of a routine never redirects a verified live workout into a regimen or experiment occurrence. If the exact workout or set coordinate is unavailable, ask one narrow workout clarification and write nothing.
+- Exact regimen or experiment context owns a repeated occurrence. This includes trusted reminder context whose `supportSeriesId`, exact owner reference, and `plannedOccurrenceAt` identify an occurrence, even when that reminder also carries a `workout_format` template reference. Read the full canonical regimen and, when applicable, exact experiment through `behavior-followthrough` and `experiment-onboarding`. Resolve one exercise, one owner, and one current per-occurrence standard before writing. Conversational recency and the previous logged set are not owner evidence.
+- Only an exact standalone `workout_format` reminder context, with neither of the owners above, starts a new `activity_session` through `tracked-table`. Read that format and log the stated set against the returned workout id. An older unfinished workout remains untouched and never receives the reminder completion.
+- If no path resolves exactly, ask one narrow clarification and write nothing.
+
+Set logging is private-only. In a group conversation, do not read or mutate a participant's private workout, routine, or experiment; acknowledge briefly and ask them to continue in their private Murph conversation.
+
+In the repeated-routine branch, treat each completion reply to one reminder as one occurrence, not as confirmation of an entire day. When one message explicitly confirms multiple sets, write one occurrence per confirmed set against the same resolved exercise and owner, attach the current per-set quantity to every occurrence, then re-read that owner's canonical progress before replying.
 
 An actual cumulative repetition total must come from explicit canonical per-session or per-set quantities. Never derive it from elapsed days, the planned rotation, assumed adherence, expected occurrences, or the current per-set standard. Keep the recorded total, theoretical full-compliance total, and any unknown historical quantity visibly separate. When old logs contain completed sets but not repetitions, give the exact known set count and an honest known subtotal or lower bound instead of fabricating precision.