@astrosheep/keiyaku 4.5.27 → 4.5.28

package/build/integrations/marketplace/plugins/keiyaku/skills/keiyaku-task/SKILL.md

@@ -1,100 +1,104 @@
 ---
 name: keiyaku-task
 description: >-
-  Use for task management: organizing work of three or more steps and
-  tracking it as it progresses.
+  Must read when using Tasks for durable work planning, decomposition, or
+  dependencies.
 ---
 
 # Keiyaku Task
 
-## What A Task Is Not
+A Task is durable planning memory. It records work, decomposition, and
+relationships that must remain after the current conversation. Task is an
+independent product; it is not a Contract, Arc, Akuma, permission, acceptance
+boundary, or fulfillment lifecycle.
 
-A Task remembers a plan: what is intended, what depends on what, what was
-decided about sequence. It grants nothing — no acceptance, no permission, no
-scope, no fulfillment loop. Whoever holds a Contract's loop uses Tasks when the
-plan is worth remembering and skips them when it is not; nothing binds Tasks to
-Arcs, Contracts, or Akuma as a package.
+## 1. When To Use A Task
 
-## Lifecycle
+Use a Task when the plan or dependency must outlive the current conversation.
+Skip it when the work is small and no durable planning memory is needed.
 
-```text
-open -> in_progress -> done | drop
-  |          |
-  +-> on_hold <-+
-```
+- Use a `kei` for one independently acceptable outcome.
+- Use an Arc for a chapter inside one `kei`.
+- Use a Task for decomposition or dependency memory.
+- Do not create a Task just to mirror a `kei`.
+
+A Task may exist without a Contract. Associating a Task with a `kei` does not
+transfer the Contract's holder, acceptance, or lifecycle to the Task.
+
+## 2. Relationships And Parallel Work
+
+Independent Tasks may start and progress in parallel when their dependencies
+allow it.
+
+Use the relationships for their actual meanings:
+
+- `needs` means this Task must wait for another Task to become terminal.
+- `parent` groups decomposition; it does not create a dependency.
+- `supersedes` points to work replaced by this Task.
+- `relates` records a connection without affecting readiness.
+
+Only `needs` orders work. Do not add it because Tasks touch the same Region or
+because one Task is related to another. A terminal Task releases its dependents.
+An `on_hold` Task is deliberately paused; it is neither ready nor blocked.
 
-Use `ready` for open tasks whose `needs` are terminal. `blocked` reports open
-or in-progress tasks with unresolved needs. `on_hold` appears in neither view.
-Both `done` and `drop` release dependents. `doctor` diagnoses the complete
-world and never repairs it.
+## 3. Task Commands
 
-## Common Commands
+Create and inspect Tasks:
 
 ```bash
-keiyaku task add "title"
-keiyaku task add "title" --priority 1 --needs <task-id>
-keiyaku task add --namespace <ns> -
+keiyaku task add "<title>"
+keiyaku task add "<title>" --priority 1 --needs <task-id>
 keiyaku task show <task-id>
 keiyaku task ls
-keiyaku task ls --closed
-keiyaku task ls --all --world
 keiyaku task ready
 keiyaku task blocked
 keiyaku task tree <task-id>
 keiyaku task doctor
 ```
 
-`ls`, `ready`, and `blocked` use the current namespace; add `--world` to
-observe the complete Task world. `show`, `tree`, `update`, and lifecycle
-commands require a complete TaskId and never infer namespace.
+Use complete Task IDs for targeted commands. `ls`, `ready`, and `blocked` use
+the current namespace; use `--world` to inspect the complete Task world.
 
-## Mutations
+Change lifecycle state:
 
 ```bash
 keiyaku task start <task-id>...
 keiyaku task stop <task-id>
-keiyaku task hold <task-id>
+keiyaku task hold <task-id>...
 keiyaku task resume <task-id>
 keiyaku task done <task-id>...
-keiyaku task drop <task-id>... [--note <text>]
-keiyaku task update <task-id> --title <text>
-keiyaku task context [<namespace>]
+keiyaku task drop <task-id>... --note "<reason>"
 ```
 
