boxdown 1.0.0 → 1.2.1

package/docs/features/ssh-config-and-proxy.md

@@ -3,12 +3,20 @@
 ## Commands
 
 ```sh
-boxdown ssh-config install
+boxdown setup --target codex
+boxdown setup --target claude
+boxdown ssh install
+boxdown ssh install --target codex
+boxdown ssh install --target claude
+boxdown ssh uninstall
 boxdown ssh-proxy
+boxdown tunnel --port 3030
 ```
 
-`boxdown ssh-config` is accepted as a convenience shortcut for
-`boxdown ssh-config install`, but docs use the explicit install form.
+`boxdown ssh` is accepted as a convenience shortcut for
+`boxdown ssh install`, but docs use the explicit install form.
+`boxdown setup` is the higher-level workflow when you also want to start or
+recreate the devcontainer before installing the SSH alias.
 
 `ssh-proxy` is primarily an internal command launched by OpenSSH as a
 `ProxyCommand`.
@@ -31,11 +39,103 @@ The generated SSH config block includes:
 The block is wrapped in Boxdown markers so repeated installs replace the managed
 block instead of duplicating it.
 
+When `boxdown ssh install` runs without `--target` in an interactive terminal,
+Boxdown asks which optional install targets to update in addition to the SSH
+alias. The menu supports selecting multiple targets or skipping all optional
+targets. In non-interactive contexts, Boxdown skips optional targets instead of
+blocking and prints the explicit `--target` form for scripts.
+
+`boxdown ssh uninstall` removes the Boxdown-managed marker block for the
+selected alias, the matching Codex app remote project entry, and the matching
+Codex persisted sidebar state for the workspace. It leaves unrelated OpenSSH
+config entries, unrelated Codex remote projects, generated state, and SSH key
+files in place.
+
 `boxdown status` reports whether that Boxdown-managed block is `installed`,
 `missing`, or `outdated`. It only recognizes blocks wrapped in Boxdown's marker
 comments; an unrelated OpenSSH `Host` entry with the same alias is not treated
 as an installed Boxdown alias.
 
+## Codex App Target
+
+Selecting Codex from the interactive prompt or running
+`boxdown ssh install --target codex` keeps the normal SSH install flow and also
+writes a Codex app remote project entry for the same alias. `--target` is
+repeatable so future optional SSH install targets can be combined in one
+install command.
+
+The Codex app config is written to:
+
+```text
+~/.codex/codex-app/config.json
+```
+
+`BOXDOWN_CODEX_APP_CONFIG` overrides this path for tests and local development.
+
+The generated Codex entry points at the canonical container workspace path:
+
+```json
+{
+  "sshAlias": "<repo-name>-devcontainer",
+  "projects": [
+    {
+      "remotePath": "/workspaces/<repo-name>",
+      "label": "<repo-name>"
+    }
+  ]
+}
+```
+
+Boxdown merges by SSH alias and normalized remote path, so repeated installs
+update the existing Codex project instead of duplicating it. If an older
+Boxdown install registered `/home/node/<repo-name>`, the next Codex target
+install migrates that entry to `/workspaces/<repo-name>`. Existing known Codex
+config keys are preserved, but unknown keys are not written back because
+Codex's app config parser is strict.
+
+Boxdown normalizes matching Codex sidebar state for the same SSH alias when it
+installs the Codex target. Restart Codex after installing the target so Codex
+applies the app config, discovers the SSH alias from normal OpenSSH config, and
+creates or updates its sidebar project entry.
+
+## Claude App Target
+
+Selecting Claude from the interactive prompt or running
+`boxdown ssh install --target claude` keeps the normal SSH install flow and also
+writes a Claude app SSH remote entry for the same alias. `--target` is
+repeatable, so `codex` and `claude` can be installed in one command.
+
+The Claude SSH config is written to:
+
+```text
+~/Library/Application Support/Claude/ssh_configs.json
+```
+
+`BOXDOWN_CLAUDE_SSH_CONFIGS` overrides this path for tests and local
+development.
+
+The generated Claude entry mirrors the desktop app's SSH remote shape:
+
+```json
+{
+  "configs": [
+    {
+      "name": "<repo-name>",
+      "sshHost": "<repo-name>-devcontainer",
+      "id": "<uuid>",
+      "source": "desktop"
+    }
+  ],
+  "trustedHosts": [
+    "<repo-name>-devcontainer"
+  ]
+}
+```
+
+Boxdown merges by `sshHost`, preserves an existing Claude remote ID, and adds
+the alias to `trustedHosts`. Restart Claude after installing the target so the
+app applies the SSH remote entry.
+
 ## Proxy Flow
 
 When OpenSSH launches `boxdown ssh-proxy`, Boxdown:
