@alexkroman1/aai-cli 9.2.0 → 10.0.1

package/dist/templates/transcription-workflow/recover.ts

@@ -0,0 +1,130 @@
+// Copyright 2026 the AAI authors. MIT license.
+/**
+ * What a reload has to remember BESIDES the key: which MODE started the run.
+ *
+ * A `runId` names a run for as long as something holds it, and the page holds it
+ * in React state — so a refresh loses it while the fan-out carries on
+ * transcribing. `useWorkflowSubmit({ key, recover: true })` is the fix; the key
+ * itself is `useRunKey()` (`@alexkroman1/aai-ui`), which owns the minting, the
+ * storage and the argument for both. What is left here is the value that is
+ * this PAGE's own concept — the mode — plus the sentence the page says while a
+ * run it did not start is arriving.
+ *
+ * It is its own module for two reasons, and only the second is about keeping
+ * `client.tsx` down to the page's shape:
+ *
+ * - **A template's spec is what makes its exemplar code true**, and none of this
+ *   can be tested from a `client.tsx`. That file ends in a `page()` call and
+ *   imports a stylesheet, and this package's suites have no DOM at all: the
+ *   vitest `include` matches `.test.ts` and not `.test.tsx`, and the scaffold
+ *   declares no React testing library — so a `client.test.tsx` would be
+ *   collected by nothing here AND would break `aai test` in a scaffolded
+ *   project. Here the decisions are ordinary functions, so `recover.test.ts`
+ *   pins them; what only a DOM can show (that the hook adopts the run, once,
+ *   and never over a submit) is `aai-ui`'s own suite.
+ * - The mode recall has a REAL branch in it: what comes back out of storage is
+ *   an untrusted string, and a page that trusted it would index `WORKFLOWS`
+ *   with it and start a run by the name `undefined` — a 400 from a value nobody
+ *   typed.
+ *
+ * ## The two values keep the same lifetime, and it is not a coincidence
+ *
+ * The mode lives in `sessionStorage`, which is the store `useRunKey()` defaults
+ * to and the same lifetime as the SDK's own upload recall (`useWorkflowSubmit`
+ * remembers the id it minted, so picking the same file again sends only the
+ * windows that did not land). All three halves of a reload therefore make the
+ * same promise: a mode remembered longer than the key that finds the run would
+ * open the desk on a flow with nothing behind it.
+ */
+
+/** Where the mode that last submitted lives between loads. */
+const MODE_STORAGE = "transcription-workflow:mode";
+
+/**
+ * Remember which flow the reader picked, so the next load shows the run it
+ * started.
+ *
+ * Without this the recovery is half-done in a way that reads as broken: the
+ * mode resets to the default on a reload, so a recovered classic run sits
+ * behind a radio nobody pressed while the page in front of the reader is an
+ * empty form — which is the "start a second run" invitation the key exists to
+ * remove.
+ *
+ * @param mode - The mode that is about to submit.
+ */
+export function rememberMode(mode: string): void {
+  try {
+    globalThis.sessionStorage?.setItem(MODE_STORAGE, mode);
+  } catch {
+    // A desk that cannot remember its mode still transcribes; it just opens on
+    // the default next time.
+  }
+}
+
+/**
+ * The mode the last load submitted with, if it is still one of the modes.
+ *
+ * The validation is the point. Storage hands back a string this page wrote
+ * SOME version ago — a renamed mode, a hand-edited value, a key another app on
+ * the origin happens to share — and the page turns a mode into a workflow NAME.
+ * An unchecked value would start a run called `undefined` and answer a 400
+ * nobody can explain, so anything not in `valid` falls back.
+ *
+ * @param valid - The modes this page offers, which is the page's own list
+ *   rather than a copy of it.
+ * @param fallback - The mode to open on when there is nothing to recall.
+ * @returns One of `valid`, always.
+ */
+export function recalledMode<M extends string>(valid: readonly M[], fallback: M): M {
+  try {
+    const stored = globalThis.sessionStorage?.getItem(MODE_STORAGE);
+    // `find` rather than a cast plus `includes`: the narrowing is then the
+    // lookup's own, so there is nothing to keep in step by hand.
+    return valid.find((mode) => mode === stored) ?? fallback;
+  } catch {
+    return fallback;
+  }
+}
+
+/** What {@link pendingNote} needs to know about the run in flight. */
+export type PendingNoteInput = {
+  /**
+   * Whether this flow's run can be picked up after a reload at all.
+   *
+   * False for the streaming flow, and the sentence has to say so — see
+   * {@link pendingNote}.
+   */
+  recoverable: boolean;
+  /** Whether THIS load pressed Transcribe. A reload cannot have. */
+  startedHere: boolean;
+  /** Whether a run has arrived yet, which on a reload means the lookup landed. */
+  found: boolean;
+};
+
+/**
+ * What the desk says while something is in flight — four situations, one line
+ * each.
+ *
+ * The one that earns this function is the first: the streaming flow's run reads
+ * the recording as this page sends it, so a reload does not orphan that run, it
+ * ENDS it — `workflows/stream.ts` gives an upload that stops growing five
+ * minutes (`MAX_IDLE_POLLS`) before it calls the uploader gone and fails the
+ * run. A page telling a reader they can close the tab would be wrong in the
+ * mode this desk opens in.
+ *
+ * The other three are the ordinary recovery copy, and the reload case gets its
+ * own words deliberately: somebody who did not press the button is owed an
+ * explanation for a transcript appearing in front of them, and it is the line
+ * that stops them sending the recording again.
+ *
+ * @param input - See {@link PendingNoteInput}.
+ * @returns One sentence, always.
+ */
+export function pendingNote(input: PendingNoteInput): string {
+  const { recoverable, startedHere, found } = input;
+  if (!recoverable)
+    return "Keep this tab open — the run is reading the recording as this page sends it, so a reload ends the run.";
+  if (startedHere) return "Reloading is safe — this page will find the run again.";
+  if (!found) return "Looking for a transcript this tab started earlier…";
+  return "Still transcribing a recording this tab sent earlier — no need to send it again.";
+}

