@murphai/murph 1.3.0 → 1.3.2

package/node_modules/@murphai/assistant-engine/skills/micronutrients-supplements/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: micronutrients-supplements
-description: Use for vitamin D iron ferritin B12 magnesium omega 3 creatine supplement evidence dosing testing and safety questions.
+description: Use for vitamin D iron ferritin B12 magnesium omega 3 creatine supplement evidence product labels dosing testing and safety questions.
 ---
 
 # Micronutrients And Supplements
@@ -24,6 +24,7 @@ Use this as Murph operating guidance, not as a consumer article. Ground the answ
 ## Data First
 
 - Check diet pattern, labs with dates, supplement list, meds, symptoms, pregnancy status if relevant, kidney/liver disease, and reason for taking it.
+- For connected or saved-meal nutrient questions, also read `food-journal` and use its bounded meal-nutrient workflow. Keep recorded intake separate from lab status: missing or partial meal coverage is not zero intake, complete-looking selected stored-meal coverage does not prove a complete day, source-app targets and percentages are not imported, and one day of food records cannot diagnose a deficiency.
 - Before personalized start, stop, dose, timing, interaction, or keep-taking guidance, read the live full active medication and supplement regimens, not only the compact context snapshot, a truncated list, or one product note. Include allergies, relevant conditions, and dated labs in the evidence bundle when they could change safety. If regimen completeness is unknown, say so and keep the advice conditional rather than assuming nothing else is taken.
 - Read saved labs before any should-I-take, keep-taking, or reorder verdict. For a named biomarker, run `vault-cli blood-test list --text "<biomarker>" --limit 1 --format json` once and reuse that result; use `vault-cli blood-test list --format json` only for a panel-wide question. Run `vault-cli blood-test show <id> --format json` only when the targeted result lacks necessary panel context, and use `vault-cli search query "<biomarker>" --format json` or `vault-cli timeline --format json` only when the question needs history. When blood-test records exist, cite the latest relevant markers with dates, or say plainly that the saved panels do not speak to this supplement. When none exist, say no labs are on file and name the test that would answer it when test-worthiness matters.
 - For supplements outside the list above (for example NAC, curcumin, ginger, berberine), identify which markers or claims would bear on the decision before classifying; do not classify from goals and stack size alone.
@@ -52,13 +53,34 @@ Ask: "Are you trying to correct a known low lab, improve a symptom/performance t
 
 ## Resolve and preserve supplement labels
 
-Use `vault-cli supplement search-labels` for one product or `vault-cli
-supplement search-labels-batch` for several before web lookup. Increase the
-default result limit only when the first result is ambiguous, generic, or
-missing a likely variant. Use a returned serving, dose, or amount instead of
-asking the user to restate it. If the database is unavailable or incomplete,
-prefer an official manufacturer label or another primary source and state the
-gap.
+For every named supplement product, brand, exact dose, serving, ingredient-panel
+question, product image or list, and create or update request, use
+`vault-cli supplement search-labels` for one product or
+`vault-cli
+supplement search-labels-batch` for several before relying on memory
+or web search. Batch a multi-product stack instead of looking up each item
+serially. Skip exact-product lookup only for a genuinely generic evidence
+question where product identity, serving, formulation, and market status cannot
+change the answer.
+
+Match the exact variant before using returned facts. Prefer agreement on product
+name, brand or manufacturer, serving, UPC, and other available identifiers; do
+not merge nearby formulas, flavors, strengths, or historical labels. Use a
+returned serving, dose, or amount instead of asking the user to restate it, but
+never treat a search result as proof that it is the product the user owns when
+material identifiers conflict or remain ambiguous.
+
+The hosted corpus can include NIH DSLD, DailyMed, and first-party manufacturer
+label records. Preserve and, when relevant, name the actual returned source.
+Never describe a database match as FDA approval, and never treat label presence
+as proof of efficacy, purity, third-party testing, current availability, or
+safety for this user.
+
+Increase the default result limit only when the first result is ambiguous,
+generic, or missing a likely variant. If a returned serving, amount, or
+ingredient field is absent or source-null, do not infer it from a nearby product
+or marketing text. Prefer an official manufacturer label or another primary
+source and state the unresolved gap.
 
 When saving known label facts, preserve the full active ingredient panel with
 repeated `vault-cli supplement save --ingredient` JSON-object flags and save the