@@ -44,15 +144,136 @@ When OpenSSH launches `boxdown ssh-proxy`, Boxdown:
 2. Ensures the per-workspace host key exists.
 3. Reuses a running devcontainer when possible.
 4. Starts the devcontainer when needed.
-5. Runs a throttled coding-agent CLI update preflight inside the container.
+5. Runs a throttled default coding-agent CLI update preflight inside the
+   container.
 6. Runs the container SSH bootstrap runtime.
 7. Bridges OpenSSH to `/usr/sbin/sshd -i` through `docker exec -i`.
 
 This does not publish an SSH port. The SSH stream travels through Docker exec.
 
-The coding-agent CLI update preflight covers already-running containers, where
-`postStartCommand` does not necessarily run before a new SSH session. Its output
-is routed to stderr so stdout remains reserved for SSH traffic.
+Boxdown augments child-process `PATH` with common macOS GUI-missing tool
+locations, including `/usr/local/bin`, Homebrew paths, `~/.docker/bin`, and
+Docker Desktop's bundled CLI directory. This lets GUI apps such as Claude launch
+the SSH proxy through OpenSSH even when their launchd environment cannot
+resolve `docker` by default.
+
+The default coding-agent CLI update preflight covers Codex and Claude Code in
+already-running containers, where `postStartCommand` does not necessarily run
+before a new SSH session. OpenCode and Antigravity remain lazy installs through
+their direct `boxdown` commands. The preflight output is routed to stderr so
+stdout remains reserved for SSH traffic.
+
+SSH proxy startup uses the same concise progress protocol as `setup` and
+`start`, but routes progress and failure summaries to stderr because stdout is
+reserved for the SSH stream. Use `boxdown ssh-proxy --verbose` only for manual
+debugging.
+
+## Local Web Tunnels
+
+The SSH proxy supports TCP forwarding, so Boxdown can expose a web server that is
+listening only inside the devcontainer.
+
+From the target project directory:
+
+```sh
+boxdown tunnel --port 3030
+```
+
+When `--port` is omitted in an interactive terminal, Boxdown prompts for one or
+more port mappings. Pressing Enter accepts the generated devcontainer published
+port when Boxdown can read one from the config, currently `3000`. Non-TTY and
+CI runs keep requiring an explicit `--port`.
+
+From another directory:
+
+```sh
+boxdown tunnel --workspace /path/to/project --port 3030
+```
+
+This starts or reuses the devcontainer, ensures the SSH alias exists, and then
+keeps a foreground SSH tunnel open:
+
+```text
+127.0.0.1:3030 -> localhost:3030
+```
+
+While the tunnel is running, host browsers and the Codex in-app browser can open
+`http://localhost:3030/`.
+
+Tunnel setup also hides raw devcontainer startup logs by default; pass
+`--verbose` before the foreground tunnel opens when debugging startup.
+
+Repeat `--port` for multiple forwards. Use `<local:remote>` when the host port
+should differ from the container port:
+
+```sh
+boxdown tunnel --port 3030 --port 8080:3031
+```
+
+The tunnel targets remote `localhost` rather than `127.0.0.1` so servers that
+bind to the container's IPv6 loopback, such as some Slidev dev sessions, still
+work.
+
+Devcontainer `forwardPorts` is an editor hint, not a host listener in the Codex
+desktop app. Docker `runArgs` / `appPort` publishing can also expose services,
+but it requires the server to bind to an externally reachable container address
+such as `0.0.0.0` and may require recreating the container.
+
+Codex's own detected-port forwarding may create a random host URL such as
+`http://localhost:52548/`. That is expected, but the generated SSH forward may
+target remote `127.0.0.1:<port>`. If the dev server is only listening on remote
+IPv6 loopback (`[::1]:<port>`), the random forwarded URL can reset even though a
+listener exists. In that case, either use `boxdown tunnel --port <port>`, or
+start the dev server with a host flag such as `--host 0.0.0.0`.
+
+## IPv4 and IPv6 Loopback Options
+
+The Codex detected-port issue is not an `/etc/hosts` problem. `/etc/hosts` maps
+names such as `localhost` to addresses, but a generated SSH forward that targets
+remote `127.0.0.1:<port>` uses a numeric IP literal. No name lookup happens, so
+changing the container's `localhost` entry would not make `127.0.0.1` reach a
+server that is listening only on `[::1]`.
+
+Potential Boxdown-side approaches:
+
+1. Inject a Node.js IPv4 preference.
+
+   Boxdown could add this to the generated devcontainer environment:
+
+   ```sh
+   NODE_OPTIONS=--dns-result-order=ipv4first
+   ```
+
+   This would likely make Node-based dev servers such as Vite and Slidev resolve
+   `localhost` to `127.0.0.1` first, causing Codex's generated
+   `127.0.0.1:<port>` forward to work without app-specific flags.
+
+   This is the smallest built-in fix to evaluate, but it mainly helps Node.js
+   tools. It would not normalize loopback behavior for dev servers written in
+   other runtimes.
+
+2. Run a Boxdown-managed loopback bridge inside the container.
+
+   A background helper could detect a listener on `[::1]:<port>` where
+   `127.0.0.1:<port>` is not listening, then bind `127.0.0.1:<port>` and proxy
+   traffic to `[::1]:<port>`.
+
+   This would be runtime-agnostic and would let Codex's generated
+   `127.0.0.1:<port>` forwards work for more tools. The tradeoff is a more
+   complex container-side service: it would need port discovery, race handling,
+   conflict handling, lifecycle cleanup, and clear diagnostics.
+
+3. Keep `boxdown tunnel` as the explicit escape hatch.
+
+   The current `boxdown tunnel --port <port>` command creates Boxdown's own SSH
+   local forward and targets remote `localhost:<port>` rather than remote
+   `127.0.0.1:<port>`. That covers dev servers bound to IPv6 loopback,
+   IPv4 loopback, or all interfaces, as long as the remote `localhost` name
+   resolves to a reachable address for that server.
+
+   This is reliable and fully under Boxdown's control, but it requires an extra
+   foreground command. It is useful as a debugging and fallback path, not a
+   fully automatic browser-forwarding experience.
 
 ## Key Boundary
 

