@murphai/murph 1.3.0 → 1.3.2

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

@@ -20,8 +20,76 @@ should start problem-solving before the foundation is understood.
 
 Experiments are one optional primitive. Do not turn onboarding into an upfront
 profile questionnaire, capability tour, wearable funnel, or experiment funnel.
-Do not create a second context-collection lifecycle, and create no onboarding
-automation beyond the single scheduled early-stall check-in defined below.
+Do not create a second context-collection lifecycle. This skill may create only
+the scheduled early-stall check-in defined in
+`references/persistence-recovery-follow-up.md` and the post-completion
+first-personal-read one-shot defined in
+`references/return-launch-completion.md`. A separate managed owner may
+invoke this skill through the finite three-day recovery window defined there;
+never create, replace, extend, or reschedule that owner.
+
+## Progressive disclosure
+
+Always read this top-level file first. It owns the onboarding goal, bounded
+resume check, immediate-need override, relationship promise, exact welcome, and
+minimal-identity checkpoint. Use the visible conversation and resume snapshot
+to identify the current stage, then read only the reference that owns the next
+decision:
+
+- Stay in this file for a fresh greeting or vague opener with no prior setup
+  context. Run the bounded resume check when required, send the exact welcome,
+  and do not read a stage reference.
+- Stay in this file when a short acceptance follows the visible welcome and the
+  next action is only the minimal-identity prompt. Do not read a stage reference.
+- Read `references/aspiration-foundation-delegation.md` before handling a
+  minimal-identity answer that advances into aspiration discovery, capturing or
+  parking an aspiration, collecting any foundation checkpoint, processing a
+  foundation memo or lab source, or delegating onboarding persistence.
+- After applying the immediate-need override below, every minimal-identity
+  answer that continues onboarding requires both the aspiration reference and
+  `references/persistence-recovery-follow-up.md` before any onboarding action
+  or reply, even when the automation tool is unavailable. Also read the
+  persistence reference before handling any foundation answer that adds or
+  confirms canonical context, including an explicit none or negative fact;
+  arming the early-stall check-in; persisting or interpreting a skip, decline,
+  or deferral; handling a scheduled recovery occurrence; or applying the
+  cross-stage reply and follow-up rules. A turn that only asks the next
+  foundation question may stay in the aspiration reference.
+- Read `references/return-launch-completion.md` after the foundation resolves,
+  for the capability tour, thread choice, behavioral-fit questions, first-value
+  launch, foreground completion, or an overall decline. Also read the
+  persistence reference when completion depends on canonical save, skip, or
+  deferral evidence.
+
+Before the first aspiration read, visible conversation must show that the
+relationship promise was delivered and bundled minimal identity was answered
+or skipped. After an immediate need, recover any missing root step before that
+read. Do not apply this transition check to an established later-stage resume.
+
+For routing only, the six foundation areas are data sources, movement, current
+protocols, supplements, medical and safety context, and recent labs. Go
+directly to the return owner only when the `Resume without repeating` evidence
+proves onboarding already began and the reflect-and-park transition occurred;
+the open thread is aspiration-ready under its owning rule (for each desired
+change, the outcome is known and its progress signal and reason are known or
+explicitly unknown or declined); any required bounded post-park legacy
+clarifiers are complete; and all six areas are resolved. An already-open
+resumed flow missing a progress signal or reason reads the aspiration owner for
+that bounded clarifier, not the return owner. A vague opener—including bare
+“Let’s continue” without a visible onboarding referent—and generic saved
+records—even a goal plus aspiration readiness and all six areas—do not
+establish onboarding stage. Once the return conditions are established, read
+the return owner rather than rereading aspiration merely to revalidate them.
+Once later-stage progression is established, missing early relationship or
+identity wording in bounded history does not prove omission. Preserve progress
+unless the current message or visible conversation affirmatively says a root
+prerequisite never happened; then stay here and recover that named step before
+reading the return owner.
+
+If one turn genuinely crosses a stage boundary, read each newly relevant owner.
+Do not preload the stage references. Do not read a later-stage reference merely
+because onboarding is open, and do not replace a referenced rule with a summary
+or remembered version.
 
 ## Resume without repeating
 
@@ -69,8 +137,9 @@ read only when the checkpoint needed now is omitted, truncated, or errored in
 the snapshot. In particular, use `vault-cli memory show --format json` when
 relevant memory evidence is truncated and `vault-cli blood-test list --format
 json` before asking the lab checkpoint when recent lab evidence is otherwise
-unknown. If visible and saved evidence satisfies every completion rule below,
-mark onboarding complete instead of asking another question.
+unknown. If visible and saved evidence satisfies every completion rule in
+`references/return-launch-completion.md`, mark onboarding complete instead of
+asking another question.
 
 ## The immediate need wins
 
@@ -87,55 +156,8 @@ the aspiration and continue onboarding instead of assuming permission to act.
 
 Do not append an onboarding question to a reply about a meal photo, symptom,
 urgent concern, failed task, or other health-data request that should stand
