@murphai/murph 1.3.0 → 1.3.2

package/node_modules/@murphai/assistant-engine/skills/signup-link/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: signup-link
+description: Use only when a current member explicitly asks for a Murph signup link, invite link, referral link, or shareable link to forward to another person.
+---
+
+# Shareable signup links
+
+The existing group-chat introduction flow remains the default. Do not create a
+link merely because someone mentions a friend, starts a group, asks about an
+earned group referral option, or agrees to introduce Murph.
+
+Only when the current member explicitly asks for a signup, invite, referral, or
+shareable link to forward, call `murph.group_usage` with
+`action="create_signup_referral_link"`. In a group, pass the exact accepted
+`message_ref` from the requester.
+
+Use only the exact returned `signupUrl`; mention `expiresAt` only when useful.
+Treat it as the member's reusable referral link: do not imply that one recipient
+consumes it or that the member needs a fresh link for each later recipient.
+Return the link to the requester. Never choose, contact, or message the
+recipient. Keep the reply focused on this handoff; do not append billing,
+low-usage, group referral, or sponsorship options unless the user also asked about
+them.
+
+Sharing or opening the link does not earn usage, qualify for a group referral
+reward, or guarantee a reward. If a recipient later finishes their own Murph setup through
+an invite attributed to that link and the referral qualifies under server
+policy, Murph adds any referral reward automatically. When helpful, explain that
+distinction in one short sentence. Do not promise a fixed reward or amount that
+the tool did not return.

package/node_modules/@murphai/assistant-engine/skills/strength-training/SKILL.md

@@ -54,8 +54,9 @@ Apply only modifiers that change the plan:
 - `references/coaching.md` — adherence friction, habits, reminders, missed sessions, motivation, or reducing dependence on Murph
 - `references/safety.md` — pain, symptoms, health uncertainty, maximal or high-skill work, special populations, competition, or body-composition risk
 - `references/evidence.md` — source-level justification, disputed claims, confidence calibration, or maintenance of defaults
+- `$MURPH_ASSISTANT_SKILLS_ROOT/tracked-table/SKILL.md` — any private messaging request to start or resume a canonical live workout, update, finish, or correct it, or log or clear one of its sets. Read it again when the member continues one with a short follow-up, or asks to put a workout log in a table, preserve set-by-set notation, or refresh its workout card. Once an exact live workout owns the exchange, use only this execution owner for set confirmations. On messaging routes, use its native compact-table flow instead of Markdown table syntax.
 
-When presenting a named exercise, unfamiliar variation, or movement walkthrough, read `$MURPH_ASSISTANT_SKILLS_ROOT/shared/exercise-catalog-runtime.md` and follow its list/show, image-media, progressive-disclosure, and catalog-gap rules. This skill still owns exercise choice, programming, dose, progression, substitutions, and safety. If catalog media is unavailable, give compact form cues rather than inventing an image workflow.
+When selecting or teaching a named exercise, unfamiliar variation, or movement walkthrough, read `$MURPH_ASSISTANT_SKILLS_ROOT/shared/exercise-catalog-runtime.md` and follow its list/show, image-media, progressive-disclosure, and catalog-gap rules. A setup-only live-workout activation that preserves member-supplied exercise names is not selection or instruction: read `tracked-table` and do not read the catalog reference. This skill still owns exercise choice, programming, dose, progression, substitutions, and safety. If catalog media is unavailable, give compact form cues rather than inventing an image workflow.
 
 The boundaries below apply even when no reference is loaded.
 
@@ -81,6 +82,21 @@ Planning is not activation. Do not silently create a protocol, reminder, check-i
 
 Treat physique photos, body measurements, pain and symptom notes, training logs, and competition health data as private by default. Sharing requires explicit user intent.
 
+### Canonical owner for set confirmations
+
+Choose one canonical write path before loading an execution skill:
+
+- A current workout command or structured card result, or a host-preserved exact `activity_session` reference from the immediately preceding assistant delivery, may identify one live-workout candidate. Read `tracked-table` and no repeated-routine execution skill. Before writing, require a current exact canonical read or a matching successful canonical mutation for that same session. A visible transcript marker, conversational recency, and the previously logged set never identify the owner. Terse wording, several sets across a day, or calling the set part of a routine never redirects a verified live workout into a regimen or experiment occurrence. If the exact workout or set coordinate is unavailable, ask one narrow workout clarification and write nothing.
+- Exact regimen or experiment context owns a repeated occurrence. This includes trusted reminder context whose `supportSeriesId`, exact owner reference, and `plannedOccurrenceAt` identify an occurrence, even when that reminder also carries a `workout_format` template reference. Read the full canonical regimen and, when applicable, exact experiment through `behavior-followthrough` and `experiment-onboarding`. Resolve one exercise, one owner, and one current per-occurrence standard before writing. Conversational recency and the previous logged set are not owner evidence.
+- Only an exact standalone `workout_format` reminder context, with neither of the owners above, starts a new `activity_session` through `tracked-table`. Read that format and log the stated set against the returned workout id. An older unfinished workout remains untouched and never receives the reminder completion.
+- If no path resolves exactly, ask one narrow clarification and write nothing.
+
+Set logging is private-only. In a group conversation, do not read or mutate a participant's private workout, routine, or experiment; acknowledge briefly and ask them to continue in their private Murph conversation.
+
+In the repeated-routine branch, treat each completion reply to one reminder as one occurrence, not as confirmation of an entire day. When one message explicitly confirms multiple sets, write one occurrence per confirmed set against the same resolved exercise and owner, attach the current per-set quantity to every occurrence, then re-read that owner's canonical progress before replying.
+
+An actual cumulative repetition total must come from explicit canonical per-session or per-set quantities. Never derive it from elapsed days, the planned rotation, assumed adherence, expected occurrences, or the current per-set standard. Keep the recorded total, theoretical full-compliance total, and any unknown historical quantity visibly separate. When old logs contain completed sets but not repetitions, give the exact known set count and an honest known subtotal or lower bound instead of fabricating precision.
+
 ## Build the smallest complete answer
 
 1. **Set the decision criterion.** Translate the request into the outcome that should guide tradeoffs. Use neutral language for appearance goals; do not promise spot reduction, rank bodies, or turn appearance into a health verdict.

package/node_modules/@murphai/assistant-engine/skills/tracked-table/SKILL.md