-Relations are explicit facts: `needs` orders work, `parent` groups it,
-`supersedes` navigates replacement, and `relates` does not affect readiness.
-`task start` accepts one or more complete TaskIds. A single ID keeps the
-single-mutation result; multiple IDs use the ordered batch result, continue
-after per-Task refusals, and preserve retry-over-refusal exit precedence.
+Use `done` when the Task is complete. Use `drop` when it will not be done.
+Both terminal states release dependent Tasks. Use `hold` for a deliberate pause,
+not for an unresolved dependency; unresolved `needs` appear in `blocked`.
 
-## Batch Create Or Modify
-
-Use `task compose -` to create and modify multiple Tasks in one planning
-document. Its input grammar is documented by the Task CLI owner:
+Update a Task without changing its lifecycle:
 
 ```bash
-keiyaku task compose - <<'EOF'
-ns=feature
-
-+ Parent
-as = parent
-state = in_progress
-pri = 0
-body <<BODY
-Parent body.
-BODY
-
-+ Child
-parent = ^parent
-needs = @task/existing
-EOF
+keiyaku task update <task-id> --title "<title>"
+keiyaku task update <task-id> --body "<body>"
+keiyaku task update <task-id> --needs <task-id>
 ```
 
-Use `--plan` to inspect aliases, admission order, and body byte previews without
-writing. New `+ Title` nodes may declare `state = open|in_progress|on_hold|done|drop`
-as their initial state; omitted state is `open`. Existing `@task/...` nodes cannot
-declare state. Aliases are nonempty single-line tokens containing neither
-Unicode whitespace nor comma; references use `^alias`. Compose does not change
-the lifecycle state of pre-existing Tasks. Each changed Task is admitted
-independently; an incomplete result returns a reusable draft for the remaining
-batch and preserves each new node's declared state.
+Use `task compose -` when several Tasks and their relationships should be
+planned or admitted together. Use `--plan` to inspect the composition without
+writing it.
+
+## 4. After Creating A Task
+
+Read the returned Task identity. Then:
+
+1. Start ready work.
+2. Run independent Tasks in parallel.
+3. Add or remove relationships when the plan changes.
+4. Hold work that is deliberately paused.
+5. Mark completed work `done`, or mark abandoned work `drop` with a reason.
+6. Use `ready`, `blocked`, `tree`, or `doctor` to rebuild the current view.
+
+Task records planning memory. It does not perform the work, claim acceptance,
+assign a holder, or decide what a Contract may accept.
+
+Read `keiyaku-bind` for Contract authoring and `keiyaku-workflow` for Contract
+lifecycle.

package/build/integrations/marketplace/plugins/keiyaku/skills/keiyaku-workflow/SKILL.md

@@ -1,151 +1,120 @@
 ---
 name: keiyaku-workflow
 description: >-
-  Use when deciding whether Keiyaku work needs a Contract or Arcs, how to
-  delegate it, or what to do next after a handoff: steer, assess a delivery,
-  request another round, or land.
+  Must read before binding a `kei` (Contract) or when acting as its holder.
+  Use when deciding when to bind a kei, how to shape and hold it, how to
+  delegate its work, and how to accept, amend, or end it.
 ---
 