package/docs/features/start-and-shell.md

@@ -6,7 +6,6 @@
 boxdown start
 boxdown codex
 boxdown claude
-boxdown cc
 boxdown opencode
 boxdown antigravity
 ```
@@ -16,18 +15,30 @@ boxdown antigravity
 ```sh
 --workspace <path>
 --recreate
+--verbose
 ```
 
+Use `boxdown setup` when you want to prepare the devcontainer and SSH/app
+integration without opening an interactive shell.
+
 `boxdown shell` remains supported as an alias for `boxdown start`, but `start`
 is the canonical command used in help and documentation.
+`boxdown cc` remains supported as an alias for `boxdown claude`, but `claude`
+is the canonical command used in help and documentation.
 
 The coding-agent aliases start or reuse the same workspace devcontainer and
 launch the selected CLI directly:
 
 - `boxdown codex` launches `codex`.
-- `boxdown claude` and `boxdown cc` launch `claude`.
-- `boxdown opencode` launches `opencode`.
-- `boxdown antigravity` launches `agy`.
+- `boxdown claude` launches `claude`.
+- `boxdown opencode` installs/updates OpenCode when needed, then launches
+  `opencode`.
+- `boxdown antigravity` installs/updates Antigravity when needed, then launches
+  `agy`.
+
+Container bring-up eagerly installs only Codex and Claude Code. OpenCode and
+Antigravity are lazy installs so projects that do not use them avoid the extra
+disk usage.
 
 Pass agent-specific arguments after `--` so Boxdown options stay unambiguous:
 
@@ -42,7 +53,7 @@ boxdown claude -- --continue
 3. Generate a Boxdown-owned devcontainer config.
 4. Install or reuse the pinned Dev Containers CLI.
 5. Run `devcontainer up --workspace-folder <repo> --override-config <config>`.
-6. Run container lifecycle hooks, including a best-effort coding-agent CLI refresh.
+6. Run container lifecycle hooks, including a best-effort Codex/Claude CLI refresh.
 7. Print a dynamic port hint when the configured published port is mapped.
 8. Run `devcontainer exec ... bash` to open an interactive shell.
 
@@ -50,6 +61,11 @@ Coding-agent aliases use the same startup flow but skip the port hint, run a
 best-effort refresh for the selected agent, and exec the agent binary instead of
 opening `bash`.
 
+Startup progress is concise by default. Raw Docker, Dev Containers CLI,
+lifecycle hook, and coding-agent install/update logs are captured; on failure,
+Boxdown prints the failed step and a short output tail. Pass `--verbose` to
+stream the full startup output before the interactive shell or agent takes over.
+
 ## Terminal Width
 
 Some terminal UIs behave poorly when a host terminal reports an extremely wide
@@ -57,6 +73,12 @@ PTY, especially from embedded terminals. Before opening the shell, Boxdown
 clamps interactive terminal width to 120 columns when the reported width is
 larger.
 
+Before starting the interactive shell or a coding-agent command, Boxdown also
+checks whether the container recognizes the forwarded `TERM` value. If the
+container does not have terminfo for a host-specific terminal such as Ghostty,
+Boxdown falls back to `xterm-256color` while preserving truecolor support with
+`COLORTERM=truecolor`.
+
 Override the default width when you want a wider layout:
 
 ```sh
