@murphai/murph 1.3.0 → 1.3.1

package/node_modules/@murphai/assistant-engine/skills/physical-therapy/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: physical-therapy
-description: Use when a user reports musculoskeletal pain, stiffness, weakness, loss of function, injury, rehabilitation, or return-to-activity needs, or asks for physical-therapy-style assessment or exercises. Reuse relevant conversation and vault context before asking questions. Read before suggesting exercises for a new or materially changed pain complaint.
+description: Use when a user reports musculoskeletal pain, stiffness, weakness, loss of function, injury, rehabilitation, or return-to-activity needs, or asks for physical-therapy-style assessment or exercises. Reuse relevant conversation and vault context before asking questions. Read before recommending exercises, rest, activity restriction, or load changes for a new or materially changed pain complaint.
 ---
 
 # Physical therapy reasoning, self-management, and follow-up
@@ -35,7 +35,7 @@ A useful episode produces the parts below that are appropriate to the case:
 
 - Do not claim to be the user's physical therapist or say Murph can fully replace one.
 - Do not make a definitive diagnosis from chat, a photo, a video, or a home test.
-- Do not anchor on the user's label. Terms such as “pinched nerve,” “tight tendon,” “weak core,” “out of alignment,” or “torn something” are hypotheses or beliefs, not findings.
+- Do not anchor on the user's label or let it choose an acute-injury branch. Terms such as “pinched nerve,” “tight tendon,” “weak core,” “out of alignment,” or “torn something” are hypotheses or beliefs, not findings.
 - Do not equate pain, clicking, or tightness with tissue damage or structural shortening.
 - Do not invent palpation findings, imaging results, exact range-of-motion values, reflexes, strength grades, vascular findings, joint mobility, ligament stability, or tissue damage.
 - Do not use one named special test as proof that a condition is present or absent.