@@ -0,0 +1,292 @@
+---
+name: tracked-table
+description: Use when a private Murph member asks to start or update a live workout, log or correct sets, finish a workout, show a workout table, create a structured tracker, use a native workout card, or refresh a tracked table. Owns canonical live-workout mutations and compact native table presentation.
+---
+
+# Tracked workout and table
+
+## Goal
+
+Make workout logging easier than opening a dedicated tracker while keeping one canonical workout record that the member can inspect for months. Text is the write interface; a compact table is an immutable presentation snapshot.
+
+A single total set count shared by multiple exercises without a per-exercise allocation is not complete or unambiguous. Ask how many sets belong to each exercise and create nothing; never apply the total to every exercise or divide it yourself.
+
+A tracked `compact_table` may add structured `workout` detail for one open or just-finished strength workout. An ordinary `compact_table` remains the right surface for arbitrary tables, historical comparisons, or tracked data that is not one live workout.
+
+## Core invariant
+
+A saved workout format owns the plan: ordered exercises, stable `sourceExerciseId` values, planned sets, and target values. One canonical `activity_session` workout event owns what actually happened: session timing, ordered exercises, completed set values, notes, and the routine reference.
+
+The canonical event is the only mutable authority. Never create a parallel tracker file, table document, memory record, database row, mutable card record, or app-only workout state. Cards are immutable presentation snapshots. The Messages extension is offline and unauthenticated; its controls only insert visible commands into the current composer, and the member still sends the message. Only the normal Murph message path may mutate canonical workout state.
+
+A prior bubble never changes in place. Updating a workout means mutating the canonical event through the guarded command surface, verifying the result, and, when canonical state changes, sending a new snapshot on a supported private card route. The native URL must not contain the canonical event id, member identity, credentials, or write authority.
+
+For ordinary live logging, use the targeted workout commands below. Do not reconstruct and replace the complete nested exercise/set array in model-authored shell arguments. The targeted commands read, preserve, validate, and rewrite the complete canonical structure inside the workout use-case boundary.
+
+## Live workout command surface
+
+- Start: `vault-cli workout start [name]` with either optional `--routine <format lookup>` or one repeated `--exercise 'name=...;sets=...;reps=...'` value per ordered ad-hoc exercise. Never combine `--routine` and `--exercise`. Preserve the returned canonical `eventId`.
+- Read one workout: `vault-cli workout show <evt_id> --format json`.
+- Delete one exact workout: `vault-cli workout delete <evt_id> --expected-revision <n>`. The expected revision must come from the exact approved workout read.
+- Add an exercise: `vault-cli workout exercise add <name> --workout-id <evt_id> --order <n> [--sets <n>]`. An explicit `--sets` count is a finite plan; omitting it creates one targetless log slot.
+- Store a fixed repetition prescription: `vault-cli workout exercise set-reps [exercise] --workout-id <evt_id> --reps <n>`.
+- Log or correct a set: `vault-cli workout set log [exercise] --workout-id <evt_id> --set-order <n>`.
+- Undo one set without shifting later set numbers: `vault-cli workout set clear [exercise] --workout-id <evt_id> --set-order <n>`.
+- Finish an early or targetless session: `vault-cli workout finish --workout-id <evt_id>`.
+
+Saved target values remain in the workout format. A newly started session contains unlogged set coordinates, but no planned target value is copied into an actual set field. A target is not a completed set. Read the referenced routine with `vault-cli workout format show <routineId> --format json` when a card needs target labels; never copy those labels into canonical actuals.
+
+## Required write flow
+
+1. Resolve one candidate only from an exact workout id in the current workout command or structured card result, or from host-preserved immediate causal context that names that exact `activity_session`. The candidate is causal identity, not write authority. Before a requested write, exact-read that candidate unless a successful canonical start or mutation in the current turn already established it, then require the successful write result to identify the same session. A visible transcript marker never identifies the owner. There is no global active or focused workout selector. Never choose a workout by recency.
+2. Once that exact workout owns the exchange, keep every terse or repeated set confirmation on this owner. Never reinterpret it as a regimen or experiment occurrence because the member calls it a routine, spreads sets across the day, or omits the exercise name.
+3. When the exact workout id or set coordinate is genuinely unavailable, ask which workout, exercise, or set the member means without switching record types. Do not block unrelated new work, demand closure metadata for another workout, or create a workout merely to make an earlier assistant claim appear true.
+4. Pass `--workout-id`, one explicit exercise selector, and `--set-order` on every set mutation. Prefer a stable `--exercise-id`; otherwise use exact exercise order or the exact canonical name. Repeated attempts then converge on the same record and coordinate instead of appending or retargeting.
+5. When the member states one exact repetition count for every set of one exercise, immediately persist that smallest exercise-owned fact with `workout exercise set-reps`. Later terse completions may omit `--reps`; the canonical use case copies the stored member fact into that completed set's actual `reps` field. The stored fact fills only an unlogged coordinate; a note, load, or other correction on an already logged set preserves that set's explicit repetitions unless the member supplies a new repetition result. The fact survives provider-thread loss and bounded transcript replay because it belongs to the workout exercise, not assistant memory. Only an explicit new statement that one exact count applies to every set updates the fact before logging that completion. An exact result for one set changes only that set's actual. Clear the fact only when the member withdraws the every-set instruction.
+6. The fixed-repetition fact is never derived from a saved-plan target, prior workout, card target, assistant suggestion, range, AMRAP, or qualitative instruction. When one exact count clearly applies to every exercise in a coordinated list, apply it to each. Ask one narrow question when the count conflicts, is not exact, or its allocation across multiple exercises is unclear. Never carry forward weight, duration, distance, RPE, bodyweight, assistance, added weight, or any other actual field.
+7. Complete all workout mutations requested by the current member message in order, treating each successful command result as verification. Then attach exactly one refreshed structured workout card from the final verified exact snapshot on a supported private card route. A final write that closes a finite workout remains card-eligible as that just-finished workout. Do not attach an intermediate card or add companion prose.
+8. Logging the last pending set of an explicitly finite workout closes that exact workout in the same canonical write. The accepted set completion time is the observed end boundary; do not issue a ceremonial independent finish command.
+9. Use `workout finish` only for explicit early closure or a targetless session. It records `endedAt` and duration but never invents missing set values. A later explicit extra set remains valid when it names that completed workout and exact exercise/set; the successful write moves that workout's observed end boundary to the extra completion.
+
+A bare acknowledgement such as “ok,” “yes,” or “got it” is not a set completion. Keep the last exact coordinate the member identified. If that coordinate still needs an actual result, ask one narrow question; if it already matches, make no workout mutation. Never advance to another set from an acknowledgement.
+
+Create-first replacement is limited to one exact ad-hoc unfinished draft that
+the batch-start command can represent without loss. Historical intent has
+precedence: a request naming yesterday, an older date, a completed workout, an
+older workout id, or an older card stays on the exact-record correction path
+and never enters this start-and-delete workflow.
+A saved format or an exact-reference reminder retains its specialized start
+and exact-record flow. An ordinary request to start a workout does not itself
+authorize deletion.
+
+Before proposing replacement, exact-read the named workout. It qualifies only
+when it has no `endedAt`, routine ownership, completed-set actuals, set notes,
+metrics, heart-rate zones, route, media, attachments, provider workout
+identity, or other member-owned or history-bearing field that the new start
+cannot preserve. Every existing set must be an unlogged placeholder. If any
+eligibility fact is missing or the replacement cannot faithfully represent the
+record, retain the old workout and use the existing exact-record correction
+path; never issue the start-and-delete sequence. A broader historical
+replacement requires a separately specified, loss-aware operation and
+approval.
+
+When the member explicitly directs Murph to replace a qualifying draft, or
+immediately gives an unambiguous affirmative to a bounded proposal, retain its
+canonical id and `lifecycle.revision`. The proposal names the draft that may be
+deleted, says that its original start time, activity type, and session note will
+be preserved unless the member explicitly changes them, and repeats the
+replacement title, every exercise in order, every stated set count, and any
+exact repetition count the member assigned to every set of that exercise.
+
+After explicit approval:
+
+1. Run one `vault-cli workout start <name>` command with the qualifying draft's
+   exact `--started-at`, `--type`, and, when present, `--note`, plus one repeated
+   `--exercise` specification per requested exercise. Change or omit those
+   preserved session fields only when that change was explicitly approved.
+   The start command must contain the complete ordered initial exercise list;
+   never create an empty workout and follow it with exercise mutations.
+2. Verify the successful start result identifies the new canonical `eventId`
+   and contains the complete ordered requested workout. A verified pre-write
+   validation failure stops with the old workout unchanged. If the result is
+   missing, interrupted, or otherwise ambiguous after invocation, treat the
+   approval as consumed: keep the old workout, do not delete it, and never run
+   `workout start` again for that approval.
+3. Recover an ambiguous start before any later creation attempt. Run one bounded
+   `vault-cli workout list --from <old-start-local-date> --to
+   <old-start-local-date> --limit 200 --format json`, exclude the old event id,
+   and exact-read every remaining candidate with `workout show`. A candidate
+   matches only when its `recordedAt` falls between approval and recovery and
+   its title, activity type, session note, preserved start time, complete
+   ordered exercises, set counts, and repetition facts exactly equal the
+   approved replacement. Exactly one match recovers its canonical id and may
+   continue to guarded deletion. With zero matches, multiple matches, an
+   incomplete bounded list, or any failed read, keep every record, disclose the
+   uncertainty and exact candidate ids, and require a fresh bounded member
+   choice. Never retry creation or infer a candidate by recency.
+4. Only after a verified creation or exactly-one recovery, run
+   `vault-cli workout delete <old_evt_id> --expected-revision <proposal_revision>`.
+   Never delete first.
+5. If the guarded delete conflicts or fails, keep both workouts.
+   Never roll back or delete the successfully created replacement. Report the
+   exact ids and failure, reconcile from fresh exact reads, and obtain new
+   approval before any later deletion.
+
+Other unfinished workouts are valid and remain untouched. Omit an unstated set
+count so that exercise gets one targetless pending slot. Pass `reps=<n>` only
+for one exact member-stated integer count that applies to every set; never
+derive it from a range, AMRAP, target, prior workout, or assistant suggestion.
+
+## Scheduled reminder relationship context
+
+A scheduled reminder and its later ordinary private-chat follow-up may carry host-preserved `automationId`, occurrence timestamps, `supportSeriesId`, and exact `contextReferences`. Preservation proves only which ids were stored with the delivered reminder. References are routing and interpretation context, not read or write authority, and native iMessage Reply is not required.
+
+When saving or patching a reminder for a saved workout, resolve the routine with a successful current `vault-cli workout format show <lookup> --format json` read or format-creation result, then copy its returned id into `contextReferences: [{ "entityKind": "workout_format", "entityId": "<exact_format_id>" }]`. If current evidence does not identify exactly one format, save no reference. On a later completion, inspect that exact format before relying on it. Never synthesize the id from reminder text, title, card state, or recency.
+
+An exact `workout_format` reference can authorize starting that routine when the member's current message clearly requests or completes one of its sets. Run `workout start --routine <exact_format_id>`, preserve the returned workout id, and apply only the stated set to that new exact record. An older unfinished workout neither blocks this start nor needs to be closed first. The reminder does not establish any older workout's end time, and Murph never derives one from `durationMinutes`, a reminder time, a later reply, local midnight, plan targets, or last-write time.
+
+When immediate causal context instead names an existing exact workout id, exact-read it with `vault-cli workout show <evt_id> --format json` and mutate only that record. If the message and relationship context do not identify one exact workout and coordinate, ask which one is intended. Missing, completed, or changed coordinates fail closed without retargeting; a completed exact workout may still accept a clearly requested extra set.
+
+The host may preserve one exact `activity_session` reference from a successful live-workout start or matching exact-workout mutation on the immediately preceding assistant delivery. Treat it as causal identity, not write authority: exact-read it, apply only the member-authorized mutation, and require the successful result to identify the same session. An unrelated assistant delivery, a missing reference, multiple session references, or a conflicting result ends implicit continuation; never recover it by recency.
+
+Explicit historical intent remains explicit targeting. A correction naming yesterday, an older date, an older workout id, or an older card updates only that exact historical event; reminder context never redirects it to a different routine or closes another workout as a side effect.
+
+The legacy `workout edit` full-structure replacement remains available only for a deliberate identity-preserving structural operation that the targeted surface cannot express, such as a reorder, addition, or coordinated field edit. Read the complete record first and preserve every unrequested field. Keep an existing `sourceExerciseId` on that same exercise; without one, keep its exact canonical name. Presentation order never proves exercise identity. The CLI refuses a structured replacement that omits, ambiguously matches, or semantically replaces a saved exercise or omits a saved set. Use `--clear-workout` only when the member explicitly wants to remove all structured workout details while preserving the event, and use `vault-cli workout delete <evt_id> --expected-revision <n>` only when they want to remove the entire record and the revision comes from that exact approved read.
+
+## Starting a workout
+
+1. Resolve the requested saved format when the member names one. If there is no reusable plan, preserve the complete ordered list of every distinct exercise the member named, including closely related variations; never collapse or omit one.
+   Dictation and compact messages may omit punctuation. When ordinary coordinated position, angle, grip, stance, or equipment modifiers clearly share one exercise head, expand each modifier into one distinct exercise by carrying the shared exercise head across the list. For example, `standing seated and kneeling cable presses` names `standing cable press`, `seated cable press`, and `kneeling cable press`. Ask one narrow question only when the exercise identities remain genuinely ambiguous; do not ask what ordinary exercise modifiers mean merely because punctuation is absent.
+2. For a complete unambiguous new-workout request, run exactly one `vault-cli workout start`, passing `--routine` only for a saved format already resolved in step 1 or one repeated `--exercise` specification per ad-hoc exercise. Never pass an inline exercise plan as `--routine`, and never retry the start after a card or reply problem. Never combine routine and ad-hoc inputs, and never create an empty workout followed by initial exercise mutations. Starting a new workout is independent of every older unfinished workout and never infers or writes an end for another record.
+3. Put each stated set count in that exercise's initial specification; the count is finite. When no count is stated, omit `sets` so creation supplies one targetless unlogged slot, not a claimed plan or completed set.
+4. Put `reps=<n>` in the initial specification only when the member assigns one exact integer repetition count to every set of that exercise. Use `workout exercise set-reps` only for a later change to that exercise-owned fact.
+5. Preserve the returned canonical event id and pass it to every later mutation. Treat the successful complete start result as verification and use its event id for the card immediately. Read the format separately before presenting planned targets.
+6. On a supported private card route, immediately attach exactly one structured workout card from that verified snapshot and end with no companion prose. For each returned exercise with `memberRepsPerSet`, copy `<n> reps` into every pending set's card target; never drop that canonical target from the widget. Never stop after the start command with a text-only acknowledgement or wait for another card request.
+
+Never use `workout format log` to start a live workout. That command records a completed workout from a format; a live session keeps targets in the format and actual performance in the event.
+
+## iMessage card commands
+
+Commands inserted by an iMessage card use explicit one-based presentation coordinates:
+
+- `Log workout exercise 2 set 1: ...`
+- `Correct workout exercise 2 set 1: ...`
+- `Finish this tracked workout.`
+
+The durable transcript marker—not the inserted sentence or native URL—owns the canonical event id and snapshot instant. Resolve exactly that card's marker. If multiple cards are plausible or the marker is missing, ask which workout rather than choosing the newest record.
+
+Then:
+
+1. Read the exact event with `vault-cli workout show <evt_id> --format json`. A missing or mismatched event fails closed instead of falling through to another workout.
+2. For Finish, run `vault-cli workout finish --workout-id <evt_id>`. An already-completed return is convergence.
+3. Reconcile the card's ordered exercise names and set counts against the exact canonical event. If a displayed coordinate no longer maps uniquely, fail closed. An old card never authorizes overwriting a newer actual.
+4. Map presentation positions to canonical exercise and set `order` values; saved formats may use sparse orders. Use `workout set log ... --workout-id <evt_id> --exercise-order <exercise-order> --set-order <set-order> --require-existing-set` for a card log or correction, passing only member-stated actuals. Use the same selectors for `workout set clear`.
+5. Persist qualitative annotations such as spotted reps on that exact set's canonical `note`.
+6. Treat the successful targeted command result as verification and send the refreshed immutable card.
+
+An exact replay converges on the same coordinate and never appends a duplicate. A clearly requested extra set may append only when the message names the exact workout and exercise/set coordinate; that path may extend a completed finite workout. If a later command conflicts with an existing actual and does not clearly request a correction, ask one narrow question.
+
+## Interpretation rules
+
+- “Bench 185 for 8” may log the next unlogged bench set only when immediate causal context identifies one exact workout and one bench exercise.
+- “Same weight, 6” may reuse only the immediately preceding canonical set for that same exercise, and only because the member explicitly said “same.”
+- “The next set was 8 reps” may target the clearly current exercise only when the exact workout id remains causal. If more than one workout or exercise is plausible, ask one narrow disambiguating question.
+- Never infer weight, repetitions, effort, assistance, rest, or failure from a plan, prior workout, elapsed time, reminder, or assistant suggestion. The only durable carry-forward is the exact member-owned `memberRepsPerSet` fact on that workout exercise.
+- Treat member-defined shorthand as ambiguous until explained. Once defined as spotted repetitions, persist a plain set note such as `note=final rep spotted` or `note=final 2 reps spotted`; do not reinterpret it as assisted-load data.
+- Persist every qualitative annotation on that exact set's canonical `note`. Never leave meaningful notation only in conversation text, an exercise summary, or the card snapshot.
+- An isolated completion with no exact causal workout identity does not authorize choosing an unfinished workout or inventing one. Ask which workout and set is intended.
+
+## Finishing
+
+The canonical set-log owner closes an explicitly finite workout when the accepted write completes its final pending planned set. That same atomic write records the actual result, `endedAt`, and final duration using the accepted completion as the observed end boundary. Do not require independent “I am done” language and do not call `workout finish` afterward merely for ceremony.
+
+Run `vault-cli workout finish --workout-id <evt_id>` only for explicit early closure or a targetless session. When one message contains both an unfinished set result and early closure intent, log that exact set first and then finish the same exact workout. Never derive an older end from a reminder, midnight, stored duration, last-write time, or plan target.
+
+A later clearly requested extra set may be logged against the completed workout's exact id. The accepted extra-set write becomes the new observed end boundary for that workout; the system does not keep all completed workouts globally active in anticipation of this rarer path.
+
+For completed presentation, every planned set without an actual becomes `skipped`. A targetless log slot that remains empty also becomes `skipped` with `target=null`; this preserves structure without turning the slot into a plan or actual performance.
+
+## Building a structured workout card
+
+Use `murph.attach_response_card` with `kind="compact_table"` and structured `workout` detail in a private direct conversation when a verified live or just-finished workout is the primary answer.
+
+Build it from the verified canonical workout event and, when present, its verified workout format:
+
+- `target`: the matching planned set from the verified format, otherwise `null`;
+- `actual` and targetless log-slot coordinates: the verified canonical event.
+
+Do not add `rowHeader`, `columns`, or `rows` to a structured workout card. Text, provider-layout, and native-envelope consumers derive progress directly from `workout.exercises`. Map each planned set in `workout.exercises` to:
+
+- `pending`: no corresponding actual result and the workout is still live;
+- `completed`: a corresponding actual result exists;
+- `skipped`: no corresponding actual result and the workout has ended.
+
+Also include every canonical event set with no matching format set. Use `target=null`; mark it `completed` when an actual result exists, `pending` while the workout is live and the slot is empty, or `skipped` after the workout ends and the slot remains empty. An empty targetless slot is a verified logging coordinate, not evidence of a planned set. Preserve canonical exercise and set order. Build and attach the complete verified card without estimating its encoded size from exercise or set count. The card tool's validation of the actual encoded envelope is authoritative. Never ask the member to delete, merge, or simplify canonical workout data merely to fit the presentation.
+
+Send the complete tool input in this shape, replacing the synthetic values with
+the verified canonical workout snapshot:
+
+```json
+{
+  "card": {
+    "kind": "compact_table",
+    "version": 1,
+    "title": "Strength workout",
+    "subtitle": null,
+    "footer": "Reply with the exercise, set, and result.",
+    "tracking": {
+      "kind": "workout",
+      "entityId": "evt_01K1ABCDEFGHJKMNPQRSTVWXYZ"
+    },
+    "workout": {
+      "version": 1,
+      "state": "active",
+      "exercises": [
+        {
+          "name": "Bench press",
+          "sets": [
+            {
+              "status": "pending",
+              "target": "185 lb × 6–8",
+              "actual": null
+            }
+          ]
+        }
+      ]
+    }
+  }
+}
+```
+
+Use `state="completed"` only after replacing every remaining `pending` set with `skipped`. A completed set always carries `actual`; pending and skipped sets never do.
+
+Set the outer `subtitle` to `null`. Workout state and progress are derived from
+the structured sets, so do not author a second state or progress label there.
+
+The footer is shared verbatim by the interactive native card and the static
+fallback. Keep it channel-neutral: never tell the member to tap an exercise or
+use another control that is unavailable on macOS or without the extension.
+When continuation guidance is useful, tell them to reply with the exercise,
+set, and result.
+
+Set `tracking` to `{ "kind": "workout", "entityId": "<exact evt id>" }`.
+The runtime records the canonical `snapshotAt`, keeps tracking in durable
+transcript text, and strips it from the native URL.
+
+## Card refresh behavior
+
+- After successfully starting or resuming one canonical live workout, use one verified structured workout card as the complete response on a supported private card route. Do not send a text-only start acknowledgement or wait for a separate card request.
+- Fall back to truthful ordinary text only when the card tool is unavailable, the canonical event cannot be verified, any claimed planned targets cannot be verified from their matching format, the card would not completely answer the turn, or the complete card is rejected by the card tool's actual encoded-envelope validation. Do not preempt that validation from an estimated exercise or set count, and do not ask the member to change the saved workout to make a card fit.
+- After completing all ordinary free-form workout mutations requested by the current message, send one refreshed card from the final verified snapshot; do not also repeat the update in prose.
+- After an accepted explicit card command, send the refreshed card as the response; do not also repeat the full workout in prose.
+- Do not send proactive cards without an existing authorized reminder or automation.
+- When a request does not materially change canonical workout state, do not emit a duplicate snapshot solely to acknowledge the no-op.
+
+## Generic and legacy compact tables
+
+Use an ordinary `compact_table` when the member explicitly asks for a table, when a table alone completely answers a non-live-workout request, or when a historical workout does not need the structured drill-down surface.
+
+- Use one flexible row-label column plus one to four compact value columns, with at most eight rows.
+- Prefer short human labels. Do not add columns merely because the schema permits them.
+- Never emit Markdown-table syntax on a messaging route.
+- A compact table cannot be combined with response media or a second response card.
+- Keep `tracking` null for a one-off table that is not backed by canonical state.
+- For a canonical workout snapshot, set the exact workout tracking marker only after re-reading the event.
+
+A message such as “show the workout table” or an update whose current exact command, structured card result, or host-preserved immediate causal context identifies one workout receives a refreshed snapshot on a supported private card route after an exact canonical read. Without that exact identity, do not choose a workout by recency or invent one from an update-like message; ask one narrow disambiguating question.
+
+When an exercise has one to four logged or planned sets and the member asks for a simple table, use the natural set-by-set shape:
+
+- row header: `Exercise`;
+- columns: `Set 1`, `Set 2`, `Set 3`, and `Set 4` as needed;
+- one row per exercise, preserving canonical exercise order;
+- each completed cell: the concise load/reps value plus any verified set note, such as `45 × 6 (final rep spotted)`;
+- each unlogged placeholder: an em dash or equally clear empty-state marker.
+
+Preserve all available set columns and set notes. Do not collapse or discard the fourth set merely to fit a dense grid; the native reader has a stacked four-set presentation. If any exercise has more than four sets, do not silently truncate it. Use a compact summary such as `Exercise | Completed | Latest | Notes`, or readable plain text when the full history is the point.
+
+For a compact-table workout that predates structured `workout` detail, accept an update only when the current exact command, structured card result, or host-preserved immediate causal context identifies one canonical event and coordinate. Before every mutation, re-read that event, use the targeted commands, and preserve all unrelated state. Persist annotations on the canonical set note, including `note=final rep spotted` or `note=final 2 reps spotted`. Never leave meaningful notation only in conversation text, an exercise summary, or a presentation snapshot.
+
+## Fallback
+
+Use readable text when explanation is necessary, the native card is not supported on the route, or the presentation would exceed its bounds. Never claim a write succeeded until the canonical command result proves it.