@@ -76,8 +98,26 @@ BOXDOWN_TTY_NORMALIZE=0 boxdown start
 Use it when changing create-time settings such as image, features, mounts, or
 Docker `runArgs`.
 
+Existing containers created before Boxdown adopted runtime-mounted secrets
+must be recreated once. After recreation, Boxdown-provided secrets remain
+ordinary Bash-session environment variables but are absent from Docker
+container configuration and `docker inspect`.
+
 ## Port Hint
 
 The v1 asset config publishes container port `3000` with a dynamic host port.
 After `up`, Boxdown asks Docker for the mapped host binding and prints the
 result as an HTTP URL when available.
+
+For dev servers that choose another port after the container is already running,
+use the SSH tunnel command instead. Interactive terminals can omit `--port` to
+be prompted for the mapping:
+
+```sh
+boxdown tunnel
+boxdown tunnel --port 3030
+boxdown tunnel --workspace /path/to/project --port 3030
+```
+
+This is the preferred path for host browsers and the Codex in-app browser when a
+server is listening on container-local `localhost`.

package/docs/superpowers/plans/2026-07-11-default-commit-signing.md

@@ -0,0 +1,110 @@
+# Default Commit Signing Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Make new Boxdown environments sign commits through the host SSH agent by default, while retaining an unsigned, warning-only fallback.
+
+**Architecture:** A host-side resolver selects one unambiguous public SSH key and snapshots only that key into workspace state. The generated devcontainer config mounts the host agent and the public-key snapshot. A container bootstrap validates a disposable SSH-signed commit and configures global Git for SSH signing or disables it without touching repository-local Git config.
+
+**Tech Stack:** Node.js 24, TypeScript, Bash, Git, OpenSSH, Docker/Dev Containers CLI, Node test runner.
+
+## Global Constraints
+
+- Never copy private signing-key material into Boxdown state or the container.
+- Multiple ambiguous agent identities disable signing and warn; never select one arbitrarily.
+- Signing diagnostics are `warn`, never a setup-preflight failure.
+- Never write `commit.gpgsign` in the repository-local `.git/config`.
+- Docker integration is optional and must not pull images or push commits.
+
+---
+
+### Task 1: Resolve and persist a signing plan
+
+**Files:**
+
+- Create: `src/git-signing.ts`
+- Modify: `src/constants.ts`, `src/paths.ts`, `src/config.ts`
+- Test: `__tests__/app.test.ts`
+
+**Interfaces:**
+
+```ts
+export type GitSigningReason = 'agent-unavailable' | 'no-identities' | 'ambiguous-identities' | 'configured-key-not-loaded' | 'agent-mount-unavailable'
+export interface GitSigningPlan { enabled: boolean, reason?: GitSigningReason, publicKey?: string, agentSocketSource?: string }
+export function parseSshPublicKey(value: string): string | undefined
+export function selectGitSigningKey(identities: string[], configuredKey?: string, githubKeys?: string[]): { key?: string, reason?: GitSigningReason }
+export function writeGitSigningPublicKey(context: WorkspaceContext, key: string): void
+```
+
+- [ ] Write focused failing tests for parsing keys without comments, configured-key selection, a unique GitHub-key match, single-key fallback, ambiguous fallback, and config mount generation.
+- [ ] Run `node --import tsx --test --test-name-pattern='git signing|devcontainer config generation' __tests__/app.test.ts` and confirm the new assertions fail because the module and mounts do not exist.
+- [ ] Add state paths and container constants, implement the pure resolver and public-key snapshot, and let `buildGeneratedDevcontainerConfig(context, signingPlan)` add read-only key-state and agent mounts only for enabled plans.
+- [ ] Rerun the focused tests and confirm they pass.
+
+### Task 2: Configure and validate container-side Git signing
+
+**Files:**
+
+- Create: `assets/devcontainer/utils/git-signing-bootstrap.sh`
+- Modify: `assets/devcontainer/utils/git-config-bootstrap.sh`, `assets/devcontainer/hooks/post-create.sh`, `assets/devcontainer/hooks/post-start.sh`
+- Test: `__tests__/app.test.ts`
+
+**Interfaces:**
+
+```bash
+bash /opt/boxdown/devcontainer/utils/git-signing-bootstrap.sh
+# Reads BOXDOWN_GIT_SIGNING_ENABLED and BOXDOWN_GIT_SIGNING_KEY_PATH.
+# Exits 0 in both signed and unsigned fallback modes.
+```
+
+- [ ] Write failing shell-hook tests for successful SSH configuration, absent-agent fallback, removal of incompatible `gpg.program`, and absence of repository-local `commit.gpgsign` writes.
+- [ ] Run the matching `devcontainer git config hooks` tests and confirm the new assertions fail.
+- [ ] Implement a temporary-repository signing probe using `ssh-add -L`, a temporary allowed-signers file, and `git commit --allow-empty`; set global SSH signing only after it succeeds, otherwise set global `commit.gpgsign=false` and print a warning.
+- [ ] Remove unconditional global signing disablement and all post-create local `commit.gpgsign` mutations; call the bootstrap after create and start.
+- [ ] Rerun the hook tests and confirm they pass.
+
+### Task 3: Use one signing-aware lifecycle for every command
+
+**Files:**
+
+- Modify: `src/devcontainer.ts`, `src/main.ts`
+- Test: `__tests__/app.test.ts`
+
+**Interfaces:**
+
+```ts
+export async function resolveGitSigningPlan(context: WorkspaceContext): Promise<GitSigningPlan>
+export async function ensureContainerGitSigning(context: WorkspaceContext, plan: GitSigningPlan, options?: ContainerCommandOptions): Promise<void>
+```
+
+- [ ] Write failing command-flow tests proving `startDevcontainer` writes a signing-aware config and invokes the non-fatal container signing refresh for fresh and reused containers.
+- [ ] Run the relevant `CLI execution` and `coding-agent command mapping` tests and confirm they fail on the missing signing lifecycle.
+- [ ] Resolve the plan before writing generated config, pass plan state to the lifecycle script, and call the refresh from shared startup so setup, shell, coding agents, SSH proxy, and tunnels all inherit it.
+- [ ] Ensure refresh failures only warn and do not change the command exit code.
+- [ ] Rerun focused lifecycle tests and confirm they pass.
+
+### Task 4: Add doctor/preflight warnings and user documentation
+
+**Files:**
+
+- Modify: `src/doctor.ts`, `src/main.ts`, `README.md`, `docs/features/setup.md`, `docs/architecture.md`, `docs/features/README.md`
+- Create: `docs/features/commit-signing.md`, `.changeset/<generated-name>.md`
+- Test: `__tests__/app.test.ts`
+
+- [ ] Write failing doctor tests for unavailable agent, ambiguous identities, unusable mount, missing GitHub signing registration, and warning-only setup behavior.
+- [ ] Run the `doctor output` and setup-preflight tests and confirm the new checks are absent.
+- [ ] Add warning-only host signing checks, including an optional GitHub signing-key query; do not add account mutations or required preflight failures.
+- [ ] Document automatic selection order, unsigned fallback, Docker mount limitations, agent security exposure, and GitHub's one-time separate signing-key registration.
+- [ ] Add a changeset for default-on best-effort commit signing.
+- [ ] Rerun focused doctor/setup tests and lint changed Markdown.
+
+### Task 5: Verify the full feature
+
+**Files:**
+
+- Test: `__tests__/app.test.ts`
+
+- [ ] Run `node --import tsx --test __tests__/**/*.test.ts`; record the two known unrelated baseline failures and require no additional failures.
+- [ ] Run `npm run build` and `npm run lint` using local project tooling where available.
+- [ ] With Docker and a loaded agent available, create a disposable container using the generated mount, make an empty signed commit, and verify its SSH fingerprint; do not push it.
+- [ ] Review `git diff --check`, changed docs, and the implementation against `docs/superpowers/specs/2026-07-11-default-commit-signing-design.md`.

