diff --git a/run.json b/run.json
index c02b828a3..0d61f317e 100644
--- a/run.json
+++ b/run.json
@@ -492,7 +492,7 @@
     "kind": "running"
   },
   "status_updated_at": "2026-05-24T01:42:40.350880Z",
-  "last_event_at": "2026-05-24T01:42:47.237937Z",
+  "last_event_at": "2026-05-24T01:44:55.050501Z",
   "pending_control": null,
   "checkpoints": [
     {
@@ -590,9 +590,9 @@
       }
     },
     {
-      "seq": 0,
+      "seq": 40,
       "checkpoint": {
-        "timestamp": "2026-05-24T01:44:51.333165Z",
+        "timestamp": "2026-05-24T01:44:55.047761Z",
         "current_node": "preflight_compile",
         "completed_nodes": [
           "start",
@@ -601,20 +601,92 @@
         ],
         "node_retries": {},
         "context_values": {
+          "thread.start.current_node": "toolchain",
+          "internal.thread_id": "toolchain",
+          "graph.rankdir": "LR",
+          "internal.retry_count.toolchain": 0,
           "internal.retry_count.preflight_compile": 0,
+          "internal.work_dir": "/home/daytona/workspace/fabro",
+          "graph.model_stylesheet": "\n            * { model: claude-opus-4-7; }\n        ",
+          "internal.fidelity": "compact",
+          "graph.goal": "---\ntitle: feat: Batch run archive actions\ntype: feat\nstatus: active\ndate: 2026-05-24\n---\n\n# feat: Batch Run Archive Actions\n\n## Overview\n\nAdd API support for archiving and unarchiving multiple runs in one request, then update the web list and board multi-run actions to use the new batch endpoints. The existing single-run archive and unarchive endpoints remain unchanged for run-scoped callers and direct lifecycle actions.\n\n## Problem Frame\n\nThe web UI currently performs multi-run archive/unarchive actions by issuing one lifecycle request per selected run. That works, but it puts batch orchestration in the browser, repeats request overhead, and leaves API/CLI/MCP consumers without a first-class batch contract. A bounded fail-soft batch endpoint gives the server ownership of the multi-run operation while preserving the independent event stream semantics of each run.\n\n## Requirements Trace\n\n- R1. Provide public API endpoints that archive and unarchive many runs in one request.\n- R2. Preserve existing single-run archive/unarchive behavior, including eligibility, idempotency, and emitted events.\n- R3. Return per-run results so mixed-success batches can be reported without rolling back successful items.\n- R4. Update web bulk actions to make one request per batch action instead of one request per run.\n- R5. Keep cache invalidation and toast behavior equivalent to the current UI.\n\n## Scope Boundaries\n\n- Do not make batch archive/unarchive transactional; each run remains an independent event stream.\n- Do not add new workflow event variants; successful batch items emit the same run archive/unarchive events as single-run actions.\n- Do not change the existing `POST /api/v1/runs/{id}/archive` or `POST /api/v1/runs/{id}/unarchive` contracts.\n- Do not add CLI commands in this change; this plan is limited to HTTP API and web UI usage.\n\n## Context & Research\n\n### Relevant Code and Patterns\n\n- OpenAPI is the source of truth for HTTP contracts in `docs/public/api-reference/fabro-api.yaml`.\n- Server lifecycle routes live in `lib/crates/fabro-server/src/server/handler/lifecycle.rs`; single-run archive/unarchive already funnel through `operations::archive` and `operations::unarchive`.\n- Batch routes that are not tied to one path run ID should use `RequiredUser`, not `RequireRunScopedOrRunTools`, because a run-scoped worker token cannot safely authorize mutation of arbitrary run IDs from a request body.\n- Web lifecycle helpers live in `apps/fabro-web/app/lib/run-actions.ts`; list and board multi-run archive behavior lives in `apps/fabro-web/app/routes/runs.tsx`.\n- Run-list cache invalidation already uses `mutateRunListCaches` in `apps/fabro-web/app/lib/board-cache.ts`.\n\n### Strategy Docs\n\n- `docs/internal/testing-strategy.md`: server tests should assert public HTTP contracts and prefer structured assertions.\n- `docs/internal/error-handling-strategy.md`: preserve structured errors internally and return curated API messages at HTTP boundaries.\n- `docs/internal/events-strategy.md`: no new events are needed because existing per-run lifecycle events already represent the durable state transition.\n\n## Key Technical Decisions\n\n- Add collection action endpoints `POST /api/v1/runs/archive` and `POST /api/v1/runs/unarchive`. These avoid changing single-run URLs and keep generated client methods clear (`batchArchiveRuns`, `batchUnarchiveRuns`).\n- Use fail-soft HTTP `200` responses for valid batch requests, even when individual items fail. Per-item failures carry structured result entries; request-level validation failures still return normal `400` errors.\n- Validate `run_ids` at the request boundary: non-empty, maximum 250 IDs, no duplicates, and every value parseable as a `RunId`. Invalid request bodies must not mutate any runs.\n- Process eligible IDs sequentially in server code. The batch is bounded, lifecycle operations append events, and sequential processing avoids adding lock-order or concurrency behavior that the feature does not need.\n- Treat idempotent single-run outcomes as successful batch outcomes: already archived counts as success for archive; terminal not-archived counts as success for unarchive.\n\n## API Contract\n\nAdd these OpenAPI operations:\n\n- `POST /api/v1/runs/archive`\n  - operationId: `batchArchiveRuns`\n  - request: `BatchRunLifecycleRequest`\n  - response: `BatchRunLifecycleResponse`\n- `POST /api/v1/runs/unarchive`\n  - operationId: `batchUnarchiveRuns`\n  - request: `BatchRunLifecycleRequest`\n  - response: `BatchRunLifecycleResponse`\n\nAdd schemas:\n\n- `BatchRunLifecycleRequest`\n  - required `run_ids`\n  - `run_ids`: array of strings, `minItems: 1`, `maxItems: 250`, `uniqueItems: true`\n- `BatchRunLifecycleResponse`\n  - required `results`, `summary`\n  - `results`: array of `BatchRunLifecycleResult`, ordered exactly like the request `run_ids`\n  - `summary`: `BatchRunLifecycleSummary`\n- `BatchRunLifecycleResult`\n  - required `run_id`, `ok`, `outcome`\n  - `run_id`: string\n  - `ok`: boolean\n  - `outcome`: enum covering `archived`, `already_archived`, `unarchived`, `not_archived`, `not_found`, `conflict`, `error`\n  - optional `run`: `Run`, present for successful items when a decorated summary can be loaded\n  - optional `error`: `ErrorResponseEntry`, present for failed items\n- `BatchRunLifecycleSummary`\n  - required `requested`, `succeeded`, `failed`\n  - all integer counts\n\n## Implementation Units\n\n- [ ] **Unit 1: OpenAPI batch lifecycle contract**\n\n**Goal:** Add the public API contract and generated clients for batch archive/unarchive.\n\n**Requirements:** R1, R3\n\n**Dependencies:** None\n\n**Files:**\n- Modify: `docs/public/api-reference/fabro-api.yaml`\n- Generated by build/codegen: `lib/crates/fabro-api/src/generated.rs`\n- Generated by codegen: `lib/packages/fabro-api-client/src/api/runs-api.ts`\n- Generated by codegen: `lib/packages/fabro-api-client/src/models/*`\n\n**Approach:**\n- Add the two collection action paths and the four batch lifecycle schemas described in the API Contract section.\n- Keep response status simple: `200` for a valid processed batch; `400`, `401`, and `500` for request-level failures.\n- Run Rust generation through `cargo build -p fabro-api`.\n- Run TypeScript generation through `cd lib/packages/fabro-api-client && bun run generate`.\n\n**Patterns to follow:**\n- Existing single-run archive/unarchive path docs in the same OpenAPI file.\n- Existing generated client workflow described in `AGENTS.md`.\n\n**Test scenarios:**\n- Happy path: generated Rust and TypeScript clients expose `batchArchiveRuns` and `batchUnarchiveRuns`.\n- Contract: request schema enforces `run_ids` as the only required input.\n- Contract: result entries can represent both a successful decorated `Run` and a failed `ErrorResponseEntry`.\n\n**Verification:**\n- API generation completes without hand-edited generated files.\n\n- [ ] **Unit 2: Server batch lifecycle handlers**\n\n**Goal:** Implement the two new endpoints in the server using existing archive/unarchive operations.\n\n**Requirements:** R1, R2, R3\n\n**Dependencies:** Unit 1\n\n**Files:**\n- Modify: `lib/crates/fabro-server/src/server/handler/lifecycle.rs`\n- Test: `lib/crates/fabro-server/src/server/tests.rs`\n\n**Approach:**\n- Register `POST /runs/archive` and `POST /runs/unarchive` in the lifecycle route set.\n- Use `RequiredUser` for both handlers and convert the user into `Principal::User` for per-run operation calls.\n- Add a small shared batch helper that accepts the parsed request, the action, and the actor, then returns `BatchRunLifecycleResponse`.\n- Before processing any item, validate the entire request for empty list, over-limit list, duplicate IDs, and invalid IDs. Return a normal `400` API error if validation fails.\n- For each valid ID, call `operations::archive` or `operations::unarchive`; map success outcomes to item-level success results and map `RunNotFound`/`Precondition` to item-level `not_found`/`conflict` failures.\n- For successful items, load and decorate the current run summary the same way single-run lifecycle responses do. If summary loading fails after the operation succeeds, record that item as `error` rather than hiding the failure.\n\n**Patterns to follow:**\n- `run_archive_action` for operation mapping and existing error semantics.\n- `run_response` / `state.decorate_run_summary` for response shape.\n- Existing server tests around `archive_and_unarchive_updates_listing_visibility`.\n\n**Test scenarios:**\n- Happy path: two terminal runs archived in one request return two successful result entries, summary `requested=2/succeeded=2/failed=0`, and both runs are hidden from default `GET /api/v1/runs`.\n- Happy path: two archived runs unarchived in one request return successful entries and both runs reappear in default listing.\n- Idempotency: archiving an already archived run returns `ok=true` with `already_archived`; unarchiving a terminal non-archived run returns `ok=true` with `not_archived`.\n- Mixed result: a batch containing one terminal run, one running run, and one missing run returns ordered results with one success, one `conflict`, and one `not_found`; the terminal run is still archived.\n- Error path: empty `run_ids`, duplicate IDs, invalid IDs, and more than 250 IDs return request-level `400` and mutate no runs.\n- Auth path: unauthenticated requests are rejected; run-scoped worker authentication is not accepted for batch endpoints.\n\n**Verification:**\n- Existing single-run archive/unarchive tests pass unchanged.\n- New endpoint tests prove both API contract and run-list visibility effects.\n\n- [ ] **Unit 3: Frontend lifecycle helpers**\n\n**Goal:** Add typed web helpers for batch archive/unarchive.\n\n**Requirements:** R3, R4, R5\n\n**Dependencies:** Unit 1\n\n**Files:**\n- Modify: `apps/fabro-web/app/lib/run-actions.ts`\n- Test: `apps/fabro-web/app/lib/run-actions.test.ts`\n\n**Approach:**\n- Add `archiveRuns(runIds: string[])` and `unarchiveRuns(runIds: string[])` wrappers around the generated client methods.\n- Keep existing `archiveRun` and `unarchiveRun` helpers unchanged.\n- Preserve existing `LifecycleActionError` behavior for single-run actions. Batch helpers should return the generated batch response for valid mixed results and throw only for request-level API failures.\n\n**Patterns to follow:**\n- Existing lifecycle action helpers in `run-actions.ts`.\n- Axios adapter tests in `run-actions.test.ts`.\n\n**Test scenarios:**\n- Happy path: `archiveRuns([\"run-1\", \"run-2\"])` sends one generated-client request and returns parsed batch results.\n- Mixed result: helper resolves a response containing one success and one per-item failure without throwing.\n- Request error: helper throws parsed `ApiError`/lifecycle-style data when the server returns a request-level `400`.\n- Regression: existing `archiveRun`, `unarchiveRun`, `canArchive`, and `canUnarchive` tests continue to pass.\n\n**Verification:**\n- Web unit tests cover the new helper contract without changing single-run behavior.\n\n- [ ] **Unit 4: Web bulk-action integration**\n\n**Goal:** Replace multi-request UI orchestration with one batch request per bulk action.\n\n**Requirements:** R4, R5\n\n**Dependencies:** Units 1 and 3\n\n**Files:**\n- Modify: `apps/fabro-web/app/routes/runs.tsx`\n- Test: `apps/fabro-web/app/routes/runs.test.tsx`\n\n**Approach:**\n- Update `BulkActionToolbar` to call `archiveRuns` or `unarchiveRuns` once with eligible selected IDs.\n- Add a small pure batch-summary helper in `runs.tsx`, export it for route tests, and use it to compute toast messages from the batch response summary rather than `Promise.allSettled`.\n- Keep current eligibility filtering: archive only selected runs whose lifecycle status is archivable, unarchive only selected archived runs.\n- Clear selection only when all eligible items succeed, matching the current all-success behavior.\n- Call `mutateRunListCaches` once after the batch settles.\n- Update the kanban column archive-all action to call `archiveRuns` once with the column’s eligible IDs and reuse the same success/partial/failure toast behavior where practical.\n\n**Patterns to follow:**\n- Current `BulkActionToolbar` pending state, clear-selection behavior, and toast wording.\n- Current `ColumnActionsMenu` archive-all action and cache invalidation.\n\n**Test scenarios:**\n- Happy path: selecting multiple archived rows and clicking Unarchive calls the batch helper once and clears selection after all items succeed.\n- Happy path: selecting multiple terminal rows and clicking Archive calls the batch helper once and invalidates run-list caches once.\n- Mixed result: partial failure keeps selection and shows an error-tone partial-success toast with succeeded/failed counts.\n- Ineligible selection: selecting only non-archivable runs still shows the existing “No selected runs can be archived” style error without making an API request.\n- Board action: archive-all for a column calls the batch helper once with all eligible IDs.\n\n**Verification:**\n- UI behavior remains equivalent from the user’s perspective, but network behavior becomes one request per bulk action.\n\n## System-Wide Impact\n\n- **Auth:** Batch endpoints are user-only. This intentionally avoids giving a worker token with one run scope the ability to mutate arbitrary run IDs from a request body.\n- **Events:** No new event names or payloads. Each successful item appends the existing per-run archive/unarchive event.\n- **Caching:** Frontend run-list caches are still invalidated after lifecycle changes. The batch path should reduce invalidation churn from once per selected run to once per user action.\n- **Generated clients:** Both Rust and TypeScript generated clients change because OpenAPI is the source of truth.\n- **Compatibility:** Single-run endpoints and existing generated methods remain available and unchanged.\n\n## Risks & Mitigations\n\n| Risk | Mitigation |\n|------|------------|\n| Route ambiguity with `/runs/{id}` paths | Use static collection action paths and add server tests that call the exact batch routes. |\n| Partial mutation surprises | Use explicit fail-soft result entries and summarize succeeded/failed counts. |\n| Worker token privilege expansion | Require `RequiredUser` for batch endpoints. |\n| Duplicate IDs producing confusing results | Reject duplicates at request validation before any mutation. |\n| UI toast regressions | Cover all-success, all-failure, partial-failure, and ineligible-selection behavior in frontend tests. |\n\n## Documentation / Operational Notes\n\n- The OpenAPI descriptions should explicitly state that batch actions are fail-soft and not transactional.\n- No migration, feature flag, or rollout sequencing is required.\n- No new public docs are required unless API reference publishing is part of the release process.\n\n## Sources & References\n\n- OpenAPI source: `docs/public/api-reference/fabro-api.yaml`\n- Server lifecycle handlers: `lib/crates/fabro-server/src/server/handler/lifecycle.rs`\n- Workflow archive operations: `lib/crates/fabro-workflow/src/operations/archive.rs`\n- Web lifecycle helpers: `apps/fabro-web/app/lib/run-actions.ts`\n- Web runs route: `apps/fabro-web/app/routes/runs.tsx`\n- Testing guidance: `docs/internal/testing-strategy.md`\n- Error handling guidance: `docs/internal/error-handling-strategy.md`\n- Event guidance: `docs/internal/events-strategy.md`\n",
+          "internal.node_visit_count": 1,
+          "failure_class": "",
+          "failure_signature": "",
+          "outcome": "succeeded",
+          "thread.toolchain.current_node": "preflight_compile",
+          "internal.run_id": "01KSBT48J14ZMK9HQN48SVMG3T",
+          "command.output": "blob://sha256/12ae32cb1ec02d01eda3581b127c1fee3b0dc53572ed6baf239721a03d82e126",
+          "current_node": "preflight_compile",
+          "internal.retry_count.start": 0
+        },
+        "node_outcomes": {
+          "start": {
+            "status": "succeeded",
+            "usage": null
+          },
+          "preflight_compile": {
+            "status": "succeeded",
+            "context_updates": {
+              "command.output": "blob://sha256/12ae32cb1ec02d01eda3581b127c1fee3b0dc53572ed6baf239721a03d82e126"
+            },
+            "notes": "Script completed: cargo check -q --workspace 2>&1",
+            "usage": null
+          },
+          "toolchain": {
+            "status": "succeeded",
+            "context_updates": {
+              "command.output": "blob://sha256/fc14b2ba2d770e5cd3169df7a29525c962adfc4cfa3097b9098c63ebd61a748c"
+            },
+            "notes": "Script completed: command -v cargo >/dev/null || { curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y && sudo ln -sf $HOME/.cargo/bin/* /usr/local/bin/; }; cargo --version 2>&1",
+            "usage": null
+          }
+        },
+        "next_node_id": "preflight_lint",
+        "git_commit_sha": "862be7863e3d019f39adf194c162558a4b4388a0",
+        "node_visits": {
+          "start": 1,
+          "toolchain": 1,
+          "preflight_compile": 1
+        }
+      },
+      "diff": {
+        "summary": {
+          "files_changed": 0,
+          "additions": 0,
+          "deletions": 0
+        }
+      }
+    },
+    {
+      "seq": 0,
+      "checkpoint": {
+        "timestamp": "2026-05-24T01:47:11.102805Z",
+        "current_node": "preflight_lint",
+        "completed_nodes": [
+          "start",
+          "toolchain",
+          "preflight_compile",
+          "preflight_lint"
+        ],
+        "node_retries": {},
+        "context_values": {
+          "internal.retry_count.preflight_compile": 0,
+          "thread.preflight_compile.current_node": "preflight_lint",
           "failure_class": "",
           "graph.model_stylesheet": "\n            * { model: claude-opus-4-7; }\n        ",
           "failure_signature": "",
           "thread.start.current_node": "toolchain",
           "command.output": "blob://sha256/12ae32cb1ec02d01eda3581b127c1fee3b0dc53572ed6baf239721a03d82e126",
+          "internal.retry_count.preflight_lint": 0,
           "internal.work_dir": "/home/daytona/workspace/fabro",
           "outcome": "succeeded",
           "graph.goal": "---\ntitle: feat: Batch run archive actions\ntype: feat\nstatus: active\ndate: 2026-05-24\n---\n\n# feat: Batch Run Archive Actions\n\n## Overview\n\nAdd API support for archiving and unarchiving multiple runs in one request, then update the web list and board multi-run actions to use the new batch endpoints. The existing single-run archive and unarchive endpoints remain unchanged for run-scoped callers and direct lifecycle actions.\n\n## Problem Frame\n\nThe web UI currently performs multi-run archive/unarchive actions by issuing one lifecycle request per selected run. That works, but it puts batch orchestration in the browser, repeats request overhead, and leaves API/CLI/MCP consumers without a first-class batch contract. A bounded fail-soft batch endpoint gives the server ownership of the multi-run operation while preserving the independent event stream semantics of each run.\n\n## Requirements Trace\n\n- R1. Provide public API endpoints that archive and unarchive many runs in one request.\n- R2. Preserve existing single-run archive/unarchive behavior, including eligibility, idempotency, and emitted events.\n- R3. Return per-run results so mixed-success batches can be reported without rolling back successful items.\n- R4. Update web bulk actions to make one request per batch action instead of one request per run.\n- R5. Keep cache invalidation and toast behavior equivalent to the current UI.\n\n## Scope Boundaries\n\n- Do not make batch archive/unarchive transactional; each run remains an independent event stream.\n- Do not add new workflow event variants; successful batch items emit the same run archive/unarchive events as single-run actions.\n- Do not change the existing `POST /api/v1/runs/{id}/archive` or `POST /api/v1/runs/{id}/unarchive` contracts.\n- Do not add CLI commands in this change; this plan is limited to HTTP API and web UI usage.\n\n## Context & Research\n\n### Relevant Code and Patterns\n\n- OpenAPI is the source of truth for HTTP contracts in `docs/public/api-reference/fabro-api.yaml`.\n- Server lifecycle routes live in `lib/crates/fabro-server/src/server/handler/lifecycle.rs`; single-run archive/unarchive already funnel through `operations::archive` and `operations::unarchive`.\n- Batch routes that are not tied to one path run ID should use `RequiredUser`, not `RequireRunScopedOrRunTools`, because a run-scoped worker token cannot safely authorize mutation of arbitrary run IDs from a request body.\n- Web lifecycle helpers live in `apps/fabro-web/app/lib/run-actions.ts`; list and board multi-run archive behavior lives in `apps/fabro-web/app/routes/runs.tsx`.\n- Run-list cache invalidation already uses `mutateRunListCaches` in `apps/fabro-web/app/lib/board-cache.ts`.\n\n### Strategy Docs\n\n- `docs/internal/testing-strategy.md`: server tests should assert public HTTP contracts and prefer structured assertions.\n- `docs/internal/error-handling-strategy.md`: preserve structured errors internally and return curated API messages at HTTP boundaries.\n- `docs/internal/events-strategy.md`: no new events are needed because existing per-run lifecycle events already represent the durable state transition.\n\n## Key Technical Decisions\n\n- Add collection action endpoints `POST /api/v1/runs/archive` and `POST /api/v1/runs/unarchive`. These avoid changing single-run URLs and keep generated client methods clear (`batchArchiveRuns`, `batchUnarchiveRuns`).\n- Use fail-soft HTTP `200` responses for valid batch requests, even when individual items fail. Per-item failures carry structured result entries; request-level validation failures still return normal `400` errors.\n- Validate `run_ids` at the request boundary: non-empty, maximum 250 IDs, no duplicates, and every value parseable as a `RunId`. Invalid request bodies must not mutate any runs.\n- Process eligible IDs sequentially in server code. The batch is bounded, lifecycle operations append events, and sequential processing avoids adding lock-order or concurrency behavior that the feature does not need.\n- Treat idempotent single-run outcomes as successful batch outcomes: already archived counts as success for archive; terminal not-archived counts as success for unarchive.\n\n## API Contract\n\nAdd these OpenAPI operations:\n\n- `POST /api/v1/runs/archive`\n  - operationId: `batchArchiveRuns`\n  - request: `BatchRunLifecycleRequest`\n  - response: `BatchRunLifecycleResponse`\n- `POST /api/v1/runs/unarchive`\n  - operationId: `batchUnarchiveRuns`\n  - request: `BatchRunLifecycleRequest`\n  - response: `BatchRunLifecycleResponse`\n\nAdd schemas:\n\n- `BatchRunLifecycleRequest`\n  - required `run_ids`\n  - `run_ids`: array of strings, `minItems: 1`, `maxItems: 250`, `uniqueItems: true`\n- `BatchRunLifecycleResponse`\n  - required `results`, `summary`\n  - `results`: array of `BatchRunLifecycleResult`, ordered exactly like the request `run_ids`\n  - `summary`: `BatchRunLifecycleSummary`\n- `BatchRunLifecycleResult`\n  - required `run_id`, `ok`, `outcome`\n  - `run_id`: string\n  - `ok`: boolean\n  - `outcome`: enum covering `archived`, `already_archived`, `unarchived`, `not_archived`, `not_found`, `conflict`, `error`\n  - optional `run`: `Run`, present for successful items when a decorated summary can be loaded\n  - optional `error`: `ErrorResponseEntry`, present for failed items\n- `BatchRunLifecycleSummary`\n  - required `requested`, `succeeded`, `failed`\n  - all integer counts\n\n## Implementation Units\n\n- [ ] **Unit 1: OpenAPI batch lifecycle contract**\n\n**Goal:** Add the public API contract and generated clients for batch archive/unarchive.\n\n**Requirements:** R1, R3\n\n**Dependencies:** None\n\n**Files:**\n- Modify: `docs/public/api-reference/fabro-api.yaml`\n- Generated by build/codegen: `lib/crates/fabro-api/src/generated.rs`\n- Generated by codegen: `lib/packages/fabro-api-client/src/api/runs-api.ts`\n- Generated by codegen: `lib/packages/fabro-api-client/src/models/*`\n\n**Approach:**\n- Add the two collection action paths and the four batch lifecycle schemas described in the API Contract section.\n- Keep response status simple: `200` for a valid processed batch; `400`, `401`, and `500` for request-level failures.\n- Run Rust generation through `cargo build -p fabro-api`.\n- Run TypeScript generation through `cd lib/packages/fabro-api-client && bun run generate`.\n\n**Patterns to follow:**\n- Existing single-run archive/unarchive path docs in the same OpenAPI file.\n- Existing generated client workflow described in `AGENTS.md`.\n\n**Test scenarios:**\n- Happy path: generated Rust and TypeScript clients expose `batchArchiveRuns` and `batchUnarchiveRuns`.\n- Contract: request schema enforces `run_ids` as the only required input.\n- Contract: result entries can represent both a successful decorated `Run` and a failed `ErrorResponseEntry`.\n\n**Verification:**\n- API generation completes without hand-edited generated files.\n\n- [ ] **Unit 2: Server batch lifecycle handlers**\n\n**Goal:** Implement the two new endpoints in the server using existing archive/unarchive operations.\n\n**Requirements:** R1, R2, R3\n\n**Dependencies:** Unit 1\n\n**Files:**\n- Modify: `lib/crates/fabro-server/src/server/handler/lifecycle.rs`\n- Test: `lib/crates/fabro-server/src/server/tests.rs`\n\n**Approach:**\n- Register `POST /runs/archive` and `POST /runs/unarchive` in the lifecycle route set.\n- Use `RequiredUser` for both handlers and convert the user into `Principal::User` for per-run operation calls.\n- Add a small shared batch helper that accepts the parsed request, the action, and the actor, then returns `BatchRunLifecycleResponse`.\n- Before processing any item, validate the entire request for empty list, over-limit list, duplicate IDs, and invalid IDs. Return a normal `400` API error if validation fails.\n- For each valid ID, call `operations::archive` or `operations::unarchive`; map success outcomes to item-level success results and map `RunNotFound`/`Precondition` to item-level `not_found`/`conflict` failures.\n- For successful items, load and decorate the current run summary the same way single-run lifecycle responses do. If summary loading fails after the operation succeeds, record that item as `error` rather than hiding the failure.\n\n**Patterns to follow:**\n- `run_archive_action` for operation mapping and existing error semantics.\n- `run_response` / `state.decorate_run_summary` for response shape.\n- Existing server tests around `archive_and_unarchive_updates_listing_visibility`.\n\n**Test scenarios:**\n- Happy path: two terminal runs archived in one request return two successful result entries, summary `requested=2/succeeded=2/failed=0`, and both runs are hidden from default `GET /api/v1/runs`.\n- Happy path: two archived runs unarchived in one request return successful entries and both runs reappear in default listing.\n- Idempotency: archiving an already archived run returns `ok=true` with `already_archived`; unarchiving a terminal non-archived run returns `ok=true` with `not_archived`.\n- Mixed result: a batch containing one terminal run, one running run, and one missing run returns ordered results with one success, one `conflict`, and one `not_found`; the terminal run is still archived.\n- Error path: empty `run_ids`, duplicate IDs, invalid IDs, and more than 250 IDs return request-level `400` and mutate no runs.\n- Auth path: unauthenticated requests are rejected; run-scoped worker authentication is not accepted for batch endpoints.\n\n**Verification:**\n- Existing single-run archive/unarchive tests pass unchanged.\n- New endpoint tests prove both API contract and run-list visibility effects.\n\n- [ ] **Unit 3: Frontend lifecycle helpers**\n\n**Goal:** Add typed web helpers for batch archive/unarchive.\n\n**Requirements:** R3, R4, R5\n\n**Dependencies:** Unit 1\n\n**Files:**\n- Modify: `apps/fabro-web/app/lib/run-actions.ts`\n- Test: `apps/fabro-web/app/lib/run-actions.test.ts`\n\n**Approach:**\n- Add `archiveRuns(runIds: string[])` and `unarchiveRuns(runIds: string[])` wrappers around the generated client methods.\n- Keep existing `archiveRun` and `unarchiveRun` helpers unchanged.\n- Preserve existing `LifecycleActionError` behavior for single-run actions. Batch helpers should return the generated batch response for valid mixed results and throw only for request-level API failures.\n\n**Patterns to follow:**\n- Existing lifecycle action helpers in `run-actions.ts`.\n- Axios adapter tests in `run-actions.test.ts`.\n\n**Test scenarios:**\n- Happy path: `archiveRuns([\"run-1\", \"run-2\"])` sends one generated-client request and returns parsed batch results.\n- Mixed result: helper resolves a response containing one success and one per-item failure without throwing.\n- Request error: helper throws parsed `ApiError`/lifecycle-style data when the server returns a request-level `400`.\n- Regression: existing `archiveRun`, `unarchiveRun`, `canArchive`, and `canUnarchive` tests continue to pass.\n\n**Verification:**\n- Web unit tests cover the new helper contract without changing single-run behavior.\n\n- [ ] **Unit 4: Web bulk-action integration**\n\n**Goal:** Replace multi-request UI orchestration with one batch request per bulk action.\n\n**Requirements:** R4, R5\n\n**Dependencies:** Units 1 and 3\n\n**Files:**\n- Modify: `apps/fabro-web/app/routes/runs.tsx`\n- Test: `apps/fabro-web/app/routes/runs.test.tsx`\n\n**Approach:**\n- Update `BulkActionToolbar` to call `archiveRuns` or `unarchiveRuns` once with eligible selected IDs.\n- Add a small pure batch-summary helper in `runs.tsx`, export it for route tests, and use it to compute toast messages from the batch response summary rather than `Promise.allSettled`.\n- Keep current eligibility filtering: archive only selected runs whose lifecycle status is archivable, unarchive only selected archived runs.\n- Clear selection only when all eligible items succeed, matching the current all-success behavior.\n- Call `mutateRunListCaches` once after the batch settles.\n- Update the kanban column archive-all action to call `archiveRuns` once with the column’s eligible IDs and reuse the same success/partial/failure toast behavior where practical.\n\n**Patterns to follow:**\n- Current `BulkActionToolbar` pending state, clear-selection behavior, and toast wording.\n- Current `ColumnActionsMenu` archive-all action and cache invalidation.\n\n**Test scenarios:**\n- Happy path: selecting multiple archived rows and clicking Unarchive calls the batch helper once and clears selection after all items succeed.\n- Happy path: selecting multiple terminal rows and clicking Archive calls the batch helper once and invalidates run-list caches once.\n- Mixed result: partial failure keeps selection and shows an error-tone partial-success toast with succeeded/failed counts.\n- Ineligible selection: selecting only non-archivable runs still shows the existing “No selected runs can be archived” style error without making an API request.\n- Board action: archive-all for a column calls the batch helper once with all eligible IDs.\n\n**Verification:**\n- UI behavior remains equivalent from the user’s perspective, but network behavior becomes one request per bulk action.\n\n## System-Wide Impact\n\n- **Auth:** Batch endpoints are user-only. This intentionally avoids giving a worker token with one run scope the ability to mutate arbitrary run IDs from a request body.\n- **Events:** No new event names or payloads. Each successful item appends the existing per-run archive/unarchive event.\n- **Caching:** Frontend run-list caches are still invalidated after lifecycle changes. The batch path should reduce invalidation churn from once per selected run to once per user action.\n- **Generated clients:** Both Rust and TypeScript generated clients change because OpenAPI is the source of truth.\n- **Compatibility:** Single-run endpoints and existing generated methods remain available and unchanged.\n\n## Risks & Mitigations\n\n| Risk | Mitigation |\n|------|------------|\n| Route ambiguity with `/runs/{id}` paths | Use static collection action paths and add server tests that call the exact batch routes. |\n| Partial mutation surprises | Use explicit fail-soft result entries and summarize succeeded/failed counts. |\n| Worker token privilege expansion | Require `RequiredUser` for batch endpoints. |\n| Duplicate IDs producing confusing results | Reject duplicates at request validation before any mutation. |\n| UI toast regressions | Cover all-success, all-failure, partial-failure, and ineligible-selection behavior in frontend tests. |\n\n## Documentation / Operational Notes\n\n- The OpenAPI descriptions should explicitly state that batch actions are fail-soft and not transactional.\n- No migration, feature flag, or rollout sequencing is required.\n- No new public docs are required unless API reference publishing is part of the release process.\n\n## Sources & References\n\n- OpenAPI source: `docs/public/api-reference/fabro-api.yaml`\n- Server lifecycle handlers: `lib/crates/fabro-server/src/server/handler/lifecycle.rs`\n- Workflow archive operations: `lib/crates/fabro-workflow/src/operations/archive.rs`\n- Web lifecycle helpers: `apps/fabro-web/app/lib/run-actions.ts`\n- Web runs route: `apps/fabro-web/app/routes/runs.tsx`\n- Testing guidance: `docs/internal/testing-strategy.md`\n- Error handling guidance: `docs/internal/error-handling-strategy.md`\n- Event guidance: `docs/internal/events-strategy.md`\n",
           "thread.toolchain.current_node": "preflight_compile",
           "internal.retry_count.start": 0,
-          "current_node": "preflight_compile",
+          "current_node": "preflight_lint",
           "internal.run_id": "01KSBT48J14ZMK9HQN48SVMG3T",
-          "internal.thread_id": "toolchain",
+          "internal.thread_id": "preflight_compile",
           "internal.node_visit_count": 1,
           "graph.rankdir": "LR",
           "internal.fidelity": "compact",
@@ -633,6 +705,14 @@
             "notes": "Script completed: command -v cargo >/dev/null || { curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y && sudo ln -sf $HOME/.cargo/bin/* /usr/local/bin/; }; cargo --version 2>&1",
             "usage": null
           },
+          "preflight_lint": {
+            "status": "succeeded",
+            "context_updates": {
+              "command.output": "blob://sha256/12ae32cb1ec02d01eda3581b127c1fee3b0dc53572ed6baf239721a03d82e126"
+            },
+            "notes": "Script completed: cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1",
+            "usage": null
+          },
           "preflight_compile": {
             "status": "succeeded",
             "context_updates": {
@@ -642,10 +722,11 @@
             "usage": null
           }
         },
-        "next_node_id": "preflight_lint",
+        "next_node_id": "implement",
         "node_visits": {
-          "start": 1,
           "toolchain": 1,
+          "preflight_lint": 1,
+          "start": 1,
           "preflight_compile": 1
         }
       },
@@ -724,7 +805,12 @@
       "first_event_seq": 33,
       "prompt": null,
       "response": null,
-      "completion": null,
+      "completion": {
+        "outcome": "succeeded",
+        "notes": "Script completed: cargo check -q --workspace 2>&1",
+        "failure_reason": null,
+        "timestamp": "2026-05-24T01:44:51.331786Z"
+      },
       "provider_used": null,
       "diff": null,
       "script_invocation": {
@@ -732,10 +818,53 @@
         "command": "exec 2>&1\ncargo check -q --workspace 2>&1",
         "language": "shell"
       },
+      "script_timing": {
+        "output": "blob://sha256/12ae32cb1ec02d01eda3581b127c1fee3b0dc53572ed6baf239721a03d82e126",
+        "exit_code": 0,
+        "duration_ms": 124084,
+        "termination": "exited",
+        "output_bytes": 0,
+        "live_streaming": false
+      },
+      "parallel_results": null,
+      "output": null,
+      "output_bytes": 0,
+      "live_streaming": false,
+      "termination": "exited",
+      "started_at": "2026-05-24T01:42:47.237349Z",
+      "handler": "command",
+      "timing": {
+        "wall_time_ms": 124094,
+        "inference_time_ms": 0,
+        "tool_time_ms": 0,
+        "active_time_ms": 0
+      },
+      "usage": {
+        "input_tokens": 0,
+        "output_tokens": 0,
+        "total_tokens": 0,
+        "reasoning_tokens": 0,
+        "cache_read_tokens": 0,
+        "cache_write_tokens": 0
+      },
+      "state": "succeeded"
+    },
+    "preflight_lint@1": {
+      "first_event_seq": 43,
+      "prompt": null,
+      "response": null,
+      "completion": null,
+      "provider_used": null,
+      "diff": null,
+      "script_invocation": {
+        "script": "cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1",
+        "command": "exec 2>&1\ncargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1",
+        "language": "shell"
+      },
       "script_timing": null,
       "parallel_results": null,
       "output": null,
-      "started_at": "2026-05-24T01:42:47.237349Z",
+      "started_at": "2026-05-24T01:44:55.050123Z",
       "handler": "command",
       "usage": {
         "input_tokens": 0,
diff --git a/stages/003-preflight_compile@1/output.log b/stages/003-preflight_compile@1/output.log
new file mode 100644
index 000000000..d87ba9545
--- /dev/null
+++ b/stages/003-preflight_compile@1/output.log
@@ -0,0 +1 @@
+blob://sha256/12ae32cb1ec02d01eda3581b127c1fee3b0dc53572ed6baf239721a03d82e126
\ No newline at end of file
diff --git a/stages/003-preflight_compile@1/script_timing.json b/stages/003-preflight_compile@1/script_timing.json
new file mode 100644
index 000000000..b8e85f266
--- /dev/null
+++ b/stages/003-preflight_compile@1/script_timing.json
@@ -0,0 +1,8 @@
+{
+  "output": "blob://sha256/12ae32cb1ec02d01eda3581b127c1fee3b0dc53572ed6baf239721a03d82e126",
+  "exit_code": 0,
+  "duration_ms": 124084,
+  "termination": "exited",
+  "output_bytes": 0,
+  "live_streaming": false
+}
\ No newline at end of file
diff --git a/stages/003-preflight_compile@1/status.json b/stages/003-preflight_compile@1/status.json
new file mode 100644
index 000000000..295f8b80d
--- /dev/null
+++ b/stages/003-preflight_compile@1/status.json
@@ -0,0 +1,6 @@
+{
+  "outcome": "succeeded",
+  "notes": "Script completed: cargo check -q --workspace 2>&1",
+  "failure_reason": null,
+  "timestamp": "2026-05-24T01:44:51.331786Z"
+}
\ No newline at end of file
diff --git a/stages/004-preflight_lint@1/script_invocation.json b/stages/004-preflight_lint@1/script_invocation.json
new file mode 100644
index 000000000..0cb6a9faa
--- /dev/null
+++ b/stages/004-preflight_lint@1/script_invocation.json
@@ -0,0 +1,5 @@
+{
+  "script": "cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1",
+  "command": "exec 2>&1\ncargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1",
+  "language": "shell"
+}
\ No newline at end of file