package/node_modules/@murphai/assistant-engine/skills/workout-csv-import/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: workout-csv-import
+description: Use when a member sends or references a workout-history CSV for import, including Strong, Hevy, an unknown export format, or a large custom spreadsheet whose rows must be grouped into canonical workouts. Owns provider inspection, source preservation, local Python transformation, schema validation, batch import, and replay safety; use strength-training only when programming or interpretation is also requested.
+---
+
+# Workout CSV import
+
+Import the full file with one bounded local transformation and one canonical
+batch write. Keep raw rows out of model context and user-facing replies.
+
+## Choose the owning path
+
+1. Run `vault-cli workout import inspect <readable-file-path> --format json`.
+2. If inspection recognizes Strong or Hevy, follow its plan and use
+   `vault-cli workout import csv`. Resolve any requested provider, timezone,
+   weight unit, or distance unit; that request is not a format failure. Do not
+   bypass this path with Python because the dedicated importer owns immutable
+   raw evidence, snapshot refreshes, corrections, edits, and deletions.
+3. Use the generic workflow only when the dedicated planner cannot recognize
+   the layout. Do not create a new provider adapter or install a parser package
+   for a one-off format.
+
+## Preserve and map an unfamiliar source
+
+Before writing any helper or command output, create one private attempt
+directory under `.runtime/tmp/workout-csv-import/` and keep every ephemeral
+file for this import inside it: the Python helper, inspection and schema
+receipts, transformed JSONL, digest, dry-run/apply/status/readback receipts,
+errors, and summaries. Use an unpredictable attempt name and restrictive
+permissions. Remove the whole attempt directory after success, a clarification,
+or any handled failure. If the process or workspace stops first, do not move
+these files elsewhere for recovery: `.runtime/tmp/**` is excluded from hosted
+snapshots, and canonical source/import-audit state is the later-turn recovery
+owner.
+
+1. Preserve the CSV once with `vault-cli document import <readable-file-path>
+   --source import --title "Workout CSV source" --reuse-exact --format json`.
+   This exact-byte mode reuses a prior live source document across turns instead
+   of minting attempt-local provenance. Keep the
+   returned document id and raw file ref. This is the durable source if mapping
+   cannot safely finish; a temporary script or JSONL file is not durable proof.
+   If exact reuse reports that the prior source document was deleted, stop
+   before Python and event import. Explain that Murph will not silently create a
+   replacement source identity; do not bypass the conflict with ordinary
+   document import in this workout workflow.
+   If exact reuse instead reports incomplete or damaged preserved source
+   evidence, also stop before Python and event import. Explain that the existing
+   evidence needs explicit recovery; never replace or bypass that identity.
+2. Immediately run `vault-cli document workout-import-status <raw-file-ref>
+   --format json`. If `status` is `completed`, the atomic workout import for
+   this exact source completed in an earlier attempt. Stop before Python or
+   JSONL generation and tell the member the source was already imported. If
+   `status` is `partial_conflict`, stop and explain that workout history exists
+   without a whole-source completion receipt and must be resolved before a safe
+   retry. Proceed only when `status` is `not_imported`. The completion receipt
+   remains valid after an imported workout is edited or deleted.
+3. Use a small local Python 3 script with the standard library only. Typical
+   modules include `csv`, `datetime`, `hashlib`, and `json`; when an offsetless
+   wall-clock timestamp has a known IANA timezone, use `zoneinfo.ZoneInfo` so
+   historical and daylight-saving offsets are applied per date. Reject an
+   ambiguous or nonexistent daylight-saving wall time before writing and ask
+   one targeted question when the source cannot disambiguate it. Inspect
+   headers, dialect, bounded samples, row count, and privacy-safe aggregate
+   values locally. Never print the complete source, expand all rows into model
+   context, or make one model or CLI call per row or set.
+4. Run `vault-cli event payload-schema --for import-jsonl --kind
+   activity_session --format json`. Treat that returned schema as authoritative;
+   do not rely on a remembered payload shape.
+5. Determine one source-backed grouping key per workout and map the complete
+   source to one temporary JSONL row per workout. Attach the preserved raw file
+   ref through the schema-supported provenance field. Resolve all consequential
+   meanings: grouping, local date/time and timezone, positive duration, units,
+   activity type, exercise names and order, set order and type, reps, load,
+   distance, and notes. Preserve source values without inventing precision.
+6. If the source cannot prove one of those meanings, ask one targeted question
+   that presents the inferred column mapping and the unresolved choice. Never
+   guess. A user-approved default such as one duration for every workout is
+   valid provenance; an unspoken default is not.
+
+## Make replay behavior explicit
+
+- Do not add model-authored `externalRef` values. Exact-source recovery belongs
+  to the preserved raw reference and immutable event history, not a temporary
+  transformer's namespace or normalization choices.
+- A refreshed export with different bytes is a new source. The generic path
+  cannot safely infer provider corrections, edits, or deletions across exports;
+  disclose that limitation. Strong and Hevy retain those richer semantics.
+- Never blindly retry a failed apply. When the apply child definitely exits
+  without a trusted receipt and the current turn still has the raw ref and
+  temporary JSONL, first verify that the JSONL digest is unchanged and run the
+  exact-source status check again in the same turn. `completed` means the
+  original apply committed: perform a bounded canonical read and report that
+  result without another apply. `partial_conflict` stops for explicit recovery.
+  `not_imported` permits exactly one proof-backed recovery apply of the same
+  verified bytes; confirm its receipt and canonical readback. Never make more
+  than one recovery attempt or more than one successful canonical apply.
+- If the child may still be running, its termination is unknown, the digest
+  changed, status is unavailable, or the canonical lock cannot be trusted, do
+  not retry. Report the genuinely unresolved result. A later-turn status check
+  remains the recovery path only when the original turn or workspace was lost.
+
+## Validate, apply, and verify
+
+1. Write all grouped workouts to one JSONL file in the current private attempt
+   directory. Record its SHA-256 digest and privacy-safe aggregates there:
+   source rows, grouped workouts, ignored rows by reason, and the mapped date
+   range. Do not log raw rows.
+2. Dry-run the complete file:
+
+   `vault-cli event import-jsonl --input @<temporary.jsonl> --source-raw-ref-once <raw-file-ref> --format json`
+
+   Require `receivedCount` to equal the grouped-workout count. Explain any
+   ignored source rows. Stop on validation errors or surprising skips or
+   supersedes; do not narrow the batch until it passes.
+3. Confirm the JSONL SHA-256 is unchanged, then apply those exact bytes once:
+
+   `vault-cli event import-jsonl --input @<temporary.jsonl> --source-raw-ref-once <raw-file-ref> --apply --format json`
+
+4. Treat a successful apply receipt as the batch result. If the command instead
+   returns without a trusted receipt, follow the same-turn status resolution
+   above before replying. Do not leave an immediately provable commit
+   unresolved, and do not retry when the proof conditions are incomplete.
+5. Confirm a bounded, representative selection through canonical `event list`
+   or `show` reads, covering the imported date range when practical. Do not
+   claim a full readback count if the query limit sampled only part of a large
+   import.
+6. Tell the member how many workouts were created, skipped, or updated, the
+   mapped date range, any deliberately ignored rows, and any replay limitation.
+   Never expose internal ids, raw rows, temporary paths, or bookkeeping jargon.

