@murphai/murph 1.3.0 → 1.3.1

package/node_modules/@murphai/assistant-engine/skills/murph-onboarding/references/return-launch-completion.md

@@ -0,0 +1,246 @@
+# Return, launch, and completion
+
+Read the top-level `../SKILL.md` first. This reference owns the contextual
+return to an open thread, capability tour, thread choice, first-value launch,
+and canonical foreground completion or overall decline. Load the persistence
+reference too when a completion decision depends on canonical save, skip, or
+deferral evidence.
+
+### 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.
+
+
+## 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 in `persistence-recovery-follow-up.md`. For a legacy
+   flow already parked and in the foundation, the bounded recovery rule in
+   `../SKILL.md` 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.
+
+#### Arm the first personal read
+
+On the ordinary foreground turn that satisfies every `user_answered` criterion,
+first run:
+
+```text
+vault-cli assistant onboarding complete --reason user_answered
+```
+
+Verify the output reports `completed`. Then, on that same foreground completion
+transition, call `murph.automation` once with exactly:
+
+```json
+{"action":"save_onboarding_first_personal_read"}
+```
+
+This structured action is only a trigger. The host owns the immutable automation
+identity, current-conversation route binding, two-minute delay, bounded active
+window, fresh continuity, selected model with high reasoning, and complete
+first-read prompt. Do not call generic `save`, provide instructions, calculate
+timestamps, choose a model, or add fields. The host accepts the action only on
+the single trusted
+ordinary foreground turn that began with onboarding open and has just completed
+it with `user_answered`; it cannot be invoked later, from a scheduled occurrence,
+or to reactivate an archived read. Never complete or arm it before every
+foundation-critical minimum fact or raw source is durable or explicitly
+deferred. Never arm it when the current message says the member asked not to
+receive this read, requested no follow-up, or otherwise revoked this proactive
+outreach.
+
+If the action fails or `murph.automation` is unavailable, do not retry, block
+completion, roll back completion, or mention the failure. Do not promise a later
+read. If it succeeds, retain that fact for the completion close below. When the
+first-personal-read save succeeded, add one natural sentence or short paragraph
+to the ordinary completion or first-launch close with this meaning: “I'm going
+to take a proper look across what you shared and any data you connected. If I
+find something genuinely useful—whether that's a pattern, a clearer
+interpretation, or something worth watching next—I'll send it over. You can
+keep texting me normally in the meantime.” Do not mention exact timing,
+schedules, automations, agents, or promise a surprising finding. 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 call the first-read action. Do not use `user_declined` for one
+skipped category, and do not require a plan or support loop merely to use
+`user_answered`.
+
+During a finite three-day recovery occurrence, do not run the completion
+command or otherwise mutate onboarding state. Return an ordinary scheduled
+notification skip when the evidence already answers the checkpoint, declines
+onboarding, defers it, or makes another question untimely or unhelpful. Only a
+later foreground user reply may advance or complete onboarding through the
+canonical state owner.

package/node_modules/@murphai/assistant-engine/skills/music-generation/SKILL.md

@@ -1,169 +1,37 @@
 ---
 name: music-generation
-description: |
-  How Murph writes the prompt for the generate_song tool so ElevenLabs
-  Eleven Music returns the track you intended. Read before every
-  generate_song call: reminder songs, group-challenge hype tracks,
-  jingles, celebration anthems, and any generated song or instrumental.
-  Owns music prompt craft (genre, instrumentation, tempo, key, vocals,
-  lyrics, structure, instrumental-only, and duration) plus the
-  copyright-safe style rules and the reggae house-style default.
-  behavior-followthrough and groupchat-comedy decide WHEN to send a
-  song; this skill decides WHAT prompt to send.
+description: Public fallback for generated-music behavior in builds without Murph Hosted's managed music policy.
 ---
 
 # Music generation
 