@@ -76,6 +76,8 @@ When presenting a named exercise or movement routine, also read `$MURPH_ASSISTAN
 - Do not announce a “red-flag screen,” “safety gate,” or checklist. Safety routing should normally be invisible unless a specific concern needs explanation.
 - If high-risk information is volunteered or found in relevant current records, skip routine intake and route safety immediately.
 - When a question is needed, pair it with a useful interpretation or low-risk next step whenever possible; do not withhold all value until a form is complete.
+- Match the response to the user's requested time horizon. When they ask for a durable or “permanent” fix, lead with the durable working path and one concrete first step; do not answer mainly with short-term flare management or a bare referral.
+- Rest, activity restriction, and fixed recovery windows are interventions, not neutral defaults while clarifying. Require positive support such as meaningful trauma, loss of function, a clearly aggravating dose, worsening response, or another safety concern. If one missing fact separates acute protection from stable load-related rehabilitation, state the working interpretation and ask that question before restricting activity; preserve tolerated movement in the meantime.
 - Explain why a sensitive or surprising question matters.
 - Invite correction without reciting the vault: “I’m treating this as the same gradual, load-related pattern unless something important has changed.”
 - Mention stored context only when it helps orientation or attribution. Do not surface unrelated diagnoses, medications, or personal details.

package/node_modules/@murphai/assistant-engine/skills/self-management-experiments/SKILL.md

@@ -13,13 +13,26 @@ Turn uncertainty into useful action through small, personalized experiments. Hel
 
 This skill is for behavioral, environmental, routine, communication, and other reversible self-management changes. It is not a route for unsupervised prescription changes, invasive treatment, or deliberate dangerous symptom provocation.
 
-Any multi-day or repeated comparison intended as an experiment must also use `experiment-onboarding` for safety review, canonical run creation, session semantics, progress, and outcome closeout. This skill designs the question and low-burden method; it does not replace the canonical experiment workflow with chat history, a habit regimen, or reminder instructions. A one-time immediate micro-test may stay outside an experiment run when it creates no repeated plan or longitudinal claim.
+Any multi-day or repeated comparison intended as an experiment must also use `experiment-onboarding` for safety review and method completeness. A useful proposal may be given before activation. Only after current authorization does `experiment-onboarding` own canonical run creation, session semantics, progress, and outcome closeout. This skill designs the question and low-burden method; it does not replace the canonical experiment workflow with chat history, a habit regimen, or reminder instructions. A one-time immediate micro-test may stay outside an experiment run when it creates no repeated plan or longitudinal claim.
 
-Use it with `chronic-illness-support` or `chronic-pain-support` when the user wants to try something, change a habit, understand a pattern, compare two routines, or make a repeated decision more intelligently.
+Use it with `chronic-illness-support` or `chronic-pain-support` when the user wants to try something, change a habit, understand a pattern, compare two routines, or make a repeated decision more intelligently, or when the direct turn-priority policy routes a private longitudinal decision here.
+
+## Personalized trial selection
+
+Use longitudinal context as a decision input, not decoration:
+
+- identify the one or two prior facts, responses, failed attempts, timing patterns, or constraints that actually change the choice;
+- let prior partial benefit refine technique, timing, dose, or comparison rather than repeating the same generic suggestion;
+- let a prior failure demote that lever or turn it into the comparison condition;
+- if no useful history exists, say so briefly and still choose the best first low-burden test;
+- do not recap the record or mention history unless it changes the experiment.
 
 ## Operating stance
 
 - Recommend an experiment when action is safe and the answer could change what the user does.
+- Lead the first useful response with a calibrated working assessment, the one or two longitudinal facts that changed the choice, and one selected trial. Make the exact action and technique, timing or dose, duration or comparable occasions, comparison, one meaningful primary outcome, burden or adverse signal, stop rule, and review decision visible. Ask at most one question first, and only when it changes safety or which lever wins.
+- Do not answer an eligible request with a list of hydration, sleep, stress, diet, trigger avoidance, or other general wellness ideas. Keep secondary advice only when needed for safety or to execute the selected trial. The structure matters more than the label; a compact “try this for…” is often better than announcing a formal experiment.
+- Give the useful proposal now. Do not withhold it because run creation, reminders, check-ins, or tracking still need authorization.
 - Do not wait for perfect certainty before starting a low-risk reversible test; let `experiment-onboarding` own baseline timing and never override a selected Health Commons test plan.
 - Prefer one strong question over broad tracking.
 - Optimize for expected benefit, information, feasibility, and low burden—not scientific theater.
@@ -417,6 +430,9 @@ An experiment fails if it:
 - demands publication-level proof before keeping a harmless strategy that clearly helps;
 - continues indefinitely without a review and off-ramp;
 - measures compliance instead of benefit;
-- offers a menu but never recommends the best first test.
+- offers a menu but never recommends the best first test;
+- ignores prior attempts or mentions history without letting it change the lever, technique, timing, dose, comparison, or outcome;
+- ends with generic wellness advice when a safe bounded trial is the selected answer;
+- withholds the useful proposal until the member authorizes persistence, reminders, check-ins, or tracking.
 
 An experiment is ready when it is specific, low burden, risk-calibrated, decision-linked, measurable enough to learn from, and easy to stop.

package/node_modules/@murphai/assistant-engine/skills/shared/exercise-catalog-runtime.md

@@ -33,25 +33,36 @@ programmatically appropriate.
    and the first-launch close are not movement-instruction turns merely because
    the saved plan contains named exercises. Defer catalog media until the first
    instructional turn or until the user asks to see the exercises.
-5. When the current turn is a movement-instruction turn and the delivery surface
-   supports response media:
-   - If any movement being taught is likely unfamiliar or uncommon, attach at
-     least one useful returned catalog image and normally two in the same
-     response. Prioritize the least familiar or most technique-sensitive
-     movements and the setup or endpoint frames that best explain them; attach
-     more only when different movements still need visual explanation.
-   - If the user clearly demonstrates relevant training fluency and every
-     movement being taught is common or already familiar, omit exercise images
-     unless the user asks for them.
-   - Use returned `images[]` with catalog URL, alt text, and source
-     `exercise_catalog:<id>:<step>`. Do not paste image URLs into message text
-     when media delivery exists. If an important movement has no image, say "no
-     catalog image yet"; never imply that an image was attached.
-6. If acute pain or safety requires an immediate action, give the minimal plan
-   now and include available catalog media in the same response. For a known
-   routine the user has already performed, send a concise reference. Provide
-   full steps only when asked, accepted as a walkthrough, or required for
-   safety.
+5. For every routine, keep each dose and instruction concrete. Estimate the
+   exercise time, transition time, and total honestly. Before sending, compare
+   the stated total with the work in the routine and do not pad a short plan to
+   sound more substantial. On Telegram, prefer a Rich Message when its structure
+   makes the routine easier to read or use. The
+   `murph.attach_exercise_routine_card` tool is useful when its standard layout
+   or catalog images fit. The `murph.attach_telegram_rich_content` tool is also
+   valid when a custom or mixed layout is clearer. These tools are presentation
+   options, not exclusive content owners. A card must carry the complete answer,
+   so do not repeat it in final text or combine it with response media. Styled
+   Telegram text is not a Rich Message.
+6. Exercise images are optional, but use them when available and helpful,
+   especially for unfamiliar or technique-sensitive movements. Choose the
+   smallest useful set and keep the complete response at eight images or fewer.
+   For a card, copy each selected catalog image URL, alt, and step exactly.
+   Construct its source as
+   `exercise_catalog:<returned-item-id>:<1-based-position-in-images[]>` and keep
+   the returned order. For Linq/iMessage, use the existing response-media path
+   when images improve the instruction. On Telegram, follow the routine-card
+   tool's per-movement mapping and bounded validation-repair guidance. Keep
+   catalog images inside that card and never use separate response media as its
+   fallback. If the card still cannot attach, use one complete generic Rich
+   Message without images and name every movement separately. Do not paste image
+   URLs into message text when media delivery exists. If an important movement
+   has no useful image, keep the written cue clear and never imply that an image
+   was attached.
+7. If acute pain or safety requires an immediate action, give the minimal plan
+   now. For a known routine the user has already performed, send a concise
+   reference. Provide full steps only when asked, accepted as a walkthrough, or
+   required for safety.
 
 Do not assign reporting homework. When subjective response matters, schedule or
 offer an appropriate check-in instead.

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` 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,6 +54,7 @@ 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. 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.
 
