feat(chat,cli): auto-resume after usage limits, ade triage, attachment overhaul

.agents/skills/quality/SKILL.md

@@ -197,7 +197,8 @@ Apply all three reference files:
    null services on bypassed IPC routes, daemon action-domain wiring, cr-sqlite
    CRR constraints, mobile-host compatibility, IPC/preload/shared/renderer
    contract drift, fast-tier loading, Node/test-env gotchas, worktree path
-   discipline.
+   discipline, and the surface coverage sweep (entry points, clients,
+   providers, reverse states, connection modes — rule 11).
 3. **`references/windows-quirks.md`** — the Windows failure classes ADE has
    actually hit and the named helper that resolves each one. Windows parity is
    a default requirement (see **Windows parity rules** above), so this file

.agents/skills/quality/references/ade-review-rules.md

@@ -156,6 +156,33 @@ these foundation-specific checks apply on top of the default review:
   reboot/restart, installed updates, and GUI artifacts as external proof. Code
   or mocked tests cannot close those gates.
 
+## 11. Surface coverage sweep
+
+**Class:** A change that works on the one path the author tested and is missing
+everywhere else — the single most common defect shape in multi-client, 
+multi-provider repos. This is the review-side enforcement of the AGENTS.md
+"Hit every ADE surface" checklist.
+
+**Check:** For each behavior the diff adds or changes, walk the checklist and
+demand an answer per entry — present, deliberately excluded (where is that
+recorded?), or missed:
+
+- **Entry points:** desktop UI, `ade` CLI, `ade code` TUI, deeplinks, command
+  palette, keybindings. A behavior wired into one entry point but reachable
+  from others is a finding.
+- **Clients:** desktop, hosted web, iOS, TUI. Logic duplicated into one client
+  instead of the shared service/type layer is a finding.
+- **Providers:** Claude / Codex / Cursor / OpenCode / Droid. A provider-shaped
+  feature needs a per-adapter decision; silence for an adapter is a finding,
+  an explicit capability gate is not.
+- **Reverse states:** every new way in needs the way out and the way to see it
+  (snooze/unsnooze, settle/unsettle, link/unlink). A one-way door is a finding.
+- **Connection modes:** local runtime, remote runtime, relay, offline,
+  phone-newer-than-host. A feature that assumes local-only must say so.
+
+Raise one finding per missed surface, severity by reachability: a reachable
+crash or dead control is High; a missing deliberate-exclusion record is Low.
+
 ---
 
 ## Output

.agents/skills/test/SKILL.md

@@ -265,6 +265,7 @@ Rules:
 - Mock only at process boundaries: file system, network, child processes, Electron APIs, IPC.
 - Tests must FAIL LOUDLY — assert preconditions explicitly.
 - Use `node` environment unless DOM is genuinely required.
+- Wait on events, receipts, resolved promises, or fake timers — never on wall-clock sleeps. A test that needs a real `sleep` or a raised timeout to pass is testing a race, not a contract; fix the seam (expose the completion signal) instead of padding the wait.
 
 ### 3d. Run as you write
 

.gitignore

@@ -104,3 +104,9 @@ apps/web/public/images/updatedImages/
 # Windows CI runner — the checkout, not a test. Ignore them so a broad
 # `git add -A` cannot sweep them in when a test throws before its cleanup.
 *\\*
+
+# Agent work artifacts: research notes an agent writes at the repo root while
+# investigating. They are scratch for one task, never product, and a broad
+# `git add -A` would otherwise sweep them into a PR (AGENTS.md work-artifacts
+# rule). Anything worth keeping goes under docs/.
+T3CODE_RESEARCH_*.md

AGENTS.md