-This skill governs the `prompt` you hand to the `generate_song` tool. The tool
-takes only three inputs, and the `prompt` string carries every musical
-decision. Writing that prompt well is the whole job.
-
-## The tool
-
-`generate_song` (murph namespace) generates one original track with ElevenLabs
-Eleven Music and attaches it to your final response as a native voice memo.
-
-- `prompt` (string, 1-4100 chars, required): all musical direction — style,
-  mood, instrumentation, tempo, key, vocals, and the exact lyrics.
-- `durationSeconds` (integer, 3-300, default 30): track length. Reminder songs
-  sit at 15-30s.
-- `instrumental` (boolean, default false): `true` produces no vocals.
-
-Constraints to plan around:
-
-- It does not send on its own — it attaches the song to the reply you compose.
-- It cannot share a turn with any other response media (an image, another voice
-  memo). The song is the reply's only media item, but it may accompany text.
-- It is available only on a deliverable iMessage/Linq or Telegram reply. If the
-  user asked for only the song, attach it and leave the reply text empty unless
-  an owning flow requires accompanying text.
-- Generation can take up to a few minutes.
-- Generated audio cannot be re-sent later. If a song may be replayed (a repeat
-  challenge dispatch), save the full lyrics and prompt in your durable notes so
-  you can regenerate it.
-
-## The prompt is the whole instrument
-
-The model reads only the `prompt` string, plus the length and the instrumental
-flag. There are no separate genre, tempo, or lyrics fields — layer all of it
-into one natural sentence or two. Cover:
-
-- **Genre / style** — be specific. "Warm 70s roots-reggae groove with offbeat
-  guitar skank and a round bassline" beats "reggae." "Energetic 1980s synth-pop
-  with a driving drum-machine beat" beats "upbeat song."
-- **Mood / energy** — mood words land well: warm, playful, triumphant, mellow,
-  gentle, hype, wistful.
-- **Instrumentation** — name the instruments. Prefix a single instrument with
-  **solo** ("solo acoustic guitar").
-- **Tempo and key** — the model follows both. Give a BPM ("90 BPM"), and a key
-  when it matters ("in A major").
-- **Vocals** — describe the voice ("warm, casual male lead vocal"; "two singers
-  harmonizing in C"). Prefix an unaccompanied vocal with **a cappella**.
-- **Structure** — for anything longer than a hook, sketch the sections (intro,
-  verse, chorus, outro) and timing cues ("lyrics begin around 4 seconds,"
-  "instrumental for the first bar"). Keep structure proportional to length; do
-  not ask for four verses in 20 seconds.
-
-## Lyrics
-
-Songs include vocals unless you say otherwise. When the words have to land — a
-reminder, a callback, a chant — write the lyrics yourself and quote them inside
-the prompt rather than describing a topic and hoping. The action has to be
-unmistakable. For example, the `prompt` value:
-
-> Upbeat roots-reggae, ~20s, warm male lead vocal. Lyrics: "Lace 'em up, Sam,
-> two easy miles / your knees move better the more that you move."
-
-Fit the lyrics to the duration, because the model will not: Eleven Music sings
-every quoted word inside the seconds you asked for, so an overlong lyric comes
-back rushed and garbled rather than trimmed. A relaxed vocal carries roughly a
-word and a half per second, and the intro and outro spend a few of those
-seconds before anyone sings — so a 15-second track holds about 18 words, a
-20-second track about 25 (a couplet or two), and a 30-second track about 40.
-The budget scales with the
-duration you request — a 60-second track holds a real verse and chorus, a
-90-second track holds two.
-
-Count the words in your lyrics before calling the tool. If they run over
-budget, fix it from either side: trim the lyric, or ask for a longer track —
-both are fine, as long as words and seconds match. Reminder songs stay short
-and tight. When the song itself is the user-requested main event, give the lyric
-the 45, 60, or 90 seconds it actually needs rather than squeezing it down.
-
-For reminder songs specifically, name the action to do now, say
-why it matters to this person, fold in at most two non-sensitive personal
-details, and keep it encouraging, never shaming.
-
-## Instrumental tracks
-
-Set `instrumental: true` (or add "instrumental only" to the prompt) for a
-focus, background, or celebration bed with no words. Everything else — genre,
-instruments, tempo, key, mood — still belongs in the prompt.
-
-## Duration
-
-`durationSeconds` is 3-300. Reminder songs are 15-30s, and a song that is the
-user-requested main event can comfortably run 45-90s. Pick the duration and the
-lyric together: the track is exactly as long as you ask for, so words beyond
-the budget in the Lyrics section get rushed, not dropped.
-
-## House style and preferences
-
-When the user has no known music preference and nothing else clearly fits
-better, default to a light, upbeat reggae groove — Murph's house style. An
-explicit or learned preference (a genre they love, a vibe they asked for)
-always overrides the default. An owning flow's own default overrides it too:
-a group-chat apology or on-the-hook song defaults to country, because the
-confessional register is what makes the over-earnestness funny
-(`groupchat-comedy` owns that call).
-
-Onboarding does not automatically trigger music. Use this skill during
-onboarding only when the user explicitly asks for a song; that current request
-does not become an onboarding requirement or completion criterion.
-
-## Copyright and safety (hard limits)
-
-- Never name a real artist, band, or song, and never paste copyrighted lyrics.
-  These trip Eleven Music's `bad_prompt` guard and fail the generation.
-  Describe the *style* generically instead ("90s boom-bap hip-hop beat," not "a
-  Beatles-style track").
-- Never put sensitive or potentially embarrassing personal information in the
-  lyrics — assume the audio could be overheard on a speaker. Do not invent
-  personal details.
-
-## Write tight, pick one lane
-
-A longer prompt is not a better prompt. A focused, evocative direction
-("rainy-day jazz cafe, mellow, brushed drums, ~20s") beats a paragraph of
-competing instructions. If two moods fight, choose one.
-
-## When it fails or would delay
-
-If generation fails, or a time-sensitive reminder cannot wait for it, send the
-plain-text version immediately — a song is a delight, never a blocker. Pair a
-reminder song with a one-line text version of the same reminder. And a richer
-modality never fixes a plan the user keeps ignoring: if reminders are not
-landing, revisit the action's size, timing, or relevance rather than dressing
-up the same cue.
-
-## Worked examples
-
-Each of these is a complete `prompt` value.
-
-Reminder song, `durationSeconds: 20`, vocal:
-
-> Upbeat, warm roots-reggae groove around 75 BPM, offbeat guitar skank, round
-> bassline, light percussion, easygoing male lead vocal. Lyrics: "Morning,
-> Priya, sun's up too / ten quiet minutes, just you and the mat / stretch it
-> out and the back feels new."
-
-Focus bed, `durationSeconds: 45`, `instrumental: true`:
-
-> Calm lo-fi study beat, soft Rhodes chords, mellow boom-bap drums around 80
-> BPM, warm vinyl texture, no vocals. Steady and unintrusive for focused work.
-
-Group-challenge hype track, `durationSeconds: 25`, vocal:
-
-> Triumphant brass-forward funk, ~110 BPM, punchy horns, slap bass, tight drums,
-> big gang-vocal chant. Celebratory and a little cocky. Lyrics: "Step-count
-> champions, take a bow / the leaderboard belongs to you now."
+This build does not include Murph Hosted's managed music-selection or
+prompt-craft policy.
+
+This public fallback intentionally contains no managed music-generation
+behavior. Do not infer proactive song eligibility, house style, group-lore
+selection, personalization, or product-flow composition from it.
+
+The public tool schema and runtime remain authoritative for tool availability,
+argument limits, media conflicts, attempt limits, delivery, and truthful
+success or failure. This skill cannot create consent, expose private context,
+or widen route or delivery authority.
+
+When the current user explicitly requests an original song or instrumental and
+`murph.generate_song` is admitted, call it and preserve the requested safe
+subject, lyrics, style, instrumentation, mood, vocal direction, and
+instrumental choice. Build the provider-visible prompt only from the minimum
+song content the member supplied or explicitly asked Murph to use; do not mine
+unrelated private context. If the member asks for only the song, leave the
+final response text empty after successful generation.
+
+A complete independently authorized owning-flow contract may also require a
+song and supply exact bounded prompt fields. This loaded skill shapes prompt
+craft after either authorization signal; it cannot independently authorize a
+call. Otherwise do not call the tool.
+
+Never invent personal details, include sensitive or potentially embarrassing
+information, name a real artist, song, show, or franchise in the generator
+prompt, or copy protected lyrics. Express requested style through generic
+musical traits. If generation is unavailable, state the capability limitation
+plainly. Report generation and delivery failures truthfully.

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

@@ -1,15 +1,16 @@
 ---
 name: nutrition-strategy
-description: Use for forward-looking nutrition decisions about meal structure, protein, training fuel, recovery eating, hydration, appetite, under-fueling, and real-life food-system execution. Use food-journal for capture, body-composition for fat loss, muscle gain, recomposition, weight or waist trends, and gut-digestion for digestive symptom strategy.
+description: Use for forward-looking nutrition decisions about meal structure, named diets and dietary patterns, protein, training fuel, recovery eating, hydration, appetite, under-fueling, and real-life food-system execution. Use food-journal for capture, body-composition for intentional body change, gut-digestion for digestive symptom strategy and elimination or reintroduction, and clinical owners for therapeutic diets or medically complex cases.
 ---
 
 # Nutrition strategy
 
-Use this as Murph operating guidance for practical food choices and repeatable food systems. It is not the owner for body-composition strategy or digestive symptom strategy.
+Use this as Murph operating guidance for practical food choices, named-diet evaluation, and repeatable food systems. It is not the owner for body-composition strategy, digestive symptom strategy, or clinician-managed therapeutic diets.
 
 ## Owns
 
 - Meal structure, food defaults, grocery/cooking/access constraints, and emergency options.
+- Understanding, comparing, adapting, and executing named diets or dietary patterns when the main job is an ordinary forward-looking food decision.
 - Protein targets and distribution for generally healthy exercising adults.
 - Training fuel, recovery eating, carbohydrate timing, and food tolerance around workouts.
 - Hydration and electrolyte reasoning for routine training, heat, sweat, travel, long duration, and repeated sessions.
@@ -30,7 +31,13 @@ Food-journal answers "what happened?" This skill answers "what should we do next
 - Use `experiment-onboarding` after the user chooses one specific food or hydration change to test with a bounded window, outcome, and stop conditions.
 - Use `behavior-followthrough` when reminders, recurring support, accountability, or repeated adherence repair becomes the main job.
 
-Persist only a plan or preference the user accepts, using the best-fit existing surface. Do not duplicate facts across stores.
+Persist only a plan or preference the user accepts, using the best-fit existing
+surface. The narrow paused daily-card proposal below has two initiation paths:
+an explicit numeric-card request, or the first eligible managed automatic meal
+closeout when the complete canonical read proves that no managed proposal has
+ever existed. Either path authorizes only that canonical draft so provisional
+values do not live in transient assistant state; it remains unusable until
+later acceptance. Do not duplicate facts across stores.
 
 ## Data First
 
@@ -44,7 +51,71 @@ The lowest useful tracking burden wins:
 - **Light structure:** one or two targets, such as protein occasions, a pre-training snack, carbohydrate during a long session, or a hydration plan.
 - **Quantified:** calories or full macros only when explicitly wanted, materially useful, and safe.
 
-Do not give unsolicited calorie, macro, or weight-loss estimates. Past tracking does not imply current consent. Treat appetite cues as information, not a test of virtue or a guarantee of adequacy.
+Outside the one first-run managed closeout proposal below, do not give
+unsolicited calorie, macro, or weight-loss estimates. Past tracking alone does
+not imply current consent. Treat appetite cues as information, not a test of
+virtue or a guarantee of adequacy.
+
+### Daily nutrition-card goals
+
+An explicit request for a numeric daily nutrition card supplies numeric intent
+for Murph's goal-aware card workflow. The first eligible managed automatic meal
+closeout may also propose once when complete all-status Goal discovery proves
+that no managed proposal has ever existed. Both paths authorize only the paused
+canonical proposal, subject to the safety rules below; neither activates or uses
+the provisional targets. Before every card,
+even when five active goals already exist, read and apply
+`references/daily-nutrition-card-safety.md`. When five usable daily goals are
+missing, also read and follow `references/daily-nutrition-card-goals.md`. The
+safety gate includes its bounded canonical procedure-event and
+encounter-diagnosis discovery plus the separate bounded `pregnancy-test`
+measurement and canonical test-event reads. It
+owns evidence-grounded default derivation, the single canonical Goal proposal,
+and the explanation-before-card sequence. Do not send a goal-less card, create
+a second goal store, or broaden the one scheduled exception into recurring
+unsolicited diet planning.
+
+## Named Diets And Dietary Patterns
+
+A named diet is a rule package, not the user's goal. First identify the job the user is asking for - a definition, comparison, fit decision, practical adaptation, or troubleshooting - and the outcome they actually care about. Answer a direct factual question before asking about goals. Ask one focused question only when the answer would materially change for the user's goal, implementation, or safety.
+
+Do not infer one exact implementation from a label. Briefly define the common version and name variants that would change the tradeoffs. Separate:
+
+- popularity and testimonials;
+- plausible mechanisms;
+- short-term changes in weight or biomarkers;
+- direct health-outcome evidence; and
+- guideline or consensus support.
+
+Popularity is evidence of demand, not efficacy. Say plainly when evidence is indirect, short-term, low-certainty, condition-specific, or absent. Do not overstate causality or make every named diet sound equally supported. Label unsupported claims and fad framing without shaming the user.
+
+Route by the actual goal and risk:
+
+- `food-journal` owns capture and retrospective patterns.
+- `body-composition` owns intentional fat loss, muscle gain, recomposition, weight, and waist strategy; return here for diet execution after it sets direction.
+- `gut-digestion` owns symptom-driven elimination and reintroduction, including low-FODMAP-style work.
+- `cardiometabolic-health`, `chronic-illness-support`, care navigation, and the user's clinician own marker-first, disease-specific, medication-linked, and therapeutic-diet decisions.
+- `micronutrients-supplements` owns supplement evidence, labels, dose, and safety when food adequacy alone is not the question.
+- `experiment-onboarding` owns a bounded test only after the user chooses one specific, safe change.
+
+For ordinary execution, preserve the useful core with the least avoidable restriction. Prefer additions, substitutions, and flexible defaults before bans. Protect adequate energy, protein, carbohydrate when demand requires it, fiber, fats, and relevant micronutrients. Include a restaurant, travel, family-meal, cultural, budget, or emergency-food fallback when it is likely to matter. Do not use purity, moral, identity, or compliance framing. Do not default to a rigid menu, day-by-day meal plan, adherence score, or transformation promise; a few meal structures, swaps, and feedback signals are usually enough.
+
+Child references are progressive disclosure, not separately registered skills. A supported child must be explicitly mapped in this section to `references/named-diets/<slug>.md`. Read at most one mapped child for a narrow question, or two only when the user explicitly compares two patterns and both files materially change the answer. Confirm the mapped file exists before reading it; do not scan the directory, invent an absent file, or preload references. The parent contract owns routing and universal safety, and no child may weaken it.
+
+**Mapped child references in this tranche:**
+
+- Intermittent fasting, time-restricted eating, TRE, 16:8, 14:10, 5:2, alternate-day fasting, ADF, or OMAD -> `references/named-diets/intermittent-fasting.md`.
+- Low-carbohydrate or low-carb eating that is not explicitly ketogenic -> `references/named-diets/low-carbohydrate.md`.
+- Ketogenic or keto diets -> `references/named-diets/ketogenic.md`.
+- Mediterranean or Mediterranean-style diets -> `references/named-diets/mediterranean.md`.
+- Carnivore or animal-based diets -> `references/named-diets/carnivore-animal-based.md`.
+- Vegan, plant-only, whole-food plant-based, or WFPB diets -> `references/named-diets/vegan-plant-based.md`.
+- Vegetarian, lacto-ovo, lacto-vegetarian, ovo-vegetarian, pescatarian, or flexitarian patterns -> `references/named-diets/vegetarian-spectrum.md`.
+- DASH or Dietary Approaches to Stop Hypertension -> `references/named-diets/dash.md`.
+
+For an unmapped named diet, use this parent contract and current authoritative evidence rather than guessing a child reference.
+
+For a named-diet answer, usually cover only what the question needs from: what it is and common variants; what evidence supports and does not support; likely benefits sought; material downsides and who should be cautious; the lowest-risk practical version; feedback and stop conditions; and the right handoff.
 
 ## Practical Levers
 
@@ -127,7 +198,7 @@ After an off-plan meal or day, return to the next normal meal; do not compensate
 
 ## Clinical Boundaries
 
-General education and low-risk meal ideas may still help in medically complex contexts. Condition-specific targets, intentional weight change, supplement dosing, or personalized fluid/electrolyte plans should involve an appropriate clinician or registered dietitian when the user is under 18; pregnant or breastfeeding; using glucose-lowering medication; living with kidney disease, advanced liver disease, significant heart disease, or a relevant endocrine disorder; post-bariatric surgery; managing a severe food allergy or therapeutic diet; or experiencing persistent digestive symptoms, substantial unintentional weight change, or medication-related appetite suppression that prevents adequate intake.
+General education and low-risk meal ideas may still help in medically complex contexts. Condition-specific targets, intentional weight change, supplement dosing, fasting, or personalized fluid/electrolyte plans should involve an appropriate clinician or registered dietitian when the user is under 18; pregnant or breastfeeding; an older adult with frailty, sarcopenia, or low intake; using glucose-lowering medication; living with kidney disease, advanced liver disease, significant heart disease, or a relevant endocrine disorder; post-bariatric surgery; managing a severe food allergy or therapeutic diet; or experiencing persistent digestive symptoms, substantial unintentional weight change, or medication-related appetite suppression that prevents adequate intake.
 
 Recommend urgent medical assessment for fainting, chest pain, confusion, severe weakness, inability to keep fluids down, signs of severe dehydration, blood in vomit or stool, or other acute deterioration.
 
@@ -148,8 +219,8 @@ Use concrete foods as options, not requirements. Explain uncertainty only where
 
 Before responding, check:
 
-- Did I answer a meal-structure, fueling, hydration, under-fueling, or food-system execution question rather than stealing body-composition or digestion ownership?
+- Did I answer a meal-structure, named-diet, fueling, hydration, under-fueling, or food-system execution question rather than stealing body-composition, digestion, marker, supplement, or therapeutic-diet ownership?
 - Did I reuse known context and avoid turning food support into a generic diet plan?
 - Did I use the lowest tracking burden that can answer the question?
-- Did I protect adequacy, autonomy, and the user's relationship with food?
+- Did I separate demand from efficacy and protect adequacy, autonomy, ordinary life, and the user's relationship with food?
 - Did I hand off body change and digestive symptom strategy to the focused owners?