@@ -81,6 +82,14 @@ 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.
 
+### Repeated-set logs and cumulative totals
+
+Repeated-set logging is private-only. In a group conversation, do not read or mutate a participant's private routine or experiment; acknowledge briefly and ask them to continue in their private Murph conversation. In a verified private conversation with several small sets spread across a day, read `$MURPH_ASSISTANT_SKILLS_ROOT/behavior-followthrough/SKILL.md` to resolve the current routine and read `$MURPH_ASSISTANT_SKILLS_ROOT/experiment-onboarding/SKILL.md` when an experiment owns the schedule or records. A terse completion that omits the exercise is not permission to infer it from conversational recency or the previous logged set. Read the full canonical plan records and resolve the unique exercise, owner, and per-set standard for the current member-local date before writing anything. If canonical state does not resolve all three, ask one narrow clarification and do not log a set.
+
+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,202 @@
+---
+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 tracked `compact_table` may add structured `workout` detail for one active 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 optional `--routine <format lookup>`.
+- Resolve: `vault-cli workout active` or `vault-cli workout active --workout-id <evt_id>`.
+- Add an exercise: `vault-cli workout exercise add <name> --order <n> [--sets <n>]`.
+- Log or correct a set: `vault-cli workout set log [exercise]`.
+- Undo one set without shifting later set numbers: `vault-cli workout set clear [exercise] --set-order <n>`.
+- Finish: `vault-cli workout finish`.
+
+Saved target values remain in the workout format. A newly started session contains unlogged set placeholders with stable coordinates, but no planned target value is copied into an actual set field.
+
+A target is not a completed set. When a table needs planned targets, read the referenced routine with `vault-cli workout format show <routineId> --format json` and label those values as targets. Never copy planned targets into actual set fields or claim that they were completed.
+
+## Required write flow
+
+1. Before a mutation, run `vault-cli workout active --format json`. Reuse the exact canonical `evt_<ULID>` returned by that read. If no live workout exists, do not create one from a completion, correction, or acknowledgement alone. Start one only when the current message explicitly requests a new workout, the member accepts the exact bounded recovery offer below, or the bounded exact-reference reminder flow below identifies the routine and set without inference.
+2. After resolving, pass `--workout-id` on every live-workout mutation, including exercise additions and finish. For every set write, pass `--workout-id`, one explicit exercise selector, and `--set-order`. Prefer a stable `--exercise-id`; otherwise use exact exercise order or the exact canonical name. This makes a repeated agent attempt correct the same set rather than append a duplicate.
+3. Pass only actual values the member stated with the completion or values already present on that exact canonical set. The sole carry-forward exception is one exact repetition count the member explicitly applied to every set of one exercise. That repetition count remains member-stated for those set coordinates only while the same workout is active and its establishing message remains available in the current direct conversation. For a later unqualified completion such as “set 2 done,” pass only `--reps` with that count instead of asking again or writing a note-only completion. Do not carry forward weight, duration, distance, RPE, bodyweight, assistance, added weight, or any other actual field; each must be stated with that completion or already exist on that exact canonical set. A repetition count stated with the completion overrides the earlier count. Ask for the repetitions when the earlier repetition prescription is a range, AMRAP or qualitative instruction, conflicts with another count, could apply to more than one exercise, or is no longer available in the current conversation. Never treat a saved-plan target, prior workout, card target, or assistant-authored suggestion as this repetition prescription. Preserve stated units and wording.
+4. Treat the successful command result as the verification read. Acknowledge only what that returned record proves.
+5. After every verified private workout mutation that changes the snapshot—including an ordinary set log, correction, clear, exercise addition, start, resume, or finish—build and attach the refreshed structured workout card as the complete response on a supported private card route. When one current message contains both a set result and unmistakable session-closure intent, log the set and finish before responding, then attach only the completed card. Do not send a text-only acknowledgement or companion prose.
+6. Use `workout set log` again to correct a set. Use `workout set clear` for “undo that set,” “I didn’t do it,” or an accidental log. Clearing preserves the placeholder and later set numbering.
+7. Follow the single finishing rule in `## Finishing`; `workout finish` records `endedAt` and final elapsed duration but never invents missing set values.
+
+A bare acknowledgement such as “ok,” “yes,” or “got it” is not a set completion. Keep the last set coordinate the member explicitly identified. If that exact coordinate still needs an actual result, ask one narrow question about it. If its canonical result already matches, treat the acknowledgement as a conversation-only no-op; never advance to another set from that acknowledgement. The sole exception is a contextual affirmative that directly accepts the exact bounded missing-workout recovery offer below.
+
+Outside the bounded exact-reference reminder flow below, if `workout active` returns no event during a completion request, correction request, or acknowledgement follow-up, fail closed. Do not start a workout to reconcile a prior assistant claim or confirmation. Do not mutate workout state, and do not claim that any set was saved. On this missing-workout turn, first say that no active tracked workout exists and that the set was not saved. When the member already provided one exact exercise, set number, and result, the same response must then ask one bounded recovery question that repeats the complete proposed action: start a new workout with that exercise, create only enough pending set coordinates through the named set with `workout exercise add --sets`, and log only the named set with the stated result. Use the shape “Start a new workout with <exercise>, create sets 1 through <set>, and log only set <set> as <result>?” Do not stop after the no-active statement or replace the exact question with generic retry advice. Otherwise ask only for the missing detail. A contextual affirmative answer to that exact offer authorizes only the proposed start and exact set write; it is not a new completion and cannot advance another set. Re-run `workout active` before acting on the answer. If an active workout now exists, do not retarget the accepted recovery; explain that the workout state changed and ask before writing.
+
+## 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 which ids were stored with the delivered reminder, not that a referenced record exists or is the right mutation target. The references are routing and interpretation context only. They do not grant permission to read or mutate a record, do not replace normal tool checks, and do not require native iMessage Reply. Use the same context when the member sends the next ordinary direct message after the reminder.
+
+When saving or patching a reminder for a saved workout, first resolve the routine with a successful current `vault-cli workout format show <lookup> --format json` read or format-creation result, then copy its returned canonical id into `contextReferences: [{ "entityKind": "workout_format", "entityId": "<exact_format_id>" }]`. If current evidence does not identify exactly one format, save no reference. When consuming that reminder or its later ordinary reply context, require that one exact `workout_format` reference and inspect the saved routine with `vault-cli workout format show <exact_format_id> --format json` before relying on it. Never hide, translate, synthesize, or infer the id from reminder text, a title, a prior card, or conversational recency. A previous-day active workout is not automatically the target merely because it remains open.
+
+When an ordinary private-chat set completion clearly targets the referenced saved routine, run `vault-cli workout active --format json` and inspect the exact format. Continue only when the reference, exercise, set coordinate, and member-stated actual result are all unambiguous. If no workout is active, the current completion plus the exact inspected reminder reference authorizes starting only that routine and logging only that stated set. If the active workout already references that routine, target the exact active event normally.
+
+If a different workout remains active, the reminder identifies the new set but does not establish when the earlier workout ended. Never derive an end from active `durationMinutes`, the reminder time, the later reply time, local midnight, a plan target, or the last-write time. When the current message supplies the earlier workout's exact end time or exact total duration, finish that exact active event with the derived `--ended-at`, then start the referenced routine and log only the stated set. Otherwise make no workout mutation, say that the new set was not saved yet, and ask one narrow question for the earlier workout's end time or total duration. Make that question text-bearing even when voice is preferred, and include the exact proposed routine, `Routine reference: <exact_format_id>`, `Active workout reference: <exact_active_workout_id>`, exercise, set, and stated result so committed transcript replay preserves the complete proposal. Only the immediate answer to that question may continue it: exact-read the recorded format id, exact-read the recorded event with `vault-cli workout active --workout-id <exact_active_workout_id> --format json`, and separately read the sole active workout before acting. Continue only when that exact event remains active and is still the sole active workout. A completed, missing, replaced, or conflicting active event, an ambiguous answer, or an unrelated later message fails closed without mutation and never reuses the proposal.
+
+The existing one-active-workout invariant and live-workout mutation lock remain authoritative for every command. Missing or conflicting references, multiple active workouts, changed state, or ambiguous timing stop rather than reopening, rolling back, or retargeting another workout.
+
+Explicit historical intent remains explicit targeting. A correction naming yesterday, an older date, an older workout id, or an older card should inspect and update that historical event through the existing exact-id path; reminder context never redirects it to a new routine or closes another workout as a side effect.
+
+The legacy `workout edit` full-structure replacement remains available only for a deliberate structural operation that the targeted surface cannot express, such as a requested reorder or full routine rewrite. Read the complete record first and preserve every unrequested field. The CLI refuses a structured replacement that omits a saved exercise or 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>` only when they want to remove the entire record.
+
+## Starting a workout
+
+1. Resolve the requested saved format when the member named one. If there is no reusable plan, start a clearly requested empty session and preserve every distinct exercise the member named, including closely related variations; never collapse one variation into another or silently omit an item. Use exactly a stated set count. When an exercise has no stated count, create one unlogged targetless placeholder as the next log slot, not as a claimed plan or completed set.
+2. Ensure no second private live workout is plausible. Reuse the clearly active event or ask one narrow question rather than creating a duplicate.
+3. Run `vault-cli workout start`, passing `--routine` when using a saved format. The command must preserve plan ownership in the format and start every planned set as an unlogged placeholder containing only canonical event coordinates and actual-state fields.
+4. Treat the returned canonical event as the verified start result. Read the format separately before presenting planned targets.
+
+Never use `workout format log` to start a live workout. That command records a completed workout from a format; a live session deliberately keeps targets in the format and actual performance in the event.
+
+## iMessage card commands
+
+Commands inserted by the iMessage card use explicit one-based coordinates:
+
+- `Log workout exercise 2 set 1: ...`
+- `Correct workout exercise 2 set 1: ...`
+- `Finish this tracked workout.`
+
+The numbers in those sentences are presentation positions, not canonical `exercise.order` or `set.order` values. Resolve them only against the single unambiguous tracked workout card in the same private conversation. Prefer the latest verified snapshot only when it is the sole plausible session. The inserted text carries no record authority. If multiple tracked cards or events are plausible—or a command from an older completed card could otherwise land on a different active workout—ask one narrow question instead of choosing by recency alone. The durable transcript marker contains the canonical event id and snapshot instant; the native URL does not.
+
+Then:
+
+1. Resolve the exact canonical event from the sole plausible durable card marker. A missing or mismatched event fails closed instead of falling through to another live workout.
+2. For Finish, run `vault-cli workout finish --workout-id <evt_id>` directly. The explicit command is replay-safe: an already-completed return is convergence, not failure. Verify that returned event and build the completed card, including skipped planned sets, even when the first reply or card delivery failed after persistence.
+3. For a set log, correction, or clear, run `vault-cli workout active --workout-id <evt_id> --format json`. A completed or stale workout fails closed.
+4. Reconcile the card's ordered exercise names and set counts against the latest canonical event. If the displayed exercise no longer maps to exactly one canonical exercise, or its displayed set position no longer exists, fail closed. An old card never authorizes overwriting newer actual values.
+5. Map the displayed exercise and set positions to that exercise's current canonical `order` values. Do not pass the display numbers through as canonical orders; saved formats may use sparse orders. Use `vault-cli workout set log '<displayed-exercise-name>' --workout-id <evt_id> --exercise-order <canonical-order> --set-order <canonical-order> --require-existing-set` for a card log or correction, passing only member-stated actual values. The exact displayed name and mapped order must both match. Use the same mapped selectors for `workout set clear`.
+6. Persist qualitative annotations such as spotted reps on that exact set's canonical `note`.
+7. Treat the successful targeted command result as the verification read. Only that returned record proves the update.
+8. Send a refreshed immutable structured workout card from the verified event plus verified format.
+
+An exact replay for the same exercise and set coordinate converges on that coordinate and never appends a duplicate. Card actions always require the mapped set to exist; ordinary free-form logging may still append a deliberately requested new set. If the coordinate already has the same actual result, report the saved state. If a later command conflicts with it 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 one live workout and one bench exercise are unambiguous.
+- “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. If two exercises are plausible, ask one narrow disambiguating question.
+- Never infer weight, repetitions, effort, assistance, rest, or failure from a plan, prior workout, elapsed time, or a reminder.
+- 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-level summary, or the card snapshot.
+- If no active workout exists, do not treat an isolated “8 reps” message as authorization to invent one.
+
+## Finishing
+
+Run `vault-cli workout finish --workout-id <evt_id>` only when the member explicitly or unmistakably closes that session. The member may combine closure with a set result in one message, such as “Last set, 45 × 6; I’m done.” Log that exact set first, finish the same workout in the same turn, and build the completed card from the finish result; no separate finish message is needed. Filling every planned placeholder without independent closure language does not finish the workout, because the member may continue with targetless extra sets. A reminder by itself, elapsed time, plan targets, or an earlier-day active record also never proves completion. The returned event must contain the verified `endedAt` and final elapsed duration. Do not fabricate missing set values or copy targets into the event.
+
+For the completed presentation, every planned set without a corresponding actual result becomes `skipped` rather than disappearing. A canonical targetless log slot that remains empty when the session ends also becomes `skipped` with `target=null`; that preserves the verified session structure without turning the slot into evidence of 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.
+
+The outer card remains `compact_table` V1. Set `workout` to:
+
+```json
+{
+  "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>", "snapshotAt": "<canonical verified UTC instant>" }`. The backend 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 every verified ordinary free-form set log, correction, clear, or exercise addition, send the refreshed card as the response; 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 unambiguous update to the single active tracked workout whose table was explicitly established earlier receives a refreshed snapshot on a supported private card route. With no active tracked table, do not invent one from an update-like message. If two workouts are plausible, 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 for the single active tracked workout whose table was explicitly established earlier. Before every mutation, re-read the canonical 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"}