@@ -21,13 +21,28 @@ Day-to-day work follows a five-stage loop, each stage an agent-folder skill unde
 - **/test** — test steward: prune/consolidate/add + docs/mobile/CLI/TUI parity + CI-mirrored shards; records a named regression test or exact alternate verification for every accepted correctness finding.
 - **/ship** — autonomous PR→merge loop (poll → fix → rebase → merge). Run baseline `/quality` and `/test` first; after any ship-loop mutation, ship reruns commit-bound `/quality` revalidation before pushing or merging. Wraps `docs/playbooks/ship-lane.md`.
 
+**"Run the dev loop"** — when the user says this (or "dev loop") after work is implemented, it names one task, not a suggestion: invoke `/quality`, then `/test`, then `/ship`, in that order. Actually invoke each skill — approximating one (running tests is not `/test`; green CI is not `/quality`) does not count. Print each skill's summary, then continue to the next without stopping; stop early only for a genuine blocker (a failing gate or a decision only the user can make) and name it.
+
 Utilities (run when relevant, not part of the core loop): **/audit** (targeted bug hunt), **/finalize** (optional pre-push local-CI gate), **/optimize** (perf profiling), **/release** (cut a release).
 
 ## Playbooks
 
 - `docs/playbooks/ship-lane.md` — autonomous PR-to-merge driver (poll → fix → rebase → merge). Baseline `/quality` and `/test` run before it; mutation-specific commit-bound quality revalidation runs inside it. Any agent CLI can follow it directly; Claude Code invokes it via the `/ship` skill.
 - `docs/playbooks/windows-signed-release.md` — maintainer handoff for taking the gated Windows x64 build through signing, clean-host and installed-update proof, draft verification, publication, and website enablement without changing the macOS or iOS release paths.
 
+## Hit every ADE surface
+
+The most common defect class in this repo is a change that works on the path you tested and is missing everywhere else. Before you call a change done (and again in `/quality`), walk this list and state which entries applied:
+
+- **Entry points.** A behavior reachable from the desktop UI is usually also reachable from the `ade` CLI, the `ade code` TUI, deeplinks, the command palette, and keybindings. Fixing one entry point is not fixing the feature.
+- **Clients.** Desktop (Electron), hosted web, iOS, and the TUI attach to the same brain. Shared logic belongs in shared services and types, not re-implemented per client.
+- **Providers.** Claude, Codex, Cursor, OpenCode, and Droid each have an adapter with different capabilities. A provider-shaped feature needs a decision per adapter, even when the decision is "not supported here" — record it in the capability gate, not by silence.
+- **Contracts.** Anything crossing a boundary is typed once: main-process handler, `src/shared` types, preload exposure, renderer caller, daemon action domain, tests/mocks. Change the contract and all of them move together.
+- **Reverse states.** If you add a way in, add the way out and the way to see it. Snooze needs unsnooze; settle needs unsettle; a link needs unlink. A one-way door is a bug.
+- **Connection modes.** Local runtime, remote runtime, and relay behave differently. Multi-device and offline cases are real; the phone can be newer than the host.
+- **Windows.** Parity is part of "done" for all new code, never a follow-up.
+- **Docs.** User-visible behavior changes update the matching `docs/features/` doc in present tense.
+
 ## Working norms
 
 - Preserve existing desktop app patterns before introducing new abstractions.