package/dist/templates/transcription-workflow/run-panel.tsx

@@ -0,0 +1,203 @@
+// Copyright 2026 the AAI authors. MIT license.
+/**
+ * What a run LOOKS like — one in flight, and every one before it.
+ *
+ * `client.tsx` owns the page's shape: the form, the three hooks, the mode, and
+ * which of them is active. This module owns the readouts, which are the same
+ * whichever hook produced the run — a `WorkflowRun<Transcript>` is a
+ * `WorkflowRun<Transcript>` whether it arrived from `useWorkflowStream`,
+ * `useWorkflowSubmit` or the history listing, which is exactly why `<RunPanel>`
+ * serves both the live run and an expanded past one.
+ *
+ * Three components, in the order a reader meets them:
+ *
+ * - **`<RunPanel>`** — the status, the narration, and the transcript once there
+ *   is one.
+ * - **`<LiveTranscript>`** — the transcript as it ARRIVES, which is what makes a
+ *   sixty-segment fan-out watchable.
+ * - **`<History>`** — every recent run, newest first.
+ */
+
+import { countWords, formatDuration, plural } from "@alexkroman1/aai/utils";
+import type { WorkflowOutputOf } from "@alexkroman1/aai/workflow-api";
+import {
+  isTerminal,
+  useWorkflowProgress,
+  WORKFLOW_STATUS_LABELS,
+  WorkflowProgress,
+  type WorkflowRun,
+} from "@alexkroman1/aai-ui";
+import { useMemo } from "react";
+import type { transcribe } from "./agent.ts";
+import { stitchChunks, TRANSCRIPT_STREAM, type TranscriptChunk } from "./workflows/stitch.ts";
+
+/**
+ * What a finished run reports.
+ *
+ * Derived from the workflow declaration rather than restated — `import type` is
+ * erased, so naming `transcribe` here bundles none of the agent, the SDK, or the
+ * workflow body into this page.
+ */
+export type Transcript = WorkflowOutputOf<typeof transcribe>;
+
+/** Most past runs the history list shows. */
+export const HISTORY_LIMIT = 10;
+
+/**
+ * One line describing where a run has got to.
+ *
+ * `WORKFLOW_STATUS_LABELS` is the SDK's neutral map — a `Record` keyed by the
+ * status union rather than a switch, so a status added upstream is a compile
+ * error in one place every page inherits, and spreading a complete record cannot
+ * drop a key. Two of these keys are really this desk's: a page knows what its
+ * workflow does and the SDK does not.
+ */
+const STATUS_LINE = {
+  ...WORKFLOW_STATUS_LABELS,
+  running: "Transcribing…",
+  completed: "Transcript ready",
+};
+
+/**
+ * Every recent run, newest first, with its transcript one click away.
+ *
+ * This is what a durable workflow with an HTTP API is FOR, and the page used to
+ * squander it: a run id is the whole handle — no session, no cookie — so
+ * `GET /workflows/runs` can answer "what has this desk transcribed" for any tab,
+ * any machine, days later. What stood here instead was a text box asking the
+ * reader to paste an id they would have had to write down, which is the same
+ * information behind a worse door.
+ */
+export function History({
+  runs,
+  error,
+  openId,
+  onOpen,
+}: {
+  runs: WorkflowRun<Transcript>[];
+  error: string | undefined;
+  openId: string | undefined;
+  onOpen: (runId: string) => void;
+}) {
+  return (
+    <section className="flex flex-col gap-3 border-t pt-6">
+      <h2 className="text-sm font-medium uppercase tracking-[1.2px]">Previous runs</h2>
+      {error !== undefined && <p className="text-sm text-red-600">{error}</p>}
+      {runs.length === 0 && error === undefined && (
+        <p className="text-sm opacity-60">Nothing transcribed yet.</p>
+      )}
+      <ul className="flex flex-col">
+        {runs.map((entry) => (
+          <li key={entry.runId} className="border-b last:border-b-0">
+            <button
+              type="button"
+              onClick={() => onOpen(entry.runId)}
+              className="flex w-full items-baseline justify-between gap-4 py-2 text-left text-sm"
+            >
+              <span className="truncate">{title(entry)}</span>
+              <span className="shrink-0 text-xs opacity-60">{STATUS_LINE[entry.status]}</span>
+            </button>
+            {openId === entry.runId && <RunPanel run={entry} />}
+          </li>
+        ))}
+      </ul>
+    </section>
+  );
+}
+
+/**
+ * One line naming a past run.
+ *
+ * The FILE where there is one — `mergeTranscript` puts the recording's own name
+ * in the output for exactly this — falling back to the id, which is all a run
+ * that failed before it read the upload ever had.
+ */
+function title(run: WorkflowRun<Transcript>): string {
+  if (run.status === "completed") return run.output.source;
+  return run.runId;
+}
+
+/** The run's status, its narration, and its transcript once there is one. */
+export function RunPanel({ run, onClear }: { run: WorkflowRun<Transcript>; onClear?: () => void }) {
+  return (
+    <section className="flex flex-col gap-3 rounded-md border p-5">
+      <div className="flex items-baseline justify-between gap-4">
+        <h2 className="text-sm font-medium uppercase tracking-[1.2px]">
+          {STATUS_LINE[run.status]}
+        </h2>
+        {onClear && (
+          <button type="button" onClick={onClear} className="text-xs underline opacity-60">
+            Clear
+          </button>
+        )}
+      </div>
+
+      {/* The run's own narration, oldest first — the complement of `STATUS_LINE`
+          above, and the reason both exist: the status is `running` for the whole
+          fan-out, so a sixty-segment recording and a one-segment recording look
+          identical while they run. These lines come from the run itself
+          (`report()` in `workflows/transcribe.ts`), and they REPLAY, so looking a
+          finished run up in the panel below shows how it got there. */}
+      <WorkflowProgress runId={run.runId} />
+
+      {/* While it runs, the transcript so far. Unguarded on the run's status
+          beyond this: the component renders nothing until a segment has landed,
+          and stops the moment there is an `output` to render instead. */}
+      {!isTerminal(run) && <LiveTranscript runId={run.runId} />}
+
+      {/* Discriminated on `status`, so `output` and `error` are reachable
+          without a cast — the reason a snapshot is a union rather than a flat
+          object with optional fields. */}
+      {run.status === "completed" && (
+        <>
+          <p className="text-xs opacity-60">
+            {run.output.segments} {plural(run.output.segments, "segment")} ·{" "}
+            {formatDuration(run.output.durationMs)} of audio · took{" "}
+            {formatDuration(run.output.elapsedMs)} · {run.output.words} words
+          </p>
+          <pre className="whitespace-pre-wrap text-sm leading-relaxed">{run.output.transcript}</pre>
+        </>
+      )}
+      {run.status === "failed" && <p className="text-red-600">{run.error}</p>}
+    </section>
+  );
+}
+
+/**
+ * The transcript as it arrives, stitched from the segments that have landed.
+ *
+ * The other half of `<WorkflowProgress>` above it: that one renders what the run
+ * SAYS about itself, this one renders what it has produced. Both are the same
+ * mechanism — a run's output stream — separated by the namespace, which is what
+ * lets this one be typed.
+ *
+ * It renders NOTHING until a segment lands, so a page can mount it unguarded:
+ * before the first chunk there is nothing to say that the progress log is not
+ * already saying better.
+ *
+ * The count is derived from the stitched text rather than summed per chunk,
+ * because the seams overlap — adding up the segments would over-count every one
+ * of them by a couple of seconds' worth of words.
+ */
+function LiveTranscript({ runId }: { runId: string }) {
+  const { progress } = useWorkflowProgress<TranscriptChunk>(runId, {
+    namespace: TRANSCRIPT_STREAM,
+  });
+  // Memoized on the ARRAY, which the hook appends to per read: stitching is a
+  // seam search per segment, and a fan-out re-renders this panel on every
+  // progress poll whether or not anything arrived.
+  const transcript = useMemo(() => stitchChunks(progress), [progress]);
+  if (progress.length === 0) return null;
+
+  // The furthest point reached, not the count: segments land out of order, so
+  // "6 segments" says nothing about how much of the recording is covered.
+  const covered = Math.max(...progress.map((chunk) => chunk.endMs));
+  return (
+    <div className="flex flex-col gap-2">
+      <p className="text-xs opacity-60">
+        {countWords(transcript)} words so far · through {formatDuration(covered)}
+      </p>
+      <pre className="whitespace-pre-wrap text-sm leading-relaxed opacity-80">{transcript}</pre>
+    </div>
+  );
+}

