This module was its own miniature task system: a `running` boolean guarding
one run at a time, hand-rolled start/end timestamps, an ok flag, a log buffer,
and an end-of-run signalled by the WORDING of a log line. Core owns all of
that now (core#21), including the parts that were never right here.

The three apt operations become ctx.tasks.define actions; the routes only
start one and answer { runId }. Answering the verdict instead — the pattern
the fast host modules use — is not an option at this length: a dist-upgrade
has a 30-minute timeout and no HTTP client will hold the connection for it.

What actually improves, beyond the deprecation:

- A run survives the process. `running` went with whatever killed it, so an
  upgrade interrupted by a restart came back reading "idle"; it is now an
  `interrupted` row that says so. It is deliberately NOT retried — core cannot
  know how far dpkg got, and re-running a dist-upgrade that died mid-unpack is
  the module deciding on the operator's behalf to touch a half-configured
  system.
- The outcome is a status, not a sentence. The old contract inferred the end
  of a run from a log line starting "done" or "error", which is why dpkg's own
  "Errors were encountered while processing:" had to be disguised before being
  published.
- The runs record who asked for them.
- apt output is withheld from non-admins. `expose` names `result` only: the
  line tail is package names, repository URLs and configuration paths, and the
  projection withholds what an action does not opt in.

All three share `lock: "apt"`, because dpkg takes one lock on the host anyway
— a second apt landing mid-upgrade fails on the lock file, so a queue is the
honest version of what the `running` boolean was pretending to be. A security
upgrade queued behind a refresh is strictly better than before: it re-simulates
against lists that refresh just updated. They also share `target: "apt"` so
/summary can answer ctx.tasks.isBusy("apt") synchronously, which is what it
needs mid-render to decide whether the buttons apply.

The Activity view may offer `refresh` (args-free and non-destructive) but not
the two upgrades: its generic Run button carries no confirmation, and
installing packages on someone's host is not a one-tap affordance.

`progressTopic` stays on the schema actions, marked transitional. The routes
answer { runId } and a current client follows that instead — the shell drops
the topic the moment it sees one — but an Android build that predates task
runs would otherwise treat the 2xx that merely CREATED the run as the work
having succeeded, and report nothing when a dist-upgrade later failed. It goes
when the deployed app understands core:task:<runId> (mobile#4).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@@ -30,0 +38,4 @@
+ * module or the store being broken, which is a 500 and not the operator's
+ * fault to fix.
+ */
+function refusalStatus(err: unknown): 403 | 404 | 409 | 500 {

@@ -90,0 +120,4 @@
+  // per flush: the run's tail is joined with newlines wherever it is rendered,
+  // so a batch reads exactly like the lines it holds — and 512 retained
+  // entries now buy 512 batches rather than 512 lines.
+  const LOG_BATCH_LINES = 40;

@@ -90,0 +137,4 @@
+  }
+
+  function recordLine(line: string): void {
+    if (logHandle === null || !line.trim()) return;

@@ -166,0 +194,4 @@
+   * whatever apt printed last — the same fact core records as the run's
+   * status, written once and used for both.
+   */
+  async function withRunLog<T>(h: TaskHandle, label: string, body: () => Promise<T>): Promise<T> {

@@ -168,0 +267,4 @@
+    // dpkg database in a state someone has to repair by hand
+    capabilities: { cancel: false as const, retry: "new-run" as const },
+    expose: ["result" as const],
+    notifyOn: ["failed" as const],

@@ -168,0 +350,4 @@
+      withRunLog(h, "Install all updates", async () => {
+        const code = await h.step("apt-get dist-upgrade", () =>
+          apt([...APT_OPTS, "dist-upgrade"], UPGRADE_TIMEOUT_MS));
+        if (code !== 0) throw new Error(`apt-get dist-upgrade exited ${code}`);

@@ -343,1 +547,3 @@
-    const canRun = host.available && !runState.running;
+    // synchronous on purpose: this is a decision taken mid-render, and an
+    // await here would mean keeping a second copy of core's own state
+    const running = ctx.tasks.isBusy("apt");

@@ -344,0 +547,4 @@
+    // synchronous on purpose: this is a decision taken mid-render, and an
+    // await here would mean keeping a second copy of core's own state
+    const running = ctx.tasks.isBusy("apt");
+    const canRun = host.available && !running;

@@ -406,0 +600,4 @@
+    // Five, not one: while a run waits on the apt lock the newest row is not
+    // the one producing output. `runView` decides which is; it is a pure
+    // function so that decision has a test (`runview_test.ts`).
+    const recent = await ctx.tasks.list({ limit: 5 });

@@ -0,0 +25,4 @@
+  text: string;
+  label: string;
+  running: boolean;
+  queued: number;

@@ -0,0 +36,4 @@
+ * and this backend imports the SDK type-only. Kept in step with `RunStatus`
+ * in core's `packages/sdk/tasks.ts`.
+ */
+export const TERMINAL = [

@@ -0,0 +107,4 @@
+  if (run.status === "waiting") {
+    return "Queued behind another update run — the log starts when apt does.";
+  }
+  return `No log for this run — it ran before the last restart. Status: ${run.status}.`;

@@ -0,0 +133,4 @@
+  eq(done("failed"), "Install all updates — failed", "failed");
+  eq(done("skipped"), "Install all updates — skipped", "skipped");
+  eq(done("interrupted"), "Install all updates — interrupted", "interrupted");
+});

@@ -28,0 +52,4 @@
+Non-admins see that a run happened and how it ended, but never its output.
+apt and dpkg print package names, repository URLs and configuration paths, so
+all four ways out are closed together: the run's line tail (core's projection
+— `expose` names `result` only), `GET /run`, the `runlog` live topic and the

@@ -60,0 +84,4 @@
+      // data", and the dashboard card reads "up to date" mid-upgrade. Serving
+      // the last known state is stale by minutes; the alternative is wrong.
+      // The run invalidates this cache when it ends.
+      if (ctx.tasks.isBusy("apt")) return cache.state;

@@ -168,0 +231,4 @@
+    lock: () => "apt",
+    // apt is not interruptible halfway through unpacking without leaving the
+    // dpkg database in a state someone has to repair by hand
+    capabilities: { cancel: false as const, retry: "new-run" as const },

@@ -476,0 +687,4 @@
+    // samples and a "could not get lock" in the Package data field. The run
+    // publishes "updates" when it ends and invalidates the cache with it, so
+    // nothing is lost by waiting for it.
+    if (ctx.tasks.isBusy("apt")) return;

@@ -0,0 +71,4 @@
+  // run holding the lock — that is what somebody watching wants to see. And a
+  // refused double click leaves a `skipped` row that is newer than the run it
+  // was refused for, so ANY live run outranks the newest terminal one.
+  const run = live.find((r) => r.id === log.runId) ?? live[0] ?? recent[0];

@@ -168,0 +277,4 @@
+    run: (h) =>
+      withRunLog(h, "Refresh package lists", async () => {
+        const code = await h.step("apt-get update", () => apt(["update"], REFRESH_TIMEOUT_MS));
+        if (code !== 0) throw new Error(`apt-get update exited ${code}`);

@@ -476,3 +708,4 @@
+    // falling mid-upgrade is real data over the only window it moves.
     if (!host.available && !await host.probe()) return;
     const s = await load(true);
 

@@ -406,0 +616,4 @@
+    // would win it instead; `runView` prefers a non-skipped row as a second
+    // line of defence (tested), but it can only pick from what arrives here.
+    const live = await ctx.tasks.list({ status: [...LIVE] });
+    const recent = live.length > 0 ? live : await ctx.tasks.list({ limit: 1 });

@@ -166,0 +180,4 @@
+ * refreshed" over lists that were never refreshed, which is the one failure a
+ * module whose whole job is "the host is behind" must not swallow.
+ *
+ * Scanning the output rather than passing `-o APT::Update::Error-Mode=any`:

@@ -99,1 +100,4 @@
+  // assumed: rc=0 with and without the flag, counts tracking the upgrade as
+  // it lands. This line is what makes it safe for load() and the collector to
+  // simulate mid-run; do not add an `isBusy("apt")` guard upstream of it.
   const res = await deps.host.run(