@murphai/murph 1.3.1 → 1.3.2

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

@@ -9,7 +9,9 @@ description: Use when a private Murph member asks to start or update a live work
 
 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.
+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
 
@@ -23,94 +25,166 @@ For ordinary live logging, use the targeted workout commands below. Do not recon
 
 ## 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.
+- 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>`.
 
-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.
+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. 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.
+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 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.
+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, 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 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.
 
-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.
+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.
 
-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.
+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 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.
+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 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.
+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 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.
+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 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.
+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 deliberately keeps targets in the format and actual performance in the event.
+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 the iMessage card use explicit one-based coordinates:
+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 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.
+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. 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.
+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 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.
+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 one live workout and one bench exercise are unambiguous.
+- “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. 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.
+- “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-level summary, or the card snapshot.
-- If no active workout exists, do not treat an isolated “8 reps” message as authorization to invent one.
+- 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
 
-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.
+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 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.
+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
 
@@ -129,24 +203,38 @@ Do not add `rowHeader`, `columns`, or `rows` to a structured workout card. Text,
 
 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:
+Send the complete tool input in this shape, replacing the synthetic values with
+the verified canonical workout snapshot:
 
 ```json
 {
-  "version": 1,
-  "state": "active",
-  "exercises": [
-    {
-      "name": "Bench press",
-      "sets": [
+  "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": [
         {
-          "status": "pending",
-          "target": "185 lb × 6–8",
-          "actual": null
+          "name": "Bench press",
+          "sets": [
+            {
+              "status": "pending",
+              "target": "185 lb × 6–8",
+              "actual": null
+            }
+          ]
         }
       ]
     }
-  ]
+  }
 }
 ```
 
@@ -161,13 +249,15 @@ 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.
+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 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 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.
@@ -183,7 +273,7 @@ Use an ordinary `compact_table` when the member explicitly asks for a table, whe
 - 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.
+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:
 
@@ -195,7 +285,7 @@ When an exercise has one to four logged or planned sets and the member asks for
 
 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.
+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
 

package/node_modules/@murphai/core/dist/automation.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"automation.d.ts","sourceRoot":"","sources":["../src/automation.ts"],"names":[],"mappings":"AAEA,OAAO,EACL,mBAAmB,EACnB,yBAAyB,EAoBzB,KAAK,iCAAiC,EACtC,KAAK,0BAA0B,EAC/B,KAAK,0BAA0B,EAC/B,KAAK,4BAA4B,EACjC,KAAK,8BAA8B,EACnC,KAAK,eAAe,EACpB,KAAK,kBAAkB,EAEvB,KAAK,yBAAyB,IAAI,iCAAiC,EACnE,KAAK,gBAAgB,EACrB,KAAK,qBAAqB,EAC3B,MAAM,oBAAoB,CAAC;AAgE5B,YAAY,EACV,iCAAiC,EACjC,0BAA0B,EAC1B,0BAA0B,EAC1B,eAAe,EACf,kBAAkB,EAClB,gBAAgB,EAChB,qBAAqB,GACtB,CAAC;AAEF,MAAM,WAAW,gBAAgB;IAC/B,aAAa,EAAE,OAAO,yBAAyB,CAAC;IAChD,OAAO,EAAE,OAAO,mBAAmB,CAAC;IACpC,YAAY,EAAE,MAAM,CAAC;IACrB,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,gBAAgB,CAAC;IACzB,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,WAAW,EAAE,MAAM,GAAG,IAAI,CAAC;IAC3B,QAAQ,EAAE,kBAAkB,CAAC;IAC7B,KAAK,EAAE,eAAe,CAAC;IACvB,uBAAuB,EAAE,iCAAiC,GAAG,IAAI,CAAC;IAClE,WAAW,EAAE,qBAAqB,GAAG,IAAI,CAAC;IAC1C,yBAAyB,EAAE,MAAM,GAAG,IAAI,CAAC;IACzC,iBAAiB,EAAE,0BAA0B,EAAE,CAAC;IAChD,gBAAgB,EAAE,0BAA0B,CAAC;IAC7C,IAAI,EAAE,MAAM,EAAE,CAAC;IACf,SAAS,EAAE,MAAM,CAAC;IAClB,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,SAAS,EAAE,MAAM,CAAC;IAClB,YAAY,EAAE,MAAM,CAAC;IACrB,YAAY,EAAE,MAAM,CAAC;IACrB,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED,wBAAgB,2BAA2B,CAAC,KAAK,EAAE;IACjD,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;CACf,GAAG,MAAM,CAMT;AAED,MAAM,MAAM,yBAAyB,GAAG,iCAAiC,CAAC;AAE1E,MAAM,WAAW,qBAAsB,SAAQ,yBAAyB;IACtE,eAAe,CAAC,EAAE,OAAO,CAAC;IAC1B,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,UAAU,CAAC,EAAE,OAAO,CAAC;IACrB,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,sBAAsB;IACrC,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,OAAO,CAAC;IACjB,MAAM,EAAE,gBAAgB,CAAC;CAC1B;AAED,MAAM,WAAW,oBAAoB;IACnC,WAAW,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,gBAAgB,CAAC,EAAE,0BAA0B,CAAC;IAC9C,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,KAAK,CAAC,EAAE,eAAe,CAAC;IACxB,uBAAuB,CAAC,EAAE,iCAAiC,GAAG,IAAI,CAAC;IACnE,WAAW,CAAC,EAAE,qBAAqB,GAAG,IAAI,CAAC;IAC3C,yBAAyB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC1C,iBAAiB,CAAC,EAAE,0BAA0B,EAAE,CAAC;IACjD,QAAQ,CAAC,EAAE,kBAAkB,CAAC;IAC9B,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,MAAM,CAAC,EAAE,gBAAgB,CAAC;IAC1B,OAAO,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACxB,IAAI,CAAC,EAAE,MAAM,EAAE,CAAC;IAChB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,0CAA0C;IACzD,KAAK,EAAE,MAAM,CAAC;IACd,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,oBAAoB,CAAC,EAAE,4BAA4B,CAAC;IACpD,wBAAwB,EAAE,0BAA0B,CAAC;IACrD,oBAAoB,EAAE,MAAM,CAAC;IAC7B,aAAa,EAAE,eAAe,CAAC;IAC/B,cAAc,CAAC,EAAE,8BAA8B,CAAC;IAChD,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,2CAA2C;IAC1D,QAAQ,EAAE,OAAO,CAAC;IAClB,MAAM,EAAE,gBAAgB,CAAC;CAC1B;AAED,MAAM,WAAW,mBAAmB;IAClC,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,mBAAmB;IAClC,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,MAAM,CAAC,EAAE,MAAM,GAAG,MAAM,EAAE,CAAC;IAC3B,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,oBAAoB;IACnC,KAAK,EAAE,gBAAgB,EAAE,CAAC;IAC1B,KAAK,EAAE,MAAM,CAAC;CACf;AAED,MAAM,WAAW,0CAA0C;IACzD,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,2CAA2C;IAC1D,QAAQ,EAAE,OAAO,CAAC;IAClB,MAAM,EAAE,gBAAgB,CAAC;CAC1B;AAED,MAAM,WAAW,qCAAqC;IACpD,oBAAoB,EAAE,SAAS,MAAM,EAAE,CAAC;IACxC,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,WAAW,CAAC,EAAE,CAAC,MAAM,OAAO,CAAC,GAAG,IAAI,CAAC;IACrC,gBAAgB,EAAE,MAAM,CAAC;IACzB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,mCAAmC;IAClD,oBAAoB,EAAE,SAAS,MAAM,EAAE,CAAC;IACxC,gBAAgB,EAAE,MAAM,CAAC;CAC1B;AAED,MAAM,WAAW,8CAA8C;IAC7D,aAAa,EAAE,SAAS,mCAAmC,EAAE,CAAC;IAC9D,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,cAAc,EAAE,MAAM,CAAC;IACvB,WAAW,CAAC,EAAE,CAAC,MAAM,OAAO,CAAC,GAAG,IAAI,CAAC;IACrC,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,sCAAsC;IACrD,aAAa,EAAE,MAAM,CAAC;IACtB,SAAS,EAAE,MAAM,GAAG,IAAI,CAAC;IACzB,YAAY,EAAE,MAAM,CAAC;IACrB,2BAA2B,EAAE,MAAM,EAAE,CAAC;IACtC,cAAc,EAAE,MAAM,CAAC;IACvB,OAAO,CAAC,EAAE,IAAI,CAAC;CAChB;AA0uBD,wBAAgB,yBAAyB,IAAI,yBAAyB,CAwBrE;AAED,wBAAsB,eAAe,CACnC,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,oBAAoB,CAAC,CAgB/B;AAED,wBAAsB,cAAc,CAClC,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,gBAAgB,CAAC,CAa3B;AAED,wBAAsB,cAAc,CAClC,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,gBAAgB,GAAG,IAAI,CAAC,CAGlC;AAiBD,wBAAsB,gBAAgB,CACpC,KAAK,EAAE,qBAAqB,GAC3B,OAAO,CAAC,sBAAsB,CAAC,CAEjC;AAED,wBAAsB,eAAe,CACnC,KAAK,EAAE,oBAAoB,GAC1B,OAAO,CAAC,sBAAsB,CAAC,CAgEjC;AAED,wBAAsB,qCAAqC,CACzD,KAAK,EAAE,0CAA0C,GAChD,OAAO,CAAC,2CAA2C,CAAC,CAuDtD;AAqBD,wBAAsB,gCAAgC,CACpD,KAAK,EAAE,qCAAqC,GAC3C,OAAO,CAAC,sCAAsC,CAAC,CAyBjD;AAED,wBAAsB,yCAAyC,CAC7D,KAAK,EAAE,8CAA8C,GACpD,OAAO,CAAC,sCAAsC,CAAC,CA+DjD;AAsKD,wBAAsB,qCAAqC,CACzD,KAAK,EAAE,0CAA0C,GAChD,OAAO,CAAC,2CAA2C,CAAC,CAuEtD;AAoND,wBAAgB,8BAA8B,CAC5C,KAAK,EAAE,yBAAyB,GAC/B,MAAM,CAyCR;AAED,wBAAsB,sBAAsB,CAC1C,SAAS,EAAE,MAAM,EACjB,YAAY,EAAE,MAAM,GACnB,OAAO,CAAC,MAAM,CAAC,CAOjB"}
+{"version":3,"file":"automation.d.ts","sourceRoot":"","sources":["../src/automation.ts"],"names":[],"mappings":"AAEA,OAAO,EACL,mBAAmB,EACnB,yBAAyB,EAoBzB,KAAK,iCAAiC,EACtC,KAAK,0BAA0B,EAC/B,KAAK,0BAA0B,EAC/B,KAAK,4BAA4B,EACjC,KAAK,8BAA8B,EACnC,KAAK,eAAe,EACpB,KAAK,kBAAkB,EAEvB,KAAK,yBAAyB,IAAI,iCAAiC,EACnE,KAAK,gBAAgB,EACrB,KAAK,qBAAqB,EAC3B,MAAM,oBAAoB,CAAC;AAgE5B,YAAY,EACV,iCAAiC,EACjC,0BAA0B,EAC1B,0BAA0B,EAC1B,eAAe,EACf,kBAAkB,EAClB,gBAAgB,EAChB,qBAAqB,GACtB,CAAC;AAEF,MAAM,WAAW,gBAAgB;IAC/B,aAAa,EAAE,OAAO,yBAAyB,CAAC;IAChD,OAAO,EAAE,OAAO,mBAAmB,CAAC;IACpC,YAAY,EAAE,MAAM,CAAC;IACrB,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,gBAAgB,CAAC;IACzB,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,WAAW,EAAE,MAAM,GAAG,IAAI,CAAC;IAC3B,QAAQ,EAAE,kBAAkB,CAAC;IAC7B,KAAK,EAAE,eAAe,CAAC;IACvB,uBAAuB,EAAE,iCAAiC,GAAG,IAAI,CAAC;IAClE,WAAW,EAAE,qBAAqB,GAAG,IAAI,CAAC;IAC1C,yBAAyB,EAAE,MAAM,GAAG,IAAI,CAAC;IACzC,iBAAiB,EAAE,0BAA0B,EAAE,CAAC;IAChD,gBAAgB,EAAE,0BAA0B,CAAC;IAC7C,IAAI,EAAE,MAAM,EAAE,CAAC;IACf,SAAS,EAAE,MAAM,CAAC;IAClB,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,SAAS,EAAE,MAAM,CAAC;IAClB,YAAY,EAAE,MAAM,CAAC;IACrB,YAAY,EAAE,MAAM,CAAC;IACrB,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED,wBAAgB,2BAA2B,CAAC,KAAK,EAAE;IACjD,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;CACf,GAAG,MAAM,CAMT;AAED,MAAM,MAAM,yBAAyB,GAAG,iCAAiC,CAAC;AAE1E,MAAM,WAAW,qBAAsB,SAAQ,yBAAyB;IACtE,eAAe,CAAC,EAAE,OAAO,CAAC;IAC1B,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,UAAU,CAAC,EAAE,OAAO,CAAC;IACrB,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,sBAAsB;IACrC,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,OAAO,CAAC;IACjB,MAAM,EAAE,gBAAgB,CAAC;CAC1B;AAED,MAAM,WAAW,oBAAoB;IACnC,WAAW,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,gBAAgB,CAAC,EAAE,0BAA0B,CAAC;IAC9C,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,KAAK,CAAC,EAAE,eAAe,CAAC;IACxB,uBAAuB,CAAC,EAAE,iCAAiC,GAAG,IAAI,CAAC;IACnE,WAAW,CAAC,EAAE,qBAAqB,GAAG,IAAI,CAAC;IAC3C,yBAAyB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC1C,iBAAiB,CAAC,EAAE,0BAA0B,EAAE,CAAC;IACjD,QAAQ,CAAC,EAAE,kBAAkB,CAAC;IAC9B,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,MAAM,CAAC,EAAE,gBAAgB,CAAC;IAC1B,OAAO,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACxB,IAAI,CAAC,EAAE,MAAM,EAAE,CAAC;IAChB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,0CAA0C;IACzD,KAAK,EAAE,MAAM,CAAC;IACd,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,oBAAoB,CAAC,EAAE,4BAA4B,CAAC;IACpD,wBAAwB,EAAE,0BAA0B,CAAC;IACrD,oBAAoB,EAAE,MAAM,CAAC;IAC7B,aAAa,EAAE,eAAe,CAAC;IAC/B,cAAc,CAAC,EAAE,8BAA8B,CAAC;IAChD,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,2CAA2C;IAC1D,QAAQ,EAAE,OAAO,CAAC;IAClB,MAAM,EAAE,gBAAgB,CAAC;CAC1B;AAED,MAAM,WAAW,mBAAmB;IAClC,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,mBAAmB;IAClC,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,MAAM,CAAC,EAAE,MAAM,GAAG,MAAM,EAAE,CAAC;IAC3B,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,oBAAoB;IACnC,KAAK,EAAE,gBAAgB,EAAE,CAAC;IAC1B,KAAK,EAAE,MAAM,CAAC;CACf;AAED,MAAM,WAAW,0CAA0C;IACzD,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,2CAA2C;IAC1D,QAAQ,EAAE,OAAO,CAAC;IAClB,MAAM,EAAE,gBAAgB,CAAC;CAC1B;AAED,MAAM,WAAW,qCAAqC;IACpD,oBAAoB,EAAE,SAAS,MAAM,EAAE,CAAC;IACxC,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,WAAW,CAAC,EAAE,CAAC,MAAM,OAAO,CAAC,GAAG,IAAI,CAAC;IACrC,gBAAgB,EAAE,MAAM,CAAC;IACzB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,mCAAmC;IAClD,oBAAoB,EAAE,SAAS,MAAM,EAAE,CAAC;IACxC,gBAAgB,EAAE,MAAM,CAAC;CAC1B;AAED,MAAM,WAAW,8CAA8C;IAC7D,aAAa,EAAE,SAAS,mCAAmC,EAAE,CAAC;IAC9D,GAAG,CAAC,EAAE,IAAI,CAAC;IACX,cAAc,EAAE,MAAM,CAAC;IACvB,WAAW,CAAC,EAAE,CAAC,MAAM,OAAO,CAAC,GAAG,IAAI,CAAC;IACrC,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,sCAAsC;IACrD,aAAa,EAAE,MAAM,CAAC;IACtB,SAAS,EAAE,MAAM,GAAG,IAAI,CAAC;IACzB,YAAY,EAAE,MAAM,CAAC;IACrB,2BAA2B,EAAE,MAAM,EAAE,CAAC;IACtC,cAAc,EAAE,MAAM,CAAC;IACvB,OAAO,CAAC,EAAE,IAAI,CAAC;CAChB;AA0uBD,wBAAgB,yBAAyB,IAAI,yBAAyB,CAwBrE;AAED,wBAAsB,eAAe,CACnC,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,oBAAoB,CAAC,CAgB/B;AAED,wBAAsB,cAAc,CAClC,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,gBAAgB,CAAC,CAa3B;AAED,wBAAsB,cAAc,CAClC,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,gBAAgB,GAAG,IAAI,CAAC,CAGlC;AAiBD,wBAAsB,gBAAgB,CACpC,KAAK,EAAE,qBAAqB,GAC3B,OAAO,CAAC,sBAAsB,CAAC,CAEjC;AAED,wBAAsB,eAAe,CACnC,KAAK,EAAE,oBAAoB,GAC1B,OAAO,CAAC,sBAAsB,CAAC,CAgEjC;AAED,wBAAsB,qCAAqC,CACzD,KAAK,EAAE,0CAA0C,GAChD,OAAO,CAAC,2CAA2C,CAAC,CAuDtD;AAqBD,wBAAsB,gCAAgC,CACpD,KAAK,EAAE,qCAAqC,GAC3C,OAAO,CAAC,sCAAsC,CAAC,CAyBjD;AAED,wBAAsB,yCAAyC,CAC7D,KAAK,EAAE,8CAA8C,GACpD,OAAO,CAAC,sCAAsC,CAAC,CA+DjD;AAsKD,wBAAsB,qCAAqC,CACzD,KAAK,EAAE,0CAA0C,GAChD,OAAO,CAAC,2CAA2C,CAAC,CAuEtD;AA6ND,wBAAgB,8BAA8B,CAC5C,KAAK,EAAE,yBAAyB,GAC/B,MAAM,CAyCR;AAED,wBAAsB,sBAAsB,CAC1C,SAAS,EAAE,MAAM,EACjB,YAAY,EAAE,MAAM,GACnB,OAAO,CAAC,MAAM,CAAC,CAOjB"}

package/node_modules/@murphai/core/dist/automation.js

@@ -1071,16 +1071,25 @@ function resolveAdvancedDeviceActivityCursor(input) {
 async function upsertAutomationWithLatestRegistry(input, records) {
     const normalizedId = normalizeId(input.automationId, "automationId", "automation");
     const title = normalizeAutomationTitle(input.title);
-    const requestedSlug = resolveAutomationUpsertSlug({
-        slug: input.slug,
-        title,
-    });
-    const existingRecord = selectAutomationRecord(records ?? await loadAutomationRecords(input.vaultRoot), { automationId: normalizedId, slug: requestedSlug });
+    const createOnlyRecordId = input.createOnly === true
+        ? normalizedId ?? generateRecordId("automation")
+        : null;
+    const requestedSlug = createOnlyRecordId !== null && input.slug === undefined
+        ? resolveAutomationUpsertSlug({ slug: createOnlyRecordId, title })
+        : resolveAutomationUpsertSlug({
+            slug: input.slug,
+            title,
+        });
+    const currentRecords = records ?? await loadAutomationRecords(input.vaultRoot);
+    const existingRecord = selectAutomationRecord(currentRecords, { automationId: normalizedId, slug: requestedSlug });
     if (input.createOnly === true && existingRecord !== null) {
         throw new VaultError("VAULT_AUTOMATION_CONFLICT", "Automation already exists; use a versioned patch to change it.");
     }
     const now = (input.now ?? new Date()).toISOString();
-    const recordId = existingRecord?.automationId ?? normalizedId ?? generateRecordId("automation");
+    const recordId = existingRecord?.automationId
+        ?? createOnlyRecordId
+        ?? normalizedId
+        ?? generateRecordId("automation");
     const createdAt = existingRecord?.createdAt ?? now;
     const updatedAt = now;
     const target = resolveMarkdownRegistryUpsertTarget({
@@ -1103,10 +1112,9 @@ async function upsertAutomationWithLatestRegistry(input, records) {
         : normalizeAutomationActiveUntil(input.activeUntil);
     assertAutomationActiveUntilMatchesSchedule({ activeUntil, schedule });
     const status = normalizeAutomationStatus(input.status ?? existingRecord?.status);
-    const timingChanged = existingRecord === null ||
+    const scheduleAnchorAt = (existingRecord === null ||
         !isDeepStrictEqual(existingRecord.schedule, schedule) ||
-        (existingRecord.status !== "active" && status === "active");
-    const scheduleAnchorAt = timingChanged
+        (existingRecord.status !== "active" && status === "active"))
         ? now
         : existingRecord.scheduleAnchorAt ?? existingRecord.createdAt;
     const requestedTags = input.tags === undefined