@@ -37,6 +52,28 @@ Utilities (run when relevant, not part of the core loop): **/audit** (targeted b
 - For computer-use changes, treat policy enforcement and artifact ownership as hard requirements, not prompt guidance.
 - `ade search "<query>" --text` searches everything in ADE (chats, terminal scrollback, PRs, commits, branches, lanes, files, Linear) instead of grepping `.ade/` internals; see the ade-search skill.
 
+## Ways to hurt yourself
+
+These are the operational hazards of developing ADE from inside ADE. Each one has caused real damage.
+
+1. **Killing by pattern.** Do not `pkill -f`, `pgrep | kill`, or kill a PID you found by matching a name or path. Your own agent process carries this worktree's path in its argv, `pgrep -f xcodebuild` also matches xcodebuildmcp and its wrapper shell, and this machine runs the real ADE brain plus other dev runtimes. Kill only a PID you captured at spawn time, after confirming its cwd is your worktree.
+2. **Writing to live state.** The project root's `.ade/` (database, secrets, artifacts) and the installed brain are the developer's real, in-use ADE instance. Read from them for realistic data; never point a dev server at them, never open them read-write, never "clean them up". Isolated dev state belongs under your worktree or a temp directory.
+3. **Editing outside the lane worktree.** Every edit targets `.ade/worktrees/<lane>/...`, never the project-root checkout. Search tools may print root-checkout paths — translate them before editing, or the change lands on the wrong branch.
+4. **Restarting shared runtimes casually.** `ensureRuntime`-style commands can restart a brain another session is using. Check what is running before starting or restarting sockets, brains, or dev servers.
+
+## Work artifacts
+
+- Keep implementation plans, research notes, and agent scratch files out of the repository. They are inputs to the work, not project documentation. The merged PR is the implementation record.
+- Docs describe the present tense. When behavior changes, update the matching `docs/features/` doc in the same branch. A task-tracking list in a feature doc must be kept current by the branch that changes the feature, or deleted — a stale checklist misleads every later agent.
+- Track future work in Linear (see the ade-linear skill), not in committed TODO files.
+
+## Pull requests
+
+- Conventional commit titles in plain language: `fix(desktop): new chats no longer spike CPU`.
+- Body house style, in order: **Problem** (a sentence or two), **Cause** (when known), **Change and boundary** (what moved, what deliberately did not), **Verification** (the exact focused tests/typechecks run and their counts). End with the model and harness that did the work.
+- UI changes need before/after images. Motion or timing needs a short video. Upload evidence to GitHub; never commit screenshots or PR-only assets to the repo.
+- One concern per PR. If the description says "also", consider splitting it.
+
 ## Validation
 
 - Desktop checks:
@@ -48,8 +85,9 @@ Utilities (run when relevant, not part of the core loop): **/audit** (targeted b
   - `npm --prefix apps/ade-cli run typecheck`
   - `npm --prefix apps/ade-cli run test`
   - `npm --prefix apps/ade-cli run build`
-- Run the smallest relevant subset first when iterating, then finish with the broader checks that cover the touched surfaces.
+- **Smallest proof first.** Run the narrowest check that proves the change: the touched test files, a scoped typecheck, one shard. Do not run full local suites by default — CI owns the full matrix, and `/finalize` is the opt-in local full gate before a push.
 - Run full desktop tests with the root `npm run test:desktop:sharded` command; use single-file or single-shard Vitest commands for iteration.
+- Tests wait on events, receipts, and promises — never on wall-clock sleeps. A test that needs a `sleep` or a raised timeout to pass is wrong; fix the seam instead.
 - Installing deps: use `npm run install:apps` from the repo root, or `cd apps/<app> && npm install`. Never `npm --prefix apps/<app> install`. `--prefix` only redirects where npm writes `node_modules`; the package npm treats as "the one being installed" is still the one in the *current working directory*. From the repo root that is the root package `ade`, so npm installs the repo into the sub-app: it writes `"ade": "file:../.."` into the app's `package.json` and `package-lock.json` and leaves an `apps/<app>/node_modules/ade` symlink back to the root. Revert that churn if you hit it. `npm --prefix apps/<app> run <script>` and `npm --prefix apps/<app> exec` do not install anything and are unaffected -- but note `exec` runs Vitest with the *current* working directory, so run whole suites as `cd apps/<app> && npx vitest run` or the app's own `npm run test`.
 
 ## Terminology

CLAUDE.md

@@ -1,34 +1,5 @@
-## Picking the right models for work delegation
+## Model roles (Claude-specific)
 
-**Applicability — read this first.** Everything below describes the *Fable-orchestrated* workflow:
-Fable 5 does the thinking and writes specs, gpt-5.6-sol executes them. **It applies only when the
-orchestrating agent is Fable 5.** If you are any other model — Opus, Sonnet, or anything else —
-this section does not govern your delegation, and you should not route work to Codex/gpt-5.6-sol
-on its account. Check what model you are before applying any of it.
+If you are Fable 5, you are always the PM/coordinator. You research, decide, and write the specs; you do not implement by default. Delegate the implementation to Claude Opus 5 subagents — medium effort for routine tasks, high effort for hard ones. Judge each result on its merits; if a subagent's output misses the bar, tighten the spec or raise the effort and redo it.
 
-**If you are not Fable:** do the work yourself, and delegate to `opus` subagents (Claude Opus 5)
-when you need parallelism, an independent review perspective, or a second opinion. Sonnet is
-acceptable only for genuinely trivial mechanical subtasks; never use Haiku. You may still use
-Codex deliberately — for an independent review via `codex review`, or when the user asks for it —
-but not as your default implementation path.
-
-### The Fable-orchestrated tiers
-
-Three tiers. Fable 5 for thinking, gpt-5.6-sol for building, Opus 5 for everything in between.
-With a tight, self-contained prompt Opus also handles implementation well when gpt-5.6-sol is
-unavailable.
-
-| model    | use for |
-|----------|---------|
-| fable-5  | Deep research, architecture/design decisions, hard debugging, anything requiring sustained reasoning or judgment. Also the orchestrator: it writes the specs and prompts the other models execute. |
-| gpt-5.6-sol (high/xhigh) | Pure implementation once a strong, self-contained prompt exists: clear-spec features, migrations, mechanical refactors, test writing, data analysis. Effectively free — use liberally. |
-| opus-5 | Everything else: reviews, moderate-complexity tasks, user-facing polish, second opinions. |
-
-How to apply:
-- The division of labor is think-then-delegate: Fable does the research and produces a detailed spec; gpt-5.6-sol executes it. Never hand gpt-5.6-sol an underspecified task — it can't ask clarifying questions mid-run, so the prompt must contain all context, file paths, constraints, and acceptance criteria.
-- These are defaults, not limits. If a model's output doesn't meet the bar, redo the work with a smarter model without asking. Judge the output, not the price tag.
-- Mechanics for gpt-5.6-sol: it's only reachable through the Codex CLI. Run `codex exec -m gpt-5.6-sol "<self-contained prompt>"` via Bash — my ~/.codex/config.toml defaults to gpt-5.6-sol at xhigh reasoning; pass `-m gpt-5.6-sol` (and `-c model_reasoning_effort=xhigh`) explicitly whenever the config default differs. Use `codex exec -s read-only` for investigation/analysis; use `codex exec resume --last` to iterate on a prior run. `codex review` for an independent review perspective.
-- Invoking codex from an agent shell (IMPORTANT): always close stdin and write output to a log file — `codex exec "<prompt>" </dev/null >"$LOG" 2>&1`, backgrounded. In non-interactive shells stdin is an open pipe and codex blocks forever on "Reading additional input from stdin..." before doing any work; piping stdout through `tail`/`head` buffers everything so you can't see progress. Verify it's actually working by checking the log grows and a new session file appears under `~/.codex/sessions/<date>/`; no session file after ~2 min = wedged, kill and relaunch.
-- Mechanics for Claude models: use the Agent/Workflow `model` parameter (`fable`, `opus`).
-- Inside Workflows (where the model parameter only takes Claude models), reach gpt-5.6-sol via a thin wrapper: spawn an `opus` agent whose prompt says "run the following via `codex exec` in Bash and return its output verbatim, then verify the result compiles/passes tests before returning."
-- Reviews of anything that ships: fable-5 or opus-5, optionally `codex review` as an extra independent perspective.
+If you are any other Claude model, do the work yourself, and use Opus 5 subagents when you need parallelism or an independent second opinion.