package/node_modules/@murphai/assistantd/dist/client.d.ts

@@ -1,3 +1,5 @@
+export declare const assistantDaemonSessionResolutionWireFields: readonly ['alias', 'approvalPolicy', 'channel', 'codexHome', 'conversation', 'identityId', 'maxSessionAgeMs', 'model', 'modelProvider', 'participantId', 'profile', 'reasoningEffort', 'sandbox', 'sessionId', 'threadId', 'threadIsDirect', 'vault'];
+export declare const assistantDaemonMessageWireFields: readonly ["alias", "approvalPolicy", "channel", "codexHome", "conversation", "identityId", "maxSessionAgeMs", "model", "modelProvider", "participantId", "profile", "reasoningEffort", "sandbox", "sessionId", "threadId", "threadIsDirect", "vault", "codexCommand", "deliverResponse", "deliveryReplyToMessageId", "deliverySubject", "deliveryTarget", "includeEarlySessionOnboarding", "operatorAuthority", "persistUserPromptOnFailure", "prompt", "turnTrigger", "workingDirectory"];
 export interface AssistantDaemonClientConfig {
     baseUrl: string;
     token: string;

package/node_modules/@murphai/assistantd/dist/client.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"client.d.ts","sourceRoot":"","sources":["../src/client.ts"],"names":[],"mappings":"AAMA,MAAM,WAAW,2BAA2B;IAC1C,OAAO,EAAE,MAAM,CAAA;IACf,KAAK,EAAE,MAAM,CAAA;CACd;AAED,wBAAgB,kCAAkC,CAChD,GAAG,GAAE,MAAM,CAAC,UAAwB,GACnC,2BAA2B,GAAG,IAAI,CAepC"}
+{"version":3,"file":"client.d.ts","sourceRoot":"","sources":["../src/client.ts"],"names":[],"mappings":"AAMA,eAAO,MAAM,0CAA0C,YACrD,OAAO,EACP,gBAAgB,EAChB,SAAS,EACT,WAAW,EACX,cAAc,EACd,YAAY,EACZ,iBAAiB,EACjB,OAAO,EACP,eAAe,EACf,eAAe,EACf,SAAS,EACT,iBAAiB,EACjB,SAAS,EACT,WAAW,EACX,UAAU,EACV,gBAAgB,EAChB,OAAO,CACC,CAAA;AAEV,eAAO,MAAM,gCAAgC,4dAanC,CAAA;AAEV,MAAM,WAAW,2BAA2B;IAC1C,OAAO,EAAE,MAAM,CAAA;IACf,KAAK,EAAE,MAAM,CAAA;CACd;AAED,wBAAgB,kCAAkC,CAChD,GAAG,GAAE,MAAM,CAAC,UAAwB,GACnC,2BAA2B,GAAG,IAAI,CAepC"}

