@murphai/murph 1.3.0 → 1.3.1

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

@@ -0,0 +1,285 @@
+# Daily nutrition-card goals
+
+Use the target-authority and canonical-discovery rules below after every explicit
+interactive request to set nutrition targets or receive a numeric daily
+nutrition card, even when the visible context appears to contain a complete
+bundle. Use the proposal workflow only when the complete read proves that the
+member does not already have one unambiguous, unit- and comparator-compatible
+daily target for calories, protein, carbohydrate, fat, and fiber. The owning
+automatic-meal-capture skill may also use this workflow for one first eligible
+managed closeout when a complete all-status Goal read proves that no Goal with
+slug `murph-daily-nutrition-starting-targets` exists in any status. That
+scheduled exception may use only already-known responsible inputs, creates and
+explains one paused proposal in ordinary text, asks no question, attaches no
+card, and never activates the proposal. Once the managed Goal exists in any
+status, later scheduled closeouts may use an accepted active bundle but never
+create, change, or automatically repeat a numeric proposal.
+
+Before using this workflow, read and apply `daily-nutrition-card-safety.md`,
+including its complete canonical memory document, bounded active-condition and
+active-regimen discovery, lifetime procedure-event and encounter-diagnosis
+discovery, 45-day body-measurement read, separate 300-day `pregnancy-test`
+measurement read, and 300-day canonical test-event list plus required detail
+reads. The context snapshot is not completeness proof for any of these owners.
+If any required canonical read is saturated or unavailable,
+or the gate suppresses numeric goals, stop here with no Goal or measurement
+mutation and keep the owning non-numeric or clinical path.
+
+A numeric card request explicitly asks for Murph's goal-aware daily-card
+experience. It authorizes only the one paused canonical proposal below so the
+provisional values do not live in transient assistant state; it does not accept,
+activate, or use those targets. The explanation and explicit later acceptance
+remain required before the proposal can affect a card.
+
+An ordinary verified private meal log carries default attachment intent only.
+It may use an already accepted complete active bundle after every required safety,
+authority, and totals read, but it does not authorize this proposal workflow,
+target setting, or any Goal mutation. When that accepted bundle is absent or any
+card gate fails, return the owning food-journal skill's short truthful fallback.
+
+## Target authority
+
+- Before treating any target bundle as complete or deciding that a metric is
+  missing, run `vault-cli goal list --status active --limit 200 --format json`.
+  If it returns 200 records, the bounded read may be incomplete: fail closed
+  with ordinary text, no Goal or measurement mutation, and no card. Otherwise,
+  run `vault-cli goal show <goal-id> --format json` for every returned active
+  Goal whose list item reports a nonzero `data.metricTargetsCount`. Do not
+  select detail reads by title, slug, domain, context-snapshot visibility, or
+  the default list prefix. Resolve metric identity, unit, comparator, effective
+  date, conflicts, and the 1,200-kcal boundary only after inspecting that
+  complete detail set. Keep this active-target authority read separate from the
+  all-status lookup used below to reuse or honor Murph's managed paused or
+  abandoned proposal; neither read substitutes for the other.
+- Read already-known goals, body measurements, training, weight trend, activity,
+  and stated body-composition direction before asking. Never infer a missing
+  physiological sex input from a name, pronouns, or gender label, and never infer
+  usual activity from a few workouts or one wearable day.
+- A member- or clinician-chosen active target always wins for its metric. Do not
+  replace it, average conflicts, or create a default over it. A range or dynamic
+  target cannot be collapsed into the card's scalar target; ask one narrow
+  question or use ordinary text instead.
+- Comparator compatibility is part of target authority. This point-target card
+  and its managed derivation accept a selected-value target only when its
+  comparator is `between` and its numeric `value` and `highValue` are identical.
+  A one-sided `<`, `<=`, `>`, or `>=` threshold, a non-identical `between`
+  range, or any other target shape remains authoritative canonical state but is
+  incompatible with this workflow. Never translate its bound into a point:
+  do not expose, compare, or copy it into the card; use it for the 1,200 kcal
+  boundary, residual-energy, or fiber calculations; or create, replace, or
+  remove managed targets around it. Use ordinary text or one narrow interactive
+  question without mutation; a scheduled closeout asks nothing and sends no
+  card. Apply this rule before any low-energy check or derivation. Multiple
+  active explicit owners are also ambiguous.
+- Unit compatibility is part of target authority. This fixed-unit workflow
+  accepts only `dietary-calories` in `kcal`, and `protein-grams`, `carbs-grams`,
+  `fat-grams`, and `fiber-grams` in `g`. An explicit target in another unit
+  remains authoritative and must not be overwritten, but its raw value must not
+  be compared with the 1,200 kcal boundary, copied into a card, or used by the
+  residual-energy or fiber calculations. Do not invent a card-specific
+  conversion. Without an existing owning conversion that yields the exact
+  canonical unit, treat the bundle as incomplete and incompatible: perform no
+  managed Goal mutation, use ordinary text or one narrow interactive question,
+  and let a scheduled closeout use ordinary text without a question or card.
+  Apply this rule before any low-energy check or derivation.
+- Effective dates are also part of target authority. Resolve them against the
+  exact card `localDate`: the selected capture date for a scheduled closeout,
+  which may be a historical catch-up date rather than the occurrence date, or
+  the explicitly requested date. Never use wall-clock today as a substitute.
+  The containing Goal applies only when
+  `window.startAt <= localDate` and its optional `window.targetAt` is absent or
+  `localDate <= window.targetAt`. A target inside it also applies only when its
+  optional `startAt` is absent or `startAt <= localDate`, and its optional
+  `targetAt` is absent or `localDate <= targetAt`; both boundaries are
+  inclusive. An out-of-window target remains canonical authority for its own
+  period, but it is not a current owner or conflict: do not copy or expose its
+  value, compare it with the 1,200 kcal boundary, derive from it, or let it
+  cause any managed Goal mutation. If one complete applicable bundle does not
+  remain, use ordinary text or one narrow interactive question with no
+  mutation; a scheduled closeout asks nothing and sends no card.
+- After explicit interactive target-setting intent, if one consolidated question
+  can collect the genuinely missing inputs, ask it once. The one scheduled
+  first-run exception asks no question: if already-known inputs cannot prove a
+  responsible calorie estimate and all five goals, write nothing and keep the
+  ordinary closeout. Until a responsible calorie estimate and all five goals
+  exist, save no active defaults and attach no card.
+
+## Derive a conservative proposal
+
+Keep population guidance separate from Murph's product judgment.
+
+1. **Calories.** Prefer representative measured total energy expenditure, or a
+   member-confirmed usual intake that coincided with a stable multi-week weight
+   trend and usual activity. Otherwise, for adults 19 and older, use the 2023
+   National Academies EER equation only when age, height in centimeters, current
+   weight in kilograms, the physiological sex input supplied for this
+   calculation, and a representative physical-activity category are known:
+
+   - Men: inactive `753.07 - 10.83*age + 6.50*height + 14.10*weight`; low active
+     `581.47 - 10.83*age + 8.30*height + 14.94*weight`; active
+     `1004.82 - 10.83*age + 6.52*height + 15.91*weight`; very active
+     `-517.88 - 10.83*age + 15.61*height + 19.11*weight`.
+   - Women: inactive `584.90 - 7.01*age + 5.72*height + 11.71*weight`; low active
+     `575.77 - 7.01*age + 6.60*height + 12.14*weight`; active
+     `710.25 - 7.01*age + 6.54*height + 12.34*weight`; very active
+     `511.83 - 7.01*age + 9.07*height + 12.56*weight`.
+
+   Treat the result as a starting estimate, not a measured requirement. Use it
+   unchanged for maintenance or recomp. For an explicit muscle-gain direction,
+   start conservatively around 5-10% above maintenance; for an explicit fat-loss
+   direction, start around 10-20% below maintenance and do not begin with a
+   deficit larger than about 500 kcal/day. These adjustments are Murph product
+   judgment informed by limited athlete literature, not DRI prescriptions.
+   Round the final target to the nearest 100 kcal and plan to adjust from a
+   multi-week trend, training performance, hunger, and recovery.
+   If the adjusted or rounded target is below 1,200 kcal/day, stop under
+   `daily-nutrition-card-safety.md`; do not floor it upward, save a Goal, or
+   attach a goal-comparison card.
+2. **Protein preference.** For a generally healthy adult with regular resistance
+   training or a muscle-gain goal, start near 1.6 g/kg/day. Use about 1.4
+   g/kg/day for other regularly exercising adults and 0.8 g/kg/day for a
+   generally healthy non-exercising adult when weight is a responsible
+   reference. Round to the nearest 5 g. This is the preferred derived protein
+   value when more than one macro is missing, not authority to override an
+   explicit metric or an energy-feasibility check.
+3. **One residual-energy algorithm.** Run this only after the calorie target and
+   every explicit protein, carbohydrate, and fat target are proven applicable
+   to the proposal's card date and exact points with comparator `between` and
+   identical endpoints, then prove the calorie target is in `kcal` and each
+   macro target is in `g`. Hold those applicable, compatible explicit targets
+   fixed. Use 4 kcal/g for protein and carbohydrate and 9 kcal/g for fat. Then
+   derive only missing macros:
+
+   - With exactly one macro missing, assign that macro the remaining energy.
+   - With protein plus another macro missing, start from the weight-based protein
+     preference, but clamp it to the feasible value nearest that preference
+     inside the 10-35% protein AMDR that leaves the other missing macro inside
+     its AMDR. If no such value exists, the bundle is infeasible.
+   - With fat and carbohydrate both missing, choose the feasible fat share
+     closest to 30%, or closest to 25% when running or another endurance demand
+     is material; carbohydrate receives the remainder. Fat must remain within
+     20-35% and carbohydrate within 45-65%.
+   - With all three macros missing, apply the protein rule first, then the
+     fat-and-carbohydrate rule.
+
+   Round each derived missing macro to the nearest 5 g, then recompute the full
+   bundle once. Every explicit value must remain unchanged, each macro must be
+   inside its adult AMDR, and `4*protein + 4*carbohydrate + 9*fat` must be within
+   50 kcal of the calorie target. Do not independently reapply percentage
+   defaults after an explicit value consumes part of the energy budget. If the
+   residual is negative, the feasible interval is empty, rounding breaks an
+   AMDR or the 50 kcal tolerance, or known inputs cannot prove one result, do
+   not write or update the Goal. Explain the conflict and ask which explicit
+   target the member wants to change.
+
+   Example: with explicit 2,000 kcal, 150 g protein, and 250 g carbohydrate,
+   fat is the sole missing macro. Residual energy gives about 44 g, which rounds
+   to 45 g; the 2,005 kcal macro total and all three shares pass. With the same
+   calories and protein but explicit 300 g carbohydrate, the residual fat is
+   below its 20% AMDR, so the bundle is infeasible and no Goal write is allowed.
+4. **Fiber.** Start from the adult reference density of 14 g per 1,000 kcal and
+   round to the nearest 5 g. This is population guidance, not a personalized
+   gastrointestinal prescription.
+
+## Save once, explain, then activate
+
+Use the existing canonical Goal owner; add no new state surface.
+
+1. Separately run `vault-cli goal list --limit 200 --format json`, then show only
+   candidate records, to find the managed Goal in any status. If this all-status
+   list is saturated or target authority is ambiguous, do not write or attach a
+   card. Do not use this lookup in place of the complete active-target authority
+   read above.
+2. Reuse at most one Goal with slug `murph-daily-nutrition-starting-targets`.
+   Create it only when absent, with title `Daily nutrition targets`, domain
+   `nutrition`, horizon `ongoing`, and status `paused`. Before that first write,
+   establish one proposal-effective local date. Use the member's explicitly
+   requested effective date when present; otherwise use the selected card
+   `localDate` for a dated card request, including a historical date; otherwise
+   use the engine-supplied current vault-local date for an undated target or
+   card request. Include `window: { startAt: <proposal-effective-localDate> }`
+   in the initial `goal import-json` payload. Do not rely on the Goal owner's
+   write-day default or substitute a wall-clock date. A paused record is the
+   proposal awaiting the member's review; an abandoned or completed record is
+   an opt-out and must not be recreated automatically.
+3. Save only metrics without an explicit owner through
+   `vault-cli goal import-json --input -`. Each point target uses `kind: "metric"`,
+   `evaluation.kind: "selected-value"`, comparator `between`, and identical
+   `value` and `highValue`. Use these stable target ids and metric/unit pairs:
+
+   - `murph-default-dietary-calories`: `dietary-calories`, `kcal`
+   - `murph-default-protein-grams`: `protein-grams`, `g`
+   - `murph-default-carbs-grams`: `carbs-grams`, `g`
+   - `murph-default-fat-grams`: `fat-grams`, `g`
+   - `murph-default-fiber-grams`: `fiber-grams`, `g`
+
+   Reuse the same Goal id and stable target ids on every update. Supplying
+   `metricTargets` replaces that Goal's stored array; every edit or overlap
+   removal must therefore send the complete intended post-update array for the
+   managed Goal. Preserve every unchanged target and stable target id, and omit
+   only a metric deliberately removed because an explicit owner now exists.
+   Never send only the changed or removed target. Read the Goal back and verify
+   the complete retained set and window; never create a duplicate or rewrite an
+   unchanged proposal. Preserve the existing Goal window on every later value,
+   overlap-removal, status, or card-request turn; omit `window` from those
+   patches and never silently rebase it to another requested card date. Change
+   the window only when the member explicitly changes the proposal's effective
+   date, then explain that revision and verify the complete record. Any write
+   that adds or changes a derived managed value must include `status: "paused"`
+   atomically, even when the same Goal was active; this keeps the revised bundle
+   a proposal until the member accepts it. Removing an overlapping metric
+   without adding or changing a derived value may leave the managed Goal active
+   because the explicit owner supplies that metric. A status-only update may
+   omit `metricTargets`.
+4. A turn that creates or changes the paused proposal must be ordinary text,
+   never a card. Briefly name all five effective values, which facts and labeled
+   assumptions materially drove them, and why calories, protein, carbohydrate,
+   fat, and fiber landed there. State the proposal-effective date, especially
+   when it is historical or future. Call the values provisional and invite
+   correction or acceptance. This explanation must happen before the first
+   goal-aware card.
+5. When the member accepts the proposal, first re-run the complete
+   current-context gate in `daily-nutrition-card-safety.md`, including its bounded
+   canonical memory, active-condition, active-regimen, procedure-event,
+   encounter-diagnosis, body-measurement, `pregnancy-test` measurement, and
+   canonical test-event reads. If that gate suppresses numeric guidance, fails, or
+   cannot resolve a saturated read, leave the proposal paused and unchanged,
+   surface no target values, use ordinary non-numeric text, and attach no card.
+   Only after that gate passes, re-read target authority. If a metric has gained an explicit
+   owner, remove it from the managed proposal by sending the complete intended
+   post-update array and read the Goal back. Then run
+   `vault-cli goal save "Daily nutrition targets" --id <goal-id> --status active`
+   and read that same Goal back. When the member changes a proposed value, or a
+   missing metric needs a newly derived replacement after an explicit owner
+   disappears, send the complete intended post-update `metricTargets` array
+   with `status: "paused"` for the same Goal through `goal import-json`,
+   explain the revision briefly, and wait for acceptance. If the member
+   declines, update the same Goal to `abandoned`. Do not silently recalculate
+   accepted values later. If an explicit target appears after activation, send
+   the managed Goal's complete retained array without that overlapping metric;
+   never edit the explicit Goal.
+6. The proposal turn never attaches a card. If an explicit card request caused
+   the proposal, its next unambiguous acceptance may be the first later eligible
+   response: after the complete pre-activation safety gate in step 5 passes,
+   activate and read back the Goal, reuse those identical current-turn safety
+   reads, re-read same-date canonical meal totals, and attach exactly one card
+   in that acceptance response when the pending
+   request is still unambiguous and the card alone completes it. A
+   target-setting-only request, correction, decline, ambiguous acceptance, or
+   compound request remains ordinary text with no card. Otherwise, only a later
+   eligible response with five exact point values in the exact canonical
+   metric/unit pairs resolved from active canonical goals may attach the card.
+   On an interactive card request, explain an existing paused proposal again
+   unless the member is accepting or changing it.
+
+## Evidence register
+
+- [National Academies, 2023 adult EER equations and individual uncertainty](https://www.ncbi.nlm.nih.gov/books/NBK591034/)
+- [National Academies adult AMDR and DRI reference tables](https://www.ncbi.nlm.nih.gov/books/NBK208874/)
+- [ISSN position stand: protein and exercise](https://link.springer.com/article/10.1186/s12970-017-0177-8)
+- [National Academies fiber reference method](https://www.ncbi.nlm.nih.gov/books/NBK208887/)
+- [National Academies energy-risk context and the adult underweight boundary](https://www.ncbi.nlm.nih.gov/books/NBK591042/)
+- [NIH/NHLBI low-calorie diet guidance and nutrient-adequacy limits](https://www.ncbi.nlm.nih.gov/books/NBK278991/)
+- [Critical review of athlete weight-gain guidance and its evidence limits](https://pubmed.ncbi.nlm.nih.gov/35233712/)
+- [Off-season bodybuilding review: surplus and rate-of-gain context](https://pubmed.ncbi.nlm.nih.gov/31247944/)
+- [Meta-analysis: energy deficiency and resistance-training lean-mass gains](https://pubmed.ncbi.nlm.nih.gov/34623696/)

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

@@ -0,0 +1,211 @@
+# Daily nutrition-card safety
+
+Read and apply this complete gate before deriving, saving, or surfacing numeric
+nutrition goals, before activating a paused nutrition proposal, and before every
+`daily_nutrition` attachment, including when five accepted active goals already
+exist and during a scheduled closeout. An active goal records prior acceptance;
+it does not prove that numeric guidance is still safe in the member's current
+context.
+
+- Reuse already-known conversation and vault context. Do not turn a routine card
+  into a universal medical screening checklist, but do not ignore a safety fact
+  that is already known or becomes known later. The context snapshot's visible
+  condition and medication-regimen rows are navigation only, not proof that the
+  canonical active sets are complete, and it does not inject the complete
+  canonical memory document.
+- As part of the same gate, run `vault-cli memory show --format json` and inspect
+  the complete Identity, Preferences, Instructions, and Context memory document
+  for explicit, unambiguous facts relevant to the exclusions below. Reuse an
+  identical current-turn result. A clearly current saved age under 18, or a
+  clearly current saved intuitive-eating or number-sensitive preference,
+  suppresses numeric setup, proposal presentation, every Goal write or
+  activation, and every card. Missing, stale, ambiguous, or conflicting age is
+  unavailable evidence, not a universal block. On an interactive request, ask
+  one narrow age question only when it is necessary to resolve a decision that
+  would otherwise change; a scheduled occurrence asks no question. If the
+  memory read fails or is unreadable, fail closed with ordinary non-numeric
+  text, no Goal or measurement mutation, and no card. Leave an existing paused
+  proposal unchanged.
+- Before deriving, saving, or surfacing numeric nutrition goals and before every
+  goal-aware card, run both `vault-cli condition list --status active --limit 200
+  --format json` and `vault-cli regimen list --status active --limit 200 --format
+  json`. Reuse identical current-turn results. If either list fails or returns
+  exactly 200 records, canonical safety discovery may be incomplete: fail closed
+  with ordinary non-numeric text, no Goal or measurement mutation, and no card.
+  Run no condition or regimen detail reads for a saturated pair. Otherwise, run
+  `vault-cli condition show <condition-id> --format json` for every returned
+  active condition and `vault-cli regimen show <regimen-id> --format json` for
+  every returned active regimen. Inspect the complete detail sets before applying
+  the exclusions below; never select records by title, substance, severity,
+  context-snapshot visibility, or the default list prefix. If any required detail
+  read fails or is unreadable, use the same fail-closed behavior. A scheduled
+  occurrence asks no question when this read is unavailable or suppresses numeric
+  output.
+- Also run `vault-cli event list --kind procedure --limit 200 --format json`
+  and inspect every returned canonical procedure item before numeric setup,
+  proposal presentation, Goal mutation or activation, and every card. Reuse an
+  identical current-turn result. If the list fails, is unreadable, or returns
+  exactly 200 records, discovery may be incomplete: fail closed with ordinary
+  non-numeric text, no Goal or measurement mutation, and no card. Run no
+  procedure detail reads for a saturated list. Otherwise, the list preserves
+  scalar `data.procedure` and `data.status`; when either field is missing or
+  visibly truncated, run `vault-cli event show <event-id> --format json` for
+  that item before deciding. If a required detail read fails or is unreadable,
+  use the same fail-closed behavior. An explicit `completed` status together
+  with an explicit bariatric procedure—such as gastric bypass or Roux-en-Y,
+  sleeve gastrectomy or gastric sleeve, biliopancreatic diversion or duodenal
+  switch, adjustable gastric band or lap band, or bariatric surgery—proves
+  post-bariatric context and suppresses numeric setup, proposal presentation,
+  every Goal write or activation, and every card. `ordered`, `planned`, or
+  `cancelled` status, an unknown or ambiguous status, and an unrelated procedure
+  are not proof of post-bariatric care and do not suppress by themselves.
+  Missing procedure records are unavailable evidence, not proof that no
+  procedure occurred and not a universal block. A scheduled occurrence asks no
+  question and performs no mutation when this read is unavailable or suppresses
+  numeric output.
+- Also run `vault-cli event list --kind encounter --limit 200 --format json`
+  and inspect every returned canonical encounter item before numeric setup,
+  proposal presentation, Goal mutation or activation, and every card. Reuse an
+  identical current-turn result. If the list fails, is unreadable, or returns
+  exactly 200 records, discovery may be incomplete: fail closed with ordinary
+  non-numeric text, no Goal or measurement mutation, and no card. Run no
+  encounter detail reads for a saturated list. Otherwise, for every item whose
+  list data reports a nonzero `diagnosesCount`, run `vault-cli event show
+  <event-id> --format json` and inspect every complete diagnosis entry; never
+  select encounters by title, visit type, context-snapshot visibility, or the
+  default list prefix. If any required detail read fails or is unreadable, use
+  the same fail-closed behavior. A safety-relevant diagnosis with explicit
+  `active` status and `documented` or `suspected` certainty is current
+  suppressing evidence. This includes the exclusions below, such as kidney,
+  advanced liver, significant heart, relevant endocrine, pregnancy,
+  eating-disorder or RED-S, underweight, frailty, or malnutrition context. If a
+  safety-relevant diagnosis has missing or `unknown` status or certainty and
+  its current meaning cannot be resolved safely, fail closed. `inactive`,
+  `resolved`, `history`, or `rule_out` status, `ruled_out` certainty, and an
+  unrelated diagnosis do not prove a current exclusion by themselves. Missing
+  encounter diagnoses are unavailable evidence, not proof that no exclusion
+  exists and not a universal block. A scheduled occurrence asks no question
+  and performs no mutation when this read is unavailable, unresolved, or
+  suppresses numeric output.
+- As part of the same pre-numeric and pre-activation gate, run one bounded
+  lossless canonical-entry read for the current local date: `vault-cli
+  measurement entry list --metric bmi --metric height
+  --metric weight --metric body-weight --from <45-days-before-today> --to
+  <today> --limit 200 --format json`. Reuse an identical current-turn result
+  instead of repeating it. Resolve only the newest unambiguous evidence inside
+  that window: either a direct `bmi` row whose unit is canonically equivalent to
+  `kg/m^2` (including `kg/m2` and `kg_m2`), or height and weight rows that share
+  the same `eventId` and have units that can be converted unambiguously. Do not
+  combine height and weight from different events or dates, and do not use
+  stale, malformed, conflicting, or unit-ambiguous values.
+  A usable adult BMI below 18.5 suppresses numeric goals, every Goal write or
+  activation, and the card. If the read fails, or a 200-record result is
+  saturated without resolving whether usable BMI evidence is present, fail
+  closed for numeric setup, proposal presentation, Goal mutation, activation,
+  and card presentation. Leave an existing paused proposal unchanged and use
+  ordinary non-numeric text. Otherwise missing measurements are unavailable
+  evidence, not a universal block. Never ask a scheduled occurrence for these
+  measurements and never mutate measurement records during this check.
+- Separately run `vault-cli measurement entry list --metric pregnancy-test
+  --from <300-days-before-today> --to <today> --limit 200 --format json`.
+  Reuse an identical current-turn result. The 300-day product window is a
+  conservative buffer over [ACOG's average 280-day pregnancy
+  length](https://www.acog.org/womens-health/faqs/when-pregnancy-goes-past-your-due-date);
+  older rows are stale for this gate. Treat a row as an explicit positive only
+  when its metric is exactly `pregnancy-test`, its unit is exactly `result`, its
+  numeric value is exactly `1`, and its `qualifiers.result` string is `positive`
+  after case and surrounding-whitespace normalization. Any explicit positive in the
+  window suppresses numeric setup, proposal presentation, every Goal write or
+  activation, and every card. It takes precedence over negative evidence in the
+  same window, including a later negative from either pregnancy-evidence owner;
+  a negative test is not strong enough to erase the positive safety signal.
+  Missing, negative, stale,
+  indeterminate, malformed, or qualifier/value-conflicting rows are unavailable
+  evidence, not proof that the member is not pregnant and not a universal
+  block. If this read fails, is unreadable, or returns exactly 200 records, fail
+  closed with ordinary non-numeric text, no Goal or measurement mutation, and
+  no card; leave an existing paused proposal unchanged. Never ask a scheduled
+  occurrence about the result, and never diagnose pregnancy from this gate.
+- Also run `vault-cli event list --kind test --from
+  <300-days-before-today> --to <today> --limit 200 --format json` before numeric
+  setup, proposal presentation, Goal mutation or activation, and every card.
+  Reuse an identical current-turn result. If the list fails, is unreadable, or
+  returns exactly 200 records, fail closed with ordinary non-numeric text, no
+  Goal or measurement mutation, and no card; run no detail reads for a
+  saturated list. Otherwise run `vault-cli event show <event-id> --format json`
+  for every returned test, because generic list output compacts structured
+  `results` to `resultsCount` and can truncate summaries. If any required detail
+  read fails or is unreadable, use the same fail-closed behavior. Never select
+  tests by title, context-snapshot visibility, `resultsCount`, or the default
+  list prefix.
+  Inspect the complete `testName`, `resultStatus`, optional `summary`, and every
+  structured result's `analyte` and optional `textValue`. Treat a test event as
+  explicit positive pregnancy evidence only when all of these are true: its
+  result status is not `pending`; either the test name identifies a urine/serum
+  pregnancy or hCG test, or a structured result analyte identifies pregnancy,
+  hCG, beta-hCG, or human chorionic gonadotropin; and the matching result
+  `textValue` or an unambiguously test-level summary explicitly says
+  `positive`, `detected`, or `pregnant` after case, punctuation, and
+  surrounding-whitespace normalization.
+  Canonical `resultStatus` classifies the result rather than the source report's
+  lifecycle, so `unknown` does not prove that a test is unfinished and may
+  qualify only when the same strict test identity and explicit textual result
+  rules pass. `pending` is unfinished and never qualifies, even if preliminary
+  text says positive.
+  A simple labeled phrase such as `Pregnancy test: positive` is explicit; a
+  negated, qualified, or otherwise ambiguous phrase is not. Do not infer
+  pregnancy from a numeric hCG value, reference range, `abnormal` or `unknown`
+  status/flag alone, test title, or non-result note alone. Any explicit positive
+  within the window suppresses numeric setup, proposal presentation, every Goal
+  write or activation, and every card, and wins over negative evidence from
+  either pregnancy-evidence owner in the same window. Missing, negative, pending,
+  indeterminate, numeric-only, stale, unrelated, or ambiguous test evidence is
+  unavailable rather than proof of non-pregnancy and is not a universal block.
+  Leave an existing paused proposal unchanged. A scheduled occurrence asks no
+  question, performs no mutation, attaches no card, and never diagnoses
+  pregnancy from this gate.
+- Do not derive, save, or surface numeric goals, and do not attach a goal-aware
+  card, for clearly current intuitive-eating or number-sensitive contexts;
+  known or suspected
+  eating disorder, severe restriction, purging, compulsive exercise, rapid or
+  unexplained weight change, under-fueling or RED-S concern; known underweight
+  (including adult BMI below 18.5 when current height and weight are available),
+  frailty, or malnutrition risk; anyone under 18; pregnancy or breastfeeding;
+  glucose-lowering medication; kidney disease, advanced liver disease,
+  significant heart disease, relevant endocrine disease, post-bariatric care,
+  a therapeutic diet, or another clinician-managed nutrition context.
+- Treat a calorie target below 1,200 kcal/day as outside this product's
+  self-directed numeric-card boundary. This applies both to an active canonical
+  target at card time and to an adjusted or rounded derived result before any
+  Goal write. For an existing target, first require that the containing Goal
+  window and target-level dates include the exact card `localDate`; an
+  out-of-window target must neither trigger nor satisfy this gate. Evaluate the
+  boundary only for an exact point `dietary-calories` target in canonical
+  `kcal`: its selected-value comparator must be `between` with identical
+  numeric `value` and `highValue`. A one-sided threshold, non-identical range,
+  or calorie target in any other unit makes the point-target card bundle
+  incompatible. Never compare a threshold bound or incompatible raw number
+  with 1,200, copy it as calories, convert it ad hoc, or use it for macro
+  derivation. In particular, a calorie threshold whose satisfying range
+  includes intake below 1,200 cannot authorize numeric self-directed card
+  feedback. Suppress the card and make no managed Goal mutation. Do not raise a
+  compatible low point target to the boundary and continue; stop numeric setup,
+  keep ordinary supportive text, and use the body-composition or qualified-care
+  owner when the member wants help with the underlying direction. This is a
+  conservative product guard, not a claim that 1,200 kcal is appropriate for
+  every adult.
+- When this gate suppresses a card, keep the owning skill's non-numeric or
+  clinical path. Do not expose stored targets or their assessments in card or
+  fallback text, and do not mutate a Goal merely because the current context
+  suppresses presentation.
+- A scheduled occurrence never gains authority to ask safety-profile questions,
+  solicit target inputs, activate a proposal, or attach a card from provisional
+  targets. The owning automatic-meal-capture skill has one narrower exception:
+  after this complete gate passes, its first eligible managed closeout may use
+  already-known responsible inputs to create and explain one paused proposal
+  when complete all-status Goal discovery proves that the managed Goal has
+  never existed. Every later scheduled occurrence remains card-time-only and
+  may not create, change, or automatically repeat a numeric proposal.
+- On an explicit interactive request, explain the non-numeric boundary briefly
+  when useful and answer through the owning safe path. Do not use the request
+  itself as evidence that the safety gate passed.