@murphai/murph 1.3.0 → 1.3.2

package/node_modules/@murphai/assistant-engine/skills/murph-onboarding/references/aspiration-foundation-delegation.md

@@ -0,0 +1,443 @@
+# Aspiration, foundation, and delegation
+
+Read the top-level `../SKILL.md` first. This reference owns aspiration capture,
+reflect-and-park behavior, the six foundation checkpoints, and onboarding-only
+non-blocking delegation. Read it only when the current turn enters or resumes
+one of those stages.
+
+## 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.
+
+### 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 in
+`persistence-recovery-follow-up.md` and `return-launch-completion.md`.
+
+### 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 in
+`persistence-recovery-follow-up.md`, 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 finite managed
+next-day recovery occurrence in `persistence-recovery-follow-up.md` decide
+whether continuation is timely.
+
+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, injury history, 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 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
+   finite managed next-day recovery occurrence in
+   `persistence-recovery-follow-up.md`. 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.

package/node_modules/@murphai/assistant-engine/skills/murph-onboarding/references/persistence-recovery-follow-up.md

@@ -0,0 +1,155 @@
+# Persistence, recovery, and follow-up
+
+Read the top-level `../SKILL.md` first. This reference owns the early-stall
+one-shot, canonical context persistence, finite scheduled recovery, and reply
+and follow-up constraints. Read it whenever the current turn persists or
+interprets a skip or deferral, handles a scheduled onboarding occurrence, or
+needs the cross-stage reply rules.
+
+#### 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 scheduled continuation belongs only to the finite managed next-day recovery occurrence below.
+```
+
+If the save fails or the tool is unavailable, continue onboarding normally
+without retrying or mentioning it.
+
+
+## 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 in
+`aspiration-foundation-delegation.md` 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 finite managed recovery 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.
+
+
+### Finite three-day recovery
+
+A managed owner may invoke this skill at most once on each of the next three
+local days after the welcome. This fixed window is the only scheduled recovery
+after the early-stall window. Each day's opportunity is consumed whether it
+sends or skips; no occurrence may create, re-enable, extend, rotate, or
+reschedule the owner.
+
+- Read current onboarding state and recent user messages before deciding.
+- If the latest onboarding question is still unanswered, do not repeat its
+  wording and do not rotate to another setup question. A later day's
+  occurrence may instead ask one shorter, natural, low-pressure question that
+  lets the user choose whether to continue, without urgency or escalating
+  pressure.
+- A visible message must contain exactly one easy question. Do not mention
+  setup completion, internal state, schedules, automations, or final attempts.
+- Return skip after an answer, completion, overall decline, request for no
+  follow-up, explicit deferral whose timing should be honored, newer urgent or
+  safety-sensitive context, or evidence too stale or incomplete to support a
+  useful reopening question. Every one of these cases uses the ordinary
+  scheduled notification skip and leaves onboarding state unchanged.
+- Send or skip consumes only the current local day's opportunity. The managed
+  owner ends permanently after day three. Any later member reply resumes
+  through ordinary reply-driven onboarding.
+
+## Reply and follow-up rules
+
+- Except for the bundled minimal-identity prompt in `../SKILL.md` and the
+  foundation brain-dump memo in `aspiration-foundation-delegation.md`, 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 in `aspiration-foundation-delegation.md`, 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. Inside the first-minutes stall window, the
+  scheduled early-stall check-in above is the only permitted nudge and it never
+  repeats. The separate finite three-day recovery rule above owns the only
+  later scheduled exception.
+- 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 the canonical completion operation when every criterion is already
+  satisfied. During the finite scheduled occurrence, leave state unchanged.
+  During ordinary reply-driven onboarding, use the direct command.