package/node_modules/@murphai/assistantd/dist/client.js

@@ -2,6 +2,39 @@ import { isLoopbackHttpBaseUrl } from '@murphai/runtime-state';
 const ASSISTANTD_BASE_URL_ENV_KEYS = ['MURPH_ASSISTANTD_BASE_URL'];
 const ASSISTANTD_CONTROL_TOKEN_ENV_KEYS = ['MURPH_ASSISTANTD_CONTROL_TOKEN'];
 const ASSISTANTD_DISABLE_CLIENT_ENV = 'MURPH_ASSISTANTD_DISABLE_CLIENT';
+export const assistantDaemonSessionResolutionWireFields = [
+    'alias',
+    'approvalPolicy',
+    'channel',
+    'codexHome',
+    'conversation',
+    'identityId',
+    'maxSessionAgeMs',
+    'model',
+    'modelProvider',
+    'participantId',
+    'profile',
+    'reasoningEffort',
+    'sandbox',
+    'sessionId',
+    'threadId',
+    'threadIsDirect',
+    'vault',
+];
+export const assistantDaemonMessageWireFields = [
+    ...assistantDaemonSessionResolutionWireFields,
+    'codexCommand',
+    'deliverResponse',
+    'deliveryReplyToMessageId',
+    'deliverySubject',
+    'deliveryTarget',
+    'includeEarlySessionOnboarding',
+    'operatorAuthority',
+    'persistUserPromptOnFailure',
+    'prompt',
+    'turnTrigger',
+    'workingDirectory',
+];
 export function resolveAssistantDaemonClientConfig(env = process.env) {
     if (env[ASSISTANTD_DISABLE_CLIENT_ENV] === '1') {
         return null;

package/node_modules/@murphai/assistantd/dist/client.js.map

@@ -1 +1 @@
-{"version":3,"file":"client.js","sourceRoot":"","sources":["../src/client.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,qBAAqB,EAAE,MAAM,wBAAwB,CAAA;AAE9D,MAAM,4BAA4B,GAAG,CAAC,2BAA2B,CAAU,CAAA;AAC3E,MAAM,iCAAiC,GAAG,CAAC,gCAAgC,CAAU,CAAA;AACrF,MAAM,6BAA6B,GAAG,iCAAiC,CAAA;AAOvE,MAAM,UAAU,kCAAkC,CAChD,GAAG,GAAsB,OAAO,CAAC,GAAG;IAEpC,IAAI,GAAG,CAAC,6BAA6B,CAAC,KAAK,GAAG,EAAE,CAAC;QAC/C,OAAO,IAAI,CAAA;IACb,CAAC;IAED,MAAM,OAAO,GAAG,4BAA4B,CAAC,GAAG,EAAE,4BAA4B,CAAC,CAAA;IAC/E,MAAM,KAAK,GAAG,4BAA4B,CAAC,GAAG,EAAE,iCAAiC,CAAC,CAAA;IAClF,IAAI,CAAC,OAAO,IAAI,CAAC,KAAK,EAAE,CAAC;QACvB,OAAO,IAAI,CAAA;IACb,CAAC;IAED,OAAO;QACL,OAAO,EAAE,+BAA+B,CAAC,OAAO,CAAC;QACjD,KAAK;KACN,CAAA;AACH,CAAC;AAED,SAAS,4BAA4B,CACnC,GAAsB,EACtB,IAAuB;IAEvB,KAAK,MAAM,GAAG,IAAI,IAAI,EAAE,CAAC;QACvB,MAAM,KAAK,GAAG,uBAAuB,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAA;QAC/C,IAAI,KAAK,EAAE,CAAC;YACV,OAAO,KAAK,CAAA;QACd,CAAC;IACH,CAAC;IACD,OAAO,IAAI,CAAA;AACb,CAAC;AAED,SAAS,+BAA+B,CAAC,OAAe;IACtD,MAAM,OAAO,GAAG,OAAO,CAAC,IAAI,EAAE,CAAA;IAC9B,IAAI,CAAC;QACH,MAAM,GAAG,GAAG,IAAI,GAAG,CAAC,OAAO,CAAC,CAAA;QAC5B,IACE,GAAG,CAAC,QAAQ;YACZ,GAAG,CAAC,QAAQ;YACZ,GAAG,CAAC,MAAM;YACV,GAAG,CAAC,IAAI;YACR,CAAC,GAAG,CAAC,QAAQ,KAAK,EAAE,IAAI,GAAG,CAAC,QAAQ,KAAK,GAAG,CAAC,EAC7C,CAAC;YACD,MAAM,IAAI,KAAK,CAAC,uDAAuD,CAAC,CAAA;QAC1E,CAAC;QACD,IAAI,CAAC,qBAAqB,CAAC,GAAG,CAAC,MAAM,CAAC,EAAE,CAAC;YACvC,MAAM,IAAI,KAAK,CAAC,sEAAsE,CAAC,CAAA;QACzF,CAAC;QACD,OAAO,GAAG,CAAC,MAAM,CAAA;IACnB,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,IAAI,KAAK,CACb,6EAA6E,EAC7E,EAAE,KAAK,EAAE,KAAK,EAAE,CACjB,CAAA;IACH,CAAC;AACH,CAAC;AAED,SAAS,uBAAuB,CAAC,KAAgC;IAC/D,IAAI,OAAO,KAAK,KAAK,QAAQ,EAAE,CAAC;QAC9B,OAAO,IAAI,CAAA;IACb,CAAC;IACD,MAAM,OAAO,GAAG,KAAK,CAAC,IAAI,EAAE,CAAA;IAC5B,OAAO,OAAO,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,IAAI,CAAA;AAC5C,CAAC"}
+{"version":3,"file":"client.js","sourceRoot":"","sources":["../src/client.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,qBAAqB,EAAE,MAAM,wBAAwB,CAAA;AAE9D,MAAM,4BAA4B,GAAG,CAAC,2BAA2B,CAAU,CAAA;AAC3E,MAAM,iCAAiC,GAAG,CAAC,gCAAgC,CAAU,CAAA;AACrF,MAAM,6BAA6B,GAAG,iCAAiC,CAAA;AAEvE,MAAM,CAAC,MAAM,0CAA0C,GAAG;IACxD,OAAO;IACP,gBAAgB;IAChB,SAAS;IACT,WAAW;IACX,cAAc;IACd,YAAY;IACZ,iBAAiB;IACjB,OAAO;IACP,eAAe;IACf,eAAe;IACf,SAAS;IACT,iBAAiB;IACjB,SAAS;IACT,WAAW;IACX,UAAU;IACV,gBAAgB;IAChB,OAAO;CACC,CAAA;AAEV,MAAM,CAAC,MAAM,gCAAgC,GAAG;IAC9C,GAAG,0CAA0C;IAC7C,cAAc;IACd,iBAAiB;IACjB,0BAA0B;IAC1B,iBAAiB;IACjB,gBAAgB;IAChB,+BAA+B;IAC/B,mBAAmB;IACnB,4BAA4B;IAC5B,QAAQ;IACR,aAAa;IACb,kBAAkB;CACV,CAAA;AAOV,MAAM,UAAU,kCAAkC,CAChD,GAAG,GAAsB,OAAO,CAAC,GAAG;IAEpC,IAAI,GAAG,CAAC,6BAA6B,CAAC,KAAK,GAAG,EAAE,CAAC;QAC/C,OAAO,IAAI,CAAA;IACb,CAAC;IAED,MAAM,OAAO,GAAG,4BAA4B,CAAC,GAAG,EAAE,4BAA4B,CAAC,CAAA;IAC/E,MAAM,KAAK,GAAG,4BAA4B,CAAC,GAAG,EAAE,iCAAiC,CAAC,CAAA;IAClF,IAAI,CAAC,OAAO,IAAI,CAAC,KAAK,EAAE,CAAC;QACvB,OAAO,IAAI,CAAA;IACb,CAAC;IAED,OAAO;QACL,OAAO,EAAE,+BAA+B,CAAC,OAAO,CAAC;QACjD,KAAK;KACN,CAAA;AACH,CAAC;AAED,SAAS,4BAA4B,CACnC,GAAsB,EACtB,IAAuB;IAEvB,KAAK,MAAM,GAAG,IAAI,IAAI,EAAE,CAAC;QACvB,MAAM,KAAK,GAAG,uBAAuB,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAA;QAC/C,IAAI,KAAK,EAAE,CAAC;YACV,OAAO,KAAK,CAAA;QACd,CAAC;IACH,CAAC;IACD,OAAO,IAAI,CAAA;AACb,CAAC;AAED,SAAS,+BAA+B,CAAC,OAAe;IACtD,MAAM,OAAO,GAAG,OAAO,CAAC,IAAI,EAAE,CAAA;IAC9B,IAAI,CAAC;QACH,MAAM,GAAG,GAAG,IAAI,GAAG,CAAC,OAAO,CAAC,CAAA;QAC5B,IACE,GAAG,CAAC,QAAQ;YACZ,GAAG,CAAC,QAAQ;YACZ,GAAG,CAAC,MAAM;YACV,GAAG,CAAC,IAAI;YACR,CAAC,GAAG,CAAC,QAAQ,KAAK,EAAE,IAAI,GAAG,CAAC,QAAQ,KAAK,GAAG,CAAC,EAC7C,CAAC;YACD,MAAM,IAAI,KAAK,CAAC,uDAAuD,CAAC,CAAA;QAC1E,CAAC;QACD,IAAI,CAAC,qBAAqB,CAAC,GAAG,CAAC,MAAM,CAAC,EAAE,CAAC;YACvC,MAAM,IAAI,KAAK,CAAC,sEAAsE,CAAC,CAAA;QACzF,CAAC;QACD,OAAO,GAAG,CAAC,MAAM,CAAA;IACnB,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,IAAI,KAAK,CACb,6EAA6E,EAC7E,EAAE,KAAK,EAAE,KAAK,EAAE,CACjB,CAAA;IACH,CAAC;AACH,CAAC;AAED,SAAS,uBAAuB,CAAC,KAAgC;IAC/D,IAAI,OAAO,KAAK,KAAK,QAAQ,EAAE,CAAC;QAC9B,OAAO,IAAI,CAAA;IACb,CAAC;IACD,MAAM,OAAO,GAAG,KAAK,CAAC,IAAI,EAAE,CAAA;IAC5B,OAAO,OAAO,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,IAAI,CAAA;AAC5C,CAAC"}

package/node_modules/@murphai/assistantd/dist/http-protocol.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"http-protocol.d.ts","sourceRoot":"","sources":["../src/http-protocol.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,GAAG,EAAE,MAAM,UAAU,CAAA;AAQ9B,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAA;AAsBzD,KAAK,gCAAgC,GAAG,UAAU,CAAC,qBAAqB,CAAC,kBAAkB,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAChG,KAAK,uBAAuB,GAAG,UAAU,CAAC,qBAAqB,CAAC,aAAa,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAClF,KAAK,8BAA8B,GAAG,UAAU,CAAC,qBAAqB,CAAC,sBAAsB,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAClG,KAAK,sBAAsB,GAAG,UAAU,CAAC,qBAAqB,CAAC,WAAW,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAC/E,KAAK,6BAA6B,GAAG,UAAU,CAAC,qBAAqB,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AACvF,KAAK,2BAA2B,GAAG,UAAU,CAAC,qBAAqB,CAAC,cAAc,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AACvF,KAAK,2BAA2B,GAAG,UAAU,CAAC,qBAAqB,CAAC,aAAa,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AACtF,KAAK,6BAA6B,GAAG,UAAU,CAAC,qBAAqB,CAAC,mBAAmB,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAC9F,KAAK,2BAA2B,GAAG,UAAU,CAAC,qBAAqB,CAAC,gBAAgB,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AACzF,KAAK,6BAA6B,GAAG,UAAU,CAAC,qBAAqB,CAAC,eAAe,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAE1F,iBAAS,gCAAgC,CAAC,OAAO,EAAE,OAAO,GAAG,gCAAgC,CAI5F;AAED,iBAAS,gCAAgC,CAAC,OAAO,EAAE,OAAO,GAAG,uBAAuB,CA0BnF;AAED,iBAAS,uCAAuC,CAAC,OAAO,EAAE,OAAO,GAAG,8BAA8B,CA2BjG;AAED,iBAAS,yBAAyB,CAAC,GAAG,EAAE,GAAG,GAAG,WAAW,CAAC,sBAAsB,CAAC,CAMhF;AAED,iBAAS,wBAAwB,CAAC,GAAG,EAAE,GAAG,GAAG,2BAA2B,CAIvE;AAED,iBAAS,0BAA0B,CAAC,GAAG,EAAE,GAAG,GAAG,6BAA6B,CAU3E;AAED,iBAAS,oCAAoC,CAAC,OAAO,EAAE,OAAO,GAAG,2BAA2B,CAO3F;AAED,iBAAS,yBAAyB,CAAC,GAAG,EAAE,GAAG,GAAG;IAC5C,QAAQ,EAAE,MAAM,CAAA;IAChB,KAAK,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CACtB,CAUA;AAED,iBAAS,sCAAsC,CAAC,OAAO,EAAE,OAAO,GAAG,6BAA6B,CAqC/F;AAED,iBAAS,oCAAoC,CAAC,OAAO,EAAE,OAAO,GAAG,2BAA2B,CAwB3F;AAED,iBAAS,sCAAsC,CAC7C,GAAG,EAAE,GAAG,EACR,OAAO,EAAE,OAAO,GACf,6BAA6B,CAmC/B;AAED,iBAAS,0BAA0B,CAAC,GAAG,EAAE,GAAG,GAAG;IAC7C,GAAG,EAAE,MAAM,CAAA;IACX,KAAK,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CACtB,CAUA;AAED,iBAAS,6BAA6B,CAAC,GAAG,EAAE,GAAG,GAAG;IAChD,GAAG,EAAE,MAAM,CAAA;IACX,KAAK,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CACtB,CAKA;AA0BD,iBAAS,2BAA2B,CAAC,GAAG,EAAE,GAAG,GAAG;IAC9C,GAAG,EAAE,MAAM,CAAA;IACX,KAAK,CAAC,EAAE,MAAM,CAAA;IACd,KAAK,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CACtB,CAWA;AA6WD,iBAAS,+BAA+B,CAAC,KAAK,EAAE,OAAO,GAAG,MAAM,CA4B/D;AAED,iBAAS,8BAA8B,CACrC,KAAK,EAAE,OAAO,EACd,UAAU,EAAE,MAAM,GACjB;IACD,IAAI,CAAC,EAAE,MAAM,CAAA;IACb,KAAK,EAAE,MAAM,CAAA;CACd,CAWA;AAWD,cAAM,yBAA0B,SAAQ,KAAK;IAGzC,QAAQ,CAAC,UAAU,EAAE,MAAM;IAC3B,QAAQ,CAAC,IAAI,CAAC,EAAE,MAAM,GAAG,IAAI;IAH/B,YACE,OAAO,EAAE,MAAM,EACN,UAAU,EAAE,MAAM,EAClB,IAAI,CAAC,EAAE,MAAM,GAAG,IAAI,YAAA,EAI9B;CACF;AAED,OAAO,EACL,yBAAyB,EACzB,8BAA8B,EAC9B,sCAAsC,EACtC,0BAA0B,EAC1B,oCAAoC,EACpC,2BAA2B,EAC3B,6BAA6B,EAC7B,sCAAsC,EACtC,gCAAgC,EAChC,oCAAoC,EACpC,yBAAyB,EACzB,uCAAuC,EACvC,0BAA0B,EAC1B,yBAAyB,EACzB,wBAAwB,EACxB,gCAAgC,EAChC,+BAA+B,GAChC,CAAA"}
+{"version":3,"file":"http-protocol.d.ts","sourceRoot":"","sources":["../src/http-protocol.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,GAAG,EAAE,MAAM,UAAU,CAAA;AAY9B,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAA;AAqCzD,KAAK,gCAAgC,GAAG,UAAU,CAAC,qBAAqB,CAAC,kBAAkB,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAChG,KAAK,uBAAuB,GAAG,UAAU,CAAC,qBAAqB,CAAC,aAAa,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAClF,KAAK,8BAA8B,GAAG,UAAU,CAAC,qBAAqB,CAAC,sBAAsB,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAClG,KAAK,sBAAsB,GAAG,UAAU,CAAC,qBAAqB,CAAC,WAAW,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAC/E,KAAK,6BAA6B,GAAG,UAAU,CAAC,qBAAqB,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AACvF,KAAK,2BAA2B,GAAG,UAAU,CAAC,qBAAqB,CAAC,cAAc,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AACvF,KAAK,2BAA2B,GAAG,UAAU,CAAC,qBAAqB,CAAC,aAAa,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AACtF,KAAK,6BAA6B,GAAG,UAAU,CAAC,qBAAqB,CAAC,mBAAmB,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAC9F,KAAK,2BAA2B,GAAG,UAAU,CAAC,qBAAqB,CAAC,gBAAgB,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AACzF,KAAK,6BAA6B,GAAG,UAAU,CAAC,qBAAqB,CAAC,eAAe,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAE1F,iBAAS,gCAAgC,CAAC,OAAO,EAAE,OAAO,GAAG,gCAAgC,CAS5F;AAED,iBAAS,gCAAgC,CAAC,OAAO,EAAE,OAAO,GAAG,uBAAuB,CA+BnF;AAED,iBAAS,uCAAuC,CAAC,OAAO,EAAE,OAAO,GAAG,8BAA8B,CA2BjG;AAED,iBAAS,yBAAyB,CAAC,GAAG,EAAE,GAAG,GAAG,WAAW,CAAC,sBAAsB,CAAC,CAMhF;AAED,iBAAS,wBAAwB,CAAC,GAAG,EAAE,GAAG,GAAG,2BAA2B,CAIvE;AAED,iBAAS,0BAA0B,CAAC,GAAG,EAAE,GAAG,GAAG,6BAA6B,CAU3E;AAED,iBAAS,oCAAoC,CAAC,OAAO,EAAE,OAAO,GAAG,2BAA2B,CAO3F;AAED,iBAAS,yBAAyB,CAAC,GAAG,EAAE,GAAG,GAAG;IAC5C,QAAQ,EAAE,MAAM,CAAA;IAChB,KAAK,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CACtB,CAUA;AAED,iBAAS,sCAAsC,CAAC,OAAO,EAAE,OAAO,GAAG,6BAA6B,CAqC/F;AAED,iBAAS,oCAAoC,CAAC,OAAO,EAAE,OAAO,GAAG,2BAA2B,CAwB3F;AAED,iBAAS,sCAAsC,CAC7C,GAAG,EAAE,GAAG,EACR,OAAO,EAAE,OAAO,GACf,6BAA6B,CAmC/B;AAED,iBAAS,0BAA0B,CAAC,GAAG,EAAE,GAAG,GAAG;IAC7C,GAAG,EAAE,MAAM,CAAA;IACX,KAAK,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CACtB,CAUA;AAED,iBAAS,6BAA6B,CAAC,GAAG,EAAE,GAAG,GAAG;IAChD,GAAG,EAAE,MAAM,CAAA;IACX,KAAK,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CACtB,CAKA;AA0BD,iBAAS,2BAA2B,CAAC,GAAG,EAAE,GAAG,GAAG;IAC9C,GAAG,EAAE,MAAM,CAAA;IACX,KAAK,CAAC,EAAE,MAAM,CAAA;IACd,KAAK,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CACtB,CAWA;AA2XD,iBAAS,+BAA+B,CAAC,KAAK,EAAE,OAAO,GAAG,MAAM,CA4B/D;AAED,iBAAS,8BAA8B,CACrC,KAAK,EAAE,OAAO,EACd,UAAU,EAAE,MAAM,GACjB;IACD,IAAI,CAAC,EAAE,MAAM,CAAA;IACb,KAAK,EAAE,MAAM,CAAA;CACd,CAWA;AAWD,cAAM,yBAA0B,SAAQ,KAAK;IAGzC,QAAQ,CAAC,UAAU,EAAE,MAAM;IAC3B,QAAQ,CAAC,IAAI,CAAC,EAAE,MAAM,GAAG,IAAI;IAH/B,YACE,OAAO,EAAE,MAAM,EACN,UAAU,EAAE,MAAM,EAClB,IAAI,CAAC,EAAE,MAAM,GAAG,IAAI,YAAA,EAI9B;CACF;AAED,OAAO,EACL,yBAAyB,EACzB,8BAA8B,EAC9B,sCAAsC,EACtC,0BAA0B,EAC1B,oCAAoC,EACpC,2BAA2B,EAC3B,6BAA6B,EAC7B,sCAAsC,EACtC,gCAAgC,EAChC,oCAAoC,EACpC,yBAAyB,EACzB,uCAAuC,EACvC,0BAA0B,EAC1B,yBAAyB,EACzB,wBAAwB,EACxB,gCAAgC,EAChC,+BAA+B,GAChC,CAAA"}