-# Holding a fulfillment loop
-
-You are the loop-holder: the one reader of this skill. Flagship and
-whole-loop delegate are the same reader — same decisions, same tools,
-no special role or permission either way.
-
-The state you steer: a Contract moves `waiting -> bound -> tendered ->
-claimed | abandoned`; claimed and abandoned are terminal. Prerequisites
-and declared gates block placement, never delivery admission. Deliver
-and a satisfied review each request placement; placement claims only
-when every current obligation permits.
-
-Routing. Authoring a Contract — its boundary, terms, gates — is
-keiyaku-bind. Commission, call, tell, wait, permission, and history
-mechanics are keiyaku-akuma. Attention across many waiting lanes is
-keiyaku-babysit. Seat procedure travels with the worktree: the
-generated seat skill in each appointment tells the Deliverer and
-Reviewer what to do. Exact grammar for any command is that command's
-help, nowhere else.
-
-## Decision 1 — hold or delegate
-
-Take the lightest shape that carries the work. Direct work may skip a
-Contract entirely. Bounded mechanical work may take a Contract with no
-review gate. Tasks and Arcs are optional planning, never ceremony owed
-to the tool.
-
-The shape is not fixed at the start. Work begun directly that grows
-beyond expectation escalates midstream: bind a Contract then, and
-carry the change you already have into the appointed worktree as the
-candidate-in-progress. Nothing is lost by starting light; the only
-mistake is continuing an oversized effort outside any acceptance
-boundary because it happened to start there.
-
-Hold the loop yourself when you will decompose or implement. Delegate
-the whole loop when you steer at direction level: one commission hands
-one Aku the entire loop. Delegation changes who decides, not what
-exists — it creates no role, state, or journal fact. A whole-loop
-commission uses Contract association plus an explicit repository
-working directory; the automatic Contract-worktree working directory
-is for seat commissions only. Once delegated, steer through the
-holder, never around it. The delegate owes decisions and coordination,
-and may open Tasks, Arcs, and seat commissions beneath itself.
-
-## Decision 2 — shape the work
-
-Cut by what must be independently acceptable. Multiple independently
-acceptable outcomes are separate Contracts. One acceptance boundary
-whose work still has chapters may use Arcs — chapters inside a single
-acceptance, never separately placeable. Decomposition and dependency
-memory that must outlive a conversation is a Task. The failure this
-decision prevents: an oversized boundary handed to one Deliverer as a
-single ordinary assignment, with no chapters and no durable plan.
-
-Authoring the Contract itself belongs to keiyaku-bind. A landing
-dependency — this Contract's placement genuinely requires that one
-landed — is a real `after` relation. Ordinary overlap is not: Regions
-are planning evidence for your scheduling eye, never ownership and
-never a gate.
-
-## Decision 3 — commission seats
-
-A commission names one Contract, one seat, one worktree, and the
-capabilities that seat needs. A Deliverer owes a candidate; a Reviewer
-owes independent testimony. Grant only the actions required by that
-duty and verify them at dispatch. A self-recording Reviewer needs
-`contract.review` and therefore cannot be `--readonly`; use that flag
-only when another actor records the verdict. The configuration grammar
-is keiyaku-akuma's and the command's help.
-
-The prompt conveys the rest, in words this literal:
-
-    Contract: <contract>
-    Seat: Deliverer (or Reviewer)
-    Worktree: <exact path>
-    Read first:
-    - .keiyaku/KEIYAKU.md
-    - <exact governing owner-law paths>
-    - <exact relevant source paths>
-    This round: <one-sentence objective>
-
-A commission directs the round; it cannot amend acceptance. Standing
-acceptance is only the journaled terms and their amendments.
-
-Reviewer reuse is the default within one Contract while the judgment
-frame stays sound; a new Contract gets a new Reviewer.
-
-## Decision 4 — adjudicate returns
-
-Review is two-valued: satisfied or unsatisfied, testified over the
-complete current candidate or document subject. Satisfied requests
-placement and may be the invocation that claims; unsatisfied never
-places. When satisfied cannot be reached, the summary names what
-blocks it: the candidate, the required evidence, or the terms as
-written. Advice beyond acceptance may accompany testimony and changes
-no verdict. A returned Reviewer verdict is transported faithfully into
-testimony, or a fresh independent review is commissioned — never
-paraphrased into a different verdict. A Contract with no review gate
-neither requires nor owes any review.
-
-Deliver records the intended candidate, freshly prepares it against
-the target as the target exists for that invocation, runs or reuses
-Verification, and requests placement. A clean worktree delivers its
-HEAD; a dirty delivery captures the complete non-ignored state as an
-immutable commit without moving the branch or the real index — a
-prior git commit is optional shaping, never a prerequisite. Deliver
-never satisfies a review gate.
-
-Conflict materialization projects an uncommitted merge; it does not resolve
-its contents or record a delivery. After editing the final worktree bytes,
-`deliver --include-dirty` can capture them even while the real index still
-reports `UU`. No `git add` or commit is required, and capture preserves the
-real index. The candidate includes the complete non-ignored worktree, not
-just the Contract's Region or the conflict paths. Candidate capture and target
-placement are separate: this authorization does not permit overwriting
-blocking changes in the target checkout.
-
-Audit observes: prospective candidate, integration, Verification,
-diff, target. It records no candidate and satisfies no gate.
-
-Evidence goes stale by subject identity: a changed candidate or
-amended terms stales the testimony over that subject. Amend only
-while the same objective and acceptance boundary remain truthful —
-amendment reshapes terms inside the same promise. When the objective
-or the boundary itself has changed, abandon and bind a truthful new
-Contract; do not steer old terms onto a different delivery. Abandon
-ends a Contract without moving the target.
-
-## Decision 5 — schedule landing
-
-You schedule overlapping Contracts; nothing persists an ordering — no
-train exists in the tool. When the target has moved, prepare the
-current-target integration before the authoritative review. A
-content-equivalent preparation retains standing testimony; a changed
-conflict resolution stales it. Target movement requires fresh deliver
-or audit preparation.
-
-A placement refusal preserves the candidate and the testimony and
-leaves target and checkout untouched: resolve the blocking obligation
-and request placement again. Reconcile finishes accepted lagging
-effects; it does not retry a placement refusal. Rebuild your picture
-at any time from the read surfaces — status, show, region — whose
-grammar lives in their help.
+# Keiyaku Workflow
+
+This skill manages a `kei` (Contract) from preparation to completion.
+
+## 1. Prepare Before Binding
+
+Before `bind`, settle the information that makes the `kei` truthful:
+
+- objective and intended outcome;
+- design and approach;
+- affected Region;
+- acceptance conditions;
+- verification and required evidence;
+- prerequisites;
+- holder.
+
+If the design, approach, or acceptance conditions are still open, do not bind.
+Resolve them with their owner first. Private implementation details may remain
+for the Deliverer; the public meaning and acceptance boundary may not.
+
+Bind independent `kei`s in parallel. Do not split one acceptance boundary just
+to create parallel work.
+
+## 2. Split the Work
+
+Use these rules:
+
+- Separate `kei`s have independently acceptable outcomes.
+- An Arc is a chapter of one `kei`; it is not separately accepted.
+- A Task stores decomposition or dependencies that must outlive the current
+  conversation.
+
+Use `after` only when one `kei` requires another `kei` to be completed first.
+Ordinary overlap is not a dependency.
+
+## 3. Hold the `kei`
+
+Every `kei` has exactly one holder. The holder owns it until completion or
+termination, coordinates its work, delegates when useful, and is responsible
+for acceptance.
+
+The holder may work directly or delegate Akumas, Deliverers, Reviewers, Tasks,
+or Arcs. An Akuma holder must receive the `kei`, current Arc when one exists,
+worktree, and holder responsibilities in its prompt, and must have
+`contract.*` and `akuma.*`.
+
+## 4. Lifecycle
+
+```text
+bind -> tender -> gates and prerequisites pass -> automatic claim
+                                      \\-> abandon
+```
+
+- `bind` creates the `kei` with its terms, acceptance conditions, gates, and
+  dependencies.
+- `tender` submits the candidate for acceptance.
+- After tender, the `kei` is claimed automatically when its prerequisites and
+  every required gate pass.
+- `abandon` ends a `kei` without claiming it.
+- A claimed or abandoned `kei` is terminal.
+
+The holder may continue work and tender again while the `kei` is not terminal.
+
+## 5. Gates
+
+A gate is a named acceptance obligation. A tendered `kei` cannot be claimed
+until every selected gate has satisfied evidence.
+
+Bind gate options:
+
+```bash
+keiyaku bind --gates <name,...> -
+keiyaku bind --gates "" -
+keiyaku bind --gates reviewed -
+```
+
+- Omitting `--gates` selects `gates.default`; when no default bundle exists,
+  it selects `reviewed`.
+- `--gates <name,...>` selects gate names and configured bundles. Bundles
+  expand to their configured gates.
+- `--gates ""` binds the `kei` with no gates.
+- `--gates reviewed` selects the `reviewed` gate directly.
+
+Gates are acceptance requirements, not work assignments. The Deliverer
+produces the candidate, the relevant producer supplies evidence, and the holder
+coordinates the remaining work.
+
+## 6. Delegate the Work
+
+Delegate with a clear owner, objective, worktree, and expected result. Include
+the current Arc when one exists. A Deliverer produces the candidate. A Reviewer
+checks it against the `kei`'s acceptance conditions and returns evidence.
+Delegation does not transfer the holder's responsibility.
+
+Use `keiyaku-akuma` for Akuma invocation, telling, waiting, permissions, and
+history. Use command help for exact syntax.
+
+## 7. Decide What Happens Next
+
+The holder checks the tendered candidate, verification, review evidence,
+prerequisites, and gates.
+
+- If everything passes, automatic claim completes the `kei`.
+- If something is missing, continue the work or delegate the next chapter.
+- Amend when the objective and acceptance boundary remain the same but the
+  terms need to change.
+- Abandon and bind a new `kei` when the objective or acceptance boundary has
+  changed.
+
+For Contract authoring, read `keiyaku-bind`. For Akuma delegation, read
+`keiyaku-akuma`. For supervising many waiting `kei`s, read
+`keiyaku-babysit`.

