chore(loop): bootstrap autonomous desktop-feature loop infra (#38)

Prerequisites for the unattended desktop-feature loop:

- e2e CDP harness (`bun run e2e`): launches the built Electron app with
  remote debugging, drives the real UI over the Chrome DevTools Protocol,
  and asserts on rendered state. Zero new deps (Bun's WebSocket + fetch).
  Runs against an isolated profile (config, userData, default workspace
  redirected under .e2e/) and is headless-aware (xvfb + --no-sandbox on
  Linux). Ships an app-boot smoke assertion as the template for new ones.
- docs/loop/feature-ledger.md: cross-run ledger with a status state
  machine (proposed/in-progress/pr-open/merged/rejected/blocked).
- docs/loop/capability-inventory.md: baseline inventory of current
  desktop capabilities to diff candidate features against.

Author: DragonnZhang

.gitignore

@@ -59,6 +59,9 @@ pnpm-lock.yaml
 # Craft Agent local data (sessions, credentials, config)
 .craft-agent/
 
+# E2E harness scratch (isolated user-data, failure screenshots)
+.e2e/
+
 # SSH keys and secrets
 *.pem
 *.key

docs/loop/capability-inventory.md

@@ -0,0 +1,98 @@
+# OpenWork Capability Inventory (baseline)
+
+A snapshot of what the OpenWork desktop app **already does today**, grounded in
+the current code. The autonomous feature loop diffs Claude Code Desktop / Codex
+desktop features against this baseline to find genuine gaps — so a candidate that
+maps to anything below is **not** a gap.
+
+> Scope: the Electron frontend/shell only. The qwen-code backend (vendored from
+> npm) is out of scope and must not be modified. Paths are representative anchors,
+> not exhaustive.
+>
+> Maintenance: refresh this when a `loop-bot` PR ships a new capability, or
+> periodically re-survey. Treat it as a fast index, not a contract.
+
+## 1. Sessions & conversation
+- Multi-session per workspace; create/delete/archive/flag; status (`todo`,
+  `in_progress`, `needs_review`, `done`, `cancelled`); search & filter.
+- Persisted history with message-level streaming, token-usage tracking, read/unread.
+- Session export/import + cross-workspace resource bundles.
+- `apps/electron/src/renderer/atoms/sessions.ts`, `packages/core/src/types/session.ts`
+
+## 2. Chat & agent interaction UI
+- Message bubbles (user/system), turn cards with actions, inline execution progress.
+- Plan accept/reject UI; streaming incremental updates; token display.
+- Auth-request cards for OAuth flows; tool-execution approval dialogs.
+- **Permission modes (4):** `explore` / `ask` / `execute` / `auto-edit`.
+- **Thinking levels (6):** off / low / medium / high / xhigh / max, with per-workspace defaults.
+- `packages/ui/src/components/chat/*`, `packages/shared/src/agent/mode-types.ts`
+
+## 3. File & artifact previews
+- Code (Shiki highlight), diffs, JSON tree, HTML (sandboxed), Mermaid, LaTeX.
+- PDF viewer, spreadsheet/Excel table (sort/filter/export), DOCX, PPTX, image gallery.
+- Rich markdown: collapsible sections, table export (CSV/Excel), link preview overlay.
+- `packages/ui/src/components/markdown/*`, `apps/electron/src/renderer/components/files/FileViewer.tsx`
+
+## 4. Local project & workspace management
+- Workspace types: `conversation` / `project`; multi-workspace; per-workspace config.
+- File read (text/binary), directory listing/search, file watching, allowed-dir enforcement.
+- Shell command execution with output capture, kill/terminate, shell-env loading (nvm/Homebrew).
+- Worktree creation; per-session modified/new-file tracking; notes.
+- `apps/electron/src/main/handlers/workspace.ts`, `apps/electron/src/main/shell-env.ts`
+
+## 5. Integrations & data sources
+- **MCP servers:** HTTP MCP connections, workspace-scoped OAuth / bearer auth, tool listing & execution.
+- **Native OAuth:** Google, Slack, Microsoft (PKCE, refresh); plus a generic OAuth 2.0 client for any provider.
+- **Local folder sources** as agent data sources; encrypted per-workspace credential store with health tracking.
+- **Messaging adapters:** WhatsApp, Telegram (pairing/linking, inbound event fanout).
+- `packages/shared/src/mcp/*`, `packages/shared/src/auth/*`, `packages/messaging-gateway/src/adapters/*`
+
+## 6. Skills & extensibility
+- `SKILL.md` (YAML frontmatter) format; metadata (name, description, icon, required sources, alwaysAllow tools).
+- Multi-tier sourcing: global (`~/.agents/`), workspace, project (`.agents/`), provider.
+- File-glob auto-trigger; tool allow-listing; enable/disable; marketplace discovery.
+- `packages/shared/src/skills/*`
+
+## 7. Settings & preferences
+- Model selection per session/workspace; multiple LLM connections per provider; custom endpoints.
+- Default + per-session permission mode; per-workspace thinking level.
+- Theme (light/dark/system + presets), language (i18next), keep-awake, keyboard shortcuts.
+- Network proxy (HTTP/HTTPS/SOCKS + auth).
+- `apps/electron/src/main/handlers/settings.ts`, `packages/shared/src/config/*`
+
+## 8. Window & UX features
+- Multi-window (per-workspace), window-state persistence, close confirmation, deep links (`craftagents://`).
+- **Pet window:** floating companion overlay, click-through, activity animations, notifications.
+- **Embedded browser pane:** Chromium pane (dockable/floating) with navigate/back/forward/reload,
+  JS eval, screenshot, form interaction, a11y snapshot, CDP integration, console/network logging.
+- Theme system with per-workspace override; i18n; command palette / action registry; global shortcuts.
+- `apps/electron/src/main/window-manager.ts`, `apps/electron/src/main/browser-pane-manager.ts`
+
+## 9. Model & provider configuration
+- Providers: Qwen (ModelStudio) primary; OpenAI-compatible custom endpoints; multi-connection.
+- Model metadata (capabilities, context window, pricing) with lazy-load/caching.
+- Auth: API key / OAuth / bearer / custom headers. Runtime proxy changes.
+- `packages/shared/src/config/llm-connections.ts`, `packages/shared/src/config/model-fetcher.ts`
+
+## 10. Auto-update & distribution
+- electron-updater: macOS (DMG/zip + signature validation), Windows (NSIS), Linux (AppImage).
+- Download progress, update notification, install-on-quit, skip-version, dev-build exclusion.
+- macOS code-signing checks; brand-configurable update sources.
+- Platforms: macOS (arm64/x64), Windows (x64/arm64), Linux (AppImage).
+- `apps/electron/src/main/auto-update.ts`
+
+## 11. Notifications
+- Native OS notifications (focus-suppressed, click-to-navigate, workspace routing).
+- macOS dock badge unread count (instance-aware); in-app Sonner toasts.
+- `apps/electron/src/main/notifications.ts`
+
+## 12. Other notable
+- Deep linking / URL scheme actions (new-chat, resume/delete/flag session, navigate to settings/sources/skills).
+- Session resource export/import; remote workspace support (WebSocket-proxied handlers, chunked RPC).
+- Power management (keep-awake during runs); Sentry error tracking with redaction; onboarding/setup flow.
+- `apps/electron/src/main/deep-link.ts`, `apps/electron/src/main/onboarding.ts`
+
+---
+
+_Generated as a baseline survey. Verify against current code before relying on any
+single line — the app evolves and this index can lag._

docs/loop/feature-ledger.md

@@ -0,0 +1,35 @@
+# Feature Ledger
+
+Working memory for the autonomous desktop-feature loop. Each run appends or
+updates a row here.
+
+**GitHub is the source of truth.** At the start of every run the loop reconciles
+this file against GitHub issues/PRs labeled `loop-bot`, so merge/close state is
+authoritative there — this table is the loop's human-readable index and learning
+log, not the system of record.
+
+## Status legend
+
+| status | meaning |
+| --- | --- |
+| `proposed` | Identified as a gap, not started. |
+| `in-progress` | Issue filed, branch open, implementation underway. |
+| `pr-open` | PR submitted, awaiting human review/merge. |
+| `merged` | PR merged — feature shipped. |
+| `rejected` | PR closed **without** merging. Record **why** in Notes. |
+| `blocked` | Not doable as a frontend-only change (needs qwen-code backend) or otherwise infeasible. Record **why**. |
+
+## Selection rules
+
+- Never pick a feature whose latest status is `merged`, `rejected`, `blocked`, or
+  `in-progress`.
+- `rejected` rows are **learning signals**: read the PR's close reason / review
+  comments before considering the area again, and only retry with a clearly
+  different and better approach.
+- Keep the newest entries at the top.
+
+## Ledger
+
+| slug | title | source | feasibility | status | issue | pr | branch | updated | notes |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| _(empty)_ | _first run appends here_ | | | | | | | | |

e2e/README.md

@@ -0,0 +1,85 @@
+# E2E harness (CDP)
+
+A dependency-free end-to-end harness that launches the **built** OpenWork
+Electron app with the Chrome DevTools Protocol enabled, drives the real UI over
+CDP, and asserts on what the user would actually see.
+
+It exists so an automated feature loop (and humans) can answer one question per
+change: **does this feature actually work in the running app?**
+
+## Run it
+
+```bash
+bun run e2e
+```
+
+This will:
+
+1. Build the Electron bundles if `apps/electron/dist/{main.cjs,renderer/index.html}`
+   are missing (set `E2E_BUILD=1` to force a rebuild).
+2. For **each** `e2e/assertions/*.assert.ts`, launch a fresh, isolated app
+   instance with `--remote-debugging-port`, run the assertion, then shut it down.
+3. Print a pass/fail summary and exit non-zero if anything failed (so it can gate
+   a PR).
+
+Failure screenshots land in `.e2e/screenshots/` (gitignored). The app runs
+against an isolated profile under `.e2e/` so runs never touch your real OpenWork
+data — Electron userData, app config (`~/.craft-agent`), and the default
+conversation workspace (`~/Documents/...`) are all redirected under `.e2e/`.
+
+### Headless / CI / cloud
+
+On a headless Linux host (no `DISPLAY`), the launcher automatically runs Electron
+under `xvfb-run` with `--no-sandbox`. The host must have `xvfb` and Electron's
+runtime libraries (`libgtk-3`, `libnss3`, …) installed.
+
+### Environment knobs
+
+| Var | Effect |
+| --- | --- |
+| `E2E_BUILD=1` | Force `electron:build` before launching. |
+| `E2E_PORT=<n>` | Pin the remote-debugging port instead of using a free one. |
+
+## Add an assertion
+
+Drop a `*.assert.ts` file into `e2e/assertions/`. It must default-export an
+`Assertion` — `{ name, run(app) }`. The runner discovers it automatically.
+
+```ts
+import type { Assertion } from '../runner';
+
+const assertion: Assertion = {
+  name: 'settings dialog opens from the sidebar',
+  async run(app) {
+    const { session } = app;
+    await session.click('[aria-label="Settings"]');
+    await session.waitForSelector('[role="dialog"]');
+    const heading = await session.getText('[role="dialog"] h2');
+    if (heading?.trim() !== 'Settings') {
+      throw new Error(`expected Settings dialog, saw heading: ${heading}`);
+    }
+  },
+};
+
+export default assertion;
+```
+
+Guidelines:
+
+- **Assert on visible result/state, not "it booted."** A green check should mean
+  the feature's key path works.
+- Prefer stable selectors (`role`, `aria-label`, visible text) over brittle
+  class chains. If the UI lacks a hook, add a `data-testid` in the same PR.
+- Each assertion gets a clean app instance, so they're independent and order
+  doesn't matter.
+
+## How it works
+
+- `cdp.ts` — minimal CDP client over Bun's global `WebSocket` + `fetch`
+  (`evaluate`, `waitForFunction`, `waitForSelector`, `click`, `getText`,
+  `screenshot`). Zero external deps.
+- `app.ts` — launches `electron apps/electron --remote-debugging-port=<port>`,
+  finds the main renderer target (title `Qwen Code Desktop`), attaches a session,
+  and owns teardown.
+- `runner.ts` — discovers assertions, runs each against a fresh app, reports.
+- `assertions/*.assert.ts` — the checks themselves.