@brainervirus/workit-codex 1.2.0 → 1.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@brainervirus/workit-codex",
-  "version": "1.2.0",
+  "version": "1.3.0",
   "private": false,
   "description": "Workit Codex CLI/desktop plugin — shared MCP transport, hooks, and fourteen method skills",
   "keywords": [
@@ -38,8 +38,8 @@
     "build": "bun scripts/build.ts"
   },
   "dependencies": {
-    "@brainervirus/workit-core": "^1.2.0",
-    "@brainervirus/workit-mcp": "^1.2.0"
+    "@brainervirus/workit-core": "^1.3.0",
+    "@brainervirus/workit-mcp": "^1.3.0"
   },
   "engines": {
     "node": ">=24"

package/skills/workit-babysit/SKILL.md

@@ -1,43 +1,37 @@
 ---
 name: workit-babysit
-description: Use after creating a PR (auto-starts, drive default), when a PR needs driving to merge-ready, CI is red, or the user says babysit
+description: Use when the user asks to babysit a PR or explicitly opts in to PR follow-up
 ---
 
-# Babysit a PR to merge-ready
+# Babysit a PR to PR-ready
 
-Babysit starts automatically on PR creation unless declined (`babysit:false`).
-One babysitter per PR; never mutate PR topology (no rebase strategy changes,
-no force-push). When a PR URL is observed from a route Workit did not enforce
-(for example a raw `gh pr create` the host allowed), load this skill and drive
-that PR anyway; do not claim the Workit route was enforced.
+PR creation does not start babysitting. `babysit:true` opts into this skill;
+omission means no follow-up. A PR URL by itself is not an instruction to drive
+it. When the user asks to babysit a URL from a route Workit did not enforce,
+help without claiming the Workit route was enforced. Never mutate PR topology
+(no rebase strategy changes, no force-push).
 
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
 
 ## Method
 
-1. Declare mode in the same turn as the PR URL: drive (fix + merge, the
-   default), watch (report only), or threads-only.
-2. Work the merge frontier in order: conflicts → review threads → CI.
-   Record a frontier brief (frontier state, next action) in task progress
-   per pass so the steps stay visible.
+1. Default to drive mode for an explicit babysit request: resolve conflicts,
+   address review threads, and get checks green. Watch reports status only;
+   threads-only addresses review threads. Ask about mode only when the choice
+   materially changes the work.
+2. Work toward PR-ready in order: conflicts → review threads → CI. Keep a brief
+   checkpoint when continuity needs it; task progress is optional.
 3. Classify CI before retry: flake (rerun once) vs stale base (verify with
    `git merge-base --is-ancestor` before updating) vs real failure (fix).
 4. Triage bot findings skeptically: reproduce or quote code before acting;
    invalid bots get a reasoned dismissal, never silent ignore.
 5. Batch fixes into one push wave; re-verify green after every push.
-6. Merge only when green and approved, honoring `pr` settings (squash +
-   delete branch). Stop at the human's line: never merge on explicit hold.
+6. Stop at PR-ready. A PR creation or babysit request does not authorize merge
+   or release. Continue to merge or release only when the user explicitly sets
+   that delivery endpoint and host authority allows the action.
 
 ## Completion
 
-PR merged per settings, or a status brief (frontier state, next action) when
-blocked on the human. Record evidence for fixes, findings for blockers.
-
-A squash merge creates a new commit on the base branch, so the pre-merge
-candidate identity changes: re-record verification and review evidence against
-the merged commit before `task.close`, or the close will report unsatisfied
-requirements.
+Report PR-ready status with evidence for fixes, or a brief blocker report. If
+the user explicitly authorized merge, honor the configured strategy only after
+checks and required approval. After a squash merge, re-record evidence against
+the new base commit before closing tracked work.

package/skills/workit-behavioral-tdd/SKILL.md

@@ -8,11 +8,6 @@ description: Use when policy identifies behavior, side effects, permissions, or
 Test the observable behavior at a stable boundary, not the implementation shape.
 Use this method when assessment selects the `testing` dimension.
 
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
 
 ## Method
 

package/skills/workit-blast-radius/SKILL.md

@@ -8,11 +8,6 @@ description: Use when a small-looking change could break something else, before
 A small diff is not a small risk. Prove the one fact it is safe because of,
 with runnable proof — not assertion.
 
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
 
 ## Method
 

package/skills/workit-challenge/SKILL.md

@@ -1,64 +1,47 @@
 ---
 name: workit-challenge
-description: Use when a proposal is ambiguous, consequential, disputed, or may hide assumptions, coupling, failure modes, or a simpler solution
+description: Use when requirements or consequences leave a real decision open
 ---
 
-# Challenge a proposal with a grounded grill
+# Challenge open choices with evidence
 
-Treat the proposal as a hypothesis. Facts are the agent's job; decisions are
-the user's. Use this method when assessment selects the `challenge` or
-`decisions` dimension.
-
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
+Skip this method for a precise, settled request.
 
 ## Method
 
-1. Ground first: inspect the task, policy, candidate, evidence, decisions, and
-   the repo docs that exist. Never ask what code or docs can answer.
-2. Diverge once, bounded: when the approach is unknown, offer 3-5 candidate
-   directions with evidence and tradeoffs in one advisory burst, without
-   critique. Record the burst as artifact evidence when it matters; the user
-   steers or mixes.
-3. Grill one question at a time: each question carries your recommended answer,
-   the facts behind it, and at least one rejected alternative. Resolve
-   dependency order and recompute after every answer — a wall of questions is
-   not an interview.
-4. Funnel every resolution: the moment a consequential choice settles, bind it
-   with a receipt-shaped question — header `Workit decision: <purpose>` and the
-   same label repeated in the question text (host UIs may not render headers) —
-   exactly `approved`/`rejected` options, the approved description carrying the
-   exact content.
-   If the user already stated the choice in conversation and no receipt can be
-   minted, record it in task progress and reassess so the settled requirement
-   retires — never re-ask to mint a receipt, and never leave it for close to
-   demand.
-5. Durability: write or refresh the spec under `docs/<slug>/` only when the
-   `durable-spec` requirement fires. No glossary, no second lifecycle.
-6. Counter-case: each material recommendation carries one strongest
-   counter-case (hidden assumption, failure mode, coupling, simpler
-   alternative). Stop when a counter-case adds no new constraint.
-
-Stop at an empty frontier or three rounds; the cap is the bound. Say directly
-when the proposal is weak, overcomplicated, or solves the wrong problem.
+1. Ground the outcome, constraints, evidence, and important unknowns. Inspect
+   code and project docs before asking about facts they can answer.
+2. Separate observations, inferences, and proposals. Test assumptions that
+   could change the recommendation.
+3. When viable alternatives exist, present two or three genuinely different
+   approaches. Recommend one; for each, give its benefit, cost or risk, when it
+   fits, and the smallest useful validation. Do not invent a weak alternative.
+4. Ask only consequential questions, in dependency order. Group independent
+   choices into one small round. If an authorized reversible default works,
+   state it and proceed.
+5. Record a settled choice once in the existing conversation or task context.
+   A discussion decision is knowledge; never fabricate a native permission
+   receipt or reopen it without new evidence.
+6. Create durable documentation only when requested or when the decision needs
+   a future reader. Brainstorming alone does not require a spec.
+
+Say directly when evidence shows a proposal is weak, overcomplicated, or solves
+the wrong problem. Raise a counter-case only when it adds a real constraint.
 
 ## Guardrails
 
 - Do not create a universal spec, plan, approval chain, or second lifecycle.
-- Unknowns that affect the dependent action remain unresolved until evidence or a
-  user decision closes them.
-- Use the shared operations for state and provenance; never write task metadata
-  directly.
-- An in-session counter-case is never fresh-context review; claim only what it is.
+- Unknowns that affect an action remain unresolved until evidence or a user
+  decision closes them.
+- Use shared operations for tracked state and provenance; never write task
+  metadata directly.
+- An in-session counter-case is not fresh-context review.
 
 ## Common mistakes
 
 | Mistake | Correction |
 | --- | --- |
-| Asking what the code or docs already answer | Ground first; the user owns choices, not lookups. |
-| Listing every hypothetical objection | One strongest counter-case, then stop. |
-| Asking "what do you think?" without a recommendation | Recommend an option and explain the tradeoff. |
-| Leaving a settled choice for close to confirm | Funnel it when it resolves; progress plus reassessment if no receipt. |
+| Asking what code or docs already answer | Ground first; the user owns choices, not lookups. |
+| Listing every hypothetical objection | Raise only objections that can change the decision. |
+| Asking for agreement without a recommendation | Recommend an option and explain the tradeoff. |
+| Treating a discussion decision as permission | Record it as knowledge; preserve native host authority. |

package/skills/workit-debug/SKILL.md

@@ -9,11 +9,6 @@ Debugging is investigation, not a fast symptom patch. Use this method when
 assessment selects `root-cause-investigation` or behavior is failing without an
 established root cause.
 
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
 
 ## Method
 
@@ -29,28 +24,11 @@ selects requirements; do not wait for a rule that can only exist after assess.
    candidate, evidence, and findings after the change; investigate sibling paths
    and stale conclusions rather than assuming the first patch worked.
 
-Honor task status, scope, revisions, and native authority gates. Do not bypass
-them for an incident, create a second lifecycle, or claim a fix from a green
-command that did not exercise the affected behavior.
-
-## Red-capable gate
-
-Never hypothesize without a loop that goes red on this exact failure. Build
-the loop first, in this order: failing test → CLI command + fixture →
-request replay → trace. Tighten it until fast, sharp, deterministic, and
-agent-runnable. No loop → stop, list what was tried, ask for the
-environment or artifact; never theorize without it.
-
-Minimise: cut one element at a time until every remainder is load-bearing;
-the minimised case becomes the regression test. State hypotheses ranked and
-falsifiable (`If <X> then changing <Y> removes it`), probe one variable at
-a time, tag debug logs for grep cleanup. Write the regression at the seam
-where the real pattern occurs — no correct seam means the finding is the
-architecture, so flag it instead of patching around it.
-
-When the host reports writer capability unavailable, do not mutate or delegate
-mutation. Continue inline only if policy and lead authority permit it;
-otherwise report the capability gap.
+Respect the user's scope and native authority. For a deterministic failure, make
+one focused reproduction that exercises the affected boundary and add a
+regression check when practical. If no direct reproduction exists, gather the
+available evidence and state what remains uncertain instead of inventing a red
+loop or blocking unrelated work.
 
 ## Common mistakes
 

package/skills/workit-deslop/SKILL.md

@@ -8,11 +8,6 @@ description: Use before opening a PR or after implementation to remove AI slop f
 Throughput without quality is slop. Clean it with a minimal diff — deslop
 never refactors behavior.
 
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
 
 ## Method
 

package/skills/workit-diagram/SKILL.md

@@ -8,11 +8,6 @@ description: Use when a spec or plan needs a flow or architecture diagram
 Tables first, ASCII trees second, mermaid only when a flow or architecture
 needs it. Flowchart, sequence, state, or ER only. No renderer, no network.
 
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
 
 ## Syntax rules (mermaid v11)
 

package/skills/workit-green-run/SKILL.md

@@ -8,11 +8,6 @@ description: Use to drive a red CI pipeline back to green, usually inside babysi
 Watch, classify, fix, push once, re-verify. Host-native (`gh` / GitLab);
 never invent CI APIs.
 
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
 
 ## Method
 

package/skills/workit-handoff/SKILL.md

@@ -5,14 +5,8 @@ description: Use when work must continue in another session, host, or agent afte
 
 # Handoff durable task state
 
-Transfer continuity, not live authority. Use this method when assessment selects
-the `durable-handoff` rule.
-
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
+Transfer continuity, not live authority. Use this method when a tracked item
+must continue in another session, host, or agent.
 
 ## Method
 

package/skills/workit-implement/SKILL.md

@@ -1,41 +1,35 @@
 ---
 name: workit-implement
-description: Use when scoped implementation, helper delegation, or checkout writer coordination is required by the current task policy
+description: Use when implementation benefits from bounded delegation or shared checkout coordination
 ---
 
 # Implement within authority
 
-Implement only inside the current task scope and writer boundary. Assignment is
-not launch authority, and a timeout is not proof that a worker stopped.
-
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
+Implement within the user request and native host permissions. A task record and
+writer ownership are optional coordination tools. Assignment never expands the
+request, and a timeout is not proof that a worker stopped.
 
 ## Method
 
-1. Inspect task state, requirements, decisions, candidate, capabilities, and
-   current workers with shared `task`, `policy`, and `worker` operations.
+1. Inspect the repository, relevant rules, host capabilities, and current work.
+   Inspect task state only when this work is already tracked.
 2. If a helper is useful, assign one bounded objective with allowed paths,
    applicable requirements, evidence needed, and a stopping condition. Helpers
    cannot change scope, record binding decisions, close or pause the task, assign
    helpers, or resolve blockers for the lead.
-3. Observe the native session and worker state. Acquire checkout writer ownership
-   through `writer` before any product-mutating command; release it explicitly.
-   Cancellation remains uncertain until process exit or explicit recovery.
-4. Reconcile the helper report and evidence through shared operations. If required
-   delegation is unavailable, continue inline only when policy allows it and state
-   the capability limitation.
+3. Use writer ownership only when another Workit actor may mutate the same
+   checkout; release it when coordination ends. Cancellation remains uncertain
+   until process exit or explicit recovery.
+4. Reconcile helper reports and run the checks appropriate to the requested
+   outcome. If delegation is unavailable, continue inline when useful.
 
 Do not edit Workit metadata directly, create nested helper trees, widen paths, or
 create a second lifecycle. Read-only investigation and bounded reports do not
 grant product-write ownership.
 
-When the host reports writer capability unavailable, do not mutate or delegate
-mutation. Continue inline only if policy and lead authority permit it;
-otherwise report the capability gap.
+Do not request writer ownership for a solo edit. If a concurrent Workit writer
+cannot be fenced, stop only the conflicting managed writes; ordinary writes still
+follow the native host permission and sandbox.
 
 ## Common mistakes
 

package/skills/workit-mockup/SKILL.md

@@ -8,11 +8,6 @@ description: Use when a UI decision needs sketching before implementation
 Sketch, don't build. Three genuinely different layout hypotheses maximum,
 ASCII only, no code output.
 
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
 
 ## Method
 

package/skills/workit-plan/SKILL.md

@@ -5,74 +5,41 @@ description: Use when dependencies, sequencing, coordination, or resumption make
 
 # Plan useful coordination
 
-Use a compact plan when assessment selects `artifacts` or `continuity`. A plan
-organizes work; it is not a second lifecycle or a prerequisite for implementation.
-
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
+A plan is useful when work has dependent steps, a handoff, concurrent actors, or
+meaningful unresolved choices. It is never a prerequisite for implementation.
 
 ## Method
 
-1. Inspect current task state, scope, decisions, requirements, candidate, workers,
-   findings, and blockers through the shared `task` and `policy` operations.
-2. Record only the useful sequence: objective, dependency, bounded task, evidence
-   needed, owner, and next action. Keep the plan against the existing system.
-3. If policy separately requires a durable specification, record that behavior
-   agreement; otherwise do not invent a spec. A plan without a spec is valid.
-4. Present before asking: show durable artifacts as a complete digest plus the
-   exact path and inline plans as their content. Never ask the user to approve
-   something they have not seen, and keep the question to one short scoped
-   sentence.
-5. Execute an approved plan continuously: one atomic commit per task after its
-   checks pass, no "continue?" prompts. Stop only for a new product decision, a
-   failed safety or verification gate, a conflicting concurrent edit, or missing
-   authority.
-6. Record the plan's commit list once through the plan-scoped action approval
-   (`git.commit` with `plan_steps` and `plan_branch`) so each listed commit runs
-   without a new question; an unlisted message, a branch change, or any change to
-   the plan needs a fresh exact approval.
-7. Update the shared task progress at meaningful boundaries. Reassess when facts,
-   dependencies, or scope change; preserve unresolved blockers and decisions.
-8. On steering (new instructions mid-task): apply `workit-steer` — park state
-   verbatim, classify same-task / new-task / quick-question, handle, re-anchor.
-
-Use shared task/progress and evidence operations. Do not create a universal
-spec-and-plan ceremony, duplicate task state, approval chain, or custom status
-machine. A short paragraph is enough when it captures the required continuity.
-
-## Triage (automatic)
-
-Set assessor signals from size facts, not memory (`triageTier` /
-`triageSignals` in policy-resolver):
-
-- **Large → spec + full plan:** new/changed observable behavior, open
-  ambiguity, cross-package/host contract or auth/data/security surface,
-  irreversible migration, or ≥3 subsystems / ≥2 packages touched.
-- **Medium → compact plan-only** (Sequence/Acceptance, ~30-60 lines): known
-  approach, single subsystem, 2-8 steps. Step count alone never escalates
-  a known single-subsystem run to spec.
-- **Small → neither** (progress + evidence only): single bounded mechanical
-  action, no open choices, reversible. Record `Spec: none (reason)`.
-
-`task.start` + `policy.assess` stay mandatory at all sizes. The lead may
-re-tier with the reason recorded in progress (override, never silent).
-
-## Decomposition
-
-Slice tracer bullets, not layers: each plan task crosses the necessary
-layers to a small demoable behavior with its blocking edges declared.
-Wide refactors use expand–contract (add the new seam, migrate callers,
-delete the old). Per task record Files (create/modify/test, exact paths),
-exact commands with expected output, and one commit. No placeholders —
-an implementer must be able to execute a task with zero extra context.
+1. Establish the requested outcome, constraints, dependencies, and important
+   unknowns from the available code, docs, and configuration before asking.
+2. Record only the useful sequence: objective, dependency, bounded outcome,
+   evidence needed, and next action. Reuse the project's existing format.
+3. Start a tracked record only when handoff, dependent steps, coordination, or
+   durable decisions need continuity. Infer observable facts instead of asking
+   the user to fill redundant protocol fields.
+4. Create a spec when a durable behavior contract or interface is requested or
+   will help a future reader. Use an ADR for a consequential trade-off and a
+   glossary for stable terms. A small fix needs no document.
+5. If the user authorized implementation, proceed through the agreed endpoint
+   and applicable checks. Do not ask for a separate plan approval or repeat
+   "continue?". Stop for a new consequential choice, host denial, conflict, or
+   blocker that cannot be resolved safely.
+6. Update a checkpoint at meaningful boundaries when another session may need
+   to resume. Keep settled decisions, changed files, actual checks, blockers,
+   and the next action; omit transcript and process trivia.
+
+## Shape
+
+Plan slices as small end-to-end outcomes with explicit dependencies and checks.
+Keep repo policy and native host authority separate. Preserve the user's branch
+and commit conventions. Do not prescribe one commit per step or create a second
+approval chain unless the user asked for that delivery format.
 
 ## Common mistakes
 
 | Mistake | Correction |
 | --- | --- |
-| Writing a full packet for a small dependency | Capture the next bounded action and its evidence. |
-| Treating the plan as authority | Authority remains in task scope, decisions, revisions, and caller provenance. |
-| Copying a transcript into the plan | Preserve decisions, gaps, blockers, and next action only. |
+| Writing a packet for a bounded reversible change | Leave the change undocumented. |
+| Asking what repository state or code can answer | Inspect it first. |
+| Treating the plan as authority | Follow the user's scope and native host permissions. |
+| Copying a transcript into the plan | Keep decisions, evidence, gaps, and next action only. |

package/skills/workit-review/SKILL.md

@@ -8,11 +8,6 @@ description: Use when policy requires fresh-context review of a candidate or whe
 Review the real candidate in a stable context. A review is evidence about the
 current candidate, not an author's success summary.
 
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
 
 ## Method
 

package/skills/workit-steer/SKILL.md

@@ -1,35 +1,35 @@
 ---
 name: workit-steer
-description: Use when new instructions, interruptions, or forgotten items arrive mid-task
+description: Use when new instructions, interruptions, or forgotten items change substantial ongoing work
 ---
 
-# Steer without losing the thread
+# Steer without forced lifecycle
 
-New context mid-session is normal; losing the thread is not. Park,
-classify, handle, re-anchor — every time.
-
-## Before method work
-
-If there is no active or paused task, run shared `task.start` then `policy.assess`
-before relying on selected policy rules or other product mutations. Assessment
-selects requirements; do not wait for a rule that can only exist after assess.
+Classify new input as a quick question, a same-task adjustment, or a separate
+request. Preserve continuity when it helps; do not manufacture task mutations.
 
 ## Method
 
-1. Park current state to task progress verbatim: summary, nextAction,
-   blockers. Never trust memory across an interruption.
-2. Classify the steering:
-   - same-task: fold into scope (reassess if facts changed), continue.
-   - new-task: `task.pause` the parked lead task, then `task.start` +
-     `policy.assess` for the new one. Keep exactly one active lead per
-     session: external actions bind to that single active task, and a second
-     active lead makes writer authority ambiguous.
-   - quick-question: answer from the parked state, then resume.
-3. Handle it with the same rigor as the parked work (no drive-by edits).
-4. Re-anchor: one-line resume brief (where we were, what changed, what
-   is next), then `task.resume` the parked task before touching it again.
-
-## Completion
-
-Both the steering and the parked work have an owner, a next action, and
-no silent drops. Interrupted work resumes from the brief, not from recall.
+1. Answer a quick question from current context. Do not pause, resume, create,
+   assess, or close a task just to answer it.
+2. For a same-task adjustment, update only affected constraints and next actions.
+   Keep an existing checkpoint when it helps; reassess policy only when evidence
+   or constraints changed enough to affect a rule.
+3. For a separate request, do not silently resume an old objective. Park a
+   concise checkpoint only when substantial work needs to continue later. Start
+   a distinct tracked record only if the new work benefits from continuity,
+   dependencies, coordination, or durable decisions.
+4. Before resuming a named tracked task, reconcile its checkout, branch, dirty
+   state, current policy, stale evidence, uncertain effects, and ownership. Do
+   not change branches, stash, fetch large histories, or seize ownership just
+   to display a history choice.
+5. Continue to the user's authorized endpoint with applicable checks. Ask only
+   about consequential choices the code and available context cannot resolve.
+
+## Common mistakes
+
+| Mistake | Correction |
+| --- | --- |
+| Treating a quick question as interruption | Answer without changing task state. |
+| Auto-resuming an old objective | Wait for the user's direction to resume it. |
+| Rebuilding continuity from a transcript | Keep a compact checkpoint with evidence and next action. |