package/dist/templates/transcription-workflow/total-latency.tsx

@@ -0,0 +1,144 @@
+// Copyright 2026 the AAI authors. MIT license.
+/**
+ * Press to transcript, which is the one number neither bar can give.
+ *
+ * The upload bar and the progress log describe the two stretches separately, and
+ * neither answers the question a reader comparing the three modes is actually
+ * asking. Nothing on the server can answer it either — `output.elapsedMs` is the
+ * RUN's own wall clock, so in the two modes that store the file first it begins
+ * after the upload and misses most of the wait. Only the browser holds both
+ * ends.
+ *
+ * Its own module because it is a self-contained instrument — a stopwatch and the
+ * one section that prints it — and `client.tsx` is the file a reader goes to for
+ * the page's SHAPE.
+ */
+
+import { formatDuration } from "@alexkroman1/aai/utils";
+import { useCallback, useEffect, useRef, useState } from "react";
+
+/**
+ * How often the running stopwatch re-renders.
+ *
+ * Under a second, so the displayed seconds turn over promptly rather than up to a
+ * second late; nothing reads this value, since the elapsed time is measured from
+ * the clock at render (see {@link useTotalLatency}).
+ */
+const STOPWATCH_TICK_MS = 250;
+
+/** What {@link useTotalLatency} reports. */
+export type TotalLatency = {
+  /**
+   * Milliseconds since the submit — ticking while the submission is in flight,
+   * frozen at the finish, and undefined before the first one.
+   */
+  elapsedMs: number | undefined;
+  /** Whether the clock is still running, which is what makes the label honest. */
+  running: boolean;
+  /** Start (or restart) the clock. Called from the form's own submit handler. */
+  start: () => void;
+  /** Drop it, for a panel that no longer describes the submission it timed. */
+  clear: () => void;
+};
+
+/**
+ * Wall clock from the submit to the finish, across both waits.
+ *
+ * `inFlight` is the submission's own `pending` — true from `submit()` until the run
+ * reaches a terminal status — so the clock covers the upload, the run, and the
+ * gap between them, which is the whole of what a reader waits for and is the one
+ * measurement no server-side number can make.
+ *
+ * Two details it would be easy to get wrong:
+ *
+ * - **The interval re-renders; it does not accumulate.** The elapsed time is read
+ *   from the clock at render, so a tick the tab throttled or dropped cannot make
+ *   the number lag behind real time.
+ * - **`performance.now()`, not `Date.now()`.** It is monotonic, so a clock
+ *   correction (NTP, a laptop waking up) cannot make a transcription look
+ *   instant — or negative.
+ */
+export function useTotalLatency(inFlight: boolean): TotalLatency {
+  const [startedAt, setStartedAt] = useState<number | undefined>(undefined);
+  const [frozenMs, setFrozenMs] = useState<number | undefined>(undefined);
+  // Re-render trigger only — see the doc above.
+  const [, tick] = useState(0);
+  // Whether `inFlight` has been seen true since the last `start()`. Without it,
+  // a start that lands one render before the submission reports itself in flight
+  // would freeze the clock at zero instead of running it.
+  const began = useRef(false);
+
+  useEffect(() => {
+    if (startedAt === undefined || frozenMs !== undefined) return;
+    if (inFlight) {
+      began.current = true;
+      const id = setInterval(() => tick((n) => n + 1), STOPWATCH_TICK_MS);
+      return () => clearInterval(id);
+    }
+    // Measured here rather than at render, so the frozen number is the one at the
+    // moment the run settled rather than whenever this page next drew.
+    if (began.current) setFrozenMs(performance.now() - startedAt);
+  }, [startedAt, frozenMs, inFlight]);
+
+  const start = useCallback(() => {
+    began.current = false;
+    setFrozenMs(undefined);
+    setStartedAt(performance.now());
+  }, []);
+
+  const clear = useCallback(() => {
+    began.current = false;
+    setStartedAt(undefined);
+    setFrozenMs(undefined);
+  }, []);
+
+  return {
+    elapsedMs: frozenMs ?? (startedAt === undefined ? undefined : performance.now() - startedAt),
+    running: startedAt !== undefined && frozenMs === undefined,
+    start,
+    clear,
+  };
+}
+
+/**
+ * The one number the two bars cannot give: click to transcript.
+ *
+ * Rendered above the run panel rather than inside it, because the stretch it
+ * covers starts before there IS a run — in two of the three modes the run does
+ * not exist until the upload finishes, so a clock living in the panel would
+ * appear only after the wait it is supposed to be timing.
+ *
+ * `runMs` is the run's own elapsed, once it reports one. The remainder is
+ * everything the run could not see: storing the file (or, in streaming mode,
+ * minting the upload id), the `POST` that starts the run, and the poll that
+ * notices it finished. Clamped at zero, because the two numbers come from two
+ * different clocks on two different machines and a few milliseconds the wrong way
+ * would otherwise print a negative.
+ */
+export function TotalLatency({
+  elapsedMs,
+  running,
+  runMs,
+}: {
+  elapsedMs: number | undefined;
+  running: boolean;
+  runMs: number | undefined;
+}) {
+  if (elapsedMs === undefined) return null;
+  const outside = runMs === undefined ? undefined : Math.max(0, elapsedMs - runMs);
+  return (
+    <section className="flex flex-wrap items-baseline justify-between gap-x-4 gap-y-1 rounded-md border px-5 py-3">
+      <h2 className="text-sm font-medium uppercase tracking-[1.2px]">
+        {running ? "Elapsed" : "Total latency"}
+      </h2>
+      <span className="flex flex-wrap items-baseline gap-x-3 gap-y-1">
+        <span className="text-sm tabular-nums">{formatDuration(elapsedMs)}</span>
+        {runMs !== undefined && outside !== undefined && (
+          <span className="text-xs tabular-nums opacity-60">
+            {formatDuration(outside)} before the run · {formatDuration(runMs)} inside it
+          </span>
+        )}
+      </span>
+    </section>
+  );
+}