package/node_modules/@murphai/assistant-engine/skills/mobility-posture/SKILL.md

@@ -17,7 +17,7 @@ Use this as Murph operating guidance, not as a consumer article. Ground the answ
 
 - Use physical-therapy for pain, injury, numbness, tingling, weakness, loss of function, swelling, or return-to-sport rehab.
 - Use strength-training when the answer is loading, progression, hypertrophy, or performance programming.
-- Use recovery-modalities for massage, foam rolling, compression, heat/cold modality tradeoffs.
+- Use the required Health Commons lookup for massage, foam rolling, compression, and heat/cold evidence or safety. Keep this skill only for non-pain mobility and posture action.
 
 When presenting a named drill or routine, 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 whether the movement fits non-pain mobility work.
 

package/node_modules/@murphai/assistant-engine/skills/murph-family/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: murph-family
-description: Use only for Murph Family product questions or account actions involving Family plans, sponsored seats, owner status, checkout, member invites, member usage handoffs, billing, or access. Do not use for ordinary family medical history, genetics, family symptoms, household health context, or caregiving unless the request is also about Murph Family account access.
+description: Use only for Murph Family product questions or account actions involving Family plans, sponsored seats, owner status, checkout, member invites, member usage handoffs, billing, or access. In a hosted group, requests to set up a plan for the requester's family, add family members, or manage Family stay here and are not group sponsorship, room funding, or room usage top-ups. Do not use for ordinary family medical history, genetics, family symptoms, household health context, or caregiving unless the request is also about Murph Family account access.
 ---
 
 # Murph Family
@@ -8,16 +8,24 @@ description: Use only for Murph Family product questions or account actions invo
 Murph Family is a private billing and sponsored-access product. It is not a
 shared health record or family-health context system.
 
-Family supports 2–6 sponsored Pulse ($7/month) or Edge ($19/month) seats.
-Owners pay and can see seat and invite status. Members retain private Murph
-access; owners cannot see member conversations or health data. Shared records
-or supervision require separate consent through their owning flows.
+Family supports 2–6 sponsored Pulse ($7/month), Edge ($19/month), or Max
+($49/month) seats. Owners pay and can see seat and invite status. Members
+retain private Murph access; owners cannot see member conversations or health
+data. Shared records or supervision require separate consent through their
+owning flows.
+
+Each seat includes monthly AI usage equal to 80% of its price: $5.60 on Pulse,
+$15.20 on Edge, and $39.20 on Max. Edge and Max share the same premium
+runtime/model access; Max adds included usage, not a separate model capability.
 
 ## Read status before account-specific guidance
 
 Use `murph.family_plan` with `action: "read_status"` for account-specific
-questions, before inviting after checkout, and before a Family-member usage
+questions, before every Family invitation, and before a Family-member usage
 handoff. Treat the returned state as authoritative for only that request.
+If `read_status` cannot be read, say no change was attempted and that retrying
+the status read is safe. Do not imply that an invite, checkout, or charge might
+have been duplicated.
 
 For a general explanation of Family, answer from this skill without reading
 private status unless account state would materially help. Do not invent billing
@@ -25,16 +33,27 @@ dates, launch terms, seat state, or unsupported admin controls.
 
 ## Start or convert Family access
 
-For an explicit request to start or convert to Family, use
-`action: "start_checkout"` and pass an invite target when provided. Return a
-checkout URL plainly.
-
-- If the result has inactive billing and a checkout URL without
-  `preparedInvite`, ask the user to activate through the link and return if they
-  want Murph to create the invite.
-- If billing is already active and `preparedInvite` exists, do not make the user
-  return merely to create the invite. Promise an invite only when that field
-  exists.
+For an explicit request to start or convert to Family, call `read_status` first,
+then use `action: "start_checkout"` only to establish Family billing. Never pass
+invite context to `start_checkout`; checkout cannot create or prepare an invite.
+Return a checkout URL plainly.
+
+When `read_status.activeTrialConversion` is non-null, do not start checkout yet.
+Tell the member that their free trial ends immediately and state the exact
+monthly amount, included Pulse-seat count, and per-seat amount from that object.
+Ask them to confirm those terms explicitly. On their confirmation turn, read
+status again. Only if the same active-trial conversion remains available may
+you call `start_checkout` with `confirmedTrialConversion: true`. Never send that
+field when the status is null, the terms changed, or the member has not freshly
+confirmed them. The billing owner revalidates the current trial and pricing;
+do not infer terms from earlier conversation text.
+
+- If the same request also asks to invite someone, call `read_status` first. If
+  billing is active, skip checkout and follow the invite flow below. Otherwise,
+  start checkout without invite context, ask the user to activate through the
+  returned link, and ask them to return after activation for the invite.
+- If checkout reports billing is already active, follow the invite flow below
+  only when the current request explicitly included an invitation.
 - If the result has no URL because Stripe is syncing the existing subscription,
   say it is syncing and ask the user to check shortly. Do not invent a failure
   or link.
