// What a streaming action looks like TO THE UI, and nothing more.
//
// `StreamActionLog` used to name `StreamActionResult` from
// `jobs/streamCommand` — the one component→jobs back-edge the layer guard
// carried on its allow-list. The type is not the problem; its `done` field is,
// because `Promise<JobDoneResult>` drags the job registry's `JobStatus` into
// the browser's type graph for a component that never reads it (see
// `StreamActionLog.tsx:140-147` — it reads ok/error/info/jobId/stream and
// stops).
//
// So the view keeps the four fields it renders. `StreamActionResult` stays
// where the dispatch layer needs it and remains ASSIGNABLE to this — the
// server hands back the richer object, the component sees the narrower one.
// `views/streamAction.test.ts` asserts that at compile time.
//
// ZERO IMPORTS, deliberately: this is what makes the edge disappear rather
// than move.

export type StreamActionView =
  | {
      ok: true;
      jobId: string;
      stream: ReadableStream<string>;
    }
  // `info: true` marks a non-error outcome that started no job (e.g. a
  // re-derived bucket that's currently empty) so the UI can show it neutrally
  // rather than as a red failure.
  | { ok: false; error: string; info?: boolean };