package/dist/templates/transcription-workflow/workflows/batch.ts

@@ -33,10 +33,9 @@
  *
  * What stays here is what a dependency cannot decide: how many steps to cut the job
  * into, and therefore what is journaled and what a retry repeats. That is also
- * structural rather than stylistic — the Workflow DevKit's builder transforms
- * exactly the files under this `workflows/` directory, so a `"use step"` shipped
- * inside the SDK would be transformed by nothing and would run inline with no
- * journal and no retry, silently.
+ * structural rather than stylistic — only the caller with a `ctx` can open a
+ * step, so a step boundary shipped inside the SDK would be no boundary at all:
+ * it would run inline, with no journal and no retry, silently.
  *
  * ## The one thing that makes this a WORKFLOW rather than a request
  *
@@ -54,6 +53,7 @@
  * request rather than two and the value journaled by the last poll IS the result.
  */
 
+import type { WorkflowCtx } from "@alexkroman1/aai";
 import { report, TRANSCRIBE_API, uploadInfo } from "@alexkroman1/aai/step";
 import {
   stepTranscribePollClassified,
@@ -61,38 +61,44 @@ import {
   stepTranscribeUploadClassified,
 } from "@alexkroman1/aai/step-errors";
 import { countWords, formatBytes } from "@alexkroman1/aai/utils";
-import { sleep } from "workflow";
 import { startClock, type Transcript } from "./transcribe.ts";
 
 /** How long between polls of a submitted job. */
-const POLL_INTERVAL = "10s";
+const POLL_INTERVAL_MS = 10_000;
 
 /**
  * Polls before the run gives up on a job.
  *
- * At {@link POLL_INTERVAL} this is an hour, well past what the async API takes for
+ * At {@link POLL_INTERVAL_MS} this is an hour, well past what the async API takes for
  * any recording it accepts. Bounded rather than endless because a job that never
  * leaves `queued` is a run that would otherwise be replayed forever.
  */
 const MAX_POLLS = 360;
 
 /** Transcribe a recording through the async API. */
-export async function transcribeBatchFlow(input: { recording: string }): Promise<Transcript> {
-  "use workflow";
-
+export async function transcribeBatchFlow(
+  input: { recording: string },
+  ctx: WorkflowCtx,
+): Promise<Transcript> {
   // Both at once: the clock does not depend on the upload, and issuing them
   // together costs one round trip instead of two before a byte moves. Their issue
   // order is still decided by this line rather than by which lands first.
+  // `maxAttempts: 6` was `uploadToProvider.maxRetries = 5` — five retries after
+  // the first, so six in all. More than the default 3 because an upload is the
+  // one call here worth another attempt: it moves the whole recording, and a lost
+  // connection on a file this size is the expected failure.
   const [startedAt, { audioUrl }] = await Promise.all([
-    startClock(),
-    uploadToProvider(input.recording),
+    ctx.step("startClock", () => startClock()),
+    ctx.step("uploadToProvider", () => uploadToProvider(input.recording), { maxAttempts: 6 }),
   ]);
-  const job = await createJob(audioUrl);
+  const job = await ctx.step("createJob", () => createJob(audioUrl));
 
   for (let poll = 0; poll < MAX_POLLS; poll += 1) {
-    const progress = await pollTranscript(input.recording, job.id, startedAt);
+    const progress = await ctx.step("pollTranscript", () =>
+      pollTranscript(input.recording, job.id, startedAt),
+    );
     if (progress.done) return progress.transcript;
-    await sleep(POLL_INTERVAL);
+    await ctx.sleep(POLL_INTERVAL_MS);
   }
   // A plain throw: this is the BODY, where the fatal/retryable distinction has
   // nothing to apply to — see `stream.ts`'s `abandon` for the same reasoning.
@@ -123,8 +129,6 @@ export async function transcribeBatchFlow(input: { recording: string }): Promise
  * same reason.
  */
 export async function uploadToProvider(uploadId: string): Promise<{ audioUrl: string }> {
-  "use step";
-
   const stored = await uploadInfo(uploadId);
   await report(
     `Uploading ${stored.name || uploadId} (${formatBytes(stored.size)}) to the async API.`,
@@ -132,13 +136,8 @@ export async function uploadToProvider(uploadId: string): Promise<{ audioUrl: st
   return await stepTranscribeUploadClassified(uploadId);
 }
 
-/** Retries beyond the default 3: an upload is the one call here worth another attempt. */
-uploadToProvider.maxRetries = 5;
-
 /** Create the transcription job, and answer with the id that outlives this run. */
 export async function createJob(audioUrl: string): Promise<{ id: string }> {
-  "use step";
-
   const job = await stepTranscribeSubmitClassified(audioUrl);
   await report(`Submitted — job ${job.id}.`);
   return job;
@@ -157,8 +156,6 @@ export async function pollTranscript(
   id: string,
   startedAt: number,
 ): Promise<{ done: false } | { done: true; transcript: Transcript }> {
-  "use step";
-
   const progress = await stepTranscribePollClassified(id);
   if (!progress.done) {
     await report(`Transcript ${id} is ${progress.status}.`);