@@ -42,16 +61,36 @@ checkout URL plainly.
   has sponsored Family access and must leave that Family before starting their
   own.
 
-Do not use `start_checkout` for active-plan tier/capacity changes, member
-removal, or invite cancellation. Route those through the private management
-handoff owned by `murph.plan_usage`.
+Do not use `start_checkout` for active-plan invitations, tier/capacity changes,
+member removal, or invite cancellation. Route management actions through the
+private handoff owned by `murph.plan_usage`; active-plan invitations use only
+the status-gated flow below.
 
 ## Create an invite
 
-For an active plan and explicit invite request, use
-`action: "create_invite"` with the provided phone, email, or Telegram target.
-Pass `planCode: "edge"` for Edge; omission means Pulse. If no target was
-provided, ask one narrow question.
+For an active plan and explicit invite request, first call `read_status`. Pass
+`planCode: "edge"` for Edge or `planCode: "max"` for Max; omission means Pulse.
+Only call `action: "create_invite"` when the status proves all three conditions:
+
+- `owner: true`
+- `billingActive: true`
+- `plans.<requested plan>.remaining` is greater than zero
+
+When those conditions hold, call `create_invite` exactly once with the provided
+phone, email, or Telegram target. If no target was provided, ask one narrow
+question before the mutation.
+
+When the requested plan has no remaining paid seat, do not call
+`create_invite`, claim that an invite exists, or charge from chat. Explain that
+a paid seat is required and send `https://www.withmurph.ai/settings#family`.
+Settings owns the informed seat-purchase confirmation and invitation. The link
+is navigation only; never claim that opening it purchased a seat or created an
+invite.
+
+If `create_invite` returns an error or an ambiguous result after the preflight,
+say the request was not confirmed and ask the owner to check Family Settings
+before retrying. Do not assert that no invite exists or encourage a blind
+duplicate.
 
 Telegram usernames and other owner-provided destinations are routing context,
 not proof the invite is bound or delivered to that account. Describe the result
@@ -81,9 +120,35 @@ claim that payment or usage was added.
 ## Group and privacy boundary
 
 A hosted group cannot own a Family plan, begin checkout, inspect account status,
-or create invites. In a group, answer only general product questions and direct
-account-specific setup or management to the requester's private Murph
-conversation. Never return a Family checkout, top-up, or invite URL to a group.
+or create invites. Those operations belong to a real member's private account,
+not the group's synthetic thread-container member.
+
+In a hosted group, phrases such as "set up a Family plan," "set one up for my
+family," "add my spouse to my plan," or similar requests are Murph Family
+account intent. This classification outranks generic group funding or usage
+language. Do not call `murph.group_usage` actions, and do not present
+room sponsorship, group funding, or room usage top-up options, unless the same
+request explicitly asks about funding or usage for the current room.
+
+For an explicit request to start or convert to Family, reply briefly with this
+choice:
+
+```text
+You can message me privately to set one up for your family, or click this link to do it:
+https://www.withmurph.ai/family/setup
+```
+
+Keep the raw URL on the final line. The person starts the private conversation;
+do not initiate a private message from the group. The setup URL is a stable
+navigation-only handoff: it authenticates the person when needed and opens that
+person's Family Settings once their Murph account is accessible. It contains no
+member, group, checkout, invite, billing, or health-data identifiers, so it is
+safe to place in the room. Do not require an extra confirmation merely to send
+it.
+
+Do not call `murph.family_plan`, claim account state, choose an owner, or create
+a checkout or invite from the group runtime. Never return a generated Family
+checkout, top-up, or invite URL to a group.
 
 Never treat ordinary family medical history, symptoms, genetics, household
 health context, or caregiving as Family account management.