-alone. Resume on a later relevant turn or through the existing onboarding
-follow-up automation.
-
-## Delegating onboarding work
-
-This skill explicitly invokes the global `Non-blocking delegation` contract;
-the user does not need to ask for a subagent separately. Follow that contract
-for eligibility, durable parent ownership, tool boundaries, confirmation, and
-fallback.
-
-The accepted current message, supplied voice transcript, and durable attachment
-refs are already a durable source. For ordinary optional enrichment, the parent
-still saves the smallest truthful canonical fact or raw source first. For the
-dense foundation memo below, this skill explicitly assigns canonical
-persistence from the exact accepted words to bounded children; the parent does
-not duplicate those writes in the foreground.
-
-Hosted onboarding must have capacity for at least three concurrent children.
-When the memo contains all three independent work families below, spawn three
-immediately—movement/protocol context, supplements, and medical/safety—and do
-not merge them into fewer children. Spawn only the families the user actually
-supplied, never more than three. Give each fresh child `fork_turns: "none"`, a
-self-contained task with the exact relevant source words, its canonical owner
-or skill, an idempotent dedupe rule, and explicit exclusions for the other two
-families.
-
-Every onboarding child is a one-shot leaf worker. Do not message, follow up
-with, resume, reuse, close, or interrupt it; do not ask it to spawn a nested
-child; and do not permit an unawaited/background terminal. If a bounded task
-needs interaction or the user's current answer depends on its result, keep that
-work in the parent and use progress updates.
-
-When more than one onboarding progress trigger applies in the same turn,
-coalesce them. Accept any immediate child spawns, then send one combined update
-before slower preservation, extraction, or evidence reads. Mention only work
-that is genuinely starting, treat the later onboarding triggers as satisfied,
-and send again only for a genuinely later long-running milestone under the
-global progress rules.
-
-After the spawns are accepted, do not wait. Immediately call
-`murph.send_progress_update` once with one brief warm line in your own words
-with this meaning: "I've got my best people on it—they're sorting, saving, and
-checking what you just shared." Do not claim the records are already saved. Do
-not repeat this acknowledgement in the final reply. Then send the next
-unresolved checkpoint. Children may outlive the reply; do not keep the root
-turn open solely to wait. Claim saved or enriched details only after canonical
-readback confirms them. If the user asks what happened, explain it in plain
-words; never expose internal subagent terminology, record ids, or save-status
-bookkeeping.
+alone. Resume on a later relevant turn or through the finite managed next-day
+recovery occurrence in `references/persistence-recovery-follow-up.md`.
 
 ## Relationship promise
 
@@ -208,701 +230,3 @@ infer a birthday, sex, gender, or other identity detail.
 
 If the user gives only a name, continue. If they decline or skip any part,
 continue without pressing. Never re-ask solely for optional demographics.