package/docs/superpowers/plans/2026-07-11-progress-ci-regression.md

@@ -0,0 +1,125 @@
+# Progress CI Regression Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Restore CI by making progress checklist cleanup mode-independent and updating stale spinner-label source assertions.
+
+**Architecture:** Preserve the existing `ProgressReporter` API and output behavior. Move only internal cleanup ahead of rendering guards, then loosen two source-presence assertions while leaving runtime checklist-output coverage intact.
+
+**Tech Stack:** TypeScript, Node.js 24 test runner, `node:assert`, pnpm, ESLint, tsdown
+
+## Global Constraints
+
+- Do not change progress APIs, spinner copy, output formatting, or command flow.
+- Use Node.js 24 for tests because the current Node.js 26 host runtime is incompatible with an installed CommonJS test dependency.
+- Commit documentation separately from the implementation, as explicitly requested.
+
+---
+
+### Task 1: Commit the approved documentation
+
+**Files:**
+
+- Create: `docs/superpowers/specs/2026-07-11-progress-ci-regression-design.md`
+- Create: `docs/superpowers/plans/2026-07-11-progress-ci-regression.md`
+
+**Interfaces:**
+
+- Consumes: The user-approved diagnosis and design.
+- Produces: Durable design and execution context for the CI fix.
+
+- [ ] **Step 1: Verify documentation formatting**
+
+Run:
+
+```bash
+git diff --check
+fnm exec --using v24.15.0 node ../../node_modules/markdownlint-cli/markdownlint.js \
+  -c .github/.markdownlint.yml -i 'apm_modules/**' -i '.git' -i '__tests__' \
+  -i '.github' -i '.changeset' -i 'CODE_OF_CONDUCT.md' -i 'CHANGELOG.md' \
+  -i 'node_modules' -i 'dist' '**/**.md'
+```
+
+Expected: PASS with no whitespace or Markdown lint errors.
+
+- [ ] **Step 2: Commit documentation only**
+
+```bash
+git add docs/superpowers/specs/2026-07-11-progress-ci-regression-design.md docs/superpowers/plans/2026-07-11-progress-ci-regression.md
+git commit -m "docs: design progress CI regression fix"
+```
+
+Expected: A commit containing only the design specification and implementation plan.
+
+### Task 2: Fix progress cleanup and stale assertions
+
+**Files:**
+
+- Modify: `src/progress.ts:147`
+- Test: `__tests__/app.test.ts:3080`
+- Test: `__tests__/app.test.ts:3427`
+
+**Interfaces:**
+
+- Consumes: `ProgressReporter.end()` and `ProgressReporter.isChecklistActive()`.
+- Produces: Mode-independent reporter cleanup without API changes.
+
+- [ ] **Step 1: Verify the existing tests reproduce both CI failures**
+
+Run:
+
+```bash
+fnm exec --using v24.15.0 node --import tsx --test \
+  --test-name-pattern='reports whether a checklist is active|hidden command helpers use friendly spinner labels' \
+  __tests__/app.test.ts
+```
+
+Expected: FAIL because checklist state remains active in `none` mode and the SSH label regular expressions require an outdated direct-property expression.
+
+- [ ] **Step 2: Make cleanup independent of rendering mode**
+
+In `ProgressReporter.end()`, clear internal state immediately after stopping timers:
+
+```ts
+this.#steps = []
+this.#renderedStepLineCount = 0
+```
+
+Remove the existing duplicate cleanup after the interactive section terminator.
+
+- [ ] **Step 3: Make the source-presence assertions expression-shape independent**
+
+Replace the two SSH assertions with:
+
+```ts
+assert.match(sshKeySource, /Generating Boxdown SSH identity/)
+assert.match(sshKeySource, /Writing Boxdown SSH public key/)
+```
+
+- [ ] **Step 4: Verify the focused regression tests pass**
+
+Run the Step 1 command again.
+
+Expected: PASS for both selected tests.
+
+- [ ] **Step 5: Run full verification**
+
+Run:
+
+```bash
+fnm exec --using v24.15.0 node ../../node_modules/c8/bin/c8.js node --import tsx --test __tests__/**/*.test.ts
+fnm exec --using v24.15.0 node ../../node_modules/eslint/bin/eslint.js .
+fnm exec --using v24.15.0 node ../../node_modules/typescript/bin/tsc
+fnm exec --using v24.15.0 node ../../node_modules/tsdown/dist/run.mjs
+```
+
+Expected: All tests pass, ESLint reports no errors, TypeScript compilation succeeds, and tsdown builds successfully.
+
+- [ ] **Step 6: Commit the implementation separately**
+
+```bash
+git add src/progress.ts __tests__/app.test.ts
+git commit -m "fix(progress): clear checklist state in every mode"
+```
+
+Expected: A second commit containing only the production fix and updated assertions.