Promote main to release

AGENTS.md

@@ -63,8 +63,9 @@ for writers before deciding. See
 
 ### State and permissions
 
-Every Copse store lives under one root, `~/.copse/` (`COPSE_DIR` moves the profile). Persistent
-settings live in `user-data/config.json`, but chat threads do **not**.
+Every Copse store lives under one root, `~/.copse/` (`COPSE_DIR` moves the profile). General app
+state lives in `user-data/config.json`; validated settings and encrypted secrets
+live in `user-data/settings.json`. Chat threads live in neither store.
 Threads live under `~/.copse/workspace/<projectId>/<threadId>/`; use `writeSeedConfig`
 (`tests/e2e/helpers/seed-config.ts`) so test threads are routed into the native thread store. See
 [`docs/thread-store-format.md`](docs/thread-store-format.md) and
@@ -126,7 +127,7 @@ oracle. Detailed local commands and screenshot ownership behavior are in
 
 ## Specialized surfaces
 
-Conversation messages, subagent timelines, and file preview use the hand-rolled renderer in
-`src/renderer/markdown/`. Before markdown or list-indent changes, read
+Conversation messages, subagent timelines, and file preview use `@copse/streaming-markdown`,
+with app integration in `src/renderer/markdown/`. Before markdown or list-indent changes, read
 [`src/renderer/markdown/README.md`](src/renderer/markdown/README.md); then run
 `pnpm run build && pnpm run test:e2e:markdown`.

README.md

@@ -84,7 +84,7 @@ Install, first run, approvals, and the project sandbox:
 
 ## Contributing
 
-See [CONTRIBUTING.md](CONTRIBUTING.md). No paid model key is required to explore the development build: connect a local model, or launch with `COPSE_PANEL_MOCK_LLM=1 pnpm run dev` to opt into the built-in mock agent.
+See [CONTRIBUTING.md](CONTRIBUTING.md) and the [architecture map](site/architecture.html). No paid model key is required to explore the development build: connect a local model, or launch with `COPSE_PANEL_MOCK_LLM=1 pnpm run dev` to opt into the built-in mock agent.
 
 Before submitting a change, run:
 

docs/README.md

@@ -8,5 +8,10 @@ sandbox, troubleshooting. A hosted site at `copse.dev/docs/` is planned
 ([plans/docs-site.md](plans/docs-site.md)); do not file a how-to for end users
 at this directory’s root.
 
+Start with the [interactive architecture map](../site/architecture.html) for runtime
+boundaries, package ownership, subsystem contracts, and the distinction between
+shipped features, experiments, and plans. [Plan status](plans/README.md) retains
+delivery history and deferred decisions.
+
 Public-readiness decisions that still need an owner stamp live in
 [public-readiness-decisions.md](public-readiness-decisions.md).

docs/browser-network-policy.md

@@ -0,0 +1,39 @@
+# Browser network policy
+
+The visible Browser pane (including MCP HTML/URL artefacts and chat links) and the
+agent's browser tools enforce `webAllowedOrigins` at the Electron session request
+boundary. This is the same allowlist used for web tools, including wildcard hosts
+and ports. An explicitly empty network allowlist denies all network requests.
+The old `browserAllowedOrigins` setting no longer grants separate network access.
+
+Every HTTP(S) request, redirect target, embedded resource and WebSocket handshake
+is checked. Private/link-local targets are denied. Requests without an owning
+page, including background service-worker traffic, fail closed. Both the browser
+and web approval settings must permit approval before a new origin can prompt.
+A remembered navigation approval adds the origin to the network allowlist;
+a one-time approval lasts for this app session and belongs only to its task.
+
+Browser partitions and automation tab managers are scoped by project and task.
+Interactive and agent browser profiles remain separate. Existing tabs keep their
+original owner when the selected task changes; popup tabs inherit that owner.
+Tab persistence, pop-outs and agent preview promotion preserve that scope too.
+
+Local HTTP previews get an additive CSP in response headers. It allows resources
+from the page's own origin, inline scripts/styles and embedded data/blob images,
+but denies external origins, frames, workers, plugins and base URL changes.
+Existing server CSPs still apply. A network approval does not relax this local
+preview CSP: bundle assets locally and proxy required APIs through the dev server
+under the user's normal network policy.
+
+HTML artefacts prepend the same CSP before untrusted markup. Data URL documents
+have no network access even if their HTML omits the CSP, including access to
+allowlisted hosts and localhost. Direct browser navigation supports HTTP(S) only. Workspace file previews use
+the existing static preview server, so relative files load from its loopback
+origin under the same policy. This does not enable arbitrary file URL browsing;
+file documents, if encountered, cannot make network requests.
+
+Validation: `browser-network-policy.test.ts` covers the request matrix and additive
+CSP; `browser-network-grants.test.ts` and the permission-gate tests cover task
+isolation. `browser-network-policy.e2e.ts` exercises real Chromium enforcement,
+asserts that blocked images/fetches never reach a second test origin, verifies
+same-origin images and captures `browser-preview-network-policy.png`.

docs/hooks.md

@@ -15,11 +15,12 @@ author writes. Read this doc for **how the pieces fit** — where the harness fi
 how a decision flows back, and the cross-cutting concerns (budget, spine, sandbox, UI)
 that are dialect-agnostic.
 
-> Everything below reflects what has **landed** (through the
-> [validation & tooling phase](./plans/hooks-and-feature-packs.md#phase-g--validation--tooling)).
-> [Feature packs](./plans/hooks-and-feature-packs.md#feature-packs) are the intended end
-> state and are not implemented yet; the packs section of the plan doc describes them.
-> Where behavior differs by phase, the phase tag links to the plan's issue breakdown.
+> Current architecture reviewed at `main` `a2880354f` (2026-09-09).
+> The hooks platform and [plugin lifecycle](plugins.md) are implemented; the
+> historical feature-pack phases record how they landed. External isolated
+> function-hook registration is a separate, partial SDK capability: explicit host
+> invocation exists, but canonical fire sites do not dispatch those registrations
+> automatically. See [the SDK contract](../packages/plugin-sdk/README.md).
 
 ## What a hook is
 
@@ -331,7 +332,7 @@ hooks cannot retroactively block work that already completed.
   summary. It is **side-effect-free by construction** — it reuses only the pure seams
   (adapter marshal/interpret + `spawnHookProcess`), so it never records a spine line, never
   propagates `sessionStart` env, and **never applies the outcome**; it reproduces the live
-  spawn boundary faithfully (sandboxed-by-default, macOS-only enforcement). Host module:
+  spawn boundary faithfully (sandboxed by default on macOS/Linux when the OS sandbox is active). Host module:
   `src/main/services/hooks/dry-run.ts`.
 
 ## Payload stability & schema drift tooling