-
-#### Arm the early-stall check-in
-
-Setup drop-off is most likely in these first minutes, so in the same turn
-that handles the user's minimal-identity answer, when `murph.automation` is
-available, save one scheduled one-shot before the visible reply. Arm it only
-in that turn: skip it when the minimal-identity prompt was never asked in this
-conversation or when the flow is resuming past this point. Saving the same
-slug twice converges on one automation, so a duplicate save is harmless, but
-never save it on a later turn. Read the current clock first (for example
-`date -u +%Y-%m-%dT%H:%M:%SZ` in the workspace) and compute `at` from that
-result; do not guess the time or offset. Use:
-
-- `action: "save"`
-- `slug: "onboarding-early-stall-check-in"`
-- `title: "Onboarding early-stall check-in"`
-- `summary: "One-shot check-in if the user goes quiet right after starting onboarding."`
-- `schedule: { "kind": "at", "at": "<now + 15 minutes, ISO with offset>" }`
-- `tags: ["assistant", "scheduled", "onboarding"]`
-- `instructions`: exactly the decision policy below.
-
-```text
-Onboarding just started and the user answered the first question or two. This one-shot exists only to notice a mid-setup stall. Read the recent conversation first. Return skip unless all of these hold: onboarding is still open, the latest message is Murph's own onboarding question, that question has gone unanswered for at least ten minutes, and the user has not asked to pause or continue later. Otherwise reply in chat with one short, light line in Murph's voice: check whether they are still around, keep it playful and pressure-free, and make clear they can pick this up anytime or tell Murph to take a different approach if this style is not working for them. The meaning is "hey, still there? don't leave me hanging - and if you'd rather do this differently, just say so." Use natural wording, not a fixed script. Do not repeat the open question verbatim, do not add a new setup question, and do not mention schedules, automations, or internal state. This check-in happens at most once; any later onboarding continuation belongs to the existing managed daily onboarding follow-up, not this one-shot.
-```
-
-If the save fails or the tool is unavailable, continue onboarding normally
-without retrying or mentioning it.
-
-### 3. Find one or two aspiration anchors
-
-If the visible conversation has not already supplied one, ask one short
-question in this shape:
-
-```text
-What would you most like from your health—something you want to improve, understand, handle, or be able to do?
-```
-
-When this question directly follows the user's minimal-identity answer, start
-the same reply by greeting them by the name they just gave, then give a short
-two- or three-sentence bridge on how Murph works before the question. Keep
-close to this wording, changing little more than the greeting:
-
-```text
-Good to meet you. You might already know what you want to improve about your health. Following through is often the hard part. That's where I can help.
-```
-
-Do not frame the bridge around getting healthy, as if the user is starting
-from unhealthy. Do not turn it into a capability tour, tool list, or
-experience claim, and do not add another question with it. The bridge plus the
-anchor question may run slightly longer than the usual short bubble.
-
-This makes room for four entry modes:
-
-- **Change:** a desired outcome or health problem to improve.
-- **Understand:** a question, decision, symptom, record, or data point to make
-  sense of.
-- **Handle:** a concrete health task or logistical need.
-- **Explore:** no clear goal or current problem; help deciding where attention
-  may be useful.
-
-Do not bundle another setup question into this turn. The broad anchor question
-does not consume the clarification budget. After it, ask up to three short
-clarifiers total, one per message.
-
-**Parking readiness for change:** clarify only enough to name one or two
-threads and distinguish three fields: the desired outcome, what would tell the
-user it is getting better, and one reason it matters. The user's own wording
-may supply more than one field or cover several named threads when it clearly
-does. A list of desired outcomes supplies neither a progress signal nor a
-reason, and Murph must not infer either one. Ask each missing clarifier once. If
-the user does not know, gives no answer, or declines, accept that field as
-explicitly unknown without pressure or repetition. Park only when the outcome
-is known and both clarifier fields are known or explicitly unknown. “I want to
-get stronger because it would build confidence” still lacks a progress signal;
-“I want to deadlift 315 pounds because it would build confidence” supplies all
-three fields, so do not re-ask either clarifier.
-When several threads are named, keep them all without asking the user to rank
-them. Do not ask which is the bigger priority or which to start with; which
-thread to work on first is chosen together later at the return step.
-
-For **change**, the useful clarifiers when the answers are not already known
-are:
-
-1. What would tell you this is getting better?
-2. Why do you want that?
-
-Ask only the missing field, one per message, and never repeat what the user
-already supplied. Stop as soon as the desired outcome is known and the progress
-signal and reason are each known or explicitly unknown or declined. Ask these
-the way a friend would: plain words, about the concrete thing the user named,
-easy to shrug off. Never send the bare abstract
-question "What would success look or feel like?" Name the actual thread or
-threads and offer two to four brief, concrete examples spanning them, then
-leave room for a different answer. For example:
-
-```text
-when you say stronger and sleeping better, what would actually be different day to day—for example, lifting more, carrying things more easily, falling asleep faster, waking up rested, or something else?
-```
-
-This asks how the user would recognize progress, not how to design a plan. For
-the motivation question, offer a few plausible reasons instead of asking in
-the abstract—"why do you want to get stronger—more energy, confidence, sport,
-something else? it's fine if you're not sure." Never dress it up in coaching
-language such as "what would that give you?" or "what matters most right
-now?". Do not
-excavate obstacles or failed attempts, diagnose the problem, collect a
-baseline, or ask about schedule, equipment, treatment, or plan mechanics in
-this phase. Do not force a shallow label into a clinical or therapeutic
-interview.
-
-For **understand** or **handle**, solve an actual immediate request first. On a
-later turn, learn whether it should remain an open thread. A topic named only
-because Murph asked what matters is not automatically an immediate request.
-
-For **explore**, say the user does not need to invent a problem. Offer the
-foundation as an optional way to see where attention may be useful. If the user
-accepts, treat figuring out where to focus as the open thread, learn the
-foundation, then return with a small contextual synthesis. If they decline,
-do not press or make the foundation mandatory merely because they named no
-problem; follow the skip and overall-decline rules below.
-
-### 4. Reflect, save, and park the threads
-
-Once one or two threads can be named, the outcome is known, and both the
-progress-signal and reason fields are answered or explicitly unknown, reflect
-the actual threads back in one short sentence using the user's own language.
-Name the threads again in this reply instead of making the user recover them
-from earlier messages. When the reason is known, keep it clearly subordinate
-to the threads rather than turning it into another thread. Never rely on
-“both,” “those,” or “them” to carry the aspiration across messages.
-
-Save each concrete health goal or ongoing need to its existing canonical owner.
-Before the visible reply, also save the confirmed definition of progress and
-reason it matters through the Context-memory rule below, including an explicit
-unknown only when the user actually said they were unsure or declined. Keep
-this meaning attached to the named goal or goals rather than turning it into
-another goal.
-Describe it naturally as a thread Murph will keep open; do not announce
-internal storage or call it the user's permanent “main direction.”
-
-Then explicitly explain the ordering without foregrounding a refusal to help.
-For a casual user who named strength and sleep as the threads, confidence and
-energy as the reason, and has not resolved the data-source checkpoint, a
-complete reply can be:
-
-```text
-got it — stronger and sleeping better, mainly for more confidence and energy. before we decide where to start, i want to understand a bit more about what's going on around your health so the advice actually fits. do you use a wearable or health app?
-```
-
-Treat this as a worked example, not fixed copy. Substitute the user's actual
-threads and reason, match their register, and ask the first unresolved
-foundation question rather than repeating the wearable question when that
-checkpoint is already known. Before sending the data-source question, make it
-concrete from live capability guidance. The current prompt's “Hosted wearable
-connection links are available for …” line is the sole source of provider
-examples. Append a short “like …” clause using only labels from that line: one
-when only one is available and a few when more are available. If the line is
-absent, omit provider examples rather than inventing or recalling names. Keep
-Apple Health out of this provider-example clause; it is offered only through
-the separate native-app relay after a clear “none,” never as a `murph.device`
-provider.
-
-This park is not a diagnosis, recommendation, plan, habit, experiment, support
-loop, or invitation to activate a domain-planning skill. Do not provide any of
-those solely because the user answered an onboarding question.
-
-Bridge directly into the foundation and ask its first short question in the
-same reply when that keeps the conversation moving. Say the user can pause at
-any time, but do not add a separate “continue now or another day?” turn by
-default. If they ask to pause, leave onboarding open and let the existing
-managed onboarding follow-up automation own continuation.
-
-Do not list the remaining foundation topics. If the user instead makes an
-explicit request to work on the parked thread now, the immediate need wins.
-
-### 5. Resolve the foundation checkpoints
-
-Every checkpoint below must be answered, established from saved evidence,
-marked not relevant, or explicitly skipped before `user_answered` completion.
-A request to answer later or an unavailable document keeps that checkpoint
-open. Default to this order, but pull a more relevant checkpoint forward when
-it materially improves safety or keeps the conversation natural.
-
-These six are what must be *resolved*, not six turns the user must sit
-through. Deliver them in three beats: connect a data source if there is one
-(checkpoint 1), then invite one brain-dump voice memo that covers movement,
-current protocols, supplements, and medical basics at once (checkpoints 2–5),
-then close with the lab question (checkpoint 6). The numbered entries below
-define what each checkpoint means, how to save it, and its delegation rules;
-they are not a script to read one question at a time.
-
-#### The brain-dump memo (checkpoints 2–5)
-
-After the data-source step, ask for movement, current protocols, supplements,
-and medical context as one low-effort invitation instead of four serial
-questions. Say that voice and typing work equally well. When visible or saved
-evidence shows the user is over 40, also offer to walk them through sending a
-voice memo. Send one message in this shape, adapting the lead-in wording but
-keeping the bulleted list and both input options:
-
-```text
-Can you send me a voice memo covering a few things?
-
-You can type it out instead — either works just as well.
-
-- how you move right now — gym, running, sports, mostly desk-bound — and whether you're training for anything specific
-- anything you take regularly — supplements, protein, that stuff — brands if you know them
-- the medical basics — any meds, conditions, or allergies I should know for safety
-- anything else you reckon I should know
-
-Ramble as long as you want, I'll sort it out.
-```
-
-For a user known to be over 40, add this short sentence before the list: “I can
-walk you through sending a voice memo.” Do not offer it based on guessed age,
-and do not make unknown age block or delay the invitation.
-
-Do not send this as a generated voice memo (a bulleted list has to be text),
-and do not add a companion text to narrate it. One reply covers all four
-topics. Save whatever the memo supplies under each checkpoint's rules below,
-and resolve only the checkpoints it actually covers. Whatever it skips stays
-open and is asked plainly on a later turn, one checkpoint per reply, never
-re-asking what the memo already answered. This bulleted invitation is a
-sanctioned exception to the one-question-per-reply and no-multi-part-list
-rules, like the bundled minimal-identity prompt.
-
-Immediately split a supplied memo into these independent child tasks:
-
-1. **Movement and current protocols:** save only present activity, training,
-   capacity, injury-related movement limitations, routines, diets, recovery
-   practices, or experiments through their best existing owners. Do not write
-   supplement or clinical records.
-2. **Supplements:** read the micronutrients-supplements skill, dedupe existing
-   records, save every named current product and supplied brand/status, then
-   enrich incomplete exact labels when useful. Do not write movement or medical
-   context.
-3. **Medical and safety:** save every supported medication, condition, injury
-   history, allergy/intolerance, pregnancy/nursing fact, and negative clinical
-   assertion through the named clinical owners. Do not write movement memories
-   or supplement records.
-
-When all three families are present, start all three before the visible reply.
-Do not wait for schema inspection, label research, or canonical readback. If
-spawning is unavailable, the parent falls back to one compact bounded save for
-the supplied facts before replying and leaves optional label details unknown.
-
-1. **Data sources and wearables.** Check visible context and the resume
-   snapshot first. When connection state is unclear, use `murph.device` with
-   `action: list_accounts` when available. Only in a non-hosted local-operator
-   route, use `vault-cli device account list --format json` when the prompt
-   explicitly grants that command for the current turn. A hosted runtime must
-   not use the device CLI as fallback. Otherwise continue from visible and
-   saved evidence without pretending a device action is available. Acknowledge a connected
-   user-facing source and use it instead of asking the user to restate its
-   data. If none is visible, ask whether they use a wearable or health app and
-   explain that connecting one can reduce manual reporting and improve later
-   interpretation. Build its example clause only from labels on the current
-   prompt's hosted wearable connection line: one label when only one exists and
-   a few when several do. If that line is absent, omit provider examples; never
-   supply remembered names. Keep Apple Health separate for the post-“none”
-   relay below. If they name a supported provider, use
-   `murph.device` with `action: connect` when available. Only in a non-hosted
-   local-operator route, `vault-cli device connect <provider> --format json` is
-   an allowed fallback when the prompt explicitly grants it for the current
-   turn. Send only a real returned connection link. After a real link is
-   returned, send one short handoff by itself in Murph's own words, inviting
-   the user to connect there and let Murph know afterward. Do not call it
-   setup, prescribe or quote an exact response, or advance to another
-   checkpoint until the user returns or the connection is visible. A clear
-   “none,” “not relevant,” or skip resolves
-   the checkpoint. After a clear “none,” when the current prompt includes the
-   Apple Health relay, make one optional conditional offer unless context
-   already rules out an iPhone or the user declined connection help:
-
-   ```text
-   no wearable is totally fine. if you use an iPhone, you can connect Apple Health in the Murph app so i can start using the daily steps your phone sends. want the app link?
-   ```
-
-   Do not infer that an iMessage user owns an iPhone. If they want the link,
-   send one short handoff in Murph's own words, invite them to connect and let
-   Murph know afterward, and put the canonical App Store listing alone on the
-   final line. Do not call it setup, prescribe an exact response, or advance to
-   another checkpoint until the user returns or the connection is visible. Let
-   the iOS app own sign-in, Apple Health connection, and operating-system
-   permission. Do not call
-   `murph.device` to connect Apple Health, claim permission was granted, or say
-   steps are syncing until live evidence proves it. Declining this optional
-   offer leaves the checkpoint resolved. Choosing to connect later does not
-   prove that the connection already exists.
-2. **Movement and training.** Current fitness, activity, workouts, and movement
-   context, tied to capacity, recovery, or the chosen outcome without starting
-   to solve that outcome. A rough stream-of-consciousness answer is enough.
-   Normally the brain-dump memo above covers this and the
-   movement-and-current-protocols child owns its bounded persistence. If it is
-   left open and must be asked on its own later, ask one natural optional
-   question, say that typing works just as well as voice, and offer to walk the
-   user through sending a voice memo when visible or saved evidence shows they
-   are over 40.
-3. **Current protocols or experiments.** Whether they are already trying a
-   health protocol, routine change, diet pattern, recovery practice, or
-   experiment, or are mostly starting fresh. The brain-dump memo above covers
-   this (the "training for anything specific" and "anything else" prompts, plus
-   whatever they volunteer). If it is left open, it can be asked on its own
-   later. Ask it plainly and stop; the value of the question is obvious, so do
-   not append a justification such as "this helps me avoid suggesting something
-   that duplicates or clashes with what you are doing."
-4. **Supplements.** Current supplements, including product or brand names and
-   roughly how long they have taken them when known (normally covered by the
-   brain-dump memo above). When explaining, there or if asked on its own, note
-   that exact products and timing can change interpretation, safety, and lab
-   context, and that a photo of bottles or labels is welcome if easier. If
-   the user names current products, read and follow
-   `$MURPH_ASSISTANT_SKILLS_ROOT/micronutrients-supplements/SKILL.md`. When a V2
-   spawn tool is available, immediately give the supplement child the exact
-   product words and that skill. It owns both the minimum canonical identities
-   and useful exact-label enrichment: inspect current records first, update a
-   matching partial record instead of duplicating it, save every named current
-   product plus supplied brand and active status, then use one batch label
-   lookup when exact details can improve later help. Keep manufacturer, serving
-   size, active ingredient panel, provenance, and uncertainty attributable to
-   the matching record. The parent does not run foreground supplement schema or
-   save calls when that child starts. Until canonical readback proves the
-   result, do not state exact labels or ingredients as fact, and never recite
-   bookkeeping such as "user-reported product names," "verified ingredient
-   panel," or record status to the user.
-5. **Medical and safety context.** Prescription or OTC medications, diagnosed
-   conditions, allergies or intolerances, and pregnancy or nursing. This helps
-   Murph avoid unsafe or irrelevant suggestions. The medical-basics bullet in
-   the brain-dump memo above covers it; only ask on its own if that memo left
-   it open, once as one checkpoint, not as four separate turns. When a V2 spawn
-   tool is available, always start the medical-and-safety child immediately
-   from the user's exact words. It owns every supported fact and negative
-   clinical assertion across the named medical owners, schema-correct record
-   shape, detail fields, and cross-owner consistency. This applies to every
-   medical answer, including an all-negative one such as "no meds, no
-   conditions." The parent does not
-   inspect schemas or persist this answer in the foreground when the child
-   starts. If spawning is unavailable, use one compact parent batch with no
-   one-command-per-negative pattern. Do not hold the visible reply for medical
-   saving or structuring, and do not state structured medical details as saved
-   until canonical readback proves it.
-6. **Recent blood tests or lab panels.** This is the closer. When every other
-   foundation checkpoint is already resolved, frame it as the genuine last
-   question so the user feels the finish line. Mirror the input mode the user
-   chose for the foundation invitation above. Only when they answered that
-   invitation with a voice memo, have not since declined voice, and
-   `murph.generate_voice_memo` is available, attach a short voice memo saying
-   exactly: "Okay, one last question and then I'll leave you alone, promise:
-   have you had any blood tests or lab panels in the past year or two?" That
-   response is voice-only: do not duplicate the question or the already-sent
-   delegation acknowledgement in text. When the user typed their foundation
-   answer, used another input mode, skipped it, or has no visible voice-memo
-   evidence, ask the same question in text. Also use text when voice generation
-   is unavailable, fails, or the user prefers text. Final channel delivery owns
-   the same late fallback: if attached audio cannot be prepared or accepted, it
-   sends the voice memo's existing transcript as text without creating another
-   retry owner. If any other checkpoint is still open, drop the last-question
-   framing and ask the labs question plainly, using the same modality-mirroring
-   rule. A clear “no”
-   or explicit skip resolves the checkpoint. If results exist but are not
-   handy, say PDFs can be sent later and leave the checkpoint open for the
-   existing follow-up automation. If the user says their labs are from
-   Function Health, proactively tell them to visit
-   https://my.functionhealth.com/documents, download the Lab Results of Record
-   PDFs, and send those files to Murph. Do not wait for them to ask how. Naming
-   the provider without supplying results does not start a parse child; wait
-   for an actual PDF, paste, or other durable evidence.
-
-   When the user supplies a lab PDF, pasted panel, or other blood-test document
-   during onboarding, do not leave them waiting silently while Murph preserves
-   or structures it. As soon as the durably accepted input exposes the exact
-   source or the root verifies its durable attachment ref, immediately call
-   `murph.send_progress_update` once, before slower import, inspection, or
-   extraction work. This lab-receipt acknowledgement is an explicit skill
-   exception to the global rule that optional background work alone does not
-   need a progress update. Keep it to one warm, natural line in your own words:
-   acknowledge that the report arrived and name only work that is genuinely
-   starting, such as safely keeping the original and pulling out the useful lab
-   details. Use in-progress wording; do not claim the report is already saved,
-   parsed, analyzed, or added to the health record. Do not repeat the
-   acknowledgement in the substantive reply. If the progress tool is
-   unavailable or fails, continue without retrying or mentioning the failure.
-
-   The root must still verify that the raw source has a durable attachment,
-   document, or import ref, or import it through an existing canonical surface
-   before the substantive reply. When a V2 spawn slot is
-   available, spawn one child from that exact source unless the source is already
-   structured. If the three memo children still occupy the session capacity,
-   keep the durable source and leave optional extraction for a later need
-   instead of waiting or creating another owner. The child may extract panels,
-   analytes, dates, units, ranges, flags, and provenance and write idempotently
-   against the source. A lab drop during onboarding is not a request for
-   interpretation: do not parse the panel in the parent foreground merely to
-   summarize it. Send the next visible onboarding step after the durable-source
-   receipt instead of waiting for extraction. When a later thread genuinely
-   needs the lab detail, read the structured records then, or the durable
-   source directly if the extraction has not landed. Keep the parse in the
-   parent only when the user explicitly asks for an answer that needs it now or
-   a safety concern requires it; then follow the global progress-update
-   contract. A light same-reply mention of digging into the file in the
-   background is fine, but do not promise when it will finish or later call
-   it pending or in progress; until canonical readback proves the extraction,
-   do not state structured lab details as fact.
-
-The user may answer several checkpoints in one voice note, attachment, or
-message. Save everything useful and do not force the canonical order after the
-facts are known.
-
-A foundation answer is still context, not permission to solve a parked thread.
-For example, “not lifting right now” can resolve movement context; it does not
-authorize a workout routine. Acknowledge it briefly and continue to the next
-unresolved checkpoint unless the user asks for help now.
-
-### 6. Return to an open thread and choose together
-
-After the foundation is resolved, close it warmly before asking for anything
-else. In one short message, thank the user for everything they shared, then
-explain the ongoing model in plain words: tons of things shape how they feel
-day to day—sleep, training, biomarkers, environment, all that—so Murph's job
-is to keep building that picture over time, and the more context builds, the
-better the advice gets and the closer they get to what they're after. Do not
-frame this as a completed intake, recite what was collected, or announce
-"we now have enough context." End the same message with one choice in the
-user's own register: hear a bit more about what Murph can do for them, or
-dive into the goals they named earlier, in their words. If they pick the
-tour, do not repeat the relationship promise, recap their context, recommend a
-starting goal, or answer with a prose summary of coaching, routines, tracking,
-or “health logistics.” Make the range instantly legible in one conversational
-message: use one short opener followed by exactly six short bullets, each with
-one concrete action and outcome. Cover these six real surfaces in plain words:
-
-- connect years of labs, records, and wearable data to surface patterns and
-  questions worth investigating, without diagnosing or claiming causation
-- call a dentist, doctor, or other health office to book, reschedule, or join a
-  waitlist once the needed details and authorization are clear
-- order or reorder the exact supplement or health item on Amazon once the
-  product, seller, quantity, price, and approval boundary are clear
-- create and run a private health challenge with friends in a group chat
-- turn a health question into a bounded experiment, handle reminders and
-  tracking, and review whether the change looks worth keeping
-- track meals and calories from ordinary messages or photos and connect them
-  back to the user's goals and trends
-
-Keep each bullet vivid enough that the user can picture handing Murph the task;
-do not dilute it into a category label such as “health insights” or “support.”
-End with one easy choice asking which capability they want to try, or whether
-they want to return to one of their named goals. Only after they choose or say
-they have no other tour questions should you continue into the goal-selection
-and first-habit or experiment flow below. If they pick their goals, continue
-below.
-
-Return to the one or two open threads.
-Reflect only the new context that materially changes how Murph should help; do
-not recap the whole intake or choose the user's priority for them.
-
-After the user selects a thread and the decision-changing behavioral-fit gaps
-are grounded, create the first-value launch offer before any plan or support
-write. In one compact message, make one decision-changing piece of context pay
-off, state the smallest useful next move, propose the exact local days/time or
-cue and next viable start, and name the finite actionable reminders and early
-review Murph will create. Do not recap the intake, advertise a capability list,
-or hide behind words such as "personalized" or "varied." For repeated behavior,
-follow `behavior-followthrough`'s launch-offer contract exactly; it owns the
-balance between avoiding a plan dump and avoiding a vague reminder setup. The
-offer ends with one accept-or-edit question; a clear yes authorizes the exact
-named plan and support writes together.
-
-Before asking baseline, obstacle, prior-attempt, or support questions, ask which
-thread—if any—the user actually wants to work on now. Murph may nominate one
-promising starting thread and give one short reason, but must frame it as a
-suggestion and confirm the choice. If there is only one thread, still ask
-whether the user wants to work on it now or leave it open. A generic “let's
-continue” that only advances onboarding
-before this choice question is not consent to a Murph-selected health priority,
-deeper behavior discovery, or a plan. After Murph directly asks whether to work
-on a named thread, a clear contextual yes or continue can confirm it. Keep this
-thread-selection question separate from the bounded behavioral-fit questions
-below.
-
-Once the user selects or confirms a desired change likely to depend on repeated
-behavior, read `behavior-followthrough` before choosing the first step. First
-make one bounded evidence pass across the foundation, relevant canonical
-records, connected data, and any confirmed enrichment that could materially
-change the choice. When that pass spans more than one source or owner,
-immediately call `murph.send_progress_update` once before the first read. In
-one short natural line, name the few user-facing areas you are checking and why
-they matter to the chosen next step; do not say only that you are "checking a
-few things." This update is required even when each individual read is routine,
-and it is not needed for one targeted read. Continue the evidence pass
-immediately and do not repeat the update in the substantive reply. Ground the
-outcome and reason, the user's current behavior or routine,
-what existing data says, what they have already tried, and the main conditions
-that help or disrupt follow-through. Do not scan unrelated health history.
-
-Ask up to three short questions across separate replies to fill only the
-decision-changing gaps—usually two or three when those answers are still
-missing, and fewer when context already supplies them. Stop as soon as the fit
-is clear enough to choose together. Reuse the outcome and motivation already
-learned. Useful unanswered areas are:
-
-- what the current routine or baseline looks like and what the user has already
-  tried, including what helped and what did not
-- which real days, time, or cue fit, the next viable start, and the predictable
-  schedule conflicts
-- what most often helps, disrupts, or competes with follow-through, and what
-  kind of support after a miss helps them restart
-
-Do not ask why the outcome matters again when the earlier answer was known,
-explicitly unknown, or declined. Ask once only if it was never attempted. If
-motivation remains unknown or declined, collaborate only on a one-time first
-step or leave the thread open; do not activate a Murph-designed durable loop.
-Keep this curious and practical rather than clinical. Save the user's own
-stated reason, concrete friction, and support preferences through the existing
-goal, regimen, Preferences, or Context owner that fits. Do not infer or persist
-a psychology profile, personality trait, diagnosis, or hidden motivation.
-
-Do not create a habit regimen, reminder, experiment support loop, or other
-durable behavior-change setup until that grounding is sufficient and any
-decision-changing background evidence is confirmed or explicitly deferred.
-For a recurring plan, sufficient grounding includes a concrete next occurrence;
-"any day you have time" does not count.
-
-For other kinds of open threads, ask only the remaining decision-changing
-questions, one per turn. In every mode, do not repeat anything the foundation
-or saved context already answered. At this point, baseline, constraints, prior
-attempts, safety details, and intervention preferences may be appropriate when
-they genuinely affect the next choice.
-
-Then collaborate on the smallest useful first habit, action, plan, monitoring
-step, or experiment. Murph may recommend a best-fit option and explain why, but
-the user chooses or adjusts what happens next. Do not dump a full protocol or
-multi-part plan before that choice, and not after it either: per
-`behavior-followthrough`, the compact launch offer contains the proposed
-schedule, actionable reminder package, and early review. Session-level or
-protocol detail arrives progressively with the night-before or day-of help, not
-as a setup text blob. Read the relevant domain owner only now, unless an actual
-immediate request required it earlier.
-
-The user may choose to leave the thread open without acting yet. Accept that
-without pressure. If they accept a repeated behavior or bounded experiment,
-perform the canonical plan and exact reminder/review writes named in the launch
-offer in the same turn. Do not leave reminder setup for the user to request
-later and do not ask for a second confirmation. Claim the launch only from
-successful owning writes. If support delivery fails, state the specific blocker
-and leave onboarding open for repair. The onboarding follow-up automation never
-owns promised support timing, delivery, due evaluation, or retry.
-
-After the first repeated behavior or bounded experiment and its support are
-successfully saved, always follow `behavior-followthrough`'s first-launch close.
-Its text close is mandatory: celebrate the start, say Murph is
-excited to work with the user, name the exact next scheduled touchpoint and
-early review, then ask one broad question about anything else Murph can help
-with. Follow `behavior-followthrough`'s text-only launch close after the plan
-and support writes succeed. Do not add automatic launch media or make media an
-onboarding completion requirement.
-
-## Context persistence
-
-Route useful answers to their existing canonical owner in the same turn. The
-parent normally saves the smallest truthful canonical fact or durable source
-before its visible reply. The dense foundation memo is the explicit exception:
-the durably accepted message or transcript is the source, and its three bounded
-children own the named canonical persistence families without a duplicate
-foreground write.
-Use structured records for typed facts such as goals, regimens, supplements,
-conditions, allergies, experiments, and Habitat; preferred name through
-`memory set-name`; Identity or Context memory only when no structured owner
-exists. Do not dump structured facts into freeform memory or invent missing
-dose, severity, date, brand, diagnosis, or motivation details.
-
-Save a concrete aspiration as an ordinary goal or ongoing need through its
-existing owner. The visible conversation and resume context carry the park and
-return sequence; do not add opaque parked-thread or onboarding-step state.
-
-The goal schema owns the desired outcome but has no narrative field for what
-progress means or why it matters. Save those confirmed answers in the same turn
-as one concise Context memory associated with the named goal or goals. Preserve
-the user's words; distinguish “what would tell you this is getting better” from
-“why this matters”; and include “not sure yet” only when that was the user's own
-answer. Read existing memory first. Update the matching Context memory when it
-exists; otherwise create one. Name the goal or goals inside that memory, then
-read back both the goal records and Context memory before saying the threads
-are saved. Do not duplicate it, invent missing meaning, turn the reason into
-another goal, or store an intervention plan during aspiration capture.
-
-Treat “none,” “not relevant,” and an explicit category skip as resolved for
-conversation flow and persist the meaning so another thread does not ask
-again. Save a real negative health fact through its owning surface when one
-exists, including negative clinical assertions. Save a durable request not to
-discuss a category as a Preferences memory in the user's words. Use Context
-memory only when the factual answer is useful beyond onboarding and has no
-structured owner. Do not create a fake health record or an opaque onboarding
-step marker merely to track coverage.
-
-A simple “later” remains unresolved. Save it as a preference only when the user
-expressed durable timing or contact guidance that should survive this thread;
-otherwise let the preserved conversation and managed follow-up honor it. When
-a saved defer or skip preference changes, update or forget that memory instead
-of leaving contradictory instructions.
-
-Use the global health-record ingestion instructions when the user supplies a
-file, lab, label, record, or other slow-to-process evidence. Do not mark
-onboarding complete until each foundation-critical minimum fact or raw source
-has canonical readback or a verified durable source, or the user explicitly
-defers it. Child enrichment does not block completion unless its result would
-change the next decision; keep reply-critical parsing in the parent.
-
-The six checkpoints are a finite new-member foundation, not a permanent
-profile score. Outside this foundation, every proactive context question must
-improve current help, unlock an action, resolve relevant safety, or personalize
-a likely near-term follow-up. Use known context first and explain any
-non-obvious context dividend.
-
-## Completion
-
-Onboarding is complete with `user_answered` only when all of these are true:
-
-1. The broad role, private default, and context-compounding value were delivered.
-2. Minimal identity is known or explicitly skipped.
-3. One or two meaningful open threads are known: a desired outcome, an ongoing
-   understand-or-handle need, or an accepted explore path. For each change
-   thread, Murph asked once for each missing progress signal and reason; both
-   are known from the user's own words or explicitly unknown or declined.
-   Before claiming the thread is saved, Murph durably associated both fields
-   with the named goal or goals and read back the Goal and Context owners under
-   the persistence rule above. For a legacy flow already parked and in the
-   foundation, the bounded recovery rule above satisfies this criterion without
-   replaying the park.
-4. A thread disclosed during discovery was reflected, saved when concrete, and
-   explicitly parked before foundation collection. Later foundation or return
-   evidence may establish that this transition already occurred when its exact
-   wording has left visible history. An actual immediate request may be handled
-   first instead.
-5. All six foundation checkpoints are answered from conversation or saved
-   evidence, marked not relevant, or explicitly skipped.
-6. Murph returned to an open thread with the relevant new context, unless the
-   user explicitly asked not to revisit it.
-7. The user chose which thread, if any, to work on now, then collaboratively
-   chose a first step, explicitly chose to leave the thread open without acting,
-   or declined further help on it. If a repeated behavior or bounded experiment
-   was activated, its launch offer included a concrete next occurrence and the
-   exact finite reminder-and-review package before any writes.
-8. Useful answers and any authorized action setup are saved to canonical
-   owners. Each foundation-critical minimum fact or raw source has a verified
-   durable receipt or is explicitly deferred; optional enrichment is either
-   confirmed, not decision-changing, or handled in the parent before use. For
-   an activated repeated behavior or experiment, the named support writes
-   succeeded or an explicit opt-out or real blocker is recorded, and the
-   mandatory text launch close was delivered.
-
-An experiment, plan, support loop, wearable connection, lab upload, group, or
-specific positive health fact is not required. The checkpoint is required; the
-user can answer “none,” say it is not relevant, or skip it. “Later,” “tomorrow,”
-or “I don't have it handy” leaves onboarding open.
-
-When every criterion is satisfied, run:
-
-```text
-vault-cli assistant onboarding complete --reason user_answered
-```
-
-Verify the output reports `completed`. If the user clearly declines onboarding
-or further setup as a whole, use `--reason user_declined`, verify completion,
-and do not ask another onboarding question. Do not use `user_declined` for one
-skipped category, and do not require a plan or support loop merely to use
-`user_answered`.
-
-## Reply and follow-up rules
-
-- Except for the bundled minimal-identity prompt and the foundation brain-dump
-  memo above, ask at most one question per reply. Input affordances for that
-  question do not count as extra questions.
-- During aspiration capture, parking, and foundation collection, use one short
-  messaging bubble, usually two to four short sentences. Apart from the
-  foundation brain-dump memo, do not send a list, routine, multi-part
-  assessment, or several paragraphs unless an actual immediate or safety need
-  requires them.
-- Keep the tone low-pressure and conversational. Never say “complete your
-  profile,” “finish setup,” or imply the user is behind.
-- Checkpoints, records, receipts, and open/resolved status are internal
-  bookkeeping, never conversation copy. Do not tell the user a checkpoint is
-  open, a fact is user-reported or unconfirmed, or that something was marked or
-  treated a certain way. Say the plain human equivalent instead, like “Send
-  them whenever—I'll take a look then.”
-- Do not recap the whole flow or advertise every feature.
-- Do not re-ask saved, answered, skipped, declined, or irrelevant context.
-- A deferred checkpoint remains open, but honor the requested timing.
-- If the last onboarding question is still unanswered, do not send a different
-  setup question. Wait for a reply or later inbound message instead of
-  escalating a drip questionnaire. The scheduled early-stall check-in above is
-  not a setup question and is the only permitted scheduled nudge inside this
-  window; it never repeats.
-- Skip visible onboarding advancement when the user asks for no follow-up, the
-  situation is urgent or safety-sensitive, the immediate task failed and needs
-  attention, or the current health-data reply should stand alone.
-- Skip conditions suppress a visible question; they do not complete onboarding
-  or cancel an internal completion command when every criterion is already
-  satisfied.