package/build/src/akuma/akuma-handle.d.ts

@@ -78,6 +78,7 @@ export declare class AkumaHandle {
     tellOutcome(tellId: string, options?: Readonly<{
         timeoutMs?: number;
         signal?: AbortSignal;
+        observe?: (observation: import("./akuma-observe.js").LiveStatusObservation) => void | Promise<void>;
     }>): Promise<Readonly<{
         reason: WaitReason;
         outcome: TurnOutcome | null;

package/build/src/akuma/akuma-handle.js

@@ -8,7 +8,7 @@ import { resolveProviderExecution } from "./providers/index.js";
 import { publishAkuma } from "./publication.js";
 import { spawnAkumaBody } from "./body.js";
 import { AkumaNotBornError, AkumaProviderError } from "./akuma-errors.js";
-import { bornStatus, defaultWaitComplete, readWaitComplete, waitForObservation, } from "./akuma-observe.js";
+import { bornStatus, bornLiveStatus, defaultWaitComplete, readWaitComplete, waitForObservation, } from "./akuma-observe.js";
 const CALL_EXECUTION = Symbol("akuma-call-execution");
 function diagnostic(error) {
     return error instanceof Error ? error.message : String(error);
@@ -209,6 +209,9 @@ export class AkumaHandle {
                 if (tell === null)
                     throw new AkumaProviderError(`recorded Tell ${tellId} is missing from Heart`);
                 const outcome = await this.boundTellOutcome(tell);
+                if (options.observe !== undefined) {
+                    await options.observe(await bornLiveStatus(this.paths, this.id, { aperture: "monitoring", admittedTellId: tellId }));
+                }
                 return { outcome, terminalWithoutTurn: tell.state === "told" && tell.binding === undefined };
             },
             complete: (observed) => observed.outcome !== null || observed.terminalWithoutTurn,

package/build/src/akuma/akuma-observe.d.ts

@@ -15,6 +15,12 @@ export type BudgetedStatusObservation = Readonly<{
 export type LiveStatusObservation = BudgetedStatusObservation & Readonly<{
     rows: readonly ActivityRow[];
 }>;
+/** Internal live companion for an observation loop; it is not a public result. */
+export declare function bornLiveStatus(paths: AkumaPaths, expected: AkuId, input: Readonly<{
+    aperture: "monitoring" | "receipt";
+    ordinaryBudget?: number;
+    admittedTellId?: string;
+}>): Promise<LiveStatusObservation>;
 export declare function bornStatus(paths: AkumaPaths, expected: AkuId, input: Readonly<{
     aperture: "monitoring" | "receipt";
     ordinaryBudget?: number;

package/build/src/akuma/akuma-observe.js

@@ -56,7 +56,8 @@ async function bornObservation(paths, expected, read, snapshot) {
         claim?.release();
     }
 }
-async function bornLiveStatus(paths, expected, input) {
+/** Internal live companion for an observation loop; it is not a public result. */
+export async function bornLiveStatus(paths, expected, input) {
     if (input.ordinaryBudget !== undefined && (!Number.isSafeInteger(input.ordinaryBudget) || input.ordinaryBudget < 0))
         throw new TypeError("ordinary budget must be a nonnegative safe integer");
     const { snapshot, soul, currentLife } = await bornObservation(paths, expected, () => readLifeSnapshot(paths));
@@ -74,6 +75,7 @@ async function bornLiveStatus(paths, expected, input) {
         status: {
             id: soul.id,
             life: currentLife,
+            cwd: soul.cwd,
             allowed: soul.allowed,
             ...(soul.readonly === undefined ? {} : { readonly: soul.readonly }),
             ...(resumeUnsupported ? { strandedReason: "resume-unsupported" } : {}),

package/build/src/akuma/akuma.d.ts

@@ -32,6 +32,7 @@ export declare const akumaStatusSchema: z.ZodObject<{
         asleep: "asleep";
         stranded: "stranded";
     }>;
+    cwd: z.ZodOptional<z.ZodString>;
     allowed: z.ZodPipe<z.ZodArray<z.ZodEnum<{
         "task.add": "task.add";
         "task.addDocument": "task.addDocument";

package/build/src/akuma/akuma.js

@@ -26,6 +26,7 @@ export const akumaStatusSchema = z
     .object({
     id: akumaIdSchema,
     life: z.enum(["running", "asleep", "stranded", "hung", "untidy", "killed"]),
+    cwd: z.string().optional(),
     allowed: allowedActionsSchema,
     readonly: readonlySchema.optional(),
     timeline: activitySnapshotSchema,

package/build/src/akuma/fleet-execution.d.ts

@@ -1,4 +1,5 @@
-import { type AkumaStatus } from "./akuma.js";
+import { type AkumaStatus, type TellResult } from "./akuma.js";
+import { type LiveStatusObservation } from "./akuma-observe.js";
 import type { ActivityRow } from "./projection.js";
 import { type DispatchAssociation } from "./dispatch-association.js";
 import type { AkumaAlias } from "../identity/selector.js";
@@ -40,6 +41,10 @@ export type WaitExecutionInput = Readonly<{
     observe?: (observed: readonly WaitObservedAkuma[]) => void;
 }>;
 export declare function executeWaitAkuma(input: WaitExecutionInput): Promise<AkumaWaitResult>;
+export type TellWaitObserver = Readonly<{
+    admitted?: (tell: TellResult, id: AkumaStatus["id"]) => void | Promise<void>;
+    observe?: (observation: LiveStatusObservation) => void | Promise<void>;
+}>;
 export type TellExecutionInput = Readonly<{
     path: WorldRoot;
     id: AkumaStatus["id"];
@@ -48,6 +53,7 @@ export type TellExecutionInput = Readonly<{
     recordedAt?: string;
     initiator?: string;
     signal?: AbortSignal;
+    onObserve?: TellWaitObserver;
 }>;
 export declare function executeTellAkuma(input: TellExecutionInput): Promise<AkumaTellResult>;
 export declare function executeTellWaitAkuma(input: TellExecutionInput & Readonly<{

package/build/src/akuma/fleet-execution.js

@@ -126,6 +126,15 @@ export async function executeTellAkuma(input) {
         tell,
     });
 }
+function tellWaitObservation(observed) {
+    if (observed.outcome === null)
+        return observed.reason === "deadline" ? { reason: "deadline" } : { reason: "unanswered" };
+    if (observed.outcome.kind === "answered")
+        return { reason: "answered", answer: observed.outcome.answerJson ?? observed.outcome.answer };
+    if (observed.outcome.kind === "failed")
+        return { reason: "failed", diagnostic: observed.outcome.diagnostic };
+    throw new AkumaDecodeError(observed.outcome.diagnostic, observed.outcome.answer);
+}
 export async function executeTellWaitAkuma(input) {
     input.signal?.throwIfAborted();
     const handle = source(input.path).selectHandle({ id: input.id });
@@ -145,6 +154,7 @@ export async function executeTellWaitAkuma(input) {
         throw new AkumaProviderError(`Tell interrupt unavailable: ${admission.evidence}`);
     if (admission.kind === "not-born")
         throw new AkumaNotBornError(input.id);
+    await input.onObserve?.admitted?.(await handle.admittedReceipt(admission.tell.id), input.id);
     // The wake runs behind the window; a settled wake is preferred, otherwise the
     // receipt reports the admitted Tell as it stands when the window closes.
     let settled;
@@ -154,18 +164,9 @@ export async function executeTellWaitAkuma(input) {
     const observed = await handle.tellOutcome(admission.tell.id, {
         timeoutMs: input.timeoutMs,
         ...(input.signal === undefined ? {} : { signal: input.signal }),
+        ...(input.onObserve?.observe === undefined ? {} : { observe: input.onObserve.observe }),
     });
-    const observation = observed.outcome === null
-        ? observed.reason === "deadline"
-            ? { reason: "deadline" }
-            : { reason: "unanswered" }
-        : observed.outcome.kind === "answered"
-            ? { reason: "answered", answer: observed.outcome.answerJson ?? observed.outcome.answer }
-            : observed.outcome.kind === "failed"
-                ? { reason: "failed", diagnostic: observed.outcome.diagnostic }
-                : (() => {
-                    throw new AkumaDecodeError(observed.outcome.diagnostic, observed.outcome.answer);
-                })();
+    const observation = tellWaitObservation(observed);
     const tell = settled ?? (await handle.admittedReceipt(admission.tell.id));
     return fleetResultSchemas.tellWait.parse({ akuma: input.id, tell, observation });
 }

package/build/src/akuma/fleet-observation.d.ts

@@ -10,6 +10,7 @@ declare const akumaObservationSchema: z.ZodObject<{
             asleep: "asleep";
             stranded: "stranded";
         }>;
+        cwd: z.ZodOptional<z.ZodString>;
         allowed: z.ZodPipe<z.ZodArray<z.ZodEnum<{
             "task.add": "task.add";
             "task.addDocument": "task.addDocument";
@@ -481,6 +482,7 @@ declare const akumaWaitResultSchema: z.ZodObject<{
                 asleep: "asleep";
                 stranded: "stranded";
             }>;
+            cwd: z.ZodOptional<z.ZodString>;
             allowed: z.ZodPipe<z.ZodArray<z.ZodEnum<{
                 "task.add": "task.add";
                 "task.addDocument": "task.addDocument";
@@ -1173,6 +1175,7 @@ export declare const fleetResultSchemas: {
                     asleep: "asleep";
                     stranded: "stranded";
                 }>;
+                cwd: z.ZodOptional<z.ZodString>;
                 allowed: z.ZodPipe<z.ZodArray<z.ZodEnum<{
                     "task.add": "task.add";
                     "task.addDocument": "task.addDocument";