diff --git a/.agents/skills/ask-matt/SKILL.md b/.agents/skills/ask-matt/SKILL.md
new file mode 100644
index 00000000000..70b807b35f8
--- /dev/null
+++ b/.agents/skills/ask-matt/SKILL.md
@@ -0,0 +1,78 @@
+---
+name: ask-matt
+description: Ask which skill or flow fits your situation. A router over the skills in this repo.
+disable-model-invocation: true
+---
+
+# Ask Matt
+
+You don't remember every skill, so ask.
+
+A **flow** is a path through the skills. Most paths run along one **main flow**, and two **on-ramps** merge onto it. Everything else is standalone, or a vocabulary layer that runs underneath.
+
+## The main flow: idea → ship
+
+The route most work travels. You have an idea and want it built.
+
+1. **`/grill-with-docs`** — sharpen the idea by interview. Start here when you **have a codebase**: it's stateful, retaining what it learns in `CONTEXT.md` and ADRs. (No codebase? Use `/grill-me` — see Standalone. Both run the same `/grilling` primitive; `grill-with-docs` is the one that leaves a paper trail.)
+2. **Branch — can you settle every question in conversation?** If a question needs a runnable answer (state, business logic, a UI you have to see), detour through a prototype, bridged by **`/handoff`** in both directions (see Crossing sessions):
+   - **`/handoff`** out, then open a fresh session against that file,
+   - **`/prototype`** to answer the question with throwaway code,
+   - **`/handoff`** back what you learned, and reference it from the original idea thread.
+3. **Branch — is this a multi-session build?**
+   - **Yes** → **`/to-spec`** (turn the thread into a spec), then **`/to-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. On a local tracker that's one file per ticket under `.scratch/<feature>/issues/`, worked blockers-first by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed — kick off **`/implement`** per ticket, **clearing context between each one**.
+   - **No** → **`/implement`** right here, in the same context window.
+
+   Either way, **`/implement`** builds each issue by driving **`/tdd`** internally — one red-green slice at a time — then closes out by running **`/code-review`**, a two-axis review (Standards + Spec) of the diff, before committing. Reach for **`/tdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`/code-review`** on its own whenever you want to review a branch or PR against a fixed point.
+
+### Context hygiene
+
+Keep steps 1–3 in **one unbroken context window** — don't compact or clear until after `/to-tickets` — so the grilling, spec, and tickets all build on the same thinking. Each `/implement` then starts fresh, working from the ticket.
+
+The limit on this is the **[smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone)**: the window (~120k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before `/to-tickets`, don't push on degraded — `/handoff` and continue in a fresh thread.
+
+## On-ramps
+
+A starting situation that generates work, then merges onto the main flow.
+
+- **Bugs and requests piling up** → **`/triage`**. It moves issues through triage roles and produces agent-ready issues, which **`/implement`** later picks up.
+
+  Triage is only for issues **you didn't create** — bug reports, incoming feature requests, anything that arrives raw. Tickets that `/to-tickets` produced are already agent-ready, so **don't triage them**.
+
+- **Something's broken** → **`/diagnosing-bugs`**. For the hard ones: the bug that resists a first glance, the intermittent flake, the regression that crept in between two known-good states. It refuses to theorise until it has a **tight feedback loop** — one command that already goes red on *this* bug — then fixes with a regression test. Its post-mortem hands off to **`/improve-codebase-architecture`** when the real finding is that there's no good seam to lock the bug down.
+
+- **A huge, foggy effort — a greenfield project or a huge feature build, too big for one session** → **`/wayfinder`**, the most cognitively demanding flow here. When the way from here to the destination isn't visible yet, it charts a **shared map** of **decision tickets** on the issue tracker and resolves them one at a time — producing **decisions, not deliverables** — until the fog is pushed back and the way is clear. Where **`/grill-with-docs`** sharpens an idea you can hold in one session, wayfinder is for the idea you can't — and it's slower and denser, so save it for exactly that, never a well-scoped feature.
+
+  When the map clears, **it hands off, it doesn't build**: merge onto the main flow at **`/to-spec`**, which collapses the map's linked decisions into a buildable plan, then `/to-tickets` and `/implement` as usual. Looping the map straight into `/implement` skips that collapse and throws the linked detail away — go straight to `/implement` only when the effort turned out genuinely small.
+
+## Codebase health
+
+Not feature work — upkeep.
+
+- **`/improve-codebase-architecture`** — run whenever you have a spare moment to keep the codebase good for agents to operate in. It surfaces **deepening opportunities**; picking one _generates an idea_ you can take into the main flow at `/grill-with-docs`. It's the survey that finds the candidates; **`/codebase-design`** (below) is the bench you design the chosen one on.
+
+## Vocabulary underneath
+
+Two model-invoked references that run *beneath* the other skills — each the single source of truth for its vocabulary. Reach for them directly when the **words**, not the process, are the problem; or let the skills above pull them in.
+
+- **`/domain-modeling`** — sharpen the project's *domain* language: challenge a fuzzy term, resolve an overloaded word ("account" doing three jobs), record a hard-to-reverse decision as an ADR. It's the active discipline `/grill-with-docs` drives to keep `CONTEXT.md` a clean glossary.
+- **`/codebase-design`** — the deep-module vocabulary (module, interface, depth, seam, adapter, leverage, locality) for designing a module's *shape*: a lot of behaviour behind a small interface at a clean seam. `/tdd` and `/improve-codebase-architecture` both speak it.
+
+## Crossing sessions
+
+- **`/handoff`** — when a thread is full or you need to branch off (e.g. into a `/prototype` session), this compacts the conversation into a markdown file. You don't continue in place — you **open a new session and reference that file** to carry the context across. It's the bridge between context windows, in either direction. Use it when you want a **fresh session** but need the **current conversation preserved**.
+- **`/compact`** (built-in) — stay in the **same conversation**, letting the earlier turns be summarized. Use it at **intentional breaks between phases**, when you don't mind losing the verbatim history. Don't compact mid-phase — the agent can lose its way. `/handoff` forks; `/compact` continues.
+
+## Standalone
+
+Off the main flow entirely.
+
+- **`/grill-me`** — the same relentless interview as `/grill-with-docs`, but for when you have **no codebase**. Stateless: it saves nothing locally, builds no `CONTEXT.md`. Reach for it to sharpen any plan or design that doesn't live in a repo.
+- **`/prototype`** — a small, throwaway program that answers one design question: does this state model feel right, or what should this UI look like. Throwaway from day one — keep the answer, delete the code. It's the detour in step 2 of the main flow, but reach for it any time a design question is hard to settle on paper.
+- **`/research`** — delegate reading legwork to a **background agent**: it investigates a question against **primary sources**, then leaves a cited Markdown file in the repo. Keep working while it reads. The file it produces is something to take *into* the main flow at `/grill-with-docs` — research feeds the thinking, it doesn't replace it.
+- **`/teach`** — learn a concept over multiple sessions, using the current directory as a stateful workspace.
+- **`/writing-great-skills`** — reference for writing and editing skills well.
+
+## Precondition
+
+**`/setup-matt-pocock-skills`** — run before your first engineering flow to configure the issue tracker, triage labels, and doc layout the other skills assume. Custom issue trackers also work.
diff --git a/.agents/skills/ask-matt/agents/openai.yaml b/.agents/skills/ask-matt/agents/openai.yaml
new file mode 100644
index 00000000000..5c60d51b5b1
--- /dev/null
+++ b/.agents/skills/ask-matt/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Ask Matt"
+  short_description: "Find the right skill or workflow"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/code-review/SKILL.md b/.agents/skills/code-review/SKILL.md
new file mode 100644
index 00000000000..2a0b5240731
--- /dev/null
+++ b/.agents/skills/code-review/SKILL.md
@@ -0,0 +1,89 @@
+---
+name: code-review
+description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
+---
+
+Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
+
+- **Standards** — does the code conform to this repo's documented coding standards?
+- **Spec** — does the code faithfully implement the originating issue / PRD / spec?
+
+Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
+
+The issue tracker should have been provided to you — run `/setup-matt-pocock-skills` if `docs/agents/issue-tracker.md` is missing.
+
+## Process
+
+### 1. Pin the fixed point
+
+Whatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. If they didn't specify one, ask for it.
+
+Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
+
+Before going further, confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty. A bad ref or empty diff should fail here — not inside two parallel sub-agents.
+
+### 2. Identify the spec source
+
+Look for the originating spec, in this order:
+
+1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.) — fetch via the workflow in `docs/agents/issue-tracker.md`.
+2. A path the user passed as an argument.
+3. A PRD/spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
+4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
+
+### 3. Identify the standards sources
+
+Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.
+
+On top of whatever the repo documents, the Standards axis always carries the **smell baseline** below — a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:
+
+- **The repo overrides.** A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.
+- **Always a judgement call.** Each smell is a labelled heuristic ("possible Feature Envy"), never a hard violation — and, like any standard here, skip anything tooling already enforces.
+
+Each smell reads *what it is* → *how to fix*; match it against the diff:
+
+- **Mysterious Name** — a function, variable, or type whose name doesn't reveal what it does or holds. → rename it; if no honest name comes, the design's murky.
+- **Duplicated Code** — the same logic shape appears in more than one hunk or file in the change. → extract the shared shape, call it from both.
+- **Feature Envy** — a method that reaches into another object's data more than its own. → move the method onto the data it envies.
+- **Data Clumps** — the same few fields or params keep travelling together (a type wanting to be born). → bundle them into one type, pass that.
+- **Primitive Obsession** — a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.
+- **Repeated Switches** — the same `switch`/`if`-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.
+- **Shotgun Surgery** — one logical change forces scattered edits across many files in the diff. → gather what changes together into one module.
+- **Divergent Change** — one file or module is edited for several unrelated reasons. → split so each module changes for one reason.
+- **Speculative Generality** — abstraction, parameters, or hooks added for needs the spec doesn't have. → delete it; inline back until a real need shows.
+- **Message Chains** — long `a.b().c().d()` navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.
+- **Middle Man** — a class or function that mostly just delegates onward. → cut it, call the real target direct.
+- **Refused Bequest** — a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.
+
+### 4. Spawn both sub-agents in parallel
+
+Send a single message with two `Agent` tool calls. Use the `general-purpose` subagent for both.
+
+**Standards sub-agent prompt** — include:
+
+- The full diff command and commit list.
+- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full — the sub-agent has no other access to it.
+- The brief: "Report — per file/hunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
+
+**Spec sub-agent prompt** — include:
+
+- The diff command and commit list.
+- The path or fetched contents of the spec.
+- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
+
+If the spec is missing, skip the Spec sub-agent and note this in the final report.
+
+### 5. Aggregate
+
+Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings — the two axes are deliberately separate (see _Why two axes_).
+
+End with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes — that's the reranking the separation exists to prevent.
+
+## Why two axes
+
+A change can pass one axis and fail the other:
+
+- Code that follows every standard but implements the wrong thing → **Standards pass, Spec fail.**
+- Code that does exactly what the issue asked but breaks the project's conventions → **Spec pass, Standards fail.**
+
+Reporting them separately stops one axis from masking the other.
diff --git a/.agents/skills/code-review/agents/openai.yaml b/.agents/skills/code-review/agents/openai.yaml
new file mode 100644
index 00000000000..9076774ba32
--- /dev/null
+++ b/.agents/skills/code-review/agents/openai.yaml
@@ -0,0 +1,3 @@
+interface:
+  display_name: "Code Review"
+  short_description: "Review a diff on standards and spec"
diff --git a/.agents/skills/codebase-design/DEEPENING.md b/.agents/skills/codebase-design/DEEPENING.md
new file mode 100644
index 00000000000..3938457b88d
--- /dev/null
+++ b/.agents/skills/codebase-design/DEEPENING.md
@@ -0,0 +1,37 @@
+# Deepening
+
+How to deepen a cluster of shallow modules safely, given its dependencies. Assumes the vocabulary in [SKILL.md](SKILL.md) — **module**, **interface**, **seam**, **adapter**.
+
+## Dependency categories
+
+When assessing a candidate for deepening, classify its dependencies. The category determines how the deepened module is tested across its seam.
+
+### 1. In-process
+
+Pure computation, in-memory state, no I/O. Always deepenable — merge the modules and test through the new interface directly. No adapter needed.
+
+### 2. Local-substitutable
+
+Dependencies that have local test stand-ins (PGLite for Postgres, in-memory filesystem). Deepenable if the stand-in exists. The deepened module is tested with the stand-in running in the test suite. The seam is internal; no port at the module's external interface.
+
+### 3. Remote but owned (Ports & Adapters)
+
+Your own services across a network boundary (microservices, internal APIs). Define a **port** (interface) at the seam. The deep module owns the logic; the transport is injected as an **adapter**. Tests use an in-memory adapter. Production uses an HTTP/gRPC/queue adapter.
+
+Recommendation shape: *"Define a port at the seam, implement an HTTP adapter for production and an in-memory adapter for testing, so the logic sits in one deep module even though it's deployed across a network."*
+
+### 4. True external (Mock)
+
+Third-party services (Stripe, Twilio, etc.) you don't control. The deepened module takes the external dependency as an injected port; tests provide a mock adapter.
+
+## Seam discipline
+
+- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a port unless at least two adapters are justified (typically production + test). A single-adapter seam is just indirection.
+- **Internal seams vs external seams.** A deep module can have internal seams (private to its implementation, used by its own tests) as well as the external seam at its interface. Don't expose internal seams through the interface just because tests use them.
+
+## Testing strategy: replace, don't layer
+
+- Old unit tests on shallow modules become waste once tests at the deepened module's interface exist — delete them.
+- Write new tests at the deepened module's interface. The **interface is the test surface**.
+- Tests assert on observable outcomes through the interface, not internal state.
+- Tests should survive internal refactors — they describe behaviour, not implementation. If a test has to change when the implementation changes, it's testing past the interface.
diff --git a/.agents/skills/codebase-design/DESIGN-IT-TWICE.md b/.agents/skills/codebase-design/DESIGN-IT-TWICE.md
new file mode 100644
index 00000000000..49a7c42a2cc
--- /dev/null
+++ b/.agents/skills/codebase-design/DESIGN-IT-TWICE.md
@@ -0,0 +1,44 @@
+# Design It Twice
+
+When the user wants to explore alternative interfaces for a chosen deepening candidate, use this parallel sub-agent pattern. Based on "Design It Twice" (Ousterhout) — your first idea is unlikely to be the best.
+
+Uses the vocabulary in [SKILL.md](SKILL.md) — **module**, **interface**, **seam**, **adapter**, **leverage**.
+
+## Process
+
+### 1. Frame the problem space
+
+Before spawning sub-agents, write a user-facing explanation of the problem space for the chosen candidate:
+
+- The constraints any new interface would need to satisfy
+- The dependencies it would rely on, and which category they fall into (see [DEEPENING.md](DEEPENING.md))
+- A rough illustrative code sketch to ground the constraints — not a proposal, just a way to make the constraints concrete
+
+Show this to the user, then immediately proceed to Step 2. The user reads and thinks while the sub-agents work in parallel.
+
+### 2. Spawn sub-agents
+
+Spawn 3+ sub-agents in parallel using the Agent tool. Each must produce a **radically different** interface for the deepened module.
+
+Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
+
+- Agent 1: "Minimize the interface — aim for 1–3 entry points max. Maximise leverage per entry point."
+- Agent 2: "Maximise flexibility — support many use cases and extension."
+- Agent 3: "Optimise for the most common caller — make the default case trivial."
+- Agent 4 (if applicable): "Design around ports & adapters for cross-seam dependencies."
+
+Include both [SKILL.md](SKILL.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
+
+Each sub-agent outputs:
+
+1. Interface (types, methods, params — plus invariants, ordering, error modes)
+2. Usage example showing how callers use it
+3. What the implementation hides behind the seam
+4. Dependency strategy and adapters (see [DEEPENING.md](DEEPENING.md))
+5. Trade-offs — where leverage is high, where it's thin
+
+### 3. Present and compare
+
+Present designs sequentially so the user can absorb each one, then compare them in prose. Contrast by **depth** (leverage at the interface), **locality** (where change concentrates), and **seam placement**.
+
+After comparing, give your own recommendation: which design you think is strongest and why. If elements from different designs would combine well, propose a hybrid. Be opinionated — the user wants a strong read, not a menu.
diff --git a/.agents/skills/codebase-design/SKILL.md b/.agents/skills/codebase-design/SKILL.md
new file mode 100644
index 00000000000..16620c24528
--- /dev/null
+++ b/.agents/skills/codebase-design/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: codebase-design
+description: Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
+---
+
+# Codebase Design
+
+Design **deep modules**: a lot of behaviour behind a small interface, placed at a clean seam, testable through that interface. Use this language and these principles wherever code is being designed or restructured. The aim is leverage for callers, locality for maintainers, and testability for everyone.
+
+## Glossary
+
+Use these terms exactly — don't substitute "component," "service," "API," or "boundary." Consistent language is the whole point.
+
+**Module** — anything with an interface and an implementation. Deliberately scale-agnostic: a function, class, package, or tier-spanning slice. _Avoid_: unit, component, service.
+
+**Interface** — everything a caller must know to use the module correctly: the type signature, but also invariants, ordering constraints, error modes, required configuration, and performance characteristics. _Avoid_: API, signature (too narrow — they refer only to the type-level surface).
+
+**Implementation** — what's inside a module, its body of code. Distinct from **Adapter**: a thing can be a small adapter with a large implementation (a Postgres repo) or a large adapter with a small implementation (an in-memory fake). Reach for "adapter" when the seam is the topic; "implementation" otherwise.
+
+**Depth** — leverage at the interface: the amount of behaviour a caller (or test) can exercise per unit of interface they have to learn. A module is **deep** when a large amount of behaviour sits behind a small interface, **shallow** when the interface is nearly as complex as the implementation.
+
+**Seam** _(Michael Feathers)_ — a place where you can alter behaviour without editing in that place; the *location* at which a module's interface lives. Where to put the seam is its own design decision, distinct from what goes behind it. _Avoid_: boundary (overloaded with DDD's bounded context).
+
+**Adapter** — a concrete thing that satisfies an interface at a seam. Describes *role* (what slot it fills), not substance (what's inside).
+
+**Leverage** — what callers get from depth: more capability per unit of interface they learn. One implementation pays back across N call sites and M tests.
+
+**Locality** — what maintainers get from depth: change, bugs, knowledge, and verification concentrate in one place rather than spreading across callers. Fix once, fixed everywhere.
+
+## Deep vs shallow
+
+**Deep module** = small interface + lots of implementation:
+
+```
+┌─────────────────────┐
+│   Small Interface   │  ← Few methods, simple params
+├─────────────────────┤
+│                     │
+│  Deep Implementation│  ← Complex logic hidden
+│                     │
+└─────────────────────┘
+```
+
+**Shallow module** = large interface + little implementation (avoid):
+
+```
+┌─────────────────────────────────┐
+│       Large Interface           │  ← Many methods, complex params
+├─────────────────────────────────┤
+│  Thin Implementation            │  ← Just passes through
+└─────────────────────────────────┘
+```
+
+When designing an interface, ask:
+
+- Can I reduce the number of methods?
+- Can I simplify the parameters?
+- Can I hide more complexity inside?
+
+## Principles
+
+- **Depth is a property of the interface, not the implementation.** A deep module can be internally composed of small, mockable, swappable parts — they just aren't part of the interface. A module can have **internal seams** (private to its implementation, used by its own tests) as well as the **external seam** at its interface.
+- **The deletion test.** Imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep.
+- **The interface is the test surface.** Callers and tests cross the same seam. If you want to test *past* the interface, the module is probably the wrong shape.
+- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a seam unless something actually varies across it.
+
+## Designing for testability
+
+Good interfaces make testing natural:
+
+1. **Accept dependencies, don't create them.**
+
+   ```typescript
+   // Testable
+   function processOrder(order, paymentGateway) {}
+
+   // Hard to test
+   function processOrder(order) {
+     const gateway = new StripeGateway();
+   }
+   ```
+
+2. **Return results, don't produce side effects.**
+
+   ```typescript
+   // Testable
+   function calculateDiscount(cart): Discount {}
+
+   // Hard to test
+   function applyDiscount(cart): void {
+     cart.total -= discount;
+   }
+   ```
+
+3. **Small surface area.** Fewer methods = fewer tests needed. Fewer params = simpler test setup.
+
+## Relationships
+
+- A **Module** has exactly one **Interface** (the surface it presents to callers and tests).
+- **Depth** is a property of a **Module**, measured against its **Interface**.
+- A **Seam** is where a **Module**'s **Interface** lives.
+- An **Adapter** sits at a **Seam** and satisfies the **Interface**.
+- **Depth** produces **Leverage** for callers and **Locality** for maintainers.
+
+## Rejected framings
+
+- **Depth as ratio of implementation-lines to interface-lines** (Ousterhout): rewards padding the implementation. We use depth-as-leverage instead.
+- **"Interface" as the TypeScript `interface` keyword or a class's public methods**: too narrow — interface here includes every fact a caller must know.
+- **"Boundary"**: overloaded with DDD's bounded context. Say **seam** or **interface**.
+
+## Going deeper
+
+- **Deepening a cluster given its dependencies** — see [DEEPENING.md](DEEPENING.md): dependency categories, seam discipline, and replace-don't-layer testing.
+- **Exploring alternative interfaces** — see [DESIGN-IT-TWICE.md](DESIGN-IT-TWICE.md): spin up parallel sub-agents to design the interface several radically different ways, then compare on depth, locality, and seam placement.
diff --git a/.agents/skills/codebase-design/agents/openai.yaml b/.agents/skills/codebase-design/agents/openai.yaml
new file mode 100644
index 00000000000..3180715edb3
--- /dev/null
+++ b/.agents/skills/codebase-design/agents/openai.yaml
@@ -0,0 +1,3 @@
+interface:
+  display_name: "Codebase Design"
+  short_description: "Vocabulary for deep-module design"
diff --git a/.agents/skills/diagnosing-bugs/SKILL.md b/.agents/skills/diagnosing-bugs/SKILL.md
new file mode 100644
index 00000000000..f400de7c193
--- /dev/null
+++ b/.agents/skills/diagnosing-bugs/SKILL.md
@@ -0,0 +1,134 @@
+---
+name: diagnosing-bugs
+description: Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
+---
+
+# Diagnosing Bugs
+
+A discipline for hard bugs. Skip phases only when explicitly justified.
+
+When exploring the codebase, read `CONTEXT.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
+
+## Phase 1 — Build a feedback loop
+
+**This is the skill.** Everything else is mechanical. If you have a **tight** pass/fail signal for the bug — one that goes red on _this_ bug — you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don't have one, no amount of staring at code will save you.
+
+Spend disproportionate effort here. **Be aggressive. Be creative. Refuse to give up.**
+
+### Ways to construct one — try them in roughly this order
+
+1. **Failing test** at whatever seam reaches the bug — unit, integration, e2e.
+2. **Curl / HTTP script** against a running dev server.
+3. **CLI invocation** with a fixture input, diffing stdout against a known-good snapshot.
+4. **Headless browser script** (Playwright / Puppeteer) — drives the UI, asserts on DOM/console/network.
+5. **Replay a captured trace.** Save a real network request / payload / event log to disk; replay it through the code path in isolation.
+6. **Throwaway harness.** Spin up a minimal subset of the system (one service, mocked deps) that exercises the bug code path with a single function call.
+7. **Property / fuzz loop.** If the bug is "sometimes wrong output", run 1000 random inputs and look for the failure mode.
+8. **Bisection harness.** If the bug appeared between two known states (commit, dataset, version), automate "boot at state X, check, repeat" so you can `git bisect run` it.
+9. **Differential loop.** Run the same input through old-version vs new-version (or two configs) and diff outputs.
+10. **HITL bash script.** Last resort. If a human must click, drive _them_ with `scripts/hitl-loop.template.sh` so the loop is still structured. Captured output feeds back to you.
+
+Build the right feedback loop, and the bug is 90% fixed.
+
+### Tighten the loop
+
+Treat the loop as a product. Once you have _a_ loop, **tighten** it:
+
+- Can I make it faster? (Cache setup, skip unrelated init, narrow the test scope.)
+- Can I make the signal sharper? (Assert on the specific symptom, not "didn't crash".)
+- Can I make it more deterministic? (Pin time, seed RNG, isolate filesystem, freeze network.)
+
+A 30-second flaky loop is barely better than no loop; a 2-second deterministic one is tight — a debugging superpower.
+
+### Non-deterministic bugs
+
+The goal is not a clean repro but a **higher reproduction rate**. Loop the trigger 100×, parallelise, add stress, narrow timing windows, inject sleeps. A 50%-flake bug is debuggable; 1% is not — keep raising the rate until it's debuggable.
+
+### When you genuinely cannot build a loop
+
+Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do **not** proceed to hypothesise without a loop.
+
+### Completion criterion — a tight loop that goes red
+
+Phase 1 is done when the loop is **tight** and **red-capable**: you can name **one command** — a script path, a test invocation, a curl — that you have **already run at least once** (paste the invocation and its output), and that is:
+
+- [ ] **Red-capable** — it drives the actual bug code path and asserts the **user's exact symptom**, so it can go red on this bug and green once fixed. Not "runs without erroring" — it must be able to _catch this specific bug_.
+- [ ] **Deterministic** — same verdict every run (flaky bugs: a pinned, high reproduction rate, per above).
+- [ ] **Fast** — seconds, not minutes.
+- [ ] **Agent-runnable** — you can run it unattended; a human in the loop only via `scripts/hitl-loop.template.sh`.
+
+If you catch yourself reading code to build a theory before this command exists, **stop — jumping straight to a hypothesis is the exact failure this skill prevents.** No red-capable command, no Phase 2.
+
+## Phase 2 — Reproduce + minimise
+
+Run the loop. Watch it go red — the bug appears.
+
+Confirm:
+
+- [ ] The loop produces the failure mode the **user** described — not a different failure that happens to be nearby. Wrong bug = wrong fix.
+- [ ] The failure is reproducible across multiple runs (or, for non-deterministic bugs, reproducible at a high enough rate to debug against).
+- [ ] You have captured the exact symptom (error message, wrong output, slow timing) so later phases can verify the fix actually addresses it.
+
+### Minimise
+
+Once it's red, shrink the repro to the **smallest scenario that still goes red**. Cut inputs, callers, config, data, and steps **one at a time**, re-running the loop after each cut — keep only what's load-bearing for the failure.
+
+Why bother: a minimal repro shrinks the hypothesis space in Phase 3 (fewer moving parts left to suspect) and becomes the clean regression test in Phase 5.
+
+Done when **every remaining element is load-bearing** — removing any one of them makes the loop go green.
+
+Do not proceed until you have reproduced **and** minimised.
+
+## Phase 3 — Hypothesise
+
+Generate **3–5 ranked hypotheses** before testing any of them. Single-hypothesis generation anchors on the first plausible idea.
+
+Each hypothesis must be **falsifiable**: state the prediction it makes.
+
+> Format: "If <X> is the cause, then <changing Y> will make the bug disappear / <changing Z> will make it worse."
+
+If you cannot state the prediction, the hypothesis is a vibe — discard or sharpen it.
+
+**Show the ranked list to the user before testing.** They often have domain knowledge that re-ranks instantly ("we just deployed a change to #3"), or know hypotheses they've already ruled out. Cheap checkpoint, big time saver. Don't block on it — proceed with your ranking if the user is AFK.
+
+## Phase 4 — Instrument
+
+Each probe must map to a specific prediction from Phase 3. **Change one variable at a time.**
+
+Tool preference:
+
+1. **Debugger / REPL inspection** if the env supports it. One breakpoint beats ten logs.
+2. **Targeted logs** at the boundaries that distinguish hypotheses.
+3. Never "log everything and grep".
+
+**Tag every debug log** with a unique prefix, e.g. `[DEBUG-a4f2]`. Cleanup at the end becomes a single grep. Untagged logs survive; tagged logs die.
+
+**Perf branch.** For performance regressions, logs are usually wrong. Instead: establish a baseline measurement (timing harness, `performance.now()`, profiler, query plan), then bisect. Measure first, fix second.
+
+## Phase 5 — Fix + regression test
+
+Write the regression test **before the fix** — but only if there is a **correct seam** for it.
+
+A correct seam is one where the test exercises the **real bug pattern** as it occurs at the call site. If the only available seam is too shallow (single-caller test when the bug needs multiple callers, unit test that can't replicate the chain that triggered the bug), a regression test there gives false confidence.
+
+**If no correct seam exists, that itself is the finding.** Note it. The codebase architecture is preventing the bug from being locked down. Flag this for the next phase.
+
+If a correct seam exists:
+
+1. Turn the minimised repro into a failing test at that seam.
+2. Watch it fail.
+3. Apply the fix.
+4. Watch it pass.
+5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario.
+
+## Phase 6 — Cleanup + post-mortem
+
+Required before declaring done:
+
+- [ ] Original repro no longer reproduces (re-run the Phase 1 loop)
+- [ ] Regression test passes (or absence of seam is documented)
+- [ ] All `[DEBUG-...]` instrumentation removed (`grep` the prefix)
+- [ ] Throwaway prototypes deleted (or moved to a clearly-marked debug location)
+- [ ] The hypothesis that turned out correct is stated in the commit / PR message — so the next debugger learns
+
+**Then ask: what would have prevented this bug?** If the answer involves architectural change (no good test seam, tangled callers, hidden coupling) hand off to the `/improve-codebase-architecture` skill with the specifics. Make the recommendation **after** the fix is in, not before — you have more information now than when you started.
diff --git a/.agents/skills/diagnosing-bugs/agents/openai.yaml b/.agents/skills/diagnosing-bugs/agents/openai.yaml
new file mode 100644
index 00000000000..a13a755a776
--- /dev/null
+++ b/.agents/skills/diagnosing-bugs/agents/openai.yaml
@@ -0,0 +1,3 @@
+interface:
+  display_name: "Diagnosing Bugs"
+  short_description: "Diagnose hard bugs and regressions"
diff --git a/.agents/skills/diagnosing-bugs/scripts/hitl-loop.template.sh b/.agents/skills/diagnosing-bugs/scripts/hitl-loop.template.sh
new file mode 100644
index 00000000000..40afc4652f6
--- /dev/null
+++ b/.agents/skills/diagnosing-bugs/scripts/hitl-loop.template.sh
@@ -0,0 +1,41 @@
+#!/usr/bin/env bash
+# Human-in-the-loop reproduction loop.
+# Copy this file, edit the steps below, and run it.
+# The agent runs the script; the user follows prompts in their terminal.
+#
+# Usage:
+#   bash hitl-loop.template.sh
+#
+# Two helpers:
+#   step "<instruction>"          → show instruction, wait for Enter
+#   capture VAR "<question>"      → show question, read response into VAR
+#
+# At the end, captured values are printed as KEY=VALUE for the agent to parse.
+
+set -euo pipefail
+
+step() {
+  printf '\n>>> %s\n' "$1"
+  read -r -p "    [Enter when done] " _
+}
+
+capture() {
+  local var="$1" question="$2" answer
+  printf '\n>>> %s\n' "$question"
+  read -r -p "    > " answer
+  printf -v "$var" '%s' "$answer"
+}
+
+# --- edit below ---------------------------------------------------------
+
+step "Open the app at http://localhost:3000 and sign in."
+
+capture ERRORED "Click the 'Export' button. Did it throw an error? (y/n)"
+
+capture ERROR_MSG "Paste the error message (or 'none'):"
+
+# --- edit above ---------------------------------------------------------
+
+printf '\n--- Captured ---\n'
+printf 'ERRORED=%s\n' "$ERRORED"
+printf 'ERROR_MSG=%s\n' "$ERROR_MSG"
diff --git a/.agents/skills/domain-modeling/ADR-FORMAT.md b/.agents/skills/domain-modeling/ADR-FORMAT.md
new file mode 100644
index 00000000000..da7e78ec1c2
--- /dev/null
+++ b/.agents/skills/domain-modeling/ADR-FORMAT.md
@@ -0,0 +1,47 @@
+# ADR Format
+
+ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
+
+Create the `docs/adr/` directory lazily — only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what did we decide, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most ADRs won't need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
+- **Considered Options** — only when the rejected alternatives are worth remembering
+- **Consequences** — only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `docs/adr/` for the highest existing number and increment by one.
+
+## When to offer an ADR
+
+All three of these must be true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will look at the code and wonder "why on earth did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
+
+### What qualifies
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
+- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.
diff --git a/.agents/skills/domain-modeling/CONTEXT-FORMAT.md b/.agents/skills/domain-modeling/CONTEXT-FORMAT.md
new file mode 100644
index 00000000000..eaf2a18573f
--- /dev/null
+++ b/.agents/skills/domain-modeling/CONTEXT-FORMAT.md
@@ -0,0 +1,60 @@
+# CONTEXT.md Format
+
+## Structure
+
+```md
+# {Context Name}
+
+{One or two sentence description of what this context is and why it exists.}
+
+## Language
+
+**Order**:
+{A one or two sentence description of the term}
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organization that places orders.
+_Avoid_: Client, buyer, account
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
+- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
+- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
+- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
+
+## Single vs multi-context repos
+
+**Single context (most repos):** One `CONTEXT.md` at the repo root.
+
+**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+
+```md
+# Context Map
+
+## Contexts
+
+- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
+- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
+
+## Relationships
+
+- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
+- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
+- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
+```
+
+The skill infers which structure applies:
+
+- If `CONTEXT-MAP.md` exists, read it to find contexts
+- If only a root `CONTEXT.md` exists, single context
+- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+
+When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.
diff --git a/.agents/skills/domain-modeling/SKILL.md b/.agents/skills/domain-modeling/SKILL.md
new file mode 100644
index 00000000000..d0f7e1a5ccb
--- /dev/null
+++ b/.agents/skills/domain-modeling/SKILL.md
@@ -0,0 +1,74 @@
+---
+name: domain-modeling
+description: Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
+---
+
+# Domain Modeling
+
+Actively build and sharpen the project's domain model as you design. This is the *active* discipline — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `CONTEXT.md` for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
+
+## File structure
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/
+│   └── adr/
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/
+│   └── adr/                          ← system-wide decisions
+├── src/
+│   ├── ordering/
+│   │   ├── CONTEXT.md
+│   │   └── docs/adr/                 ← context-specific decisions
+│   └── billing/
+│       ├── CONTEXT.md
+│       └── docs/adr/
+```
+
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+## During the session
+
+### Challenge against the glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+
+### Sharpen fuzzy language
+
+When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
+
+### Discuss concrete scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+
+### Cross-reference with code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
+
+### Update CONTEXT.md inline
+
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
diff --git a/.agents/skills/domain-modeling/agents/openai.yaml b/.agents/skills/domain-modeling/agents/openai.yaml
new file mode 100644
index 00000000000..7f1522d2f11
--- /dev/null
+++ b/.agents/skills/domain-modeling/agents/openai.yaml
@@ -0,0 +1,3 @@
+interface:
+  display_name: "Domain Modeling"
+  short_description: "Build and sharpen a domain model"
diff --git a/.agents/skills/grill-me/SKILL.md b/.agents/skills/grill-me/SKILL.md
new file mode 100644
index 00000000000..9470cfcfe23
--- /dev/null
+++ b/.agents/skills/grill-me/SKILL.md
@@ -0,0 +1,7 @@
+---
+name: grill-me
+description: A relentless interview to sharpen a plan or design.
+disable-model-invocation: true
+---
+
+Run a `/grilling` session.
diff --git a/.agents/skills/grill-me/agents/openai.yaml b/.agents/skills/grill-me/agents/openai.yaml
new file mode 100644
index 00000000000..4d6fb0c746c
--- /dev/null
+++ b/.agents/skills/grill-me/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Grill Me"
+  short_description: "Sharpen a plan through interview"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/grill-with-docs/SKILL.md b/.agents/skills/grill-with-docs/SKILL.md
new file mode 100644
index 00000000000..bed05d2bd32
--- /dev/null
+++ b/.agents/skills/grill-with-docs/SKILL.md
@@ -0,0 +1,7 @@
+---
+name: grill-with-docs
+description: A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.
+disable-model-invocation: true
+---
+
+Run a `/grilling` session, using the `/domain-modeling` skill.
diff --git a/.agents/skills/grill-with-docs/agents/openai.yaml b/.agents/skills/grill-with-docs/agents/openai.yaml
new file mode 100644
index 00000000000..5dbe2780a51
--- /dev/null
+++ b/.agents/skills/grill-with-docs/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Grill with Docs"
+  short_description: "Grill a design and write its docs"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/grilling/SKILL.md b/.agents/skills/grilling/SKILL.md
new file mode 100644
index 00000000000..52d8eb3cadd
--- /dev/null
+++ b/.agents/skills/grilling/SKILL.md
@@ -0,0 +1,12 @@
+---
+name: grilling
+description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
+---
+
+Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
+
+If a *fact* can be found by exploring the environment (filesystem, tools, etc.), look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.
+
+Do not act on it until I confirm we have reached a shared understanding.
diff --git a/.agents/skills/grilling/agents/openai.yaml b/.agents/skills/grilling/agents/openai.yaml
new file mode 100644
index 00000000000..85b12607d00
--- /dev/null
+++ b/.agents/skills/grilling/agents/openai.yaml
@@ -0,0 +1,3 @@
+interface:
+  display_name: "Grilling"
+  short_description: "Stress-test thinking one question at a time"
diff --git a/.agents/skills/handoff/SKILL.md b/.agents/skills/handoff/SKILL.md
new file mode 100644
index 00000000000..043d9e13dc7
--- /dev/null
+++ b/.agents/skills/handoff/SKILL.md
@@ -0,0 +1,16 @@
+---
+name: handoff
+description: Compact the current conversation into a handoff document for another agent to pick up.
+argument-hint: "What will the next session be used for?"
+disable-model-invocation: true
+---
+
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
+
+Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
+
+Do not duplicate content already captured in other artifacts (specs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
+
+Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
+
+If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.
diff --git a/.agents/skills/handoff/agents/openai.yaml b/.agents/skills/handoff/agents/openai.yaml
new file mode 100644
index 00000000000..6e1d8da121b
--- /dev/null
+++ b/.agents/skills/handoff/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Handoff"
+  short_description: "Compact a conversation into a handoff"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/implement/SKILL.md b/.agents/skills/implement/SKILL.md
new file mode 100644
index 00000000000..7a0b11f5f4f
--- /dev/null
+++ b/.agents/skills/implement/SKILL.md
@@ -0,0 +1,15 @@
+---
+name: implement
+description: "Implement a piece of work based on a spec or set of tickets."
+disable-model-invocation: true
+---
+
+Implement the work described by the user in the spec or tickets.
+
+Use /tdd where possible, at pre-agreed seams.
+
+Run typechecking regularly, single test files regularly, and the full test suite once at the end.
+
+Once done, use /code-review to review the work.
+
+Commit your work to the current branch.
diff --git a/.agents/skills/implement/agents/openai.yaml b/.agents/skills/implement/agents/openai.yaml
new file mode 100644
index 00000000000..f8794dc153b
--- /dev/null
+++ b/.agents/skills/implement/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Implement"
+  short_description: "Build work from a spec or tickets"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/improve-codebase-architecture/HTML-REPORT.md b/.agents/skills/improve-codebase-architecture/HTML-REPORT.md
new file mode 100644
index 00000000000..17f6d2c7b83
--- /dev/null
+++ b/.agents/skills/improve-codebase-architecture/HTML-REPORT.md
@@ -0,0 +1,123 @@
+# HTML Report Format
+
+The architectural review is rendered as a single self-contained HTML file in the OS temp directory. Tailwind and Mermaid both come from CDNs. Mermaid handles graph-shaped diagrams reliably; hand-built divs and inline SVG handle the more editorial visuals (mass diagrams, cross-sections). Mix the two — don't lean on Mermaid for everything, it'll start to look generic.
+
+## Scaffold
+
+```html
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <title>Architecture review — {{repo name}}</title>
+    <script src="https://cdn.tailwindcss.com"></script>
+    <script type="module">
+      import mermaid from "https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs";
+      mermaid.initialize({ startOnLoad: true, theme: "neutral", securityLevel: "loose" });
+    </script>
+    <style>
+      /* small custom layer for things Tailwind doesn't cover cleanly:
+         dashed seam lines, hand-drawn-feeling arrow heads, etc. */
+      .seam { stroke-dasharray: 4 4; }
+      .leak { stroke: #dc2626; }
+      .deep { background: linear-gradient(135deg, #0f172a, #1e293b); }
+    </style>
+  </head>
+  <body class="bg-stone-50 text-slate-900 font-sans">
+    <main class="max-w-5xl mx-auto px-6 py-12 space-y-12">
+      <header>...</header>
+      <section id="candidates" class="space-y-10">...</section>
+      <section id="top-recommendation">...</section>
+    </main>
+  </body>
+</html>
+```
+
+## Header
+
+Repo name, date, and a compact legend: solid box = module, dashed line = seam, red arrow = leakage, thick dark box = deep module. No introduction paragraph — straight into the candidates.
+
+## Candidate card
+
+The diagrams carry the weight. Prose is sparse, plain, and uses the glossary terms (from the `/codebase-design` skill) without ceremony.
+
+Each candidate is one `<article>`:
+
+- **Title** — short, names the deepening (e.g. "Collapse the Order intake pipeline").
+- **Badge row** — recommendation strength (`Strong` = emerald, `Worth exploring` = amber, `Speculative` = slate), plus a tag for the dependency category (`in-process`, `local-substitutable`, `ports & adapters`, `mock`).
+- **Files** — monospaced list, `font-mono text-sm`.
+- **Before / After diagram** — the centrepiece. Two columns, side by side. See patterns below.
+- **Problem** — one sentence. What hurts.
+- **Solution** — one sentence. What changes.
+- **Wins** — bullets, ≤6 words each. e.g. "Tests hit one interface", "Pricing logic stops leaking", "Delete 4 shallow wrappers".
+- **ADR callout** (if applicable) — one line in an amber-tinted box.
+
+No paragraphs of explanation. If the diagram needs a paragraph to be understood, redraw the diagram.
+
+## Diagram patterns
+
+Pick the pattern that fits the candidate. Mix them. Don't make every diagram look the same — variety is part of the point.
+
+### Mermaid graph (the workhorse for dependencies / call flow)
+
+Use a Mermaid `flowchart` or `graph` when the point is "X calls Y calls Z, and look at the mess." Wrap it in a Tailwind-styled card so it doesn't feel parachuted in. Style with classDef to colour leakage edges red and the deep module dark. Sequence diagrams work well for "before: 6 round-trips; after: 1."
+
+```html
+<div class="rounded-lg border border-slate-200 bg-white p-4">
+  <pre class="mermaid">
+    flowchart LR
+      A[OrderHandler] --> B[OrderValidator]
+      B --> C[OrderRepo]
+      C -.leak.-> D[PricingClient]
+      classDef leak stroke:#dc2626,stroke-width:2px;
+      class C,D leak
+  </pre>
+</div>
+```
+
+### Hand-built boxes-and-arrows (when Mermaid's layout fights you)
+
+Modules as `<div>`s with borders and labels. Arrows as inline SVG `<line>` or `<path>` elements positioned absolutely over a relative container. Reach for this when you want the "after" diagram to feel like one thick-bordered deep module with greyed-out internals — Mermaid won't render that with the right weight.
+
+### Cross-section (good for layered shallowness)
+
+Stack horizontal bands (`h-12 border-l-4`) to show layers a call passes through. Before: 6 thin layers each doing nothing. After: 1 thick band labelled with the consolidated responsibility.
+
+### Mass diagram (good for "interface as wide as implementation")
+
+Two rectangles per module — one for interface surface area, one for implementation. Before: interface rectangle is nearly as tall as the implementation rectangle (shallow). After: interface rectangle is short, implementation rectangle is tall (deep).
+
+### Call-graph collapse
+
+Before: a tree of function calls rendered as nested boxes. After: the same tree collapsed into one box, with the now-internal calls shown faded inside it.
+
+## Style guidance
+
+- Lean editorial, not corporate-dashboard. Generous whitespace. Serif optional for headings (`font-serif` works well with stone/slate).
+- Colour sparingly: one accent (emerald or indigo) plus red for leakage and amber for warnings.
+- Keep diagrams ~320px tall so before/after sits comfortably side by side without scrolling.
+- Use `text-xs uppercase tracking-wider` for module labels inside diagrams — they should read as schematic, not as UI.
+- The only scripts are the Tailwind CDN and the Mermaid ESM import. The report is otherwise static — no app code, no interactivity beyond Mermaid's own rendering.
+
+## Top recommendation section
+
+One larger card. Candidate name, one sentence on why, anchor link to its card. That's it.
+
+## Tone
+
+Plain English, concise — but the architectural nouns and verbs come straight from the `/codebase-design` skill. Concision is not an excuse to drift.
+
+**Use exactly:** module, interface, implementation, depth, deep, shallow, seam, adapter, leverage, locality.
+
+**Never substitute:** component, service, unit (for module) · API, signature (for interface) · boundary (for seam) · layer, wrapper (for module, when you mean module).
+
+**Phrasings that fit the style:**
+
+- "Order intake module is shallow — interface nearly matches the implementation."
+- "Pricing leaks across the seam."
+- "Deepen: one interface, one place to test."
+- "Two adapters justify the seam: HTTP in prod, in-memory in tests."
+
+**Wins bullets** name the gain in glossary terms: *"locality: bugs concentrate in one module"*, *"leverage: one interface, N call sites"*, *"interface shrinks; implementation absorbs the wrappers"*. Don't write *"easier to maintain"* or *"cleaner code"* — those terms aren't in the glossary and don't earn their place.
+
+No hedging, no throat-clearing, no "it's worth noting that…". If a sentence could be a bullet, make it a bullet. If a bullet could be cut, cut it. If a term isn't in the `/codebase-design` glossary, reach for one that is before inventing a new one.
diff --git a/.agents/skills/improve-codebase-architecture/SKILL.md b/.agents/skills/improve-codebase-architecture/SKILL.md
new file mode 100644
index 00000000000..b56969e92f0
--- /dev/null
+++ b/.agents/skills/improve-codebase-architecture/SKILL.md
@@ -0,0 +1,71 @@
+---
+name: improve-codebase-architecture
+description: Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
+disable-model-invocation: true
+---
+
+# Improve Codebase Architecture
+
+Surface architectural friction and propose **deepening opportunities** — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.
+
+This command is _informed_ by the project's domain model and built on a shared design vocabulary:
+
+- Run the `/codebase-design` skill for the architecture vocabulary (**module**, **interface**, **depth**, **seam**, **adapter**, **leverage**, **locality**) and its principles (the deletion test, "the interface is the test surface", "one adapter = hypothetical seam, two = real"). Use these terms exactly in every suggestion — don't drift into "component," "service," "API," or "boundary."
+- The domain language in `CONTEXT.md` gives names to good seams; ADRs in `docs/adr/` record decisions this command should not re-litigate.
+
+## Process
+
+### 1. Explore
+
+**Scope before you scan — YAGNI.** Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that have recently changed. Decide *where* to look before you look:
+
+- If the user named a direction — a module, a subsystem, a pain point — take it, and skip the inference below.
+- Otherwise, walk back a good stretch of the commit history (`git log --oneline`) to find the codebase's hot spots — the files and areas that keep coming up — and let those paths pull your attention first. If the changes are scattered with no clear hot spot, widen the net.
+
+Read the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.
+
+Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
+
+- Where does understanding one concept require bouncing between many small modules?
+- Where are modules **shallow** — interface nearly as complex as the implementation?
+- Where have pure functions been extracted just for testability, but the real bugs hide in how they're called (no **locality**)?
+- Where do tightly-coupled modules leak across their seams?
+- Which parts of the codebase are untested, or hard to test through their current interface?
+
+Apply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A "yes, concentrates" is the signal you want.
+
+### 2. Present candidates as an HTML report
+
+Write a self-contained HTML file to the OS temp directory so nothing lands in the repo. Resolve the temp dir from `$TMPDIR`, falling back to `/tmp` (or `%TEMP%` on Windows), and write to `<tmpdir>/architecture-review-<timestamp>.html` so each run gets a fresh file. Open it for the user — `xdg-open <path>` on Linux, `open <path>` on macOS, `start <path>` on Windows — and tell them the absolute path.
+
+The report uses **Tailwind via CDN** for layout and styling, and **Mermaid via CDN** for diagrams where a graph/flow/sequence reliably communicates the structure. Mix Mermaid with hand-crafted CSS/SVG visuals — use Mermaid when relationships are graph-shaped (call graphs, dependencies, sequences), and hand-built divs/SVG when you want something more editorial (mass diagrams, cross-sections, collapse animations). Each candidate gets a **before/after visualisation**. Be visual.
+
+For each candidate, render a card with:
+
+- **Files** — which files/modules are involved
+- **Problem** — why the current architecture is causing friction
+- **Solution** — plain English description of what would change
+- **Benefits** — explained in terms of locality and leverage, and how tests would improve
+- **Before / After diagram** — side-by-side, custom-drawn, illustrating the shallowness and the deepening
+- **Recommendation strength** — one of `Strong`, `Worth exploring`, `Speculative`, rendered as a badge
+
+End the report with a **Top recommendation** section: which candidate you'd tackle first and why.
+
+**Use CONTEXT.md vocabulary for the domain, and the `/codebase-design` vocabulary for the architecture.** If `CONTEXT.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
+
+**ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly in the card (e.g. a warning callout: _"contradicts ADR-0007 — but worth reopening because…"_). Don't list every theoretical refactor an ADR forbids.
+
+See [HTML-REPORT.md](HTML-REPORT.md) for the full HTML scaffold, diagram patterns, and styling guidance.
+
+Do NOT propose interfaces yet. After the file is written, ask the user: "Which of these would you like to explore?"
+
+### 3. Grilling loop
+
+Once the user picks a candidate, run the `/grilling` skill to walk the decision tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, what tests survive.
+
+Side effects happen inline as decisions crystallize — run the `/domain-modeling` skill to keep the domain model current as you go:
+
+- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md`. Create the file lazily if it doesn't exist.
+- **Sharpening a fuzzy term during the conversation?** Update `CONTEXT.md` right there.
+- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones.
+- **Want to explore alternative interfaces for the deepened module?** Run the `/codebase-design` skill and use its design-it-twice parallel sub-agent pattern.
diff --git a/.agents/skills/improve-codebase-architecture/agents/openai.yaml b/.agents/skills/improve-codebase-architecture/agents/openai.yaml
new file mode 100644
index 00000000000..706fdca096d
--- /dev/null
+++ b/.agents/skills/improve-codebase-architecture/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Improve Codebase Architecture"
+  short_description: "Find and grill architecture improvements"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/prototype/LOGIC.md b/.agents/skills/prototype/LOGIC.md
new file mode 100644
index 00000000000..fe9a2c29f77
--- /dev/null
+++ b/.agents/skills/prototype/LOGIC.md
@@ -0,0 +1,79 @@
+# Logic Prototype
+
+A tiny interactive terminal app that lets the user drive a state model by hand. Use this when the question is about **business logic, state transitions, or data shape** — the kind of thing that looks reasonable on paper but only feels wrong once you push it through real cases.
+
+## When this is the right shape
+
+- "I'm not sure if this state machine handles the edge case where X then Y."
+- "Does this data model actually let me represent the case where..."
+- "I want to feel out what the API should look like before writing it."
+- Anything where the user wants to **press buttons and watch state change**.
+
+If the question is "what should this look like" — wrong branch. Use [UI.md](UI.md).
+
+## Process
+
+### 1. State the question
+
+Before writing code, write down what state model and what question you're prototyping. One paragraph, in the prototype's README or a comment at the top of the file. A logic prototype that answers the wrong question is pure waste — make the question explicit so it can be checked later, whether the user is watching now or returning to it AFK.
+
+### 2. Pick the language
+
+Use whatever the host project uses. If the project has no obvious runtime (e.g. a docs repo), ask.
+
+Match the project's existing conventions for tooling — don't add a new package manager or runtime just for the prototype.
+
+### 3. Isolate the logic in a portable module
+
+Put the actual logic — the bit that's answering the question — behind a small, pure interface that could be lifted out and dropped into the real codebase later. The TUI around it is throwaway; the logic module shouldn't be.
+
+The right shape depends on the question:
+
+- **A pure reducer** — `(state, action) => state`. Good when actions are discrete events and state is a single value.
+- **A state machine** — explicit states and transitions. Good when "which actions are even legal right now" is part of the question.
+- **A small set of pure functions** over a plain data type. Good when there's no implicit current state — just transformations.
+- **A class or module with a clear method surface** when the logic genuinely owns ongoing internal state.
+
+Pick whichever shape best fits the question being asked, *not* whichever is easiest to wire to a TUI. Keep it pure: no I/O, no terminal code, no `console.log` for control flow. The TUI imports it and calls into it; nothing flows the other direction.
+
+This is what makes the prototype useful past its own lifetime: when the question's been answered, the validated reducer / machine / function set can be lifted into the real module on its own.
+
+### 4. Build the smallest TUI that exposes the state
+
+Build it as a **lightweight TUI** — on every tick, clear the screen (`console.clear()` / `print("\033[2J\033[H")` / equivalent) and re-render the whole frame. The user should always see one stable view, not an ever-growing scrollback.
+
+Each frame has two parts, in this order:
+
+1. **Current state**, pretty-printed and diff-friendly (one field per line, or formatted JSON). Use **bold** for field names or section headers and **dim** for less important context (timestamps, IDs, derived values). Native ANSI escape codes are fine — `\x1b[1m` bold, `\x1b[2m` dim, `\x1b[0m` reset. No need to pull in a styling library unless one is already in the project.
+2. **Keyboard shortcuts**, listed at the bottom: `[a] add user  [d] delete user  [t] tick clock  [q] quit`. Bold the key, dim the description, or vice-versa — whatever reads cleanly.
+
+Behaviour:
+
+1. **Initialise state** — a single in-memory object/struct. Render the first frame on start.
+2. **Read one keystroke (or one line)** at a time, dispatch to a handler that mutates state.
+3. **Re-render** the full frame after every action — don't append, replace.
+4. **Loop until quit.**
+
+The whole frame should fit on one screen.
+
+### 5. Make it runnable in one command
+
+Add a script to the project's existing task runner (`package.json` scripts, `Makefile`, `justfile`, `pyproject.toml`). The user should run `pnpm run <prototype-name>` or equivalent — never need to remember a path.
+
+If the host project has no task runner, just put the command at the top of the prototype's README.
+
+### 6. Hand it over
+
+Give the user the run command. They'll drive it themselves; the interesting moments are when they say "wait, that shouldn't be possible" or "huh, I assumed X would be different" — those are the bugs in the _idea_, which is the whole point. If they want new actions added, add them. Prototypes evolve.
+
+### 7. Capture the answer and the prototype
+
+Once the prototype has answered its question, capture the answer, then capture the prototype the way the [SKILL](SKILL.md) describes. The logic-specific mapping: the validated reducer / machine / function set lifts into the real module (the decision, absorbed); the TUI shell rides along to the throwaway branch that keeps the prototype as a primary source.
+
+## Anti-patterns
+
+- **Don't add tests.** A prototype that needs tests is no longer a prototype.
+- **Don't wire it to the real database.** Use an in-memory store unless the question is specifically about persistence.
+- **Don't generalise.** No "what if we wanted to support X later." The prototype answers one question.
+- **Don't blur the logic and the TUI together.** If the reducer / state machine references `console.log`, prompts, or terminal escape codes, it's no longer portable. Keep the TUI as a thin shell over a pure module.
+- **Don't ship the TUI shell into production.** The shell is optimised for being driven by hand from a terminal. The logic module behind it is the bit worth keeping.
diff --git a/.agents/skills/prototype/SKILL.md b/.agents/skills/prototype/SKILL.md
new file mode 100644
index 00000000000..e75d5331cef
--- /dev/null
+++ b/.agents/skills/prototype/SKILL.md
@@ -0,0 +1,26 @@
+---
+name: prototype
+description: Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
+---
+
+# Prototype
+
+A prototype is **throwaway code that answers a question**. The question decides the shape.
+
+## Pick a branch
+
+Identify which question is being answered — from the user's prompt, the surrounding code, or by asking if the user is around:
+
+- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper.
+- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.
+
+The two branches produce very different artifacts — getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.
+
+## Rules that apply to both
+
+1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
+2. **One command to run.** Whatever the project's existing task runner supports — `pnpm <name>`, `python <path>`, `bun <path>`, etc. The user must be able to start it without thinking.
+3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
+4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast.
+5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
+6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: commit it to a throwaway branch, out of main, and leave a context pointer to that branch on the implementation issue. Capture the answer too — the verdict and the question it settled — in the issue or a commit. The main branch keeps only the validated decision.
diff --git a/.agents/skills/prototype/UI.md b/.agents/skills/prototype/UI.md
new file mode 100644
index 00000000000..76c0f6012b0
--- /dev/null
+++ b/.agents/skills/prototype/UI.md
@@ -0,0 +1,112 @@
+# UI Prototype
+
+Generate **several radically different UI variations** on a single route, switchable from a floating bottom bar. The user flips between variants in the browser, picks one (or steals bits from each), then throws the rest away.
+
+If the question is about logic/state rather than what something looks like — wrong branch. Use [LOGIC.md](LOGIC.md).
+
+## When this is the right shape
+
+- "What should this page look like?"
+- "I want to see a few options for this dashboard before committing."
+- "Try a different layout for the settings screen."
+- Any time the user would otherwise spend a day picking between three vague mockups in their head.
+
+## Two sub-shapes — strongly prefer sub-shape A
+
+A UI prototype is much easier to judge when it's **butting up against the rest of the app** — real header, real sidebar, real data, real density. A throwaway route on its own is a vacuum: every variant looks fine in isolation. Default to sub-shape A whenever there's a plausible existing page to host the variants. Only reach for sub-shape B if the prototype genuinely has no nearby home.
+
+### Sub-shape A — adjustment to an existing page (preferred)
+
+The route already exists. Variants are rendered **on the same route**, gated by a `?variant=` URL search param. The existing data fetching, params, and auth all stay — only the rendering swaps. This is the default; pick it unless there's a specific reason not to.
+
+If the prototype is for something that doesn't yet have a page but *would naturally live inside one* (a new section of the dashboard, a new card on the settings screen, a new step in an existing flow) — that's still sub-shape A. Mount the variants inside the host page.
+
+### Sub-shape B — a new page (last resort)
+
+Only use this when the thing being prototyped genuinely has no existing page to live inside — e.g. an entirely new top-level surface, or a flow that can't be embedded anywhere sensible.
+
+Create a **throwaway route** following whatever routing convention the project already uses — don't invent a new top-level structure. Name it so it's obviously a prototype (e.g. include the word `prototype` in the path or filename). Same `?variant=` pattern.
+
+Before committing to sub-shape B, sanity-check: is there really no existing page this could be embedded in? An empty route hides design problems that a populated one would expose.
+
+In both sub-shapes the floating bottom bar is identical.
+
+## Process
+
+### 1. State the question and pick N
+
+Default to **3 variants**. More than 5 stops being radically different and starts being noise — cap there.
+
+Write down the plan in one line, in the prototype's location or a top-of-file comment:
+
+> "Three variants of the settings page, switchable via `?variant=`, on the existing `/settings` route."
+
+This works whether the user is here to push back or not.
+
+### 2. Generate radically different variants
+
+Draft each variant. Hold each one to:
+
+- The page's purpose and the data it has access to.
+- The project's component library / styling system (TailwindCSS, shadcn, MUI, plain CSS, whatever).
+- A clear exported component name, e.g. `VariantA`, `VariantB`, `VariantC`.
+
+Variants must be **structurally different** — different layout, different information hierarchy, different primary affordance, not just different colours. Three slightly-tweaked card grids isn't a UI prototype, it's wallpaper. If two drafts come out too similar, redo one with explicit "do not use a card grid" guidance.
+
+### 3. Wire them together
+
+Create a single switcher component on the route:
+
+```tsx
+// pseudo-code — adapt to the project's framework
+const variant = searchParams.get('variant') ?? 'A';
+return (
+  <>
+    {variant === 'A' && <VariantA {...data} />}
+    {variant === 'B' && <VariantB {...data} />}
+    {variant === 'C' && <VariantC {...data} />}
+    <PrototypeSwitcher variants={['A','B','C']} current={variant} />
+  </>
+);
+```
+
+For sub-shape A (existing page): keep all the existing data fetching above the switcher; only the rendered subtree changes per variant.
+
+For sub-shape B (new page): the throwaway route under `/prototype/<name>` mounts the same switcher.
+
+### 4. Build the floating switcher
+
+A small fixed-position bar at the bottom-centre of the screen with three pieces:
+
+- **Left arrow** — cycles to the previous variant (wraps around).
+- **Variant label** — shows the current variant key and, if the variant exports a name, that name too. e.g. `B — Sidebar layout`.
+- **Right arrow** — cycles forward (wraps around).
+
+Behaviour:
+
+- Clicking an arrow updates the URL search param (use the framework's router — `router.replace` on Next, `navigate` on React Router, etc) so the variant is shareable and reload-stable.
+- Keyboard: `←` and `→` arrow keys also cycle. Don't intercept arrow keys when an `<input>`, `<textarea>`, or `[contenteditable]` is focused.
+- Visually distinct from the page (e.g. high-contrast pill, subtle shadow) so it's obviously not part of the design being evaluated.
+- Hidden in production builds — gate on `process.env.NODE_ENV !== 'production'` or an equivalent check, so a stray prototype merge can't ship the bar to users.
+
+Put the switcher in a single shared component so both sub-shapes can reuse it. Locate it wherever shared UI lives in the project.
+
+### 5. Hand it over
+
+Surface the URL (and the `?variant=` keys). The user will flip through whenever they get to it. The interesting feedback is usually **"I want the header from B with the sidebar from C"** — that's the actual design they want.
+
+### 6. Capture the answer and clean up
+
+Once a variant has won, capture the answer — which variant and why — then capture the prototype the way the [SKILL](SKILL.md) describes. Fold the winner into the real code and move the rest onto the throwaway branch, not into main:
+
+- **Sub-shape A** — fold the winner into the existing page; drop the losing variants and the switcher from main.
+- **Sub-shape B** — promote the winning variant to a real route; drop the throwaway route and the switcher from main.
+
+The full set of variants is the primary source, so it lands on the throwaway branch, not the bin — variant components and the switcher left in the main branch rot fast and confuse the next reader.
+
+## Anti-patterns
+
+- **Variants that differ only in colour or copy.** That's a tweak, not a prototype. Real variants disagree about structure.
+- **Sharing too much code between variants.** A shared `<Header>` is fine; a shared `<Layout>` defeats the point. Each variant should be free to throw out the layout.
+- **Wiring variants to real mutations.** Read-only prototypes are fine. If a variant needs to mutate, point it at a stub — the question is "what should this look like", not "does the backend work".
+- **Promoting the prototype directly to production.** The variant code was written under prototype constraints (no tests, minimal error handling). Rewrite it properly when you fold it in.
diff --git a/.agents/skills/prototype/agents/openai.yaml b/.agents/skills/prototype/agents/openai.yaml
new file mode 100644
index 00000000000..1618b147965
--- /dev/null
+++ b/.agents/skills/prototype/agents/openai.yaml
@@ -0,0 +1,3 @@
+interface:
+  display_name: "Prototype"
+  short_description: "Prototype to answer a design question"
diff --git a/.agents/skills/research/SKILL.md b/.agents/skills/research/SKILL.md
new file mode 100644
index 00000000000..0ba594a07f3
--- /dev/null
+++ b/.agents/skills/research/SKILL.md
@@ -0,0 +1,12 @@
+---
+name: research
+description: Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.
+---
+
+Spin up a **background agent** to do the research, so you keep working while it reads.
+
+Its job:
+
+1. Investigate the question against **primary sources** — official docs, source code, specs, first-party APIs — not a secondary write-up of them. Follow every claim back to the source that owns it.
+2. Write the findings to a single Markdown file, citing each claim's source.
+3. Save it where the repo already keeps such notes; match the existing convention, and if there is none, put it somewhere sensible and say where.
diff --git a/.agents/skills/research/agents/openai.yaml b/.agents/skills/research/agents/openai.yaml
new file mode 100644
index 00000000000..e18b96ca0cc
--- /dev/null
+++ b/.agents/skills/research/agents/openai.yaml
@@ -0,0 +1,3 @@
+interface:
+  display_name: "Research"
+  short_description: "Research from high-trust sources"
diff --git a/.agents/skills/resolving-merge-conflicts/SKILL.md b/.agents/skills/resolving-merge-conflicts/SKILL.md
new file mode 100644
index 00000000000..aadb3fcb1df
--- /dev/null
+++ b/.agents/skills/resolving-merge-conflicts/SKILL.md
@@ -0,0 +1,14 @@
+---
+name: resolving-merge-conflicts
+description: "Use when you need to resolve an in-progress git merge/rebase conflict."
+---
+
+1. **See the current state** of the merge/rebase. Check git history, and the conflicting files.
+
+2. **Find the primary sources** for each conflict. Understand deeply why each change was made, and what the original intent was. Read the commit messages, check the PRs, check original issues/tickets.
+
+3. **Resolve each hunk.** Preserve both intents where possible. Where incompatible, pick the one matching the merge's stated goal and note the trade-off. Do **not** invent new behaviour. Always resolve; never `--abort`.
+
+4. Discover the project's **automated checks** and run them — typically typecheck, then tests, then format. Fix anything the merge broke.
+
+5. **Finish the merge/rebase.** Stage everything and commit. If rebasing, continue the rebase process until all commits are rebased.
diff --git a/.agents/skills/resolving-merge-conflicts/agents/openai.yaml b/.agents/skills/resolving-merge-conflicts/agents/openai.yaml
new file mode 100644
index 00000000000..331ffb9d389
--- /dev/null
+++ b/.agents/skills/resolving-merge-conflicts/agents/openai.yaml
@@ -0,0 +1,3 @@
+interface:
+  display_name: "Resolving Merge Conflicts"
+  short_description: "Resolve merge and rebase conflicts"
diff --git a/.agents/skills/setup-matt-pocock-skills/SKILL.md b/.agents/skills/setup-matt-pocock-skills/SKILL.md
new file mode 100644
index 00000000000..aecf855317d
--- /dev/null
+++ b/.agents/skills/setup-matt-pocock-skills/SKILL.md
@@ -0,0 +1,116 @@
+---
+name: setup-matt-pocock-skills
+description: Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.
+disable-model-invocation: true
+---
+
+# Setup Matt Pocock's Skills
+
+Scaffold the per-repo configuration that the engineering skills assume:
+
+- **Issue tracker** — where issues live (GitHub by default; local markdown is also supported out of the box)
+- **Triage labels** — the strings used for the five canonical triage roles
+- **Domain docs** — where `CONTEXT.md` and ADRs live, and the consumer rules for reading them
+
+This is a prompt-driven skill, not a deterministic script. Explore, present what you found, confirm with the user, then write.
+
+## Process
+
+### 1. Explore
+
+Look at the current repo to understand its starting state. Read whatever exists; don't assume:
+
+- `git remote -v` and `.git/config` — is this a GitHub repo? Which one?
+- `AGENTS.md` and `CLAUDE.md` at the repo root — does either exist? Is there already an `## Agent skills` section in either?
+- `CONTEXT.md` and `CONTEXT-MAP.md` at the repo root
+- `docs/adr/` and any `src/*/docs/adr/` directories
+- `docs/agents/` — does this skill's prior output already exist?
+- `.scratch/` — sign that a local-markdown issue tracker convention is already in use
+- Is the `triage` skill installed? (a `triage` skill folder alongside this one, or `triage` in your available skills.) This decides whether Section B runs at all.
+- Monorepo signals — a `pnpm-workspace.yaml`, a `workspaces` field in `package.json`, or a populated `packages/*` with its own `src/`. Present only in a genuinely large multi-package repo; their absence means single-context, which is almost every repo.
+
+### 2. Present findings and ask
+
+Summarise what's present and what's missing. Then take the sections in order — one section, one answer, then the next.
+
+Lead each section with the recommended answer so the user can accept it in a word. Give a one-line explainer only when the choice genuinely branches; skip the section entirely when exploration already settled it (Section B when `triage` isn't installed, Section C when there's no monorepo).
+
+**Section A — Issue tracker.**
+
+> Explainer: The "issue tracker" is where issues live for this repo. Skills like `to-tickets`, `triage`, `to-spec`, and `qa` read from and write to it — they need to know whether to call `gh issue create`, write a markdown file under `.scratch/`, or follow some other workflow you describe. Pick the place you actually track work for this repo.
+
+Default posture: these skills were designed for GitHub. If a `git remote` points at GitHub, propose that. If a `git remote` points at GitLab (`gitlab.com` or a self-hosted host), propose GitLab. Otherwise (or if the user prefers), offer:
+
+- **GitHub** — issues live in the repo's GitHub Issues (uses the `gh` CLI)
+- **GitLab** — issues live in the repo's GitLab Issues (uses the [`glab`](https://gitlab.com/gitlab-org/cli) CLI)
+- **Local markdown** — issues live as files under `.scratch/<feature>/` in this repo (good for solo projects or repos without a remote)
+- **Other** (Jira, Linear, etc.) — ask the user to describe the workflow in one paragraph; the skill will record it as freeform prose
+
+Record the choice in `docs/agents/issue-tracker.md`. The GitHub and GitLab templates carry a "PRs as a request surface" flag, defaulted **off** — leave it off and don't raise it; a user who wants external PRs in the triage queue can flip the flag in the file later.
+
+**Section B — Triage label vocabulary.** Skip this section entirely if the `triage` skill isn't installed (exploration told you) — an uninstalled skill needs no labels.
+
+If it is installed, ask exactly one question:
+
+> Do you want to keep the default triage labels? (recommended: **yes**)
+
+The defaults are the five canonical roles, each label string equal to its name: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`. On **yes**, write them as-is. Only if the user says no — usually because their tracker already uses other names (e.g. `bug:triage` for `needs-triage`) — collect the overrides so `triage` applies existing labels instead of creating duplicates.
+
+**Section C — Domain docs.** Default to **single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root. This fits almost every repo; write it without asking.
+
+Offer **multi-context** — a root `CONTEXT-MAP.md` pointing to per-context `CONTEXT.md` files — only when exploration found monorepo signals. Then confirm which layout they want.
+
+### 3. Confirm and edit
+
+Show the user a draft of:
+
+- The `## Agent skills` block to add to whichever of `CLAUDE.md` / `AGENTS.md` is being edited (see step 4 for selection rules)
+- The contents of `docs/agents/issue-tracker.md`, `docs/agents/domain.md`, and `docs/agents/triage-labels.md` (the last only when `triage` is installed)
+
+Let them edit before writing.
+
+### 4. Write
+
+**Pick the file to edit:**
+
+- If `CLAUDE.md` exists, edit it.
+- Else if `AGENTS.md` exists, edit it.
+- If neither exists, ask the user which one to create — don't pick for them.
+
+Never create `AGENTS.md` when `CLAUDE.md` already exists (or vice versa) — always edit the one that's already there.
+
+If an `## Agent skills` block already exists in the chosen file, update its contents in-place rather than appending a duplicate. Don't overwrite user edits to the surrounding sections.
+
+The block:
+
+```markdown
+## Agent skills
+
+### Issue tracker
+
+[one-line summary of where issues are tracked]. See `docs/agents/issue-tracker.md`.
+
+### Triage labels
+
+[one-line summary of the label vocabulary]. See `docs/agents/triage-labels.md`.
+
+### Domain docs
+
+[one-line summary of layout — "single-context" or "multi-context"]. See `docs/agents/domain.md`.
+```
+
+Include the `### Triage labels` sub-block, and write `docs/agents/triage-labels.md`, only when `triage` is installed and Section B ran. When it isn't, both are omitted.
+
+Then write the docs files using the seed templates in this skill folder as a starting point:
+
+- [issue-tracker-github.md](./issue-tracker-github.md) — GitHub issue tracker
+- [issue-tracker-gitlab.md](./issue-tracker-gitlab.md) — GitLab issue tracker
+- [issue-tracker-local.md](./issue-tracker-local.md) — local-markdown issue tracker
+- [triage-labels.md](./triage-labels.md) — label mapping (only if `triage` is installed)
+- [domain.md](./domain.md) — domain doc consumer rules + layout
+
+For "other" issue trackers, write `docs/agents/issue-tracker.md` from scratch using the user's description.
+
+### 5. Done
+
+Tell the user the setup is complete and which engineering skills will now read from these files. Mention they can edit `docs/agents/*.md` directly later — re-running this skill is only necessary if they want to switch issue trackers or restart from scratch.
diff --git a/.agents/skills/setup-matt-pocock-skills/agents/openai.yaml b/.agents/skills/setup-matt-pocock-skills/agents/openai.yaml
new file mode 100644
index 00000000000..65a0da8128c
--- /dev/null
+++ b/.agents/skills/setup-matt-pocock-skills/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Setup Matt Pocock Skills"
+  short_description: "Configure a repo for the skills"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/setup-matt-pocock-skills/domain.md b/.agents/skills/setup-matt-pocock-skills/domain.md
new file mode 100644
index 00000000000..b548c538d60
--- /dev/null
+++ b/.agents/skills/setup-matt-pocock-skills/domain.md
@@ -0,0 +1,51 @@
+# Domain Docs
+
+How the engineering skills should consume this repo's domain documentation when exploring the codebase.
+
+## Before exploring, read these
+
+- **`CONTEXT.md`** at the repo root, or
+- **`CONTEXT-MAP.md`** at the repo root if it exists — it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
+- **`docs/adr/`** — read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
+
+If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `/domain-modeling` skill (reached via `/grill-with-docs` and `/improve-codebase-architecture`) creates them lazily when terms or decisions actually get resolved.
+
+## File structure
+
+Single-context repo (most repos):
+
+```
+/
+├── CONTEXT.md
+├── docs/adr/
+│   ├── 0001-event-sourced-orders.md
+│   └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+Multi-context repo (presence of `CONTEXT-MAP.md` at the root):
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/adr/                          ← system-wide decisions
+└── src/
+    ├── ordering/
+    │   ├── CONTEXT.md
+    │   └── docs/adr/                  ← context-specific decisions
+    └── billing/
+        ├── CONTEXT.md
+        └── docs/adr/
+```
+
+## Use the glossary's vocabulary
+
+When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
+
+If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
+
+## Flag ADR conflicts
+
+If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
+
+> _Contradicts ADR-0007 (event-sourced orders) — but worth reopening because…_
diff --git a/.agents/skills/setup-matt-pocock-skills/issue-tracker-github.md b/.agents/skills/setup-matt-pocock-skills/issue-tracker-github.md
new file mode 100644
index 00000000000..82cfbf5b191
--- /dev/null
+++ b/.agents/skills/setup-matt-pocock-skills/issue-tracker-github.md
@@ -0,0 +1,45 @@
+# Issue tracker: GitHub
+
+Issues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.
+
+## Conventions
+
+- **Create an issue**: `gh issue create --title "..." --body "..."`. Use a heredoc for multi-line bodies.
+- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.
+- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.
+- **Comment on an issue**: `gh issue comment <number> --body "..."`
+- **Apply / remove labels**: `gh issue edit <number> --add-label "..."` / `--remove-label "..."`
+- **Close**: `gh issue close <number> --comment "..."`
+
+Infer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.
+
+## Pull requests as a triage surface
+
+**PRs as a request surface: no.** _(Set to `yes` if this repo treats external PRs as feature requests; `/triage` reads this flag.)_
+
+When set to `yes`, PRs run through the same labels and states as issues, using the `gh pr` equivalents:
+
+- **Read a PR**: `gh pr view <number> --comments` and `gh pr diff <number>` for the diff.
+- **List external PRs for triage**: `gh pr list --state open --json number,title,body,labels,author,authorAssociation,comments` then keep only `authorAssociation` of `CONTRIBUTOR`, `FIRST_TIME_CONTRIBUTOR`, or `NONE` (drop `OWNER`/`MEMBER`/`COLLABORATOR`).
+- **Comment / label / close**: `gh pr comment`, `gh pr edit --add-label`/`--remove-label`, `gh pr close`.
+
+GitHub shares one number space across issues and PRs, so a bare `#42` may be either — resolve with `gh pr view 42` and fall back to `gh issue view 42`.
+
+## When a skill says "publish to the issue tracker"
+
+Create a GitHub issue.
+
+## When a skill says "fetch the relevant ticket"
+
+Run `gh issue view <number> --comments`.
+
+## Wayfinding operations
+
+Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
+
+- **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. `gh issue create --label wayfinder:map`.
+- **Child ticket**: an issue linked to the map as a GitHub sub-issue (`gh api` on the sub-issues endpoint). Where sub-issues aren't enabled, add the child to a task list in the map body and put `Part of #<map>` at the top of the child body. Labels: `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
+- **Blocking**: GitHub's **native issue dependencies** — the canonical, UI-visible representation. Add an edge with `gh api --method POST repos/<owner>/<repo>/issues/<child>/dependencies/blocked_by -F issue_id=<blocker-db-id>`, where `<blocker-db-id>` is the blocker's numeric **database id** (`gh api repos/<owner>/<repo>/issues/<n> --jq .id`, _not_ the `#number` or `node_id`). GitHub reports `issue_dependencies_summary.blocked_by` (open blockers only — the live gate). Where dependencies aren't available, fall back to a `Blocked by: #<n>, #<n>` line at the top of the child body. A ticket is unblocked when every blocker is closed.
+- **Frontier query**: list the map's open children (`gh issue list --state open`, scoped to the map's sub-issues / task list), drop any with an open blocker (`issue_dependencies_summary.blocked_by > 0`, or an open issue in the `Blocked by` line) or an assignee; first in map order wins.
+- **Claim**: `gh issue edit <n> --add-assignee @me` — the session's first write.
+- **Resolve**: `gh issue comment <n> --body "<answer>"`, then `gh issue close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.
diff --git a/.agents/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md b/.agents/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md
new file mode 100644
index 00000000000..8a54714a16d
--- /dev/null
+++ b/.agents/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md
@@ -0,0 +1,46 @@
+# Issue tracker: GitLab
+
+Issues and PRDs for this repo live as GitLab issues. Use the [`glab`](https://gitlab.com/gitlab-org/cli) CLI for all operations.
+
+## Conventions
+
+- **Create an issue**: `glab issue create --title "..." --description "..."`. Use a heredoc for multi-line descriptions. Pass `--description -` to open an editor.
+- **Read an issue**: `glab issue view <number> --comments`. Use `-F json` for machine-readable output.
+- **List issues**: `glab issue list -F json` with appropriate `--label` filters.
+- **Comment on an issue**: `glab issue note <number> --message "..."`. GitLab calls comments "notes".
+- **Apply / remove labels**: `glab issue update <number> --label "..."` / `--unlabel "..."`. Multiple labels can be comma-separated or by repeating the flag.
+- **Close**: `glab issue close <number>`. `glab issue close` does not accept a closing comment, so post the explanation first with `glab issue note <number> --message "..."`, then close.
+- **Merge requests**: GitLab calls PRs "merge requests". Use `glab mr create`, `glab mr view`, `glab mr note`, etc. — the same shape as `gh pr ...` with `mr` in place of `pr` and `note`/`--message` in place of `comment`/`--body`.
+
+Infer the repo from `git remote -v` — `glab` does this automatically when run inside a clone.
+
+## Merge requests as a triage surface
+
+**MRs as a request surface: no.** _(Set to `yes` if this repo treats external merge requests as feature requests; `/triage` reads this flag.)_
+
+When set to `yes`, MRs run through the same labels and states as issues, using the `glab mr` equivalents:
+
+- **Read an MR**: `glab mr view <number> --comments` and `glab mr diff <number>` for the diff.
+- **List external MRs for triage**: `glab mr list -F json`, then keep only MRs whose author is not a project member/owner (a contributor's MR, not a maintainer's in-flight work).
+- **Comment / label / close**: `glab mr note`, `glab mr update --label`/`--unlabel`, `glab mr close`.
+
+Unlike GitHub, GitLab numbers issues and MRs separately, so `#42` is unambiguous once you know which surface the maintainer means.
+
+## When a skill says "publish to the issue tracker"
+
+Create a GitLab issue.
+
+## When a skill says "fetch the relevant ticket"
+
+Run `glab issue view <number> --comments`.
+
+## Wayfinding operations
+
+Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
+
+- **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. `glab issue create --label wayfinder:map`. (On GitLab tiers with native epics, an epic may hold the map instead; a labelled issue works everywhere.)
+- **Child ticket**: an issue carrying `Part of #<map>` at the top of its description and labels `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
+- **Blocking**: GitLab's **native blocking link** — the canonical, UI-visible representation. Add it with the `/blocked_by #<n>` quick action, posted as a note (`glab issue note <child> --message "/blocked_by #<blocker>"`). Native blocking links are a Premium/Ultimate feature; on the free tier (or where unavailable) fall back to a `Blocked by: #<n>, #<n>` line at the top of the description. A ticket is unblocked when every blocker is closed.
+- **Frontier query**: `glab issue list -F json` scoped to the map's children, drop any with an open blocker — a native `blocked_by` link to an open issue (`glab api projects/:id/issues/:iid/links`), or an open issue in the `Blocked by` line — or an assignee; first in map order wins.
+- **Claim**: `glab issue update <n> --assignee @me` — the session's first write.
+- **Resolve**: `glab issue note <n> --message "<answer>"`, then `glab issue close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.
diff --git a/.agents/skills/setup-matt-pocock-skills/issue-tracker-local.md b/.agents/skills/setup-matt-pocock-skills/issue-tracker-local.md
new file mode 100644
index 00000000000..6b124b36719
--- /dev/null
+++ b/.agents/skills/setup-matt-pocock-skills/issue-tracker-local.md
@@ -0,0 +1,30 @@
+# Issue tracker: Local Markdown
+
+Issues and specs (you may know a spec as a PRD) for this repo live as markdown files in `.scratch/`.
+
+## Conventions
+
+- One feature per directory: `.scratch/<feature-slug>/`
+- The spec is `.scratch/<feature-slug>/spec.md`
+- Implementation issues are one file per ticket at `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01` — never a single combined tickets file
+- Triage state is recorded as a `Status:` line near the top of each issue file (see `triage-labels.md` for the role strings)
+- Comments and conversation history append to the bottom of the file under a `## Comments` heading
+
+## When a skill says "publish to the issue tracker"
+
+Create a new file under `.scratch/<feature-slug>/` (creating the directory if needed).
+
+## When a skill says "fetch the relevant ticket"
+
+Read the file at the referenced path. The user will normally pass the path or the issue number directly.
+
+## Wayfinding operations
+
+Used by `/wayfinder`. The **map** is a file with one **child** file per ticket.
+
+- **Map**: `.scratch/<effort>/map.md` — the Notes / Decisions-so-far / Fog body.
+- **Child ticket**: `.scratch/<effort>/issues/NN-<slug>.md`, numbered from `01`, with the question in the body. A `Type:` line records the ticket type (`research`/`prototype`/`grilling`/`task`); a `Status:` line records `claimed`/`resolved`.
+- **Blocking**: a `Blocked by: NN, NN` line near the top. A ticket is unblocked when every file it lists is `resolved`.
+- **Frontier**: scan `.scratch/<effort>/issues/` for files that are open, unblocked, and unclaimed; first by number wins.
+- **Claim**: set `Status: claimed` and save before any work.
+- **Resolve**: append the answer under an `## Answer` heading, set `Status: resolved`, then append a context pointer (gist + link) to the map's Decisions-so-far in `map.md`.
diff --git a/.agents/skills/setup-matt-pocock-skills/triage-labels.md b/.agents/skills/setup-matt-pocock-skills/triage-labels.md
new file mode 100644
index 00000000000..b716855d485
--- /dev/null
+++ b/.agents/skills/setup-matt-pocock-skills/triage-labels.md
@@ -0,0 +1,15 @@
+# Triage Labels
+
+The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
+
+| Label in mattpocock/skills | Label in our tracker | Meaning                                  |
+| -------------------------- | -------------------- | ---------------------------------------- |
+| `needs-triage`             | `needs-triage`       | Maintainer needs to evaluate this issue  |
+| `needs-info`               | `needs-info`         | Waiting on reporter for more information |
+| `ready-for-agent`          | `ready-for-agent`    | Fully specified, ready for an AFK agent  |
+| `ready-for-human`          | `ready-for-human`    | Requires human implementation            |
+| `wontfix`                  | `wontfix`            | Will not be actioned                     |
+
+When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
+
+Edit the right-hand column to match whatever vocabulary you actually use.
diff --git a/.agents/skills/tdd/SKILL.md b/.agents/skills/tdd/SKILL.md
new file mode 100644
index 00000000000..9a2e1d2a1ad
--- /dev/null
+++ b/.agents/skills/tdd/SKILL.md
@@ -0,0 +1,36 @@
+---
+name: tdd
+description: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
+---
+
+# Test-Driven Development
+
+TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.
+
+When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
+
+## What a good test is
+
+Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — "user can checkout with valid cart" tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure.
+
+See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
+
+## Seams — where tests go
+
+A **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.
+
+**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything — agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
+
+Ask: "What's the public interface, and which seams should we test?"
+
+## Anti-patterns
+
+- **Implementation-coupled** — mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
+- **Tautological** — the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth — a known-good literal, a worked example, the spec.
+- **Horizontal slicing** — writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead — one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.
+
+## Rules of the loop
+
+- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
+- **One slice at a time.** One seam, one test, one minimal implementation per cycle.
+- **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.
diff --git a/.agents/skills/tdd/agents/openai.yaml b/.agents/skills/tdd/agents/openai.yaml
new file mode 100644
index 00000000000..651b838a766
--- /dev/null
+++ b/.agents/skills/tdd/agents/openai.yaml
@@ -0,0 +1,3 @@
+interface:
+  display_name: "TDD"
+  short_description: "Test-driven red-green-refactor"
diff --git a/.agents/skills/tdd/mocking.md b/.agents/skills/tdd/mocking.md
new file mode 100644
index 00000000000..71cbfee674d
--- /dev/null
+++ b/.agents/skills/tdd/mocking.md
@@ -0,0 +1,59 @@
+# When to Mock
+
+Mock at **system boundaries** only:
+
+- External APIs (payment, email, etc.)
+- Databases (sometimes - prefer test DB)
+- Time/randomness
+- File system (sometimes)
+
+Don't mock:
+
+- Your own classes/modules
+- Internal collaborators
+- Anything you control
+
+## Designing for Mockability
+
+At system boundaries, design interfaces that are easy to mock:
+
+**1. Use dependency injection**
+
+Pass external dependencies in rather than creating them internally:
+
+```typescript
+// Easy to mock
+function processPayment(order, paymentClient) {
+  return paymentClient.charge(order.total);
+}
+
+// Hard to mock
+function processPayment(order) {
+  const client = new StripeClient(process.env.STRIPE_KEY);
+  return client.charge(order.total);
+}
+```
+
+**2. Prefer SDK-style interfaces over generic fetchers**
+
+Create specific functions for each external operation instead of one generic function with conditional logic:
+
+```typescript
+// GOOD: Each function is independently mockable
+const api = {
+  getUser: (id) => fetch(`/users/${id}`),
+  getOrders: (userId) => fetch(`/users/${userId}/orders`),
+  createOrder: (data) => fetch('/orders', { method: 'POST', body: data }),
+};
+
+// BAD: Mocking requires conditional logic inside the mock
+const api = {
+  fetch: (endpoint, options) => fetch(endpoint, options),
+};
+```
+
+The SDK approach means:
+- Each mock returns one specific shape
+- No conditional logic in test setup
+- Easier to see which endpoints a test exercises
+- Type safety per endpoint
diff --git a/.agents/skills/tdd/tests.md b/.agents/skills/tdd/tests.md
new file mode 100644
index 00000000000..7ab86479f92
--- /dev/null
+++ b/.agents/skills/tdd/tests.md
@@ -0,0 +1,77 @@
+# Good and Bad Tests
+
+## Good Tests
+
+**Integration-style**: Test through real interfaces, not mocks of internal parts.
+
+```typescript
+// GOOD: Tests observable behavior
+test("user can checkout with valid cart", async () => {
+  const cart = createCart();
+  cart.add(product);
+  const result = await checkout(cart, paymentMethod);
+  expect(result.status).toBe("confirmed");
+});
+```
+
+Characteristics:
+
+- Tests behavior users/callers care about
+- Uses public API only
+- Survives internal refactors
+- Describes WHAT, not HOW
+- One logical assertion per test
+
+## Bad Tests
+
+**Implementation-detail tests**: Coupled to internal structure.
+
+```typescript
+// BAD: Tests implementation details
+test("checkout calls paymentService.process", async () => {
+  const mockPayment = jest.mock(paymentService);
+  await checkout(cart, payment);
+  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
+});
+```
+
+Red flags:
+
+- Mocking internal collaborators
+- Testing private methods
+- Asserting on call counts/order
+- Test breaks when refactoring without behavior change
+- Test name describes HOW not WHAT
+- Verifying through external means instead of interface
+
+```typescript
+// BAD: Bypasses interface to verify
+test("createUser saves to database", async () => {
+  await createUser({ name: "Alice" });
+  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
+  expect(row).toBeDefined();
+});
+
+// GOOD: Verifies through interface
+test("createUser makes user retrievable", async () => {
+  const user = await createUser({ name: "Alice" });
+  const retrieved = await getUser(user.id);
+  expect(retrieved.name).toBe("Alice");
+});
+```
+
+**Tautological tests**: Expected value restates the implementation, so the test passes by construction.
+
+```typescript
+// BAD: Expected value is recomputed the way the code computes it
+test("calculateTotal sums line items", () => {
+  const items = [{ price: 10 }, { price: 5 }];
+  const expected = items.reduce((sum, i) => sum + i.price, 0);
+  expect(calculateTotal(items)).toBe(expected);
+});
+
+// GOOD: Expected value is an independent, known literal
+test("calculateTotal sums line items", () => {
+  expect(calculateTotal([{ price: 10 }, { price: 5 }])).toBe(15);
+});
+```
diff --git a/.agents/skills/teach/GLOSSARY-FORMAT.md b/.agents/skills/teach/GLOSSARY-FORMAT.md
new file mode 100644
index 00000000000..9cae84c44c8
--- /dev/null
+++ b/.agents/skills/teach/GLOSSARY-FORMAT.md
@@ -0,0 +1,35 @@
+# GLOSSARY.md Format
+
+`GLOSSARY.md` is the canonical language for this teaching workspace. All explainers, exercises, and learning records should adhere to its terminology. Building it is itself part of learning: compressing a concept into a tight definition is evidence the user understands it.
+
+## Structure
+
+```md
+# {Topic} Glossary
+
+{One or two sentence description of the topic this glossary covers.}
+
+## Terms
+
+**Hypertrophy**:
+Muscle growth driven by mechanical tension and metabolic stress over repeated training sessions.
+_Avoid_: Bulking, getting big
+
+**Progressive overload**:
+Systematically increasing the demand on a muscle over time — via load, volume, or intensity.
+_Avoid_: Pushing harder, levelling up
+
+**RPE (Rate of Perceived Exertion)**:
+A 1–10 self-rating of how hard a set felt, where 10 is failure and 8 means two reps left in the tank.
+_Avoid_: Effort score, intensity rating
+```
+
+## Rules
+
+- **Add a term only when the user understands it.** The glossary is a record of compressed knowledge, not a dictionary the user reads to learn. If the user has just been introduced to a concept, wait until they can use it correctly before promoting it here.
+- **Be opinionated.** When several words exist for the same concept, pick the best one and list the rest as aliases to avoid. This is how language compresses.
+- **Keep definitions tight.** One or two sentences. Define what the term IS, not what it does or how to do it.
+- **Use the glossary's own terms inside definitions.** Once a term is in the glossary, prefer it everywhere — including inside other definitions. This is what makes complex terms easier to grasp later.
+- **Group under subheadings** when natural clusters emerge (e.g. `## Anatomy`, `## Programming`). A flat list is fine when terms cohere.
+- **Flag ambiguities explicitly.** If a term is used loosely in the wider field, note the resolution: "In this workspace, 'set' always means a working set — warm-ups are tracked separately."
+- **Revise as understanding deepens.** A definition the user wrote in week one may be wrong by week six. Update in place; do not leave stale entries.
diff --git a/.agents/skills/teach/LEARNING-RECORD-FORMAT.md b/.agents/skills/teach/LEARNING-RECORD-FORMAT.md
new file mode 100644
index 00000000000..2faa7c98fab
--- /dev/null
+++ b/.agents/skills/teach/LEARNING-RECORD-FORMAT.md
@@ -0,0 +1,46 @@
+# Learning Record Format
+
+Learning records live in `./learning-records/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc. Create the directory lazily — only when the first record is written.
+
+They are the teaching equivalent of ADRs: they capture non-obvious lessons, key insights, and stated prior knowledge that will steer future sessions. They are used to calculate the zone of proximal development.
+
+## Template
+
+```md
+# {Short title of what was learned or established}
+
+{1-3 sentences: what was learned (or what prior knowledge was established), and why it matters for future sessions.}
+```
+
+That is the whole format. A learning record can be a single paragraph. The value is recording _that_ this is now known and _why_ it changes what to teach next — not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most records won't need them.
+
+- **Status** frontmatter (`active | superseded by LR-NNNN`) — useful when an earlier understanding turns out to be wrong and is replaced.
+- **Evidence** — how the user demonstrated the understanding (a question answered, an exercise completed, prior experience cited). Useful when the claim might be revisited.
+- **Implications** — what this unlocks or rules out for future sessions. Worth recording when non-obvious.
+
+## Numbering
+
+Scan `./learning-records/` for the highest existing number and increment by one.
+
+## When to write a learning record
+
+Write one when any of these is true:
+
+1. **The user demonstrated genuine understanding of something non-trivial** — not just exposure, but evidence they can use the concept correctly. This sets a new floor for what to teach next.
+2. **The user disclosed prior knowledge** — "I already know X." Record it so future sessions don't re-teach it. Also record the _depth_ claimed.
+3. **A misconception was corrected** — the user previously believed something wrong and now sees why. These are high-value: they predict future stumbling blocks for related topics.
+4. **The mission shifted in response to learning** — the user discovered they cared about something different than they thought. Cross-link to [[MISSION.md]] and update it.
+
+### What does _not_ qualify
+
+- Material that was merely covered. Coverage is not learning. Wait for evidence.
+- Anything already captured tersely in [[GLOSSARY.md]] as a term definition. Don't duplicate.
+- Session-by-session activity logs. Learning records are not a journal — they are decision-grade insights.
+
+## Supersession
+
+When a later record contradicts an earlier one (the user's understanding deepened or corrected), mark the old record `Status: superseded by LR-NNNN` rather than deleting it. The history of how understanding evolved is itself useful signal.
diff --git a/.agents/skills/teach/MISSION-FORMAT.md b/.agents/skills/teach/MISSION-FORMAT.md
new file mode 100644
index 00000000000..5dac184a319
--- /dev/null
+++ b/.agents/skills/teach/MISSION-FORMAT.md
@@ -0,0 +1,31 @@
+# MISSION.md Format
+
+`MISSION.md` lives at the workspace root. It captures the _reason_ the user is learning this topic. Every teaching decision — what to teach next, which resources to surface, which exercises to design — should trace back to this document.
+
+## Template
+
+```md
+# Mission: {Topic}
+
+## Why
+{1-3 sentences. The concrete real-world goal the user is chasing. What changes in their life or work when they have this skill? Avoid abstract framings like "to understand X" — push for the underlying outcome.}
+
+## Success looks like
+- {A specific, observable thing the user will be able to do}
+- {Another specific thing}
+- {…}
+
+## Constraints
+- {Time, budget, prior commitments, learning preferences, anything that bounds the approach}
+
+## Out of scope
+- {Adjacent topics the user explicitly does not want to chase right now — protects the zone of proximal development}
+```
+
+## Rules
+
+- **One mission per workspace.** If the user wants to learn two unrelated things, that is two workspaces.
+- **Concrete over abstract.** "Run a half marathon by October" beats "get fitter." "Ship a Rust CLI to my team" beats "learn Rust."
+- **Push back on vagueness.** If the user cannot articulate why, interview them before writing anything. A bad mission is worse than no mission.
+- **Revise when reality shifts.** Missions change. When the user's goal moves, update this file — don't leave a stale mission steering future sessions.
+- **Keep it short.** If `MISSION.md` runs past a screen, it has stopped being a compass and started being a plan.
diff --git a/.agents/skills/teach/RESOURCES-FORMAT.md b/.agents/skills/teach/RESOURCES-FORMAT.md
new file mode 100644
index 00000000000..c94aac6a263
--- /dev/null
+++ b/.agents/skills/teach/RESOURCES-FORMAT.md
@@ -0,0 +1,32 @@
+# RESOURCES.md Format
+
+`RESOURCES.md` is the curated set of trusted sources for this topic. Knowledge for explainers should be drawn from here, not from parametric guesses. Wisdom comes from the communities listed here.
+
+## Structure
+
+```md
+# {Topic} Resources
+
+## Knowledge
+
+- [Book: _The Science and Practice of Strength Training_ — Zatsiorsky & Kraemer](https://example.com)
+  Foundational text on programming and adaptation. Use for: anything to do with periodisation, recovery, intensity zones.
+- [Article: "How Much Should I Train?" — Greg Nuckols (Stronger By Science)](https://example.com)
+  Evidence-based review of volume landmarks. Use for: weekly set targets per muscle group.
+
+## Wisdom (Communities)
+
+- [r/weightroom](https://reddit.com/r/weightroom)
+  High-signal subreddit, moderated against bro-science. Use for: programme critique, plateau troubleshooting.
+- Local: Tuesday strength class at {gym name}
+  Use for: real-time coaching feedback on lifts.
+```
+
+## Rules
+
+- **High-trust only.** Prefer primary sources, recognised experts, peer-reviewed work, and communities with strong moderation. If a resource is marketing dressed as education, leave it out.
+- **Annotate every entry.** A bare link is useless in three months. Add one line: what it covers and when to reach for it.
+- **Group by Knowledge / Wisdom.** Mirrors the philosophy in [SKILL.md](./SKILL.md). It is fine for a resource to appear in only one group.
+- **Surface gaps explicitly.** If no good resource exists for an area the mission needs, write a `## Gaps` section listing what is missing. This drives future search.
+- **Prune ruthlessly.** A resource that turned out to be wrong, shallow, or off-mission should be removed, not buried. Better five sharp sources than thirty mediocre ones.
+- **Record community preferences.** If the user has opted out of joining communities, note it here so future sessions don't keep proposing them.
diff --git a/.agents/skills/teach/SKILL.md b/.agents/skills/teach/SKILL.md
new file mode 100644
index 00000000000..b1603e5ac53
--- /dev/null
+++ b/.agents/skills/teach/SKILL.md
@@ -0,0 +1,140 @@
+---
+name: teach
+description: Teach the user a new skill or concept, within this workspace.
+disable-model-invocation: true
+argument-hint: "What would you like to learn about?"
+---
+
+The user has asked you to teach them something. This is a stateful request - they intend to learn the topic over multiple sessions.
+
+## Teaching Workspace
+
+Treat the current directory as a teaching workspace. The state of their learning is captured in this directory in several files:
+
+- `MISSION.md`: A document capturing the _reason_ the user is interested in the topic. This should be used to ground all teaching. Use the format in [MISSION-FORMAT.md](./MISSION-FORMAT.md).
+- `./reference/*.html`: A directory of reference materials. These are the compressed learnings from the lessons - cheat sheets, reference algorithms, syntax, yoga poses, glossaries. They are the raw units of learning. They should be beautiful documents which print out well, and are designed for quick reference.
+- `RESOURCES.md`: A list of resources which can be explored to ground your teaching in contextual knowledge, or to acquire knowledge and wisdom. Use the format in [RESOURCES-FORMAT.md](./RESOURCES-FORMAT.md).
+- `./learning-records/*.md`: A directory of learning records, which capture what the user has learned. These are loosely equivalent to architectural decision records in software development - they capture non-obvious lessons and key insights that may need to be revised later, or drive future sessions. These should be used to calculate the zone of proximal development. They are titled `0001-<dash-case-name>.md`, where the number increments each time. Use the format in [LEARNING-RECORD-FORMAT.md](./LEARNING-RECORD-FORMAT.md).
+- `./lessons/*.html`: A directory of lessons. A **lesson** is a single, self-contained HTML output that teaches one tightly-scoped thing tied to the mission. This is the primary unit of teaching in this workspace.
+- `./assets/*`: Reusable **components** shared across lessons. See [Assets](#assets).
+- `NOTES.md`: A scratchpad for you to jot down user preferences, or working notes.
+
+## Philosophy
+
+To learn at a deep level, the user needs three things:
+
+- **Knowledge**, captured from high-quality, high-trust resources
+- **Skills**, acquired through highly-relevant interactive lessons devised by you, based on the knowledge
+- **Wisdom**, which comes from interacting with other learners and practitioners
+
+Before the `RESOURCES.md` is well-populated, your focus should be to find high-quality resources which will help the user acquire knowledge. Never trust your parametric knowledge.
+
+Some topics may require more skills than knowledge. Learning more about theoretical physics might be more knowledge-based. For yoga, more skills-based.
+
+### Fluency vs Storage Strength
+
+You should be careful to split between two types of learning:
+
+- **Fluency strength**: in-the-moment retrieval of knowledge
+- **Storage strength**: long-term retention of knowledge
+
+Fluency can give the user an illusory sense of mastery, but storage strength is the real goal. Try to design lessons which build long-term retention by desirable difficulty:
+
+- Using retrieval practice (recall from memory)
+- Spacing (distributing practice over time)
+- Interleaving (mixing up different but related topics in practice - for skills practice only)
+
+## Lessons
+
+A lesson is the main thing you produce — the unit in which knowledge and skills reach the user. Each lesson is one self-contained HTML file, saved to `./lessons/` and titled `0001-<dash-case-name>.html` where the number increments each time.
+
+A lesson should be **beautiful** — clean, readable typography and layout — since the user will return to these later to review. Think Tufte.
+
+The lesson should be short, and completable very quickly. Learners' working memory is very small, and we need to stay within it. But each lesson should give the user a single tangible win that they can build on. It should be directly tied to the mission, and should be in the user's zone of proximal development.
+
+If possible, open the lesson file for the user by running a CLI command.
+
+Each lesson should link via HTML anchors to other lessons and reference documents.
+
+Each lesson should recommend a primary source for the user to read or watch. This should be the most high-quality, high-trust resource you found on the topic.
+
+Each lesson should contain a reminder to ask followup questions to the agent. The agent is their teacher, and can assist with anything that's unclear.
+
+## Assets
+
+Lessons are built from reusable **components**, stored in `./assets/`: stylesheets, quiz widgets, simulators, diagram helpers — anything a second lesson could reuse.
+
+Reuse is the default, not the exception. Before authoring a lesson, read `./assets/` and build from the components already there. When a lesson needs something new and reusable, write it as a component in `./assets/` and link to it — never inline code a future lesson would duplicate.
+
+A shared stylesheet is the first component every workspace earns: every lesson links it, so the lessons look like one consistent course rather than a pile of one-offs. As the workspace grows, so should the component library.
+
+## The Mission
+
+Every lesson should be tied into the mission - the reason that the user is interested in learning about the topic.
+
+If the user is unclear about the mission, or the `MISSION.md` is not populated, your first job should be to question the user on why they want to learn this.
+
+Failing to understand the mission will mean knowledge acquisition is not grounded in real-world goals. Lessons will feel too abstract. You will have no way of judging what the user should do next.
+
+Missions may change as the user develops more skills and knowledge. This is normal - make sure to update the `MISSION.md` and add a learning record to capture the change. Confirm with the user before changing the mission.
+
+## Zone Of Proximal Development
+
+Each lesson, the user should always feel as if they are being challenged 'just enough'.
+
+The user may specify an exact thing they want to learn. If they don't, figure out their zone of proximal development by:
+
+- Reading their `learning-records`
+- Figuring out the right thing to teach them based on their mission
+- Teach the most relevant thing that fits in their zone of proximal development
+
+## Knowledge
+
+Lessons should be designed around a skill the user is going to learn. The knowledge in the lesson should be only what's required to acquire that skill. You teach the knowledge first, then get the user to practice the skills via an interactive feedback loop.
+
+Knowledge should first be gathered from trusted resources. Use `RESOURCES.md` to keep track of them. Lessons should be littered with citations - links to external resources to back up any claim made. This increases the trustworthiness of the lesson.
+
+For acquiring knowledge, difficulty is the enemy. It eats working memory you need for understanding.
+
+## Skills
+
+If knowledge is all about acquisition, skills are about durability and flexibility. Make the knowledge stick.
+
+For skill acquisition, difficulty is the tool. Effortful retrieval is what builds storage strength. Skills should be taught through interactive lessons. There are several tools at your disposal:
+
+- Interactive lessons, using quizzes and light in-browser tasks
+- Lessons which guide the user through a list of real-world steps to take (for instance, yoga poses)
+
+Each of these should be based on a **feedback loop**, where the user receives feedback on their performance. This feedback loop should be as tight as possible, giving feedback immediately - and ideally automatically.
+
+For quizzes, each answer should be exactly the same number of words (and characters, if possible). Don't give the user any clues about the answer through formatting.
+
+## Acquiring Wisdom
+
+Wisdom comes from true real-world interaction - testing your skills outside the learning environment.
+
+When the user asks a question that appears to require wisdom, your default posture should be to attempt to answer - but to ultimately delegate to a **community**.
+
+A community is a place (online or offline) where the user can test their skills in the real world. This might be a forum, a subreddit, a real-world class (budget permitting) or a local interest group.
+
+You should attempt to find high-reputation communities the user can join. If the user expresses a preference that they don't want to join a community, respect it.
+
+## Reference Documents
+
+While creating lessons, you should also create reference documents. Lessons can reference these documents - they are useful for tracking raw units of knowledge useful across lessons.
+
+Lessons will rarely be revisited later - reference documents will be. They should be the compressed essence of the lesson, in a format designed for quick reference.
+
+Some learning topics lend themselves to reference:
+
+- Syntax and code snippets for programming
+- Algorithms and flowcharts for processes
+- Yoga poses and sequences for yoga
+- Exercises and routines for fitness
+- Glossaries for any topic with its own nomenclature
+
+Glossaries, in particular, are an essential reference. Once one is created, it should be adhered to in every lesson.
+
+## `NOTES.md`
+
+The user will sometimes express preferences of how they want to be taught, or things you should keep in mind. This is the place to record those preferences, so you can refer back to them when designing lessons or working with the user.
diff --git a/.agents/skills/teach/agents/openai.yaml b/.agents/skills/teach/agents/openai.yaml
new file mode 100644
index 00000000000..3452a850e3b
--- /dev/null
+++ b/.agents/skills/teach/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Teach"
+  short_description: "Learn a concept in a guided workspace"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/to-spec/SKILL.md b/.agents/skills/to-spec/SKILL.md
new file mode 100644
index 00000000000..f3cca8d3dbd
--- /dev/null
+++ b/.agents/skills/to-spec/SKILL.md
@@ -0,0 +1,75 @@
+---
+name: to-spec
+description: Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
+disable-model-invocation: true
+---
+
+This skill takes the current conversation context and codebase understanding and produces a spec (you may know this document as a PRD). Do NOT interview the user — just synthesize what you already know.
+
+The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
+
+## Process
+
+1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.
+
+2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.
+
+Check with the user that these seams match their expectations.
+
+3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.
+
+<spec-template>
+
+## Problem Statement
+
+The problem that the user is facing, from the user's perspective.
+
+## Solution
+
+The solution to the problem, from the user's perspective.
+
+## User Stories
+
+A LONG, numbered list of user stories. Each user story should be in the format of:
+
+1. As an <actor>, I want a <feature>, so that <benefit>
+
+<user-story-example>
+1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
+</user-story-example>
+
+This list of user stories should be extremely extensive and cover all aspects of the feature.
+
+## Implementation Decisions
+
+A list of implementation decisions that were made. This can include:
+
+- The modules that will be built/modified
+- The interfaces of those modules that will be modified
+- Technical clarifications from the developer
+- Architectural decisions
+- Schema changes
+- API contracts
+- Specific interactions
+
+Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
+
+Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+
+## Testing Decisions
+
+A list of testing decisions that were made. Include:
+
+- A description of what makes a good test (only test external behavior, not implementation details)
+- Which modules will be tested
+- Prior art for the tests (i.e. similar types of tests in the codebase)
+
+## Out of Scope
+
+A description of the things that are out of scope for this spec.
+
+## Further Notes
+
+Any further notes about the feature.
+
+</spec-template>
diff --git a/.agents/skills/to-spec/agents/openai.yaml b/.agents/skills/to-spec/agents/openai.yaml
new file mode 100644
index 00000000000..549e6f76f02
--- /dev/null
+++ b/.agents/skills/to-spec/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "To Spec"
+  short_description: "Turn a conversation into a spec"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/to-tickets/SKILL.md b/.agents/skills/to-tickets/SKILL.md
new file mode 100644
index 00000000000..23140c577f7
--- /dev/null
+++ b/.agents/skills/to-tickets/SKILL.md
@@ -0,0 +1,107 @@
+---
+name: to-tickets
+description: Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker — edges as text in one file per ticket locally, or native blocking links on a real tracker.
+disable-model-invocation: true
+---
+
+# To Tickets
+
+Break a plan, spec, or conversation into a set of **tickets** — tracer-bullet vertical slices, each declaring the tickets that **block** it.
+
+The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
+
+## Process
+
+### 1. Gather context
+
+Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an issue number or URL) as an argument, fetch it and read its full body and comments.
+
+### 2. Explore the codebase (optional)
+
+If you have not already explored the codebase, do so to understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
+
+Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."
+
+### 3. Draft vertical slices
+
+Break the work into **tracer bullet** tickets.
+
+<vertical-slice-rules>
+
+- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests) — vertical, NOT a horizontal slice of one layer
+- A completed slice is demoable or verifiable on its own
+- Each slice is sized to fit in a single fresh context window
+- Any prefactoring should be done first
+
+</vertical-slice-rules>
+
+Give each ticket its **blocking edges** — the other tickets that must complete before it can start. A ticket with no blockers can start immediately.
+
+**Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change — rename a column, retype a shared symbol — whose **blast radius** fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as **expand–contract**. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket — green is promised only there.
+
+### 4. Quiz the user
+
+Present the proposed breakdown as a numbered list. For each ticket, show:
+
+- **Title**: short descriptive name
+- **Blocked by**: which other tickets (if any) must complete first
+- **What it delivers**: the end-to-end behaviour this ticket makes work
+
+Ask the user:
+
+- Does the granularity feel right? (too coarse / too fine)
+- Are the blocking edges correct — does each ticket only depend on tickets that genuinely gate it?
+- Should any tickets be merged or split further?
+
+Iterate until the user approves the breakdown.
+
+### 5. Publish the tickets to the configured tracker
+
+Publish the approved tickets. **How** depends on the tracker `/setup-matt-pocock-skills` configured — the tickets are the same either way, only the shape of the blocking edges changes:
+
+- **Local files** → write one file per ticket under `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01` in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on. Use the per-ticket file template below — one ticket per file, never a single combined file.
+- **A real issue tracker (GitHub, Linear, …)** → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking / sub-issue relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. Apply the `ready-for-agent` triage label unless instructed otherwise — the tickets are agent-grabbable by construction.
+
+Work the **frontier**: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
+
+Do NOT close or modify any parent issue.
+
+<local-ticket-template>
+
+# <NN> — <Ticket title>
+
+**What to build:** the end-to-end behaviour this ticket makes work, from the user's perspective — not a layer-by-layer implementation list.
+
+**Blocked by:** the numbers/titles of the tickets that gate this one, or "None — can start immediately".
+
+**Status:** ready-for-agent
+
+- [ ] Acceptance criterion 1
+- [ ] Acceptance criterion 2
+
+</local-ticket-template>
+
+<issue-template>
+
+## Parent
+
+A reference to the parent issue on the tracker (if the source was an existing issue, otherwise omit this section).
+
+## What to build
+
+The end-to-end behaviour this ticket makes work, from the user's perspective — not layer-by-layer implementation.
+
+## Acceptance criteria
+
+- [ ] Criterion 1
+- [ ] Criterion 2
+
+## Blocked by
+
+- A reference to each blocking ticket, or "None — can start immediately".
+
+</issue-template>
+
+In either form, avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+
+Work the frontier one ticket at a time with `/implement`, clearing context between tickets.
diff --git a/.agents/skills/to-tickets/agents/openai.yaml b/.agents/skills/to-tickets/agents/openai.yaml
new file mode 100644
index 00000000000..24605a5db64
--- /dev/null
+++ b/.agents/skills/to-tickets/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "To Tickets"
+  short_description: "Split a plan into tracer-bullet tickets"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/triage/AGENT-BRIEF.md b/.agents/skills/triage/AGENT-BRIEF.md
new file mode 100644
index 00000000000..6535c9bd00e
--- /dev/null
+++ b/.agents/skills/triage/AGENT-BRIEF.md
@@ -0,0 +1,207 @@
+# Writing Agent Briefs
+
+An agent brief is a structured comment posted on a GitHub issue or PR when it moves to `ready-for-agent`. It is the authoritative specification that an AFK agent will work from. The original body and discussion are context — the agent brief is the contract.
+
+The brief states **what the agent should do**, which stretches to both surfaces: for an issue, that's building the change from nothing; for a PR, it's what's left to do *to the existing diff* — finish it, close gaps, address review points. Same principles either way; the PR example below shows the difference.
+
+## Principles
+
+### Durability over precision
+
+The issue may sit in `ready-for-agent` for days or weeks. The codebase will change in the meantime. Write the brief so it stays useful even as files are renamed, moved, or refactored.
+
+- **Do** describe interfaces, types, and behavioral contracts
+- **Do** name specific types, function signatures, or config shapes that the agent should look for or modify
+- **Don't** reference file paths — they go stale
+- **Don't** reference line numbers
+- **Don't** assume the current implementation structure will remain the same
+
+### Behavioral, not procedural
+
+Describe **what** the system should do, not **how** to implement it. The agent will explore the codebase fresh and make its own implementation decisions.
+
+- **Good:** "The `SkillConfig` type should accept an optional `schedule` field of type `CronExpression`"
+- **Bad:** "Open src/types/skill.ts and add a schedule field on line 42"
+- **Good:** "When a user runs `/triage` with no arguments, they should see a summary of issues needing attention"
+- **Bad:** "Add a switch statement in the main handler function"
+
+### Complete acceptance criteria
+
+The agent needs to know when it's done. Every agent brief must have concrete, testable acceptance criteria. Each criterion should be independently verifiable.
+
+- **Good:** "Running `gh issue list --label needs-triage` returns issues that have been through initial classification"
+- **Bad:** "Triage should work correctly"
+
+### Explicit scope boundaries
+
+State what is out of scope. This prevents the agent from gold-plating or making assumptions about adjacent features.
+
+## Template
+
+```markdown
+## Agent Brief
+
+**Category:** bug / enhancement
+**Summary:** one-line description of what needs to happen
+
+**Current behavior:**
+Describe what happens now. For bugs, this is the broken behavior.
+For enhancements, this is the status quo the feature builds on.
+
+**Desired behavior:**
+Describe what should happen after the agent's work is complete.
+Be specific about edge cases and error conditions.
+
+**Key interfaces:**
+- `TypeName` — what needs to change and why
+- `functionName()` return type — what it currently returns vs what it should return
+- Config shape — any new configuration options needed
+
+**Acceptance criteria:**
+- [ ] Specific, testable criterion 1
+- [ ] Specific, testable criterion 2
+- [ ] Specific, testable criterion 3
+
+**Out of scope:**
+- Thing that should NOT be changed or addressed in this issue
+- Adjacent feature that might seem related but is separate
+```
+
+## Examples
+
+### Good agent brief (bug)
+
+```markdown
+## Agent Brief
+
+**Category:** bug
+**Summary:** Skill description truncation drops mid-word, producing broken output
+
+**Current behavior:**
+When a skill description exceeds 1024 characters, it is truncated at exactly
+1024 characters regardless of word boundaries. This produces descriptions
+that end mid-word (e.g. "Use when the user wants to confi").
+
+**Desired behavior:**
+Truncation should break at the last word boundary before 1024 characters
+and append "..." to indicate truncation.
+
+**Key interfaces:**
+- The `SkillMetadata` type's `description` field — no type change needed,
+  but the validation/processing logic that populates it needs to respect
+  word boundaries
+- Any function that reads SKILL.md frontmatter and extracts the description
+
+**Acceptance criteria:**
+- [ ] Descriptions under 1024 chars are unchanged
+- [ ] Descriptions over 1024 chars are truncated at the last word boundary
+      before 1024 chars
+- [ ] Truncated descriptions end with "..."
+- [ ] The total length including "..." does not exceed 1024 chars
+
+**Out of scope:**
+- Changing the 1024 char limit itself
+- Multi-line description support
+```
+
+### Good agent brief (enhancement)
+
+```markdown
+## Agent Brief
+
+**Category:** enhancement
+**Summary:** Add `.out-of-scope/` directory support for tracking rejected feature requests
+
+**Current behavior:**
+When a feature request is rejected, the issue is closed with a `wontfix` label
+and a comment. There is no persistent record of the decision or reasoning.
+Future similar requests require the maintainer to recall or search for the
+prior discussion.
+
+**Desired behavior:**
+Rejected feature requests should be documented in `.out-of-scope/<concept>.md`
+files that capture the decision, reasoning, and links to all issues that
+requested the feature. When triaging new issues, these files should be
+checked for matches.
+
+**Key interfaces:**
+- Markdown file format in `.out-of-scope/` — each file should have a
+  `# Concept Name` heading, a `**Decision:**` line, a `**Reason:**` line,
+  and a `**Prior requests:**` list with issue links
+- The triage workflow should read all `.out-of-scope/*.md` files early
+  and match incoming issues against them by concept similarity
+
+**Acceptance criteria:**
+- [ ] Closing a feature as wontfix creates/updates a file in `.out-of-scope/`
+- [ ] The file includes the decision, reasoning, and link to the closed issue
+- [ ] If a matching `.out-of-scope/` file already exists, the new issue is
+      appended to its "Prior requests" list rather than creating a duplicate
+- [ ] During triage, existing `.out-of-scope/` files are checked and surfaced
+      when a new issue matches a prior rejection
+
+**Out of scope:**
+- Automated matching (human confirms the match)
+- Reopening previously rejected features
+- Bug reports (only enhancement rejections go to `.out-of-scope/`)
+```
+
+### Good agent brief (PR)
+
+For a PR, "Current behavior" describes the state of the diff, and the brief asks the agent to finish or fix it rather than build from scratch.
+
+```markdown
+## Agent Brief
+
+**Category:** enhancement
+**Summary:** Finish the contributor's `--json` output flag for `triage list`
+
+**Current behavior:**
+The PR adds a `--json` flag that serializes the issue list to JSON. The happy
+path works and the diff matches the project's command structure. Two gaps
+remain: errors are still printed as human text (not JSON), and the new flag has
+no test coverage.
+
+**Desired behavior:**
+With `--json`, all output — including errors — is well-formed JSON on stdout,
+and the command's exit codes are unchanged. The existing human-readable output
+is untouched when the flag is absent.
+
+**Key interfaces:**
+- The command's error path should emit `{ "error": string }` under `--json`
+  instead of the plain-text error
+- Reuse the existing serializer the PR already added; don't introduce a second
+
+**Acceptance criteria:**
+- [ ] `triage list --json` emits valid JSON for both success and error cases
+- [ ] Exit codes match the non-JSON command
+- [ ] A test covers the `--json` success output and one error case
+- [ ] Default (non-JSON) output is byte-for-byte unchanged
+
+**Out of scope:**
+- Adding `--json` to any other command
+- Changing the JSON shape of the success payload the PR already defined
+```
+
+### Bad agent brief
+
+```markdown
+## Agent Brief
+
+**Summary:** Fix the triage bug
+
+**What to do:**
+The triage thing is broken. Look at the main file and fix it.
+The function around line 150 has the issue.
+
+**Files to change:**
+- src/triage/handler.ts (line 150)
+- src/types.ts (line 42)
+```
+
+This is bad because:
+- No category
+- Vague description ("the triage thing is broken")
+- References file paths and line numbers that will go stale
+- No acceptance criteria
+- No scope boundaries
+- No description of current vs desired behavior
diff --git a/.agents/skills/triage/OUT-OF-SCOPE.md b/.agents/skills/triage/OUT-OF-SCOPE.md
new file mode 100644
index 00000000000..fc0e39f5291
--- /dev/null
+++ b/.agents/skills/triage/OUT-OF-SCOPE.md
@@ -0,0 +1,105 @@
+# Out-of-Scope Knowledge Base
+
+The `.out-of-scope/` directory in a repo stores persistent records of rejected feature requests. It serves two purposes:
+
+1. **Institutional memory** — why a feature was rejected, so the reasoning isn't lost when the issue is closed
+2. **Deduplication** — when a new issue comes in that matches a prior rejection, the skill can surface the previous decision instead of re-litigating it
+
+## Directory structure
+
+```
+.out-of-scope/
+├── dark-mode.md
+├── plugin-system.md
+└── graphql-api.md
+```
+
+One file per **concept**, not per issue. Multiple issues requesting the same thing are grouped under one file.
+
+## File format
+
+The file should be written in a relaxed, readable style — more like a short design document than a database entry. Use paragraphs, code samples, and examples to make the reasoning clear and useful to someone encountering it for the first time.
+
+```markdown
+# Dark Mode
+
+This project does not support dark mode or user-facing theming.
+
+## Why this is out of scope
+
+The rendering pipeline assumes a single color palette defined in
+`ThemeConfig`. Supporting multiple themes would require:
+
+- A theme context provider wrapping the entire component tree
+- Per-component theme-aware style resolution
+- A persistence layer for user theme preferences
+
+This is a significant architectural change that doesn't align with the
+project's focus on content authoring. Theming is a concern for downstream
+consumers who embed or redistribute the output.
+
+```ts
+// The current ThemeConfig interface is not designed for runtime switching:
+interface ThemeConfig {
+  colors: ColorPalette; // single palette, resolved at build time
+  fonts: FontStack;
+}
+```
+
+## Prior requests
+
+- #42 — "Add dark mode support"
+- #87 — "Night theme for accessibility"
+- #134 — "Dark theme option"
+```
+
+### Naming the file
+
+Use a short, descriptive kebab-case name for the concept: `dark-mode.md`, `plugin-system.md`, `graphql-api.md`. The name should be recognizable enough that someone browsing the directory understands what was rejected without opening the file.
+
+### Writing the reason
+
+The reason should be substantive — not "we don't want this" but why. Good reasons reference:
+
+- Project scope or philosophy ("This project focuses on X; theming is a downstream concern")
+- Technical constraints ("Supporting this would require Y, which conflicts with our Z architecture")
+- Strategic decisions ("We chose to use A instead of B because...")
+
+The reason should be durable. Avoid referencing temporary circumstances ("we're too busy right now") — those aren't real rejections, they're deferrals.
+
+## When to check `.out-of-scope/`
+
+During triage (Step 1: Gather context), read all files in `.out-of-scope/`. When evaluating a new issue:
+
+- Check if the request matches an existing out-of-scope concept
+- Matching is by concept similarity, not keyword — "night theme" matches `dark-mode.md`
+- If there's a match, surface it to the maintainer: "This is similar to `.out-of-scope/dark-mode.md` — we rejected this before because [reason]. Do you still feel the same way?"
+
+The maintainer may:
+
+- **Confirm** — the new issue gets added to the existing file's "Prior requests" list, then closed
+- **Reconsider** — the out-of-scope file gets deleted or updated, and the issue proceeds through normal triage
+- **Disagree** — the issues are related but distinct, proceed with normal triage
+
+## When to write to `.out-of-scope/`
+
+Only when an **enhancement** (not a bug) is *rejected* as `wontfix`. This applies to enhancement PRs exactly as it does to issues — a rejected PR is recorded here so the same request doesn't return as fresh code.
+
+Do **not** write here when something is closed as `wontfix` because it's **already implemented**. That's a built feature, not a rejected one; recording it would poison the dedup checks with false rejections. Instead, the closing comment points to where the feature already lives.
+
+The flow:
+
+1. Maintainer decides a feature request is out of scope
+2. Check if a matching `.out-of-scope/` file already exists
+3. If yes: append the new issue to the "Prior requests" list
+4. If no: create a new file with the concept name, decision, reason, and first prior request
+5. Post a comment on the issue explaining the decision and mentioning the `.out-of-scope/` file
+6. Close the issue with the `wontfix` label
+
+## Updating or removing out-of-scope files
+
+If the maintainer changes their mind about a previously rejected concept:
+
+- Delete the `.out-of-scope/` file
+- The skill does not need to reopen old issues — they're historical records
+- The new issue that triggered the reconsideration proceeds through normal triage
diff --git a/.agents/skills/triage/SKILL.md b/.agents/skills/triage/SKILL.md
new file mode 100644
index 00000000000..be47b78100c
--- /dev/null
+++ b/.agents/skills/triage/SKILL.md
@@ -0,0 +1,112 @@
+---
+name: triage
+description: Move issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.
+disable-model-invocation: true
+---
+
+# Triage
+
+Move issues on the project issue tracker through a small state machine of triage roles.
+
+If this repo treats external pull requests as a request surface (see the issue-tracker config), triage covers them too: **a PR is an issue with attached code** — same roles, same states, same machine, with a few deltas marked "for a PR" below. Resolve a bare `#42` to an issue or PR per the tracker config.
+
+Every comment or issue posted to the issue tracker during triage **must** start with this disclaimer:
+
+```
+> *This was generated by AI during triage.*
+```
+
+## Reference docs
+
+- [AGENT-BRIEF.md](AGENT-BRIEF.md) — how to write durable agent briefs
+- [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — how the `.out-of-scope/` knowledge base works
+
+## Roles
+
+Two **category** roles:
+
+- `bug` — something is broken
+- `enhancement` — new feature or improvement
+
+Five **state** roles:
+
+- `needs-triage` — maintainer needs to evaluate
+- `needs-info` — waiting on reporter for more information
+- `ready-for-agent` — fully specified, ready for an AFK agent
+- `ready-for-human` — needs human implementation
+- `wontfix` — will not be actioned
+
+For a PR, the same states read against the attached code: `ready-for-agent` means a brief is attached and an agent should take the next step on the diff; `ready-for-human` means it's ready for a human to merge.
+
+Every triaged issue should carry exactly one category role and one state role. If state roles conflict, flag it and ask the maintainer before doing anything else.
+
+These are canonical role names — the actual label strings used in the issue tracker may differ. The mapping should have been provided to you - run `/setup-matt-pocock-skills` if not.
+
+State transitions: an unlabeled issue normally goes to `needs-triage` first; from there it moves to `needs-info`, `ready-for-agent`, `ready-for-human`, or `wontfix`. `needs-info` returns to `needs-triage` once the reporter replies. The maintainer can override at any time — flag transitions that look unusual and ask before proceeding.
+
+## Invocation
+
+The maintainer invokes `/triage` and describes what they want in natural language. Interpret the request and act. Examples:
+
+- "Show me anything that needs my attention"
+- "Let's look at #42" (issue or PR)
+- "Move #42 to ready-for-agent"
+- "What's ready for agents to pick up?"
+
+## Show what needs attention
+
+Query the issue tracker and present three buckets, oldest first:
+
+1. **Unlabeled** — never triaged.
+2. **`needs-triage`** — evaluation in progress.
+3. **`needs-info` with reporter activity since the last triage notes** — needs re-evaluation.
+
+When PRs are in scope, include external PRs in these buckets and tag each line `[PR]` or `[issue]`. Discovery surfaces only *external* PRs (the tracker config defines who counts as external) — a collaborator's in-flight PR is not triage work. This filter is discovery-only; an explicitly named PR is always triaged regardless of author.
+
+Show counts and a one-line summary per item. Let the maintainer pick.
+
+## Triage a specific issue or PR
+
+1. **Gather context.** Read the full issue or PR (body, comments, labels, author, dates; for a PR, the diff too). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Run two checks against the codebase: (a) **redundancy** — search for an existing implementation of the requested behavior by domain concept (not just the request's wording), and report where you looked. If found, it's an already-implemented `wontfix` (step 5). (b) **prior rejection** — read `.out-of-scope/*.md` and surface any that resembles this request.
+
+2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the request — including whether it's already implemented. Wait for direction.
+
+3. **Verify the claim.** Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims — check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong `needs-info` signal). A confirmed verification makes a much stronger agent brief.
+
+4. **Grill (if needed).** If the request needs fleshing out, run the `/grilling` and `/domain-modeling` skills together — grill it into shape one question at a time, sharpening domain terms and updating `CONTEXT.md`/ADRs inline as decisions land.
+
+5. **Apply the outcome:**
+   - `ready-for-agent` — post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)).
+   - `ready-for-human` — same structure as an agent brief, but note why it can't be delegated (judgment calls, external access, design decisions, manual testing).
+   - `needs-info` — post triage notes (template below).
+   - `wontfix` — close, with the comment depending on *why*:
+     - **Already implemented** — the change already exists in the codebase. Point to where it lives; do **not** write to `.out-of-scope/` (that KB is for *rejected* requests, not built ones).
+     - **Rejected (bug)** — polite explanation, then close.
+     - **Rejected (enhancement)** — write to `.out-of-scope/`, link to it from a comment, then close ([OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)).
+   - `needs-triage` — apply the role. Optional comment if there's partial progress.
+
+## Quick state override
+
+If the maintainer says "move #42 to ready-for-agent", trust them and apply the role directly. Confirm what you're about to do (role changes, comment, close), then act. Skip grilling. If moving to `ready-for-agent` without a grilling session, ask whether they want to write an agent brief.
+
+## Needs-info template
+
+```markdown
+## Triage Notes
+
+**What we've established so far:**
+
+- point 1
+- point 2
+
+**What we still need from you (@reporter):**
+
+- question 1
+- question 2
+```
+
+Capture everything resolved during grilling under "established so far" so the work isn't lost. Questions must be specific and actionable, not "please provide more info".
+
+## Resuming a previous session
+
+If prior triage notes exist on the issue or PR, read them, check whether the reporter has answered any outstanding questions, and present an updated picture before continuing. Don't re-ask resolved questions.
diff --git a/.agents/skills/triage/agents/openai.yaml b/.agents/skills/triage/agents/openai.yaml
new file mode 100644
index 00000000000..acb366cf0f2
--- /dev/null
+++ b/.agents/skills/triage/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Triage"
+  short_description: "Move issues through triage roles"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/wayfinder/SKILL.md b/.agents/skills/wayfinder/SKILL.md
new file mode 100644
index 00000000000..42e3644cc57
--- /dev/null
+++ b/.agents/skills/wayfinder/SKILL.md
@@ -0,0 +1,128 @@
+---
+name: wayfinder
+description: Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
+disable-model-invocation: true
+---
+
+A loose idea has arrived — too big for one agent session, and wrapped in fog: the way from here to the **destination** isn't visible yet. Wayfinding is about finding that way, not charging at the destination. This skill charts the way as a **shared map** on the repo's issue tracker, then works its **decision tickets** — questions whose resolution is a decision, not slices of a build to execute — one at a time until the route is clear.
+
+The destination varies per effort, and naming it is the first act of charting — it shapes every ticket. It might be a spec to hand off and iterate on, a decision to lock before planning starts, or a change made in place like a data-structure migration. The map is domain-agnostic — engineering work, course content, whatever fits the shape.
+
+## Plan, don't do
+
+Wayfinder is **planning** by default: each ticket resolves a decision, and the map is done when the way is clear — nothing left to decide before someone goes and does the thing. The pull to just do the work is usually the signal you've reached the edge of the map and it's time to hand off. An effort can override this in its **Notes** — carrying execution into the map itself — but absent that, produce decisions, not deliverables.
+
+## Refer by name
+
+Every map and ticket is an issue, so it has a **name** — its title. In everything the human reads — narration, the map's Decisions-so-far — refer to it by that name, never by a bare id, number, or slug. A wall of `#42, #43, #44` is illegible; names read at a glance. The id and URL don't vanish — a name wraps its link — but they ride *inside* the name, never stand in for it.
+
+## The Map
+
+The map is a single issue on this repo's issue tracker, labelled `wayfinder:map` — the canonical artifact. Its tickets are child issues of the map.
+
+The map is an **index**, not a store. It lists the decisions made and points at the tickets that hold their detail; a decision lives in exactly one place — its ticket — so the map never restates it, only gists it and links.
+
+**Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific.** The issue tracker should have been provided to you — run `/setup-matt-pocock-skills` if not. Consult the tracker doc's "Wayfinding operations" section for how _this_ repo expresses them. If no tracker has been provided, default to the local-markdown tracker.
+
+### The map body
+
+The whole map at low resolution, loaded once per session. Open tickets are **not** listed — they are open child issues, found by query.
+
+```markdown
+## Destination
+
+<what reaching the end of this map looks like — the spec, decision, or change this effort is finding its way to. One or two lines; every session orients to it before choosing a ticket.>
+
+## Notes
+
+<domain; skills every session should consult; standing preferences for this effort>
+
+## Decisions so far
+
+<!-- the index — one line per closed ticket: enough to judge relevance, then zoom the link for the detail the ticket holds -->
+
+- [<closed ticket title>](link) — <one-line gist of the answer>
+
+## Not yet specified
+
+<!-- see "Fog of war": in-scope fog you can't ticket yet; graduates as the frontier advances -->
+
+## Out of scope
+
+<!-- see "Out of scope": work ruled beyond the destination; closed, never graduates -->
+```
+
+### Tickets
+
+Each ticket is a **child issue** of the map; the tracker's issue id is its identity. Its body is the question, sized to one 100K token agent session:
+
+```markdown
+## Question
+
+<the decision or investigation this ticket resolves>
+```
+
+Each ticket carries a `wayfinder:<type>` label — one of `research`, `prototype`, `grilling`, `task` (see [Ticket Types](#ticket-types)).
+
+A session **claims** a ticket by assigning it to the dev driving the map, **first**, before any work, so concurrent sessions skip it. That assignee _is_ the claim: an open, unassigned ticket is unclaimed.
+
+Blocking uses the tracker's **native** dependency relationship — essential because it renders the frontier _visually_ in the tracker's own UI, so the human sees what's takeable without opening the map. Only a tracker that lacks native blocking falls back to a body convention. A ticket is **unblocked** when every ticket blocking it is closed; the **frontier** is the open, unblocked, unclaimed children — the edge of the known.
+
+The answer isn't part of the body — it's recorded on resolution (see [Work through the map](#work-through-the-map)). Assets created while resolving a ticket are linked from the issue, not pasted in.
+
+## Ticket Types
+
+Every ticket is either **HITL** — human in the loop, worked *with* a human who speaks for themselves — or **AFK**, driven by the agent alone. A HITL ticket only resolves through that live exchange; the agent never stands in for the human's side of it (a grilling agent that answers its own questions has broken this).
+
+- **Research** (AFK): Reading documentation, third-party APIs, or local resources like knowledge bases to surface a fact a decision waits on. Resolved by a `/research` **subagent**. Use when knowledge outside the current working directory is required.
+- **Prototype** (HITL): Raise the fidelity of the discussion by making a cheap, rough, concrete artifact to react to — an outline, a rough take, a stub, or UI/logic code via the /prototype skill. Links the prototype as an asset. Use when "how should it look" or "how should it behave" is the key question.
+- **Grilling** (HITL): Conversation via the /grilling and /domain-modeling skills, one question at a time. The default case.
+- **Task** (HITL or AFK): Manual work that must happen before a *decision* can be made — nothing to decide, prototype, or research, but the discussion is blocked until it's done. Signing up for a service so its API can be judged, provisioning access, moving data so its shape can be seen. This is the one type that *does* rather than decides — and it earns its place by unblocking a decision, not by delivering the destination. The agent drives it alone where it can (AFK); otherwise it hands the human a precise checklist (HITL). Resolved when the work is done; the answer records what was done and any resulting facts (credentials location, new URLs, row counts) later tickets depend on.
+
+## Fog of war
+
+The map is _deliberately_ incomplete: don't chart what you can't yet see. Beyond the live tickets lies the **fog of war** — the dim view of decisions and investigations you can tell are coming but can't yet pin down, because they hang on questions still open. Resolving a ticket clears the fog ahead of it, graduating whatever's now specifiable into fresh tickets — one at a time, until the way to the destination is clear and no tickets remain.
+
+The map's **Not yet specified** section is where that dim view is written down: the suspected question, the area to revisit later. It's the undiscovered frontier _toward_ the destination — everything here is in scope, just not sharp enough to ticket. Write as loosely or as fully as the view allows; it doubles as a signpost for collaborators reading where the effort is headed.
+
+**Fog or ticket?** The test is whether you can state the question precisely now — _not_ whether you can answer it now.
+
+- **Ticket when** the question is already sharp — even if it's blocked and you can't act on it yet.
+- **Not yet specified when** you can't yet phrase it that sharply. Don't pre-slice the fog into ticket-sized pieces: it's coarser than a ticket, and one patch may graduate into several tickets, or none, once the frontier reaches it.
+
+**Not yet specified** excludes what's already decided (Decisions so far), what's already a live ticket, and what's out of scope (the next section).
+
+## Out of scope
+
+Fog only ever gathers _toward_ the destination. The destination fixes the scope, so work beyond it is **out of scope** — it isn't fog, and it doesn't belong in **Not yet specified**. It gets its own **Out of scope** section on the map: work you've consciously ruled out of _this_ effort. Scope, not sharpness, lands it here.
+
+Out-of-scope work never graduates — the frontier stops at the destination — so it returns only if the destination is redrawn, and then as a fresh effort, not a resumption.
+
+Ruling something out of scope is a scoping act, not a step on the route. When a ticket that already exists turns out to sit past the destination — mis-scoped in while charting, or exposed by a resolution — **close it** (a closed ticket is unambiguously off the frontier) and leave one line in the **Out of scope** section: the gist plus why it's out of scope, linking the closed ticket. It stays out of **Decisions so far**, which records the route actually walked — a scope boundary isn't a step on it.
+
+## Invocation
+
+Two modes. Either way, **never resolve more than one ticket per session** — with the exception of research tickets.
+
+### Chart the map
+
+User invokes with a loose idea.
+
+1. **Name the destination.** Run a `/grilling` and `/domain-modeling` session to pin down what this map is finding its way to — the spec, decision, or change. The destination fixes the scope, so it's settled first.
+2. **Map the frontier.** Grill again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. **If this surfaces no fog** — the way to the destination is already clear, the whole journey small enough for one session — you don't need a map. Stop and ask the user how they'd like to proceed.
+3. **Create the map** (label `wayfinder:map`): Destination and Notes filled in, Decisions-so-far empty, the fog sketched into **Not yet specified**.
+4. **Create the tickets you can specify now** as child issues of the map — then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the fog — the **Not yet specified** section.
+5. **Fire the research subagents.** For each `research` ticket you just created, spin up a `/research` subagent to resolve it in parallel, capturing its findings on a throwaway `research/<name>` branch with a context pointer from the ticket.
+6. Stop — charting is one session's work; it hand-resolves nothing.
+
+### Work through the map
+
+User invokes with a map (URL or number). A ticket is **optional** — without one, you pick the next decision, not the user.
+
+1. Load the **map** — the low-res view, not every ticket body.
+2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work.
+3. Resolve it — **zoom as needed**: fetch the full body of any related or closed ticket on demand; invoke the skills the `## Notes` block names. If in doubt, use `/grilling` and `/domain-modeling`.
+4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far.
+5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals a ticket — this one or another — sits beyond the destination, **rule it out of scope** rather than resolving it on the route. If the decision invalidates other parts of the map, update or delete those tickets.
+
+The user may run unblocked tickets in parallel, so expect other sessions to be editing the tracker concurrently.
diff --git a/.agents/skills/wayfinder/agents/openai.yaml b/.agents/skills/wayfinder/agents/openai.yaml
new file mode 100644
index 00000000000..b37544751e0
--- /dev/null
+++ b/.agents/skills/wayfinder/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Wayfinder"
+  short_description: "Map a large effort as decision tickets"
+policy:
+  allow_implicit_invocation: false
diff --git a/.agents/skills/writing-great-skills/GLOSSARY.md b/.agents/skills/writing-great-skills/GLOSSARY.md
new file mode 100644
index 00000000000..0269ca89b9d
--- /dev/null
+++ b/.agents/skills/writing-great-skills/GLOSSARY.md
@@ -0,0 +1,201 @@
+# Glossary — Building Great Skills
+
+The domain model for what makes a skill great. A skill exists to wrangle determinism out of a stochastic system; the root virtue is **Predictability**, and every term below is a lever on it. This is the disclosed reference for [`writing-great-skills`](SKILL.md).
+
+The terms are grouped by axis: **Invocation** (how a skill is reached), **Information Hierarchy** (how its content is arranged), **Steering** (how the agent's runtime behaviour is shaped), and **Pruning** (how it is kept lean). Each **failure mode** lives beside the lever that cures it, tagged _failure mode_.
+
+**Bold terms** in any definition are themselves defined in this glossary; find them by their heading.
+
+## Predictability
+
+The degree to which a skill makes the agent behave the same _way_ on every run — the same process, not the same output (a brainstorming skill should _predictably_ diverge; its tokens vary, its behaviour doesn't). The root virtue every other term serves — cost and maintainability are symptoms of it, not rivals.
+
+_Avoid_: consistency, reliability, robustness, output-determinism
+
+## Invocation
+
+How a skill is reached — and the two loads you pay for the choice.
+
+### Model-Invoked
+
+A skill that keeps its **description** field, so the agent can see it and fire it autonomously — and the human can still type its name, so model-invocation always _includes_ user reach. There is no model-only state: a description only ever _adds_ agent discovery, never removes the human's. Pays a permanent **context load** on every turn in exchange for that discoverability. Reachable by other skills, because the description that makes it agent-discoverable makes it invocable. A model-invoked skill whose content is all **reference** is also one home for shared reference: another skill can invoke it, so reference needed by several skills lives in one place. Pick model-invocation only when the agent must reach the skill on its own; if it never fires except by hand, drop the description and pay no context load.
+
+_Avoid_: ability, tool, capability
+
+### User-Invoked
+
+A skill with its **description** stripped — invisible to the agent and reachable only by the human typing its name (user-_only_, where **model-invoked** is user-_and-agent_). Trades agent-discoverability for zero **context load**. Because it has no description, nothing but the human can reach it: no other skill can fire it.
+
+_Avoid_: procedure, workflow, command
+
+### Description
+
+The skill's machine-readable trigger, and the one **context pointer** a **model-invoked** skill is forced to keep loaded at all times. Its mere presence _is_ the invocation axis: keep it and the skill is model-invoked (and reachable by other skills); delete it and the skill is **user-invoked**, reachable only by the human. The source of a model-invoked skill's **context load**.
+
+_Avoid_: frontmatter, summary
+
+### Context Pointer
+
+A reference held in the agent's context that names some out-of-context material and encodes the condition for reaching it. The **description** is the top-level context pointer (context window → skill); pointers to disclosed files are the same object one level down. Its wording, not the target, decides _when_ the agent reaches — and _how reliably_. A must-have target behind a weakly worded pointer is a variance bug: fix the wording first, and inline the material only if sharpening fails.
+
+_Avoid_: link, reference, import
+
+### Context Load
+
+The cost a **model-invoked** skill imposes on the agent's context window — its **description**, always loaded, spending both tokens and attention. What **user-invoked** skills escape by having no description, and the brake on splitting into more model-invoked skills.
+
+_Avoid_: token cost, context bloat
+
+### Cognitive Load
+
+The cost a **user-invoked** skill imposes on the human — what they must hold in their head: which skills exist and when to reach for each (the human is the index). What **model-invocation** removes by being agent-discoverable, and the brake on splitting into more user-invoked skills. Not a cost to minimise: it is the price of human agency, the reason some skills stay user-invoked. Spend it where human judgement matters; remove it where it does not.
+
+_Avoid_: human index, burden, overhead
+
+### Router Skill
+
+A **user-invoked** skill whose job is to point at your other user-invoked skills — naming each and when to reach for it — so the human has one skill to remember instead of many. It can only hint, never fire them: user-invoked skills have no **description**, so nothing but the human can reach them. The cure for **cognitive load** when user-invoked skills multiply.
+
+_Avoid_: dispatcher, menu, registry, index, router procedure
+
+### Granularity
+
+How finely you divide skills. Finer division spends one of the two loads: more **model-invoked** skills spend **context load** (more descriptions crowding the window and competing for attention); more **user-invoked** skills spend **cognitive load** (more for the human to remember and reach for). Two cuts guide the division. By **invocation**, split off a model-invoked skill where you have a distinct **leading word** to trigger it — a trigger word you actually use in your prompts. By **sequence**, split a run of **steps** where a step's **post-completion steps** need hiding, since isolating it in its own context clears what follows. Beware the reverse: merging sequences exposes each step's post-completion steps to what follows, inviting premature completion.
+
+_Avoid_: chunking, modularity
+
+## Information Hierarchy
+
+How a skill's content is arranged, and how far down the ladder each piece sits.
+
+### Information Hierarchy
+
+A skill's content ranked by how immediately the agent needs it — a single ladder, produced by two cuts: in-file or behind a pointer, and step or reference. The rungs:
+
+- **Steps** — in-file, primary
+- **Reference**, in-file — secondary
+- **Reference**, disclosed — behind a **context pointer**
+
+A skill with no **steps** uses just the bottom two rungs — often a legitimately flat peer-set (e.g. every rule of a review on one rung), which is a fine arrangement, not a smell. The hierarchy is independent of invocation: a skill can be model- or user-invoked whether it is all steps, all reference, or both. When a skill has steps, in-file reference that should be disclosed buries them and turns attending to them into a coin-flip — a variance lever, not just a legibility one. Keep the top of the ladder legible; push down it whatever you can.
+
+_Avoid_: structure, organization, layout
+
+### Steps
+
+The ordered actions the agent performs — when a skill has them, the primary tier of its content, and the part that earns its place in SKILL.md. Not every skill has steps: a skill can be all steps (`tdd`), all **reference** (a review), or both, independent of invocation. Every step ends on a **completion criterion**, clear or vague.
+
+_Avoid_: workflow, instructions, choreography
+
+### Reference
+
+Material the agent refers to on demand — definitions, facts, parameters, examples, conditional instructions. When a skill has **steps** it is secondary to them; when a skill has none it is the entire content; or it lives outside any skill entirely — see **External Reference**. Reached via **context pointers**, and the prime candidate for **progressive disclosure**.
+
+_Avoid_: supporting material, docs, background
+
+### External Reference
+
+**Reference** that lives outside the skill system — a plain file, no **description**, no **steps**, not invocable — that any skill can point at. The home for shared reference that needn't fire on its own, and the only shared home two **user-invoked** skills can use, since neither has a description and so neither can fire the other.
+
+_Avoid_: doc, resource, knowledge base
+
+### Progressive Disclosure
+
+Moving **reference** down the ladder — out of SKILL.md and behind a **context pointer** — so the top stays legible. Not primarily a token optimisation; it is how the **information hierarchy** is protected. Licensed by **branching**: disclose what only some branches need, inline what every path needs, and if a pointer fires unreliably on must-have material, sharpen its wording, and pull it back inline only if that fails.
+
+_Avoid_: lazy loading, chunking
+
+### Co-location
+
+Keeping the material an agent needs at once in one place — a concept's definition, rules, and caveats under a single heading, not scattered across the file — so reading one part brings its neighbours with it. The within-file companion to the **Information Hierarchy**: the hierarchy ranks _how far down_ a piece sits; co-location decides _what sits beside it_ once there. There is no formula for the right format of a body of **reference**; the test is that a skill should read like documentation written for the agent, and grouped material reads that way where scattered material does not. Distinct from **Duplication**: that repeats one meaning in two places, where scattering fragments a single meaning across many.
+
+_Avoid_: grouping, clustering, cohesion
+
+### Sprawl
+
+_Failure mode._ A skill that is simply too long — too many lines in SKILL.md — independent of whether they are stale or repeated. Even an all-live, all-unique skill can sprawl. It costs readability (the agent wades through more before it can act, and attention thins across the excess), maintainability (every extra line is one more to keep **relevant**), and tokens. The cure is the **information hierarchy**: push **reference** down behind **context pointers**, and split by **branch** or sequence so each path carries only what it needs. Distinct from **sediment** (length from stale accumulation) and **duplication** (length from repeated meaning) — sprawl is length itself, whatever its cause.
+
+_Avoid_: bloat, length, size, verbosity
+
+## Steering
+
+The levers that shape the agent's runtime behaviour toward **Predictability**.
+
+### Branch
+
+A distinct way a skill can be invoked — a case the skill handles — so different runs take different paths through it. A skill with many steps may carry many branches; a linear one has none.
+
+_Avoid_: path, case, fork
+
+### Leading Word
+
+A compact concept — also called a _Leitwort_ — already living in the model's pretraining, that the agent thinks with while running the skill. It encodes a behavioural principle in the fewest possible tokens by invoking priors the model already holds (e.g. _lesson_, _proximal zone of development_, _fog of war_, _tracer bullets_). Repeated as a token, never as a sentence, it accumulates a distributed definition across the skill and anchors a whole region of behaviour. Coining your own works if you define it clearly, but a made-up word recruits no priors — you pay in definition tokens what a pretrained word gives free. Reach for an existing word first.
+
+A leading word serves **predictability** twice. In the body it anchors **execution** — the agent reaches for the same behaviour every time the concept appears, and inside flat reference it focuses attention on a class of thing to look for, recruiting the right checks each run. In the **description** it anchors **invocation** — and not only within the skill: when the same word lives in your prompts, your docs, and your codebase, the agent links that shared language to the skill and fires it more reliably. Word a description with the leading words you actually use when you want the skill.
+
+_Avoid_: keyword, term, motif
+
+### Completion Criterion
+
+The condition that tells the agent a unit of work is done — the target it judges against. Two properties make it a lever, not just a quality. Its **clarity** (can the agent tell done from not-done?) resists **premature completion** — a vague bound ("understanding reached") lets the agent declare done and slip to the next step; this axis needs _steps_ to bite, since premature completion is a between-steps failure. Its **demand** (how much it requires) sets **legwork** — "every modified model accounted for" forces thorough work where "produce a change list" does not — and this axis is _not_ step-bound: it can bind a body of flat reference too, which is how a skill with no steps still carries an exhaustiveness bar ("every rule applied"). The strongest criteria are both checkable and exhaustive.
+
+_Avoid_: done condition, exit condition, stopping rule
+
+### Legwork
+
+The work an agent does behind the scenes within a single step — reading files, exploring the codebase, making changes, digging up what it needs rather than offloading to the user. It lives below the step structure: never written as its own step, latent in the wording, controlled by the agent rather than the skill. The within-step counterpart to **post-completion steps**' across-step pull. Raised by a **leading word** (_comprehensive_, _thorough_) or a **completion criterion** that demands the work be exhaustive — including the demand axis applied to flat reference, which is what drives a skill of flat reference to cover all its rungs. Goes thin either when that demand is missing or when **premature completion** cuts the step short.
+
+_Avoid_: scope, effort, diligence, coverage
+
+### Post-Completion Steps
+
+The **steps** that follow the current step. Visible, they pull the agent forward into **premature completion** — the more it sees, the stronger the tug; the defence is to hide them by splitting the sequence of steps into two.
+
+_Avoid_: horizon, fog of war, lookahead
+
+### Premature Completion
+
+_Failure mode._ Ending the current step before it is genuinely done, because the agent's attention slips to being done rather than to the work. A between-steps failure: it needs **steps** to occur — a skill with no steps that quits early isn't premature completion but thin **legwork** under an unmet demand. A tug-of-war between two forces: visible **post-completion steps** (the pull forward) and the **completion criterion**'s clarity (the resistance — a sharp, checkable bar holds; a vague one gives way). Fuzziness is the necessary condition: a sharp bound resists the pull no matter how many later steps are visible, so a step that never rushes needs no defending. Two levers hold a step that does, but reach for them in order: **sharpen the bound first** — it is local and cheap. Only when the criterion is irreducibly fuzzy _and_ you actually observe the rush do you **hide the later steps** — and hiding only works across a real context boundary (a user-invoked hand-off or a subagent dispatch; an inline model-invoked call leaves the later steps in context and clears nothing). One cause of thin legwork, but distinct from it: legwork can be thin even when a step runs to full completion.
+
+_Avoid_: premature closure, the rush, rushing, shortcutting
+
+### Negation
+
+_Failure mode._ Steering by prohibition — telling the agent what _not_ to do — which drags the forbidden behaviour into context and makes it _more_ available, not less. _Don't think of an elephant_, and the elephant is all there is; _never write verbose comments_, and verbosity is the pattern the agent has just read. The negation is a weak modifier the strongly-activated concept overruns, so the ban half-reads as an instruction to do the thing. Its **leading word** is the _elephant_: whatever a prohibition names into the frame. Cure: prompt the **positive** — describe the target behaviour ("write one-line comments") so the banned one is never spoken. A prohibition earns its place only as a hard guardrail on a behaviour you cannot phrase positively; even then, pair it with the positive target so attention lands on what to do.
+
+_Avoid_: ironic rebound, don't-prompting, the pink elephant
+
+## Pruning
+
+Keeping a skill lean — each remedy paired with the failure it cures.
+
+### Single Source of Truth
+
+The desired state where each meaning lives in exactly one authoritative place, so a change to the skill's behaviour is a change in one place. **Duplication** is its violation.
+
+_Avoid_: home, canonical location
+
+### Duplication
+
+_Failure mode._ The same meaning given more than one **single source of truth**. It costs maintenance (change one place, you must change the others), costs tokens, and inflates prominence — repeating a meaning weights it on the ladder past its real rank. The accidental inverse of a **leading word**, which raises attention on purpose by repeating a token, never the meaning.
+
+_Avoid_: repetition, redundancy
+
+### Relevance
+
+Whether a line still bears on what the skill does — the lens for what to keep. A line loses relevance either by never bearing on the task (mere exposition, or a **branch** that should be disclosed) or by going stale: drifting out of date as the behaviour or world it describes changes. Shorter skills are easier to keep relevant, because each line is cheaper to check. Distinct from **no-op**: relevance asks whether a line bears on the task, not whether it changes behaviour.
+
+_Avoid_: load-bearing, staleness, freshness
+
+### Sediment
+
+_Failure mode._ Layers of old content that settle in a skill and are never cleared, because adding feels safe and removing feels risky — so stale and irrelevant lines accumulate and you must core down through them to find what is still live. The default fate of any skill without a pruning discipline; the slow erosion of **relevance**, as opposed to **duplication**'s repeated meaning.
+
+_Avoid_: accretion, bloat, cruft, rot
+
+### No-Op
+
+_Failure mode._ An instruction that changes nothing because the model already does it by default — you pay load to tell the agent what it would do anyway. The test: does a line change behaviour versus the default? A line can be perfectly **relevant** and still be a no-op. The same priors that make a **leading word** free make a no-op worthless.
+
+A leading word is a _technique_; No-Op is a _verdict_ on a line — and they cross. A leading word too weak to beat the default is a no-op (_be thorough_ when the agent is already thorough-ish), and the fix is a stronger word that passes the verdict (_relentless_), not a different technique. So the No-Op test — does it change behaviour versus the default? — is also how you grade whether a leading word is earning its repetitions. This is model-relative, not reader-relative: two people disagreeing over whether a line is a no-op disagree about the default, and settle it by running the skill, not by debate.
+
+_Avoid_: redundant instruction, restating the obvious, belaboring
diff --git a/.agents/skills/writing-great-skills/SKILL.md b/.agents/skills/writing-great-skills/SKILL.md
new file mode 100644
index 00000000000..82abd0dce26
--- /dev/null
+++ b/.agents/skills/writing-great-skills/SKILL.md
@@ -0,0 +1,83 @@
+---
+name: writing-great-skills
+description: Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
+disable-model-invocation: true
+---
+
+A skill exists to wrangle determinism out of a stochastic system. **Predictability** — the agent taking the same _process_ every run, not producing the same output — is the root virtue; every lever below serves it.
+
+**Bold terms** are defined in [`GLOSSARY.md`](GLOSSARY.md); look them up there for the full meaning.
+
+## Invocation
+
+Two choices, trading different costs:
+
+- A **model-invoked** skill keeps a **description**, so the agent can fire it autonomously _and_ other skills can reach it (you can still type its name too). It contributes to **context load** — the description sits in the window every turn. Mechanics: omit `disable-model-invocation`, and write a model-facing description with rich trigger phrasing ("Use when the user wants…, mentions…").
+- A **user-invoked** skill strips the description from the agent's reach: only you, typing its name, can invoke it — and no other skill can. Zero context load, but it spends **cognitive load**: _you_ are the index that must remember it exists. Mechanics: set `disable-model-invocation: true`; the `description` becomes human-facing — a one-line summary, trigger lists stripped.
+
+Pick model-invocation only when the agent must reach the skill on its own, or another skill must. If it only ever fires by hand, make it user-invoked and pay no context load.
+
+When user-invoked skills multiply past what you can remember, that piled-up cognitive load is cured by a **router skill**: one user-invoked skill that names the others and when to reach for each.
+
+## Writing the description
+
+A model-invoked **description** does two jobs — state what the skill is, and list the **branches** that should trigger it. Every word increases **context load**, so a description earns even harder pruning than the body:
+
+- **Front-load the skill's leading word** — the description is where it does its invocation work.
+- **One trigger per branch.** Synonyms that rename a single branch are **duplication** — "build features using TDD … asks for test-first development" is one branch written twice. Collapse them; keep only genuinely distinct branches.
+- **Cut identity that's already in the body.** Keep the description to triggers, plus any "when another skill needs…" reach clause.
+
+## Information hierarchy
+
+A skill is built from two content types — **steps** and **reference** — that mix freely: a skill can be all steps, all reference, or both. The core decision is which to use and where each sits on the **information hierarchy**, a ladder ranked by how immediately the agent needs the material:
+
+1. **In-skill step** — an ordered action in `SKILL.md`, the primary tier: what the agent does, in order. Each step ends on a **completion criterion**, the condition that tells the agent the work is done. Make it _checkable_ (can the agent tell done from not-done?) and, where it matters, _exhaustive_ ("every modified model accounted for", not "produce a change list") — a vague criterion invites **premature completion**.
+2. **In-skill reference** — a definition, rule, or fact in `SKILL.md`, consulted on demand. Often a legitimately flat peer-set (every rule of a review on one rung) — a fine arrangement, not a smell. _This skill is all reference._
+3. **External reference** — reference pushed out of `SKILL.md` into a separate file, reached by a **context pointer**, loaded only when the pointer fires. (Spans _disclosed_ reference — a sibling file like `GLOSSARY.md`, still part of the skill — through fully **external reference** that lives outside the skill system and any skill can point at.)
+
+A demanding completion criterion drives thorough **legwork** — the digging the agent does within the work — whether the skill has steps or not, since "every rule applied" binds flat reference just as "every step done" binds a sequence.
+
+Push too little down and the top bloats; push too much and you hide material the agent actually needs. That tension is the whole decision.
+
+**Progressive disclosure** is the move down the ladder — out of `SKILL.md` into a linked file — so the top stays legible. Mechanics: a linked `.md` file in the skill folder, named for what it holds (this skill discloses its full definitions to `GLOSSARY.md`). Some skills are used in more than one way, and each distinct way is a **branch** — different runs taking different paths through the skill. Branching is the cleanest disclosure test: inline what every branch needs, and push behind a pointer what only some branches reach. A **context pointer**'s _wording_, not its target, decides when and how reliably the agent reaches the material.
+
+Where the ladder decides _how far down_ a piece sits, **co-location** decides _what sits beside it_ once there: keep a concept's definition, rules, and caveats under one heading rather than scattered, so reading one part brings its neighbours with it.
+
+## When to split
+
+**Granularity** is how finely you divide skills, and each cut spends one of the two loads, so split only when the cut earns it. Two cuts:
+
+- **By invocation** — split off a **model-invoked** skill when you have a distinct **leading word** that should trigger it on its own, or another skill must reach it. You pay **context load** for the new always-loaded **description**, so that independent reach has to be worth it.
+- **By sequence** — split a run of **steps** when the steps still ahead (a step's **post-completion steps**) tempt the agent to rush the one in front of it (**premature completion**). Keeping them out of view encourages the agent to do more **legwork** on the current task.
+
+## Pruning
+
+Keep each meaning in a **single source of truth**: one authoritative place, so changing the behaviour is a one-place edit.
+
+Check every line for **relevance**: does it still bear on what the skill does?
+
+Then hunt **no-ops** sentence by sentence, not just line by line: run the no-op test on each sentence in isolation, and when one fails, delete the whole sentence rather than trim words from it. Be aggressive — most prose that fails should go, not be rewritten.
+
+## Leading words
+
+A **leading word** is a compact concept already living in the model's pretraining that the agent thinks with while running the skill (e.g. _lesson_, _fog of war_, _tracer bullets_). Repeated throughout the text (though not necessarily - a strong leading word might only be needed once), it accumulates a distributed definition and anchors a whole region of behaviour in the fewest tokens, by recruiting priors the model already holds.
+
+It serves predictability twice. In the body it anchors _execution_: the agent reaches for the same behaviour every time the word appears. In the description it anchors _invocation_: when the same word lives in your prompts, docs, and code, the agent links that shared language to the skill and fires it more reliably.
+
+Hunt for opportunities to refactor skills to use leading words. A triad spelled out at three sites (**duplication**), a description spending a sentence to gesture at one idea — each is a passage begging to **collapse** into a single token. Examples include:
+
+- "fast, deterministic, low-overhead" -> _tight_ — one quality restated across a phase — into a single pretrained word (a _tight_ loop).
+- "a loop you believe in" -> _red_ — converts a fuzzy gate into a binary observable state (the loop goes _red_ on the bug, or it doesn't).
+
+You win twice over: fewer tokens, _and_ a sharper hook for the agent to hang its thinking on. Assume every skill is carrying restatements that leading words retire — go find them.
+
+## Failure modes
+
+Use these to diagnose issues the user may be having with the skill.
+
+- **Premature completion** — ending a step before it's genuinely done, attention slipping to _being done_. Defence, in order: sharpen the completion criterion first (cheap, local); only if it is irreducibly fuzzy _and_ you observe the rush, hide the post-completion steps by splitting (the sequence cut).
+- **Duplication** — the same meaning in more than one place. Costs maintenance and tokens, and inflates a meaning's prominence on the ladder past its real rank.
+- **Sediment** — stale layers that settle because adding feels safe and removing feels risky. The default fate of any skill without a pruning discipline.
+- **Sprawl** — a skill simply too long, even when every line is live and unique. Hurts readability and maintainability and wastes tokens. The cure is the ladder: disclose **reference** behind pointers, and split by **branch** or sequence so each path carries only what it needs.
+- **No-op** — a line the model already obeys by default, so you pay load to say nothing. The test: does it change behaviour versus the default? A weak leading word (_be thorough_ when the agent is already thorough-ish) is a no-op; the fix is a stronger word (_relentless_), not a different technique.
+- **Negation** — steering by prohibition backfires: _don't think of an elephant_ names the elephant and makes it more available, not less. Prompt the **positive** — state the target behaviour so the banned one is never spoken; keep a prohibition only as a hard guardrail you can't phrase positively, and even then pair it with what to do instead.
diff --git a/.agents/skills/writing-great-skills/agents/openai.yaml b/.agents/skills/writing-great-skills/agents/openai.yaml
new file mode 100644
index 00000000000..d677a13f4b6
--- /dev/null
+++ b/.agents/skills/writing-great-skills/agents/openai.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Writing Great Skills"
+  short_description: "Principles for predictable skills"
+policy:
+  allow_implicit_invocation: false
diff --git a/.scratch/pob-cursor-agent-spec-body.md b/.scratch/pob-cursor-agent-spec-body.md
new file mode 100644
index 00000000000..90e0fee9f48
--- /dev/null
+++ b/.scratch/pob-cursor-agent-spec-body.md
@@ -0,0 +1,165 @@
+## Problem Statement
+
+As a Path of Exile 1 player using Path of Building, I want an AI build advisor that understands my live build and PoE1 sources, so I can get grounded suggestions and apply them safely without leaving PoB or paying a second LLM vendor. Today I either leave PoB for chat tools that do not see my build, or risk PoE2/wrong-game contamination and irreversible edits with no clear undo.
+
+## Solution
+
+A personal (fork-only) **PoB Cursor Agent**: PoB remains build authority; a local **sidecar** owns a floating Agent Window and talks to **Cursor** via the local SDK using the owner's user API key. The agent advises on the current build (and separate research threads), proposes multi-surface changes as ops the user can inspect, then **Apply / Reject / Undo** over a localhost HTTP/JSON bridge. PoE2 Exclusion is fail-closed. A git **Knowledge Pack** supplies allow/deny policy and notes; Patch-Notes Sync always opens a PR.
+
+Canonical discovery docs: `docs/pob-cursor-agent/` (map: https://github.com/waltersmike/PathOfBuilding/issues/1).
+
+## User Stories
+
+1. As a PoB user, I want a floating Agent Window beside PoB, so that I can chat about my build without blocking the main PoB UI.
+2. As a PoB user, I want the open window to be a narrow chat stack, so that it fits a second monitor and does not dominate the desk.
+3. As a PoB user, I want build and research thread chips, so that I can separate build-scoped advice from general PoE1 research.
+4. As a PoB user, I want streaming replies with citations, so that I can see answers arrive and judge their sources.
+5. As a PoB user, I want a proposal drawer with Apply, Reject, and Undo, so that suggestions never mutate my build without confirmation.
+6. As a PoB user, I want a usage meter and model pill showing Composer 2.5 by default, so that I know spend and which model I am on.
+7. As a PoB user, I want closing the window to leave a compact connected pill, so that I can reopen quickly without hunting menus.
+8. As a PoB user, I want PoB to spawn the sidecar for me, so that I do not run a separate manual process every session.
+9. As a PoB user, I want the sidecar to shut down with PoB by default, so that orphan agent processes do not linger.
+10. As a PoB user, I want every build-thread turn to include a full build export (`SaveDB`), so that advice is grounded in my live tree, items, skills, and config.
+11. As a PoB user, I want research threads that do not require a build, so that I can ask league/mechanic questions independently.
+12. As a PoB user, I want proposals that may touch tree, items/gems, and Configuration together, so that coherent multi-surface changes arrive as one unit.
+13. As a PoB user, I want Apply to be all-or-nothing, so that I never end up with a half-applied proposal.
+14. As a PoB user, I want Reject to discard the proposal with no build change, so that I can ignore bad advice safely.
+15. As a PoB user, I want Undo to restore the pre-Apply full-build snapshot, so that one confirmed Apply is reversible in one step.
+16. As a PoB user, I want the in-window diff to show a human summary derived from ops JSON, so that I can review intent without reading raw XML.
+17. As a PoB user, I want optional manual handoff into Compare, so that I can use PoB's before/after when I choose—not as a required Apply step.
+18. As a PoB user, I want PoE2-risk Apply attempts to hard-refuse with a clear explanation, so that wrong-game data never lands on my build.
+19. As a PoB user, I want contaminated research/chat answers to be refused and automatically re-asked on allowlisted PoE1 sources, so that I am not shown PoE2 "for comparison."
+20. As a PoB user, I want denylisted hosts and paths blocked before the model consumes them, so that PoE2 lookalikes never enter context.
+21. As a PoB user, I want same-named skills/items absent from PoB/PoE1 id sets to fail Apply, so that name collisions cannot smuggle PoE2 entities in.
+22. As a PoB user, I want no silent stripping of bad citations or ops, so that failures are visible and honest.
+23. As a PoB user, I want a soft warning near ~80% of my usage cap, so that I can slow down before hard stop.
+24. As a PoB user, I want a hard stop at 100% of the configurable cap, so that spend cannot runaway without my raising the cap.
+25. As a PoB user, I want to raise or reset the cap after a hard stop, so that I can continue when I choose.
+26. As a PoB user, I want per-thread opt-up to a more capable Cursor model, so that hard problems can use a stronger model without changing the default.
+27. As a PoB user, I want billing only against my Cursor subscription via my user API key, so that I do not pay a second LLM vendor.
+28. As a PoB user, I want thread history to resume via Cursor agent ids, so that conversations survive sidecar restarts.
+29. As a PoB user, I want a clear error if the sidecar fails to spawn or dies, so that I am not left thinking the agent is working.
+30. As a PoB user, I want Cursor auth and rate-limit failures surfaced without unbounded retries, so that failures are diagnosable.
+31. As a PoB user, I want Knowledge Pack notes with active / possibly_stale / retired status, so that the agent distrusts stale guidance and ignores retired notes.
+32. As a PoB user, I want a pack-level staleness warning when Sync detects a newer patch, so that I know advice may lag the league.
+33. As a maintainer of the personal fork, I want Knowledge Pack policy and notes in git under `knowledge-pack/`, so that policy is reviewable and versioned.
+34. As a maintainer, I want Patch-Notes Sync to always open a PR with human merge, so that pack updates never auto-merge quietly.
+35. As a maintainer, I want Sync to prefer PoE1 Patch Notes forum HTML (`3.x`), so that PoE2 Early Access forum content is excluded.
+36. As a maintainer, I want allowlist/denylist seeds covering official PoE1, poewiki, poe.ninja/poe1, and known PoE2 traps, so that Exclusion has concrete data.
+37. As an implementer, I want tools that request snapshots and submit proposals without bypassing user confirm, so that Apply remains human-gated.
+38. As an implementer, I want the Agent Window UX to match the locked prototype (open stack+drawer; closed pill), so that chrome is not rediscovered.
+39. As an implementer, I want this feature only on the personal fork, so that upstream PathOfBuildingCommunity is never targeted.
+40. As a PoB user, I do not want a PoB power-user tutor as the primary product, so that scope stays on build advising.
+41. As a PoB user, I do not want PoE2 support or dual-game advice, so that Exclusion stays absolute.
+42. As a PoB user, I do not want fine-tuning or a second LLM vendor, so that the stack stays Cursor-only plus non-LLM sidecar.
+
+## Implementation Decisions
+
+### Architecture
+
+- Dual process: **PoB (Lua)** is build authority; **sidecar** owns Agent Window UI, Cursor local SDK, usage metering, PoE2 gates, and tool/MCP surface.
+- Transport between PoB and sidecar: **localhost HTTP/JSON** (not stdio as the bus). PoB spawns the sidecar.
+- Cursor: local agent loop (`@cursor/sdk` / `cursor-sdk`); owner **user API key**; Cloud Agents are not the live-PoB path.
+- Default model: **Composer 2.5** (not Fast); per-thread opt-up allowed.
+- Knowledge Pack at repo-root `knowledge-pack/` with `policy/`, `notes/`, and pack `meta`; Sync updates via PR only.
+
+### PoB-facing modules (conceptual)
+
+- Agent bridge module: spawn/monitor sidecar; serve/consume bridge message kinds (snapshot export, apply/reject/undo, guard/usage signals as needed).
+- Snapshot: reuse full-build `SaveDB` (XML; optional share-code encoding).
+- Apply orchestrator: all-or-nothing multi-surface apply; capture pre-Apply `SaveDB` for Undo; Reject leaves build unchanged.
+- Compare handoff: reuse existing import-as-comparison path optionally; not on the Apply critical path.
+- Do not use modal `PopupDialog` as the chat surface.
+
+### Sidecar-facing modules (conceptual)
+
+- Agent Window UI matching prototype variant D (narrow chat + proposal drawer; compact pill when closed).
+- Thread multiplex: `threadType: build | research` + `buildId` when build-scoped; map each thread to a durable Cursor `agentId`.
+- Cursor adapter: create/resume agents, stream turns, expose local custom tools and/or MCP for PoB operations (tools must not bypass Apply confirm).
+- Usage guardrails: soft warn ~80%; hard stop at 100% of configurable cap (numeric default implementer-chosen).
+- PoE2 Exclusion runtime: source/tool gates + output guard + Apply id checks; research contamination → refuse + automatic re-ask.
+
+### Bridge message kinds (normative; exact route/field names implementer-chosen)
+
+- Build snapshot/export
+- Chat turn
+- Proposal (canonical **ops JSON** with PoB ids + human summary)
+- Apply / Reject / Undo
+- Usage status
+- PoE2-guard signals
+
+### Proposal / Apply semantics
+
+- Ops JSON is canonical for validation and Apply; UI summary is derived.
+- Apply validates PoE2 / PoB-id guards **before** mutation; failure hard-refuses entire Apply (no partial, no override).
+- Undo snapshot held until next Apply or explicit discard.
+
+### Prototype-encoded UX (from `docs/pob-cursor-agent/prototype/agent-window`)
+
+Open chrome = chat stack + bottom proposal drawer (Apply / Reject / Undo) + usage meter + model pill; closed = compact connected pill (not dismiss-only). Rejected for v1: always-on split proposal pane; tabbed Chat/Proposal/History as primary open layout.
+
+### Deferred implementer details (not product rediscovery)
+
+- Exact allowlist/denylist file contents (seed sets documented in Knowledge Pack design)
+- Concrete numeric usage-cap default
+- Window/pill placement persistence
+- Friend handoff runbook
+- Sync job cadence / operator
+- Exact HTTP routes, JSON field names, and ops vocabulary
+
+### Fork policy
+
+- Build only on `waltersmike/PathOfBuilding`. Never for upstream merge.
+
+## Testing Decisions
+
+### What makes a good test
+
+- Assert **external behavior** at agreed seams (protocol outcomes, build state before/after, policy allow/deny/refuse), not private implementation details or UI pixels.
+- Prefer highest seams; mock Cursor network; do not require live Cursor or live PoE websites for the core suite.
+- Fail-closed PoE2 cases must be explicit tests (URL/domain deny, same-name Apply refuse, mixed citation refuse+re-ask).
+
+### Seams (agreed)
+
+1. **Primary — Agent Bridge contract (localhost HTTP/JSON)**
+   - PoB/Lua side: Busted + `HeadlessWrapper` — `SaveDB` export, all-or-nothing Apply, Undo restores pre-Apply snapshot.
+   - Sidecar side: in-process HTTP with Cursor SDK mocked — turn packaging, proposal handoff, guard/usage signals.
+2. **Secondary — PoE2 / Knowledge Pack policy (pure)**
+   - Pure functions over policy data + ops/citations for allow/deny, same-name Apply refusal, mixed-citation re-ask.
+   - Mandatory fail-closed acceptance suite lives here and/or is exercised through Bridge Apply refuse.
+
+### Explicitly not v1 automated seams
+
+- Agent Window layout/pixel tests (prototype is the visual reference).
+- Live Cursor API calls.
+- Full Patch-Notes Sync scraper E2E (PR-only policy is the product rule; scraper can be thinner/manual later).
+
+### Modules under test
+
+- PoB agent bridge / apply-undo orchestration (via HeadlessWrapper).
+- Sidecar bridge handlers and usage/guard signaling (mocked Cursor).
+- Knowledge Pack policy evaluators.
+
+### Prior art in this codebase
+
+- Busted under `spec/System` (Docker/`busted --lua=luajit`); build lifecycle via `HeadlessWrapper` (`newBuild`, load XML).
+- Import/reimport and tree/item specs show how to assert build state after mutations without the GUI.
+- Sidecar tests will be new (Node 22.13+ or Python) alongside the Lua suite; keep them behavior-focused at the HTTP contract.
+
+## Out of Scope
+
+- Upstream PathOfBuildingCommunity contribution or merge of this feature
+- PoE2 support or dual-game advice
+- Fine-tuning a model; second LLM vendor
+- PoB power-user agent as primary job (teach UI / debug imports as the product)
+- Embedding Cursor IDE chat UI or reading Cursor IDE chat history
+- Auto-merge of Knowledge Pack Sync PRs
+- Friend handoff runbook and numeric cap default as blockers to starting implementation (ship sensible defaults)
+
+## Further Notes
+
+- Wayfinder map (closed): https://github.com/waltersmike/PathOfBuilding/issues/1
+- Handoff pack index: `docs/pob-cursor-agent/README.md`
+- Research: `docs/research/cursor-sdk-pob-agent.md`, `docs/research/pob-agent-integration-surfaces.md`, `docs/research/poe1-knowledge-sources-patch-notes.md`
+- ADRs under `docs/pob-cursor-agent/adr/` (sidecar UI, Apply/Undo, Cursor local SDK, PoE2 fail-closed, Knowledge Pack PR Sync)
+- Next skill after this spec: `/to-tickets` to split into tracer-bullet implementation tickets with blocking edges
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 00000000000..63de4b8b9ef
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,13 @@
+## Agent skills
+
+### Issue tracker
+
+Issues live in GitHub Issues for this repo. See `docs/agents/issue-tracker.md`.
+
+### Triage labels
+
+Five canonical triage roles mapped to GitHub labels. See `docs/agents/triage-labels.md`.
+
+### Domain docs
+
+Single-context layout: root `CONTEXT.md` and `docs/adr/`. See `docs/agents/domain.md`.
diff --git a/Launch-Dev.bat b/Launch-Dev.bat
new file mode 100644
index 00000000000..0db7f20a386
--- /dev/null
+++ b/Launch-Dev.bat
@@ -0,0 +1,3 @@
+@echo off
+cd /d "%~dp0"
+start "" "%~dp0runtime\Path{space}of{space}Building.exe"
diff --git a/Sync-Upstream.bat b/Sync-Upstream.bat
new file mode 100644
index 00000000000..1ed05c94680
--- /dev/null
+++ b/Sync-Upstream.bat
@@ -0,0 +1,3 @@
+@echo off
+cd /d "%~dp0"
+powershell -NoProfile -ExecutionPolicy Bypass -File "%~dp0Sync-Upstream.ps1" %*
diff --git a/Sync-Upstream.ps1 b/Sync-Upstream.ps1
new file mode 100644
index 00000000000..5ccd243c2c3
--- /dev/null
+++ b/Sync-Upstream.ps1
@@ -0,0 +1,142 @@
+#Requires -Version 5.1
+<#
+.SYNOPSIS
+    Syncs this fork's local `dev` branch with upstream PathOfBuildingCommunity/PathOfBuilding.
+
+.DESCRIPTION
+    Follows CONTRIBUTING.md "Keeping your fork up to date":
+      1. Ensure the `upstream` remote exists
+      2. Fetch upstream
+      3. Check out `dev`
+      4. Rebase onto upstream/dev
+      5. Optionally push to origin (use -Push)
+
+.PARAMETER Push
+    After a successful rebase, force-push the updated `dev` branch to origin.
+    Required when the rebase rewrites history relative to origin/dev.
+
+.PARAMETER Branch
+    Local branch to update. Defaults to `dev`.
+
+.EXAMPLE
+    .\Sync-Upstream.ps1
+
+.EXAMPLE
+    .\Sync-Upstream.ps1 -Push
+#>
+[CmdletBinding()]
+param(
+    [switch]$Push,
+    [string]$Branch = "dev"
+)
+
+$ErrorActionPreference = "Stop"
+Set-Location -LiteralPath $PSScriptRoot
+
+$UpstreamUrl = "https://github.com/PathOfBuildingCommunity/PathOfBuilding.git"
+
+function Write-Step([string]$Message) {
+    Write-Host "`n==> $Message" -ForegroundColor Cyan
+}
+
+function Assert-GitRepo {
+    git rev-parse --is-inside-work-tree 2>$null | Out-Null
+    if ($LASTEXITCODE -ne 0) {
+        throw "Not inside a git repository: $PSScriptRoot"
+    }
+}
+
+function Get-Remotes {
+    git remote 2>$null
+}
+
+Assert-GitRepo
+
+# Block on modified/staged tracked files only; untracked files are fine.
+$dirty = git status --porcelain --untracked-files=no
+if ($dirty) {
+    throw @"
+Working tree has uncommitted changes to tracked files. Commit, stash, or discard them first:
+
+$dirty
+"@
+}
+
+Write-Step "Ensuring upstream remote"
+$remotes = @(Get-Remotes)
+if ($remotes -notcontains "upstream") {
+    Write-Host "Adding upstream -> $UpstreamUrl"
+    git remote add upstream $UpstreamUrl
+    if ($LASTEXITCODE -ne 0) { throw "Failed to add upstream remote." }
+} else {
+    $currentUrl = (git remote get-url upstream).Trim()
+    Write-Host "upstream already configured: $currentUrl"
+}
+
+Write-Step "Fetching from upstream"
+git fetch upstream
+if ($LASTEXITCODE -ne 0) { throw "git fetch upstream failed." }
+
+$upstreamRef = "upstream/$Branch"
+git rev-parse --verify "$upstreamRef^{commit}" 2>$null | Out-Null
+if ($LASTEXITCODE -ne 0) {
+    throw "Upstream branch '$upstreamRef' not found after fetch."
+}
+
+Write-Step "Checking out $Branch"
+git checkout $Branch
+if ($LASTEXITCODE -ne 0) { throw "Failed to check out '$Branch'." }
+
+$before = (git rev-parse HEAD).Trim()
+$upstreamTip = (git rev-parse $upstreamRef).Trim()
+
+if ($before -eq $upstreamTip) {
+    Write-Host "`nAlready up to date with $upstreamRef." -ForegroundColor Green
+} else {
+    $behind = (git rev-list --count "HEAD..$upstreamRef").Trim()
+    $ahead = (git rev-list --count "$upstreamRef..HEAD").Trim()
+    Write-Host "Local $Branch is $behind commit(s) behind and $ahead commit(s) ahead of $upstreamRef."
+
+    Write-Step "Rebasing $Branch onto $upstreamRef"
+    git rebase $upstreamRef
+    if ($LASTEXITCODE -ne 0) {
+        Write-Host @"
+
+Rebase failed (likely conflicts). Resolve them, then run:
+  git add <resolved-files>
+  git rebase --continue
+
+Or abort with:
+  git rebase --abort
+"@ -ForegroundColor Yellow
+        exit 1
+    }
+
+    $after = (git rev-parse HEAD).Trim()
+    Write-Host "`nRebase complete: $before -> $after" -ForegroundColor Green
+}
+
+if ($Push) {
+    Write-Step "Force-pushing $Branch to origin"
+    git push -f origin $Branch
+    if ($LASTEXITCODE -ne 0) { throw "git push -f origin $Branch failed." }
+    Write-Host "Pushed origin/$Branch." -ForegroundColor Green
+} else {
+    $localTip = (git rev-parse HEAD).Trim()
+    $originTip = $null
+    git rev-parse --verify "origin/$Branch^{commit}" 2>$null | Out-Null
+    if ($LASTEXITCODE -eq 0) {
+        $originTip = (git rev-parse "origin/$Branch").Trim()
+    }
+
+    if ($originTip -and $localTip -ne $originTip) {
+        Write-Host @"
+
+Local $Branch differs from origin/$Branch.
+To update your fork on GitHub, re-run with -Push:
+  .\Sync-Upstream.ps1 -Push
+"@ -ForegroundColor Yellow
+    } else {
+        Write-Host "`nDone. Use -Push if you also want to update origin/$Branch." -ForegroundColor Green
+    }
+}
diff --git a/docs/agents/domain.md b/docs/agents/domain.md
new file mode 100644
index 00000000000..b548c538d60
--- /dev/null
+++ b/docs/agents/domain.md
@@ -0,0 +1,51 @@
+# Domain Docs
+
+How the engineering skills should consume this repo's domain documentation when exploring the codebase.
+
+## Before exploring, read these
+
+- **`CONTEXT.md`** at the repo root, or
+- **`CONTEXT-MAP.md`** at the repo root if it exists — it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
+- **`docs/adr/`** — read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
+
+If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `/domain-modeling` skill (reached via `/grill-with-docs` and `/improve-codebase-architecture`) creates them lazily when terms or decisions actually get resolved.
+
+## File structure
+
+Single-context repo (most repos):
+
+```
+/
+├── CONTEXT.md
+├── docs/adr/
+│   ├── 0001-event-sourced-orders.md
+│   └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+Multi-context repo (presence of `CONTEXT-MAP.md` at the root):
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/adr/                          ← system-wide decisions
+└── src/
+    ├── ordering/
+    │   ├── CONTEXT.md
+    │   └── docs/adr/                  ← context-specific decisions
+    └── billing/
+        ├── CONTEXT.md
+        └── docs/adr/
+```
+
+## Use the glossary's vocabulary
+
+When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
+
+If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
+
+## Flag ADR conflicts
+
+If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
+
+> _Contradicts ADR-0007 (event-sourced orders) — but worth reopening because…_
diff --git a/docs/agents/issue-tracker.md b/docs/agents/issue-tracker.md
new file mode 100644
index 00000000000..82cfbf5b191
--- /dev/null
+++ b/docs/agents/issue-tracker.md
@@ -0,0 +1,45 @@
+# Issue tracker: GitHub
+
+Issues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.
+
+## Conventions
+
+- **Create an issue**: `gh issue create --title "..." --body "..."`. Use a heredoc for multi-line bodies.
+- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.
+- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.
+- **Comment on an issue**: `gh issue comment <number> --body "..."`
+- **Apply / remove labels**: `gh issue edit <number> --add-label "..."` / `--remove-label "..."`
+- **Close**: `gh issue close <number> --comment "..."`
+
+Infer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.
+
+## Pull requests as a triage surface
+
+**PRs as a request surface: no.** _(Set to `yes` if this repo treats external PRs as feature requests; `/triage` reads this flag.)_
+
+When set to `yes`, PRs run through the same labels and states as issues, using the `gh pr` equivalents:
+
+- **Read a PR**: `gh pr view <number> --comments` and `gh pr diff <number>` for the diff.
+- **List external PRs for triage**: `gh pr list --state open --json number,title,body,labels,author,authorAssociation,comments` then keep only `authorAssociation` of `CONTRIBUTOR`, `FIRST_TIME_CONTRIBUTOR`, or `NONE` (drop `OWNER`/`MEMBER`/`COLLABORATOR`).
+- **Comment / label / close**: `gh pr comment`, `gh pr edit --add-label`/`--remove-label`, `gh pr close`.
+
+GitHub shares one number space across issues and PRs, so a bare `#42` may be either — resolve with `gh pr view 42` and fall back to `gh issue view 42`.
+
+## When a skill says "publish to the issue tracker"
+
+Create a GitHub issue.
+
+## When a skill says "fetch the relevant ticket"
+
+Run `gh issue view <number> --comments`.
+
+## Wayfinding operations
+
+Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
+
+- **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. `gh issue create --label wayfinder:map`.
+- **Child ticket**: an issue linked to the map as a GitHub sub-issue (`gh api` on the sub-issues endpoint). Where sub-issues aren't enabled, add the child to a task list in the map body and put `Part of #<map>` at the top of the child body. Labels: `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
+- **Blocking**: GitHub's **native issue dependencies** — the canonical, UI-visible representation. Add an edge with `gh api --method POST repos/<owner>/<repo>/issues/<child>/dependencies/blocked_by -F issue_id=<blocker-db-id>`, where `<blocker-db-id>` is the blocker's numeric **database id** (`gh api repos/<owner>/<repo>/issues/<n> --jq .id`, _not_ the `#number` or `node_id`). GitHub reports `issue_dependencies_summary.blocked_by` (open blockers only — the live gate). Where dependencies aren't available, fall back to a `Blocked by: #<n>, #<n>` line at the top of the child body. A ticket is unblocked when every blocker is closed.
+- **Frontier query**: list the map's open children (`gh issue list --state open`, scoped to the map's sub-issues / task list), drop any with an open blocker (`issue_dependencies_summary.blocked_by > 0`, or an open issue in the `Blocked by` line) or an assignee; first in map order wins.
+- **Claim**: `gh issue edit <n> --add-assignee @me` — the session's first write.
+- **Resolve**: `gh issue comment <n> --body "<answer>"`, then `gh issue close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.
diff --git a/docs/agents/triage-labels.md b/docs/agents/triage-labels.md
new file mode 100644
index 00000000000..b716855d485
--- /dev/null
+++ b/docs/agents/triage-labels.md
@@ -0,0 +1,15 @@
+# Triage Labels
+
+The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
+
+| Label in mattpocock/skills | Label in our tracker | Meaning                                  |
+| -------------------------- | -------------------- | ---------------------------------------- |
+| `needs-triage`             | `needs-triage`       | Maintainer needs to evaluate this issue  |
+| `needs-info`               | `needs-info`         | Waiting on reporter for more information |
+| `ready-for-agent`          | `ready-for-agent`    | Fully specified, ready for an AFK agent  |
+| `ready-for-human`          | `ready-for-human`    | Requires human implementation            |
+| `wontfix`                  | `wontfix`            | Will not be actioned                     |
+
+When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
+
+Edit the right-hand column to match whatever vocabulary you actually use.
diff --git a/docs/pob-cursor-agent/ARCHITECTURE.md b/docs/pob-cursor-agent/ARCHITECTURE.md
new file mode 100644
index 00000000000..12d346f2574
--- /dev/null
+++ b/docs/pob-cursor-agent/ARCHITECTURE.md
@@ -0,0 +1,105 @@
+# Architecture — PoB Cursor Agent
+
+System shape for the personal PoB build-advisor agent. Product behavior lives in [PRD.md](./PRD.md); irreversible forks live in [adr/](./adr/).
+
+## 1. Context diagram
+
+```text
+┌─────────────────────────────────────────────────────────────┐
+│  Desktop (owner machine)                                    │
+│                                                             │
+│  ┌──────────────────────┐     localhost HTTP/JSON           │
+│  │ Path of Building     │◄──────────────────────────────────┤
+│  │ (Lua / SimpleGraphic)│                                   │
+│  │                      │     spawn process                 │
+│  │  • build authority   │──────────────────────┐            │
+│  │  • SaveDB snapshot   │                      │            │
+│  │  • Apply / Undo      │                      ▼            │
+│  │  • optional Compare  │           ┌─────────────────────┐ │
+│  └──────────────────────┘           │ Sidecar (Node 22+   │ │
+│                                       │  or Python)         │ │
+│                                       │  • Agent Window UI  │ │
+│                                       │  • threads ↔ agentId│ │
+│                                       │  • usage caps       │ │
+│                                       │  • PoE2 guards      │ │
+│                                       │  • @cursor/sdk      │ │
+│                                       └─────────┬───────────┘ │
+└─────────────────────────────────────────────────┼───────────┘
+                                                  │ local agent loop
+                                                  ▼
+                                        ┌─────────────────────┐
+                                        │ Cursor (hosted LLM) │
+                                        │  user API key bill  │
+                                        └─────────────────────┘
+
+External (tools / Sync, not in hot path of every chat):
+  knowledge-pack/   ← git; Sync opens PRs
+  allowlisted PoE1 web sources (research tools)
+```
+
+## 2. Component responsibilities
+
+| Component | Owns | Does not own |
+| --- | --- | --- |
+| **PoB (Lua)** | Live build state; `SaveDB` export; Apply/Undo orchestration against tabs; spawning the sidecar | Chat UI; Cursor auth; model choice; Knowledge Pack editing |
+| **Sidecar** | Floating Agent Window; Cursor SDK local runtime; thread↔`agentId` map; usage metering; tool/MCP surface; PoE2 gates on chat/research and pre-Apply ops | Authoritative build mutation without PoB confirm path |
+| **Cursor** | Inference + durable agent transcripts (`agentId`) | IDE chat history reuse; personal hard-budget API; embeddable chat widget |
+| **Knowledge Pack (git)** | Allow/deny policy data; mechanic notes; pack `meta` patch/generation | Runtime enforcement (sidecar); auto-merge Sync |
+
+## 3. Key flows
+
+### 3.1 Chat turn (build thread)
+
+1. PoB (or sidecar on demand) obtains full build XML via `buildMode:SaveDB`.
+2. Sidecar sends turn to Cursor local agent with snapshot + tools.
+3. Stream renders in Agent Window; citations checked against allowlist.
+4. Optional Proposal (ops JSON) lands in proposal drawer.
+
+### 3.2 Apply / Reject / Undo
+
+1. User **Apply** → sidecar validates ops (PoE2 / PoB-id guards) → PoB captures pre-Apply `SaveDB` → PoB applies all-or-nothing → success or hard refuse.
+2. **Reject** → discard proposal; no mutation.
+3. **Undo** → PoB restores pre-Apply snapshot (held until next Apply or discard).
+
+### 3.3 Research turn
+
+Same Cursor path without requiring a build snapshot (or with optional context). Contaminated answers refuse + auto re-ask on allowlisted sources.
+
+### 3.4 Patch-Notes Sync (offline / maintainer)
+
+Scraper or job reads PoE1 Patch Notes forum HTML → proposes updates under `knowledge-pack/notes/` (+ `meta`) → **always opens a PR**; human merge required.
+
+## 4. Integration seams (from research)
+
+| Need | Verdict | Detail |
+| --- | --- | --- |
+| Floating UI | **Sidecar window** (chosen) | Lua has no second OS window; `PopupDialog` is modal |
+| Snapshot | **Reuse** `SaveDB` | Strongest seam |
+| Apply | **Invent** cross-tab orchestrator + rollback | Per-tab helpers exist; no proposal transaction today |
+| Compare | **Reuse** optional import-as-comparison | Not on Apply critical path |
+| IPC | **Invent** localhost HTTP/JSON | Host has spawn/`lcurl`/files; no agent protocol |
+
+Full write-up: [docs/research/pob-agent-integration-surfaces.md](../research/pob-agent-integration-surfaces.md).
+
+## 5. ADR index
+
+| ADR | Decision |
+| --- | --- |
+| [0001-sidecar-owned-agent-window.md](./adr/0001-sidecar-owned-agent-window.md) | Agent Window lives in the sidecar, not an in-PoB panel |
+| [0002-apply-all-or-nothing-savedb-undo.md](./adr/0002-apply-all-or-nothing-savedb-undo.md) | Multi-surface proposals; all-or-nothing Apply; SaveDB Undo |
+| [0003-cursor-local-sdk-user-key.md](./adr/0003-cursor-local-sdk-user-key.md) | Cursor local SDK + owner user API key; no second LLM |
+| [0004-poe2-exclusion-fail-closed.md](./adr/0004-poe2-exclusion-fail-closed.md) | Gates + output guard; Apply hard refuse; research re-ask |
+| [0005-knowledge-pack-git-pr-sync.md](./adr/0005-knowledge-pack-git-pr-sync.md) | Repo-root `knowledge-pack/`; Sync via PR only |
+
+## 6. Wire schemas (deferred naming)
+
+Minimum **message kinds** between PoB and sidecar (names exactable at implement time):
+
+- Build snapshot / export
+- Chat turn
+- Proposal (ops JSON)
+- Apply / Reject / Undo
+- Usage status
+- PoE2-guard signals
+
+Exact HTTP routes and ops vocabulary are map fog — behavior above is normative; identifiers are not.
diff --git a/docs/pob-cursor-agent/CURSOR-INTEGRATION.md b/docs/pob-cursor-agent/CURSOR-INTEGRATION.md
new file mode 100644
index 00000000000..869c2bf417d
--- /dev/null
+++ b/docs/pob-cursor-agent/CURSOR-INTEGRATION.md
@@ -0,0 +1,101 @@
+# Cursor integration guide
+
+How the sidecar talks to Cursor and what surface it exposes to PoB. Product UX: [PRD.md](./PRD.md). ADR: [adr/0003-cursor-local-sdk-user-key.md](./adr/0003-cursor-local-sdk-user-key.md).
+
+**Research basis:** [docs/research/cursor-sdk-pob-agent.md](../research/cursor-sdk-pob-agent.md).
+
+## 1. Auth and billing
+
+| Item | Decision |
+| --- | --- |
+| Mechanism | Owner **user API key** (`CURSOR_API_KEY` or SDK `apiKey`) |
+| Billing | Owner's Cursor subscription pools (same pricing class as IDE) |
+| Avoid | Team Admin keys (unsupported); treating Cloud Agents as the live-PoB path |
+| Friend handoff | Share key out-of-band; dedicated runbook deferred |
+
+## 2. Runtime shape
+
+| Item | Decision |
+| --- | --- |
+| SDK | `@cursor/sdk` (TypeScript, Node **22.13+**) or `cursor-sdk` (Python) |
+| Mode | **Local** agent loop in the sidecar process |
+| Inference | Always Cursor-hosted (“local” ≠ local model) |
+| Cloud Agents | Not for live build advice beside PoB |
+
+## 3. Threads and history
+
+| Item | Decision |
+| --- | --- |
+| Thread types | `build` and `research` |
+| Mapping | Each thread ↔ durable Cursor `agentId` |
+| Resume | `Agent.resume` / send follow-ups; list via `Agent.messages.list` / conversation APIs |
+| IDE history | **Not available** — do not promise Cursor IDE chat reuse |
+| UI | Custom Agent Window streams SDK events |
+
+Build-scoped threads carry `buildId` (sidecar multiplexes).
+
+## 4. Tools / MCP
+
+Sidecar exposes PoB operations to the agent via **local `customTools` and/or MCP** (local-only; cloud custom tools throw). Typical tools wrap:
+
+- Request/refresh build snapshot
+- Submit proposal ops for UI
+- Trigger Apply / Reject / Undo (user-confirmed in UI — tools must not bypass confirm)
+- Knowledge Pack / allowlisted fetch helpers
+- Usage status
+
+Exact tool names deferred; behavior is normative.
+
+## 5. Usage guardrails (app-level)
+
+Cursor exposes per-run `TokenUsage` and plan/`RateLimitError` signals but **no personal hard-budget API**. Sidecar enforces:
+
+| Threshold | Behavior |
+| --- | --- |
+| ~80% of configurable cap | Soft warn in UI |
+| 100% | **Hard stop** new turns until cap raised/reset |
+
+| Model | Decision |
+| --- | --- |
+| Default | **Composer 2.5** (standard — **not** Fast) |
+| Opt-up | Per-thread allow more capable Cursor models |
+| Numeric default cap | Deferred — ship configurable |
+
+## 6. PoB ↔ sidecar message surface
+
+Transport: **localhost HTTP/JSON** (not stdio as the PoB↔sidecar bus). PoB **spawns** the sidecar.
+
+Minimum message kinds:
+
+| Kind | Direction (typical) | Role |
+| --- | --- | --- |
+| Build snapshot/export | PoB → sidecar | Full `SaveDB` XML (and metadata) each turn / on demand |
+| Chat turn | UI → sidecar → Cursor | User text + thread ids |
+| Proposal | sidecar → UI | Ops JSON + human summary |
+| Apply / Reject / Undo | UI → sidecar → PoB | Confirm path; Undo uses pre-Apply snapshot |
+| Usage status | sidecar → UI | Meter + warn/stop |
+| PoE2-guard signals | sidecar → UI / PoB | Refuse reasons; Apply hard-fail |
+
+Exact route paths and JSON field names are deferred (map fog). Implementers must preserve kinds and semantics above.
+
+## 7. Lifecycle
+
+1. User opens Agent (or PoB auto-starts sidecar with BUILD mode).
+2. Sidecar loads API key, resumes or creates `agentId`s for threads.
+3. Turns stream until user collapses to pill or exits PoB.
+4. On PoB exit: sidecar shutdown policy is implementer choice (die with parent vs linger) — prefer **die with parent** unless a documented reason not to.
+
+## 8. Hard blockers (do not design around)
+
+From research — treat as constraints, not TODOs:
+
+- No Cursor chat UI embed
+- No API to read Cursor IDE chat history
+- Cloud VM cannot attach to live Lua PoB
+
+## 9. Related ADRs
+
+- [0001](./adr/0001-sidecar-owned-agent-window.md) — UI placement
+- [0002](./adr/0002-apply-all-or-nothing-savedb-undo.md) — Apply/Undo
+- [0003](./adr/0003-cursor-local-sdk-user-key.md) — SDK/auth
+- [0004](./adr/0004-poe2-exclusion-fail-closed.md) — Exclusion on this surface
diff --git a/docs/pob-cursor-agent/KNOWLEDGE-PACK.md b/docs/pob-cursor-agent/KNOWLEDGE-PACK.md
new file mode 100644
index 00000000000..3eaec36b259
--- /dev/null
+++ b/docs/pob-cursor-agent/KNOWLEDGE-PACK.md
@@ -0,0 +1,100 @@
+# Knowledge Pack design
+
+Design for the versioned PoE1 knowledge layer that grounds research tools and PoE2 Exclusion **data**. Runtime enforcement behavior is in [adr/0004-poe2-exclusion-fail-closed.md](./adr/0004-poe2-exclusion-fail-closed.md); layout/Sync policy ADR: [adr/0005-knowledge-pack-git-pr-sync.md](./adr/0005-knowledge-pack-git-pr-sync.md).
+
+**Research basis:** [docs/research/poe1-knowledge-sources-patch-notes.md](../research/poe1-knowledge-sources-patch-notes.md).
+
+## 1. Location and ownership
+
+| Item | Decision |
+| --- | --- |
+| Root | Repo-root `knowledge-pack/` |
+| Versioning | Git on the personal fork |
+| Local overlays | None — Sync updates land via commits/PRs |
+| Runtime enforcement | Sidecar (not the pack files themselves) |
+
+## 2. Directory schema
+
+```text
+knowledge-pack/
+  policy/          # allowlist, denylist, exclusion rule data (rare manual PRs)
+  notes/           # markdown mechanic/pitfall notes (primary Sync surface)
+  meta             # or meta.json / meta.yaml — current patch + pack generation
+```
+
+Exact filenames inside `policy/` are fixed at first materialize (deferred). Required **kinds** of data:
+
+| Kind | Purpose |
+| --- | --- |
+| Allowlist | Hosts/paths/namespaces the agent may fetch or cite for PoE1 |
+| Denylist | PoE2 and lookalike traps (hosts, forum sections, path prefixes) |
+| Exclusion extras | Any non-URL rules needed by gates (e.g. forum id `2212`) |
+| Notes | Human-maintained pitfalls; Sync may add/retire |
+| Meta | `current_patch` / generation counters for behind-pack warnings |
+
+## 3. Note frontmatter (normative fields)
+
+Every note under `notes/` carries:
+
+```yaml
+status: active | possibly_stale | retired
+verified_against_patch: "<PoE1 patch id, e.g. 3.29.0>"
+```
+
+Agent rules:
+
+- Trust `active` notes aligned with current pack meta
+- **Distrust** `possibly_stale` (may cite with caution / prefer re-fetch)
+- **Ignore** `retired`
+
+## 4. Allowlist / denylist seeds (from research)
+
+Exact file contents are deferred; **seed sets** an implementer must encode:
+
+### Allowlist (PoE1)
+
+- Official: `pathofexile.com` — especially [Patch Notes forum](https://www.pathofexile.com/forum/view-forum/patch-notes), developer docs/data exports, trade API; `grindinggear/skilltree-export` / atlastree-export
+- Wiki: `poewiki.net` (+ MediaWiki/Cargo API; plan for Anubis bot protection)
+- Economy/builds: `poe.ninja/poe1/*` (legacy `/api/data/...` paths are dead)
+- Reddit: `r/pathofexile`, `r/PathOfExileBuilds`
+- Secondary: `poedb.tw`, `maxroll.gg/poe/`, `pobb.in`
+
+### Denylist / PoE2 traps
+
+- `pathofexile2.com`, forum **2212** (Early Access `0.x` notes), `poe2wiki.net`, `poe2db.tw`, `poe.ninja/poe2/`, `maxroll.gg/poe2/`, `r/PathOfExile2`, `poe2-skilltree-export`
+- Rule: **host/namespace beats name equality** — same-named skills/items on PoE2 wikis are not PoE1 truth
+
+## 5. Patch-Notes Sync policy
+
+| Rule | Decision |
+| --- | --- |
+| Primary feed | HTML list + threads under `/forum/view-forum/patch-notes` (PoE1 `3.x`) |
+| Secondary | `https://www.pathofexile.com/news/rss` only as noisy hint (incomplete; can mention PoE2) |
+| Discrimination | Forum section + version scheme (`3.x` vs `0.x` / forum 2212) |
+| Landing | Updates under `knowledge-pack/notes/` and pack `meta` |
+| Merge | **Always open a PR**; human merge required — no auto-merge |
+| Cadence / operator | Deferred (map fog) |
+
+No official dedicated patch-notes RSS/API exists (research verified).
+
+## 6. Staleness signals to the agent
+
+| Level | Signal | Agent behavior |
+| --- | --- | --- |
+| Pack | Sync detected newer patch and/or generation behind | Warn in UI / system prompt |
+| Note | `possibly_stale` | Distrust |
+| Note | `retired` | Ignore |
+
+## 7. Boundary with PoE2 Exclusion
+
+| Concern | Lives in |
+| --- | --- |
+| Allow/deny data | `knowledge-pack/policy/` |
+| Tool/source gates, output guard, Apply id checks, re-ask | Sidecar runtime ([ADR 0004](./adr/0004-poe2-exclusion-fail-closed.md)) |
+
+## 8. Out of scope for the pack
+
+- Fine-tuned weights
+- Mirroring full wiki dumps as the primary strategy
+- Auto-merging Sync to default branch
+- PoE2 content “for comparison”
diff --git a/docs/pob-cursor-agent/PRD.md b/docs/pob-cursor-agent/PRD.md
new file mode 100644
index 00000000000..c06785598c1
--- /dev/null
+++ b/docs/pob-cursor-agent/PRD.md
@@ -0,0 +1,130 @@
+# Product requirements — PoB Cursor Agent
+
+Personal **Path of Exile 1–only** AI **build advisor** embedded beside Path of Building, billed only against the owner's **Cursor** subscription. Non-LLM sidecar is allowed.
+
+**Audience:** implementer on fork `waltersmike/PathOfBuilding`.  
+**Not for:** upstream PathOfBuildingCommunity merge.
+
+## 1. Jobs to be done
+
+### Primary — Build advisor
+
+With the user's **current build** loaded in PoB:
+
+- Explain tradeoffs (tree, gear, skills, config) grounded in PoB's live state
+- Suggest changes as a **Proposal** the user can inspect, apply, reject, or undo
+- Use web/research against **allowlisted PoE1 sources** when the build alone is not enough
+
+### Secondary — Research threads
+
+Separate **research** threads (not bound to a single build) for league/mechanic/meta questions, still PoE1-only and citation-gated.
+
+### Explicit non-jobs (out of scope)
+
+- PoB **power-user** agent (teach the UI, debug imports as the main product)
+- PoE2 support or dual-game advice
+- Fine-tuning a model
+- Second LLM vendor
+- Upstream contribution of this feature
+
+## 2. Users and deployment
+
+| Attribute | Decision |
+| --- | --- |
+| User | Owner of the Cursor subscription (and anyone they hand a key to — runbook deferred) |
+| Host app | Personal fork of Path of Building (Lua + SimpleGraphic) |
+| LLM | Cursor only (local SDK agent loop; inference Cursor-hosted) |
+| Sidecar | Local non-LLM process; owns Agent Window UI and Cursor SDK |
+
+## 3. UX — Agent Window
+
+Locked from [Prototype floating agent window UX](https://github.com/waltersmike/PathOfBuilding/issues/10) (variant **D**).
+
+### Open state
+
+- Narrow **chat stack** (second-monitor friendly)
+- Thread chips: **build** vs **research**
+- Streaming replies + citations
+- **Proposal drawer** at bottom: Apply / Reject / Undo
+- Usage meter + model pill (**Composer 2.5**, not Fast)
+
+### Closed state
+
+- Collapses to a **compact connected pill** (re-open from pill) — not dismiss-only
+
+### Rejected chrome for v1
+
+- Always-on split proposal pane (too wide)
+- Tabbed Chat/Proposal/History as primary open layout (history via SDK `agentId`, not main chrome)
+
+### Prototype artifact
+
+[`prototype/agent-window/index.html`](./prototype/agent-window/index.html)
+
+### Placement persistence
+
+Pill/window position across monitors/sessions is **deferred** (map fog). Implementer chooses a reasonable default; not a product reopen.
+
+## 4. Core loop — Propose → Diff → Confirm → Apply
+
+1. User chats; sidecar includes a **full build export** every turn (see Architecture / research).
+2. Agent may emit a **Proposal**: canonical **ops JSON** (typed ops with PoB ids) plus a human summary for the in-window diff.
+3. User **Apply** / **Reject** / **Undo**:
+   - **Apply** is **all-or-nothing** across all touched surfaces (tree, items/gems, Configuration, …).
+   - **Reject** discards; build unchanged.
+   - Before Apply: capture full-build `SaveDB` snapshot; **Undo** restores that snapshot (one-step reverse of the whole proposal).
+4. **Compare** tab handoff remains **optional/manual** — nice for full before/after, not required to apply.
+
+PoE2 / unknown-id guards run on ops **before** Apply; failure **hard-refuses** (no override, no partial apply). See [KNOWLEDGE-PACK.md](./KNOWLEDGE-PACK.md) and [adr/0004-poe2-exclusion-fail-closed.md](./adr/0004-poe2-exclusion-fail-closed.md).
+
+## 5. Context every turn
+
+- **Full build snapshot** via PoB `SaveDB` (XML; optional share-code encoding) — strongest existing seam.
+- Thread metadata: `threadType: build | research`, `buildId` when build-scoped.
+- Knowledge Pack policy + notes available to tools/guards (not pasted wholesale into every prompt unless needed).
+
+## 6. Knowledge and PoE2
+
+| Concern | Rule |
+| --- | --- |
+| Game | **PoE1 only** |
+| Mixing PoE2 as PoE1 truth | **Catastrophic failure** |
+| Sources | Allowlist/denylist in `knowledge-pack/policy/` |
+| Apply | Proposals may only reference entities present in loaded PoB / PoE1 id sets |
+| Research contamination | Refuse + **automatic re-ask** constrained to allowlisted PoE1 / PoB grounding |
+| Silent stripping | Forbidden |
+
+## 7. Models and usage
+
+| Setting | Decision |
+| --- | --- |
+| Default model | **Composer 2.5** (standard — **not** Composer 2.5 Fast) |
+| Per-thread opt-up | Allowed to a more capable Cursor model |
+| Soft warn | ~80% of configurable cap |
+| Hard stop | 100% — block new turns until cap raised/reset |
+| Numeric default | Deferred (map fog); implementer ships a configurable default |
+
+Billing is the owner's Cursor plan via **user API key**. No personal hard-budget API from Cursor — caps are **app-level** in the sidecar.
+
+## 8. Failure modes (product-visible)
+
+| Failure | User-visible behavior |
+| --- | --- |
+| PoE2-risk on Apply | Hard refuse; explain PoE2-risk; no partial apply |
+| PoE2-risk in research/chat | Refuse contaminated answer; auto re-ask on allowlisted sources |
+| Usage at hard cap | Block new turns; show meter; allow raise/reset |
+| Sidecar down / spawn fail | Clear error in PoB or last-known pill state; no silent LLM calls from Lua |
+| Cursor rate limit / auth | Surface error; do not retry unbounded |
+
+## 9. Acceptance for “spec complete”
+
+This PRD plus Architecture, ADRs, Knowledge Pack, and Cursor Integration docs are sufficient when an implementer does not need to reopen:
+
+- Primary job and non-jobs
+- Window open/closed chrome
+- Propose / Apply / Reject / Undo semantics
+- PoE2 Exclusion behavior
+- Sidecar ownership of UI + Cursor billing model
+- Knowledge Pack layout and Sync-via-PR policy
+
+Remaining fog (exact list entries, numeric cap default, placement persistence, friend runbook, Sync cadence, wire schemas) is **implementation detail**, not product discovery.
diff --git a/docs/pob-cursor-agent/README.md b/docs/pob-cursor-agent/README.md
new file mode 100644
index 00000000000..dc4f0405099
--- /dev/null
+++ b/docs/pob-cursor-agent/README.md
@@ -0,0 +1,57 @@
+# PoB Cursor Agent — handoff pack
+
+Index for the **personal Path of Exile 1–only** AI **build-advisor** agent for Path of Building, powered by the owner's **Cursor subscription only** (non-LLM sidecar allowed).
+
+**Map:** [PoB Cursor Agent — handoff spec map](https://github.com/waltersmike/PathOfBuilding/issues/1)
+
+**Scope of this pack:** product + technical specification dense enough that an implementer can build without redoing discovery. **Implementing the agent is out of scope for the map**; these docs *are* the destination.
+
+**Fork only:** `waltersmike/PathOfBuilding`. Never for PathOfBuildingCommunity merge.
+
+## How to read
+
+| Order | Doc | Owns |
+| --- | --- | --- |
+| 1 | [PRD.md](./PRD.md) | Jobs, UX, propose→apply loop, failure modes, out of scope |
+| 2 | [ARCHITECTURE.md](./ARCHITECTURE.md) | System diagram, component responsibilities, ADR index |
+| 3 | [adr/](./adr/) | Irreversible forks (sidecar UI, apply/undo, Cursor local SDK, PoE2 gates, Knowledge Pack layout) |
+| 4 | [KNOWLEDGE-PACK.md](./KNOWLEDGE-PACK.md) | Pack schema, Sync policy, staleness, PoE2 Exclusion data vs runtime |
+| 5 | [CURSOR-INTEGRATION.md](./CURSOR-INTEGRATION.md) | Auth, SDK runtime, threads/history, usage caps, message surface |
+
+## Research (linked, not copied)
+
+| Topic | Doc | Branch (authored on) |
+| --- | --- | --- |
+| Cursor SDK / billing / history | [docs/research/cursor-sdk-pob-agent.md](../research/cursor-sdk-pob-agent.md) | `research/cursor-sdk-pob-agent` |
+| PoB Lua seams (snapshot, apply, float, IPC) | [docs/research/pob-agent-integration-surfaces.md](../research/pob-agent-integration-surfaces.md) | `research/pob-agent-integration-surfaces` |
+| PoE1 sources + patch-notes feeds | [docs/research/poe1-knowledge-sources-patch-notes.md](../research/poe1-knowledge-sources-patch-notes.md) | `research/poe1-knowledge-sources` |
+
+## Prototype
+
+| Artifact | Path | Branch |
+| --- | --- | --- |
+| Floating agent window UX (variant **D** default) | [prototype/agent-window/index.html](./prototype/agent-window/index.html) | `prototype/agent-window-ux` |
+
+## Destination complete checklist
+
+An implementer should be able to start from this pack alone when:
+
+- [x] All files listed above exist under `docs/pob-cursor-agent/`
+- [x] Required sections filled (no TBD in those sections)
+- [x] Expected ADRs written
+- [x] Research remains under `docs/research/` and is linked, not pasted into product docs
+- [x] Map [Decisions so far](https://github.com/waltersmike/PathOfBuilding/issues/1) lists every closed ticket; no open map tickets remain after Assemble
+
+## Materialized (issue #13)
+
+- Repo-root `knowledge-pack/` with `policy/`, `notes/`, `meta.yaml` — see [knowledge-pack/README.md](../../knowledge-pack/README.md)
+- Pure PoE2 policy evaluators + tests in `sidecar/src/policy/`
+
+## Deferred (not blocking this pack)
+
+Left on the map as **Not yet specified** — pin during implementation, not here:
+- Concrete numeric default for usage cap
+- Window/pill placement persistence across monitors/sessions
+- Friend handoff runbook
+- Sync job cadence / who runs the scraper
+- Exact ops vocabulary and HTTP route/schema names
diff --git a/docs/pob-cursor-agent/adr/0001-sidecar-owned-agent-window.md b/docs/pob-cursor-agent/adr/0001-sidecar-owned-agent-window.md
new file mode 100644
index 00000000000..3eb04730b8b
--- /dev/null
+++ b/docs/pob-cursor-agent/adr/0001-sidecar-owned-agent-window.md
@@ -0,0 +1,14 @@
+# Sidecar owns the Agent Window
+
+PoB's Lua/SimpleGraphic host has a single OS window and only modal `PopupDialog` overlays — unsuitable for a chat advisor that must stay open while the user edits the build. We put the floating Agent Window in a **local sidecar process** that PoB spawns; PoB remains build authority (snapshot / apply / undo) over localhost HTTP/JSON.
+
+## Considered options
+
+- **In-app non-modal floating panel** — would require inventing hit-testing and input routing outside `main.popups`; possible later, rejected for v1.
+- **Modal PopupDialog** — blocks PoB use while open; rejected.
+- **Sidecar-owned window** — chosen; matches Cursor SDK hosting and custom chat UX.
+
+## Consequences
+
+- PoB must spawn/monitor the sidecar and expose bridge APIs; UI polish lives outside Lua.
+- Closed state is a compact pill in the sidecar (see PRD / prototype), not a PoB toast.
diff --git a/docs/pob-cursor-agent/adr/0002-apply-all-or-nothing-savedb-undo.md b/docs/pob-cursor-agent/adr/0002-apply-all-or-nothing-savedb-undo.md
new file mode 100644
index 00000000000..ba9654cd23b
--- /dev/null
+++ b/docs/pob-cursor-agent/adr/0002-apply-all-or-nothing-savedb-undo.md
@@ -0,0 +1,18 @@
+# All-or-nothing Apply with SaveDB Undo
+
+A Proposal may touch multiple surfaces (tree, items/gems, Configuration, …). **Apply is all-or-nothing** — no partial or per-section Apply. Before Apply, PoB captures a full-build `SaveDB` snapshot; **Undo** restores that snapshot (one-step reverse of the whole proposal). Reject discards the Proposal with no mutation.
+
+## Why
+
+Per-tab undo/load helpers exist, but there is no cross-tab proposal transaction. Full-build replace via Import-style `Shutdown`+`Init(xml)` is the reliable seam; wrapping it with a pre-Apply snapshot gives a clear rollback story without inventing multi-tab undo stacks.
+
+## Format
+
+- **Ops JSON** (typed ops with PoB ids) is canonical for validation and Apply.
+- In-window diff shows a **human summary** derived from ops; deeper/XML detail may be optional.
+- Compare-tab handoff stays optional/manual — not required for Apply.
+
+## Consequences
+
+- Contaminated or invalid ops fail the entire Apply (ties to PoE2 Exclusion ADR).
+- Snapshot retention: held until next Apply or explicit discard.
diff --git a/docs/pob-cursor-agent/adr/0003-cursor-local-sdk-user-key.md b/docs/pob-cursor-agent/adr/0003-cursor-local-sdk-user-key.md
new file mode 100644
index 00000000000..28a9f2b97f1
--- /dev/null
+++ b/docs/pob-cursor-agent/adr/0003-cursor-local-sdk-user-key.md
@@ -0,0 +1,19 @@
+# Cursor local SDK with owner user API key
+
+LLM access is **Cursor only**, via `@cursor/sdk` / `cursor-sdk` **local** runtime in the sidecar, authenticated with the owner's **user API key** (bills their subscription pools). Cloud Agents are the wrong shape for a live desktop PoB session. There is no second LLM vendor and no fine-tune.
+
+## Why
+
+- Local agent loop can sit beside Lua PoB; cloud VMs cannot attach to the live process.
+- User API keys map spend to the owner; Team Admin keys are unsupported by the SDK.
+- Cursor does not expose embeddable IDE chat or IDE history APIs — custom Agent Window + SDK `agentId` resume is mandatory anyway.
+
+## Guardrails
+
+- Default model: **Composer 2.5** (not Fast); per-thread opt-up allowed.
+- Soft warn ~80% / hard stop at 100% of an **app-level** configurable cap (Cursor has no personal hard-budget API).
+
+## Consequences
+
+- Sidecar requires Node 22.13+ (or Python SDK equivalent) and network to Cursor.
+- Friend handoff implies sharing a key out-of-band (runbook deferred).
diff --git a/docs/pob-cursor-agent/adr/0004-poe2-exclusion-fail-closed.md b/docs/pob-cursor-agent/adr/0004-poe2-exclusion-fail-closed.md
new file mode 100644
index 00000000000..48d2cc58bf2
--- /dev/null
+++ b/docs/pob-cursor-agent/adr/0004-poe2-exclusion-fail-closed.md
@@ -0,0 +1,25 @@
+# PoE2 Exclusion is fail-closed
+
+Treating Path of Exile 2 data (including same-named skills/items) as Path of Exile 1 truth is a **catastrophic failure**. Runtime enforcement combines:
+
+1. **Baseline gates** — tool/source gates refuse denylisted hosts/paths before the model consumes them; output guard checks citations/proposals.
+2. **Apply path** — proposals may only reference entities present in loaded PoB / PoE1 id sets; unknown same-named entities **hard-fail**.
+
+## On guard trip
+
+| Path | Behavior |
+| --- | --- |
+| **Apply** | Hard refuse — no override, no partial apply of the contaminated slice; user told it was PoE2-risk refusal |
+| **Research/chat** | Refuse contaminated answer and **automatically re-ask** constrained to allowlisted PoE1 sources / PoB grounding |
+
+No silent stripping. No Apply override in v1.
+
+## Policy vs enforcement
+
+Allowlist/denylist and exclusion **data** live in `knowledge-pack/policy/`. This ADR owns **runtime** behavior only.
+
+## Mandatory fail-closed acceptance suite
+
+1. **URL/domain** — denylisted hosts/paths blocked (`pathofexile2.com`, `poe2wiki.net`, `poe.ninja/poe2/*`, forum 2212, etc.)
+2. **Same-name Apply** — proposing Apply of a same-named skill/item absent from PoB/PoE1 ids hard-refuses
+3. **Mixed citation** — PoE1+PoE2 links in one answer refuses and re-asks; PoE2 link must not be shown even “for comparison”
diff --git a/docs/pob-cursor-agent/adr/0005-knowledge-pack-git-pr-sync.md b/docs/pob-cursor-agent/adr/0005-knowledge-pack-git-pr-sync.md
new file mode 100644
index 00000000000..99718956faf
--- /dev/null
+++ b/docs/pob-cursor-agent/adr/0005-knowledge-pack-git-pr-sync.md
@@ -0,0 +1,25 @@
+# Knowledge Pack lives in git; Sync always opens a PR
+
+The Knowledge Pack is versioned at repo-root `knowledge-pack/` (not a local-only overlay). **Patch-Notes Sync** updates the pack by committing and **always opening a PR**; human merge is required — no auto-merge to the default branch.
+
+## Layout
+
+| Path | Role |
+| --- | --- |
+| `knowledge-pack/policy/` | Allowlist, denylist, PoE2 Exclusion **data**; rare manual PRs |
+| `knowledge-pack/notes/` | Markdown pitfalls/mechanic notes — primary Sync touch surface |
+| Pack `meta` | Current patch / generation for behind-pack detection |
+
+## Staleness → agent
+
+- **Pack-level:** warn when Sync has detected a newer patch and/or pack generation is behind
+- **Per-note:** frontmatter `status: active | possibly_stale | retired` + `verified_against_patch`; agent must distrust `possibly_stale` and ignore `retired`
+
+## Sync input
+
+Primary: PoE1 Patch Notes forum HTML (see research). Exact job cadence and operator are deferred.
+
+## Consequences
+
+- First materialize of allowlist/denylist seeds comes from research ticket findings; exact file contents deferred to Assemble/implement.
+- Runtime Exclusion behavior is separate ([0004](./0004-poe2-exclusion-fail-closed.md)).
diff --git a/docs/pob-cursor-agent/prototype/agent-window/index.html b/docs/pob-cursor-agent/prototype/agent-window/index.html
new file mode 100644
index 00000000000..6c0f81fb364
--- /dev/null
+++ b/docs/pob-cursor-agent/prototype/agent-window/index.html
@@ -0,0 +1,724 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8" />
+  <meta name="viewport" content="width=device-width, initial-scale=1" />
+  <title>PROTOTYPE — PoB Agent Window UX</title>
+  <style>
+    :root {
+      --bg: #1a1d21;
+      --panel: #23282e;
+      --panel-2: #2b3138;
+      --border: #3a424c;
+      --text: #e8ecef;
+      --muted: #9aa3ad;
+      --accent: #c4a35a;
+      --ok: #5a9e6f;
+      --danger: #c45a5a;
+      --warn: #c49a5a;
+      --font: "Segoe UI", system-ui, sans-serif;
+      --mono: ui-monospace, "Cascadia Code", Consolas, monospace;
+    }
+    * { box-sizing: border-box; }
+    body {
+      margin: 0;
+      min-height: 100vh;
+      font-family: var(--font);
+      background: #0f1113;
+      color: var(--text);
+    }
+    .banner {
+      background: #3d2e12;
+      color: #f0d9a0;
+      padding: 8px 14px;
+      font-size: 13px;
+      border-bottom: 1px solid #6a5220;
+    }
+    .banner code { font-family: var(--mono); font-size: 12px; }
+    .stage {
+      display: grid;
+      place-items: center;
+      padding: 24px 16px 96px;
+      min-height: calc(100vh - 40px);
+    }
+    .desk {
+      width: min(1100px, 100%);
+      height: 640px;
+      background:
+        linear-gradient(180deg, #2a3038 0%, #1e2328 100%);
+      border: 1px solid var(--border);
+      border-radius: 6px;
+      position: relative;
+      overflow: hidden;
+      box-shadow: 0 20px 50px rgba(0,0,0,.45);
+    }
+    .desk-label {
+      position: absolute;
+      top: 10px;
+      left: 12px;
+      font-size: 11px;
+      letter-spacing: .04em;
+      text-transform: uppercase;
+      color: var(--muted);
+      z-index: 1;
+    }
+    .desk-fake-pob {
+      position: absolute;
+      inset: 36px 12px 12px;
+      border: 1px dashed #3f4750;
+      border-radius: 4px;
+      color: #5c6670;
+      display: grid;
+      place-items: center;
+      font-size: 13px;
+      pointer-events: none;
+    }
+
+    /* Shared chrome bits */
+    .win {
+      position: absolute;
+      background: var(--bg);
+      border: 1px solid var(--border);
+      border-radius: 8px;
+      box-shadow: 0 12px 40px rgba(0,0,0,.5);
+      display: flex;
+      flex-direction: column;
+      overflow: hidden;
+      z-index: 2;
+    }
+    .titlebar {
+      display: flex;
+      align-items: center;
+      gap: 8px;
+      padding: 8px 10px;
+      background: var(--panel);
+      border-bottom: 1px solid var(--border);
+      cursor: default;
+      user-select: none;
+    }
+    .titlebar h1 {
+      margin: 0;
+      font-size: 13px;
+      font-weight: 600;
+      flex: 1;
+    }
+    .pill {
+      font-size: 11px;
+      padding: 2px 8px;
+      border-radius: 999px;
+      background: var(--panel-2);
+      color: var(--muted);
+      border: 1px solid var(--border);
+    }
+    .pill.accent { color: var(--accent); border-color: #6a5a30; }
+    .btn {
+      border: 1px solid var(--border);
+      background: var(--panel-2);
+      color: var(--text);
+      border-radius: 5px;
+      padding: 6px 10px;
+      font-size: 12px;
+      cursor: pointer;
+    }
+    .btn:hover { border-color: #5a6570; }
+    .btn.primary { background: #3a4a32; border-color: #5a7a4a; color: #d8efd0; }
+    .btn.danger { background: #4a3030; border-color: #7a4a4a; color: #efd0d0; }
+    .btn.ghost { background: transparent; }
+    .msg { padding: 10px 12px; font-size: 13px; line-height: 1.45; }
+    .msg.user { background: #1f262c; }
+    .msg.agent { background: transparent; border-top: 1px solid #2a3138; }
+    .msg .meta { font-size: 11px; color: var(--muted); margin-bottom: 4px; }
+    .cite {
+      display: inline-block;
+      margin-top: 6px;
+      font-size: 11px;
+      color: var(--accent);
+      text-decoration: underline;
+      text-underline-offset: 2px;
+    }
+    .composer {
+      display: flex;
+      gap: 8px;
+      padding: 10px;
+      border-top: 1px solid var(--border);
+      background: var(--panel);
+    }
+    .composer textarea {
+      flex: 1;
+      resize: none;
+      height: 56px;
+      background: var(--bg);
+      color: var(--text);
+      border: 1px solid var(--border);
+      border-radius: 6px;
+      padding: 8px;
+      font: inherit;
+      font-size: 13px;
+    }
+    .usage {
+      font-size: 11px;
+      color: var(--muted);
+      padding: 4px 10px;
+      border-top: 1px solid var(--border);
+      display: flex;
+      justify-content: space-between;
+      gap: 8px;
+    }
+    .usage .bar {
+      flex: 1;
+      height: 6px;
+      align-self: center;
+      background: #2a3138;
+      border-radius: 99px;
+      overflow: hidden;
+    }
+    .usage .bar > span {
+      display: block;
+      height: 100%;
+      width: 62%;
+      background: var(--warn);
+    }
+    .diff {
+      font-family: var(--mono);
+      font-size: 11px;
+      background: #14181c;
+      border: 1px solid var(--border);
+      border-radius: 6px;
+      padding: 8px;
+      white-space: pre-wrap;
+    }
+    .diff .add { color: #8fdf9f; }
+    .diff .del { color: #efa0a0; }
+    .hidden { display: none !important; }
+
+    /* ===== Variant A: Chat-first stack + proposal drawer ===== */
+    .vA {
+      right: 18px;
+      bottom: 18px;
+      width: 380px;
+      height: 560px;
+    }
+    .vA .threads {
+      display: flex;
+      gap: 4px;
+      padding: 8px 10px;
+      border-bottom: 1px solid var(--border);
+      background: var(--panel);
+      overflow-x: auto;
+    }
+    .vA .threads button {
+      white-space:nowrap;
+      font-size: 11px;
+      padding: 4px 8px;
+      border-radius: 4px;
+      border: 1px solid transparent;
+      background: transparent;
+      color: var(--muted);
+      cursor: pointer;
+    }
+    .vA .threads button.active {
+      background: var(--panel-2);
+      border-color: var(--border);
+      color: var(--text);
+    }
+    .vA .chat { flex: 1; overflow: auto; }
+    .vA .drawer {
+      border-top: 1px solid var(--border);
+      background: var(--panel);
+      max-height: 42%;
+      display: flex;
+      flex-direction: column;
+    }
+    .vA .drawer header {
+      display: flex;
+      align-items: center;
+      gap: 8px;
+      padding: 8px 10px;
+      font-size: 12px;
+      font-weight: 600;
+    }
+    .vA .drawer .body { padding: 0 10px 10px; overflow: auto; }
+    .vA .drawer .actions {
+      display: flex;
+      gap: 8px;
+      padding: 0 10px 10px;
+    }
+
+    /* ===== Variant B: Split — chat | always-on proposal ===== */
+    .vB {
+      left: 50%;
+      top: 50%;
+      transform: translate(-50%, -48%);
+      width: 860px;
+      height: 520px;
+    }
+    .vB .body-row {
+      flex: 1;
+      display: grid;
+      grid-template-columns: 1fr 1fr;
+      min-height: 0;
+    }
+    .vB .left, .vB .right {
+      display: flex;
+      flex-direction: column;
+      min-height: 0;
+      overflow: hidden;
+    }
+    .vB .right { border-left: 1px solid var(--border); background: #171b1f; }
+    .vB .rail {
+      display: flex;
+      gap: 6px;
+      padding: 8px 10px;
+      border-bottom: 1px solid var(--border);
+      align-items: center;
+    }
+    .vB .chat { flex: 1; overflow: auto; }
+    .vB .prop-head {
+      padding: 10px 12px;
+      font-size: 12px;
+      font-weight: 600;
+      border-bottom: 1px solid var(--border);
+      display: flex;
+      justify-content: space-between;
+      align-items: center;
+    }
+    .vB .prop-body { flex: 1; overflow: auto; padding: 10px 12px; }
+    .vB .prop-actions {
+      display: flex;
+      gap: 8px;
+      padding: 10px 12px;
+      border-top: 1px solid var(--border);
+    }
+    .vB select {
+      background: var(--bg);
+      color: var(--text);
+      border: 1px solid var(--border);
+      border-radius: 4px;
+      padding: 4px 6px;
+      font-size: 12px;
+    }
+
+    /* ===== Variant C: Compact strip → expands to panels ===== */
+    .vC-strip {
+      right: 20px;
+      bottom: 20px;
+      width: auto;
+      height: auto;
+      flex-direction: row;
+      align-items: center;
+      gap: 8px;
+      padding: 8px 10px;
+      border-radius: 999px;
+    }
+    .vC-strip .dot {
+      width: 8px; height: 8px; border-radius: 50%;
+      background: var(--ok);
+    }
+    .vC-panel {
+      right: 20px;
+      bottom: 64px;
+      width: 420px;
+      height: 480px;
+    }
+    .vC-panel .tabs {
+      display: grid;
+      grid-template-columns: 1fr 1fr 1fr;
+      border-bottom: 1px solid var(--border);
+    }
+    .vC-panel .tabs button {
+      background: var(--panel);
+      border: 0;
+      border-right: 1px solid var(--border);
+      color: var(--muted);
+      padding: 10px;
+      font-size: 12px;
+      cursor: pointer;
+    }
+    .vC-panel .tabs button:last-child { border-right: 0; }
+    .vC-panel .tabs button.active {
+      color: var(--text);
+      background: var(--bg);
+      box-shadow: inset 0 -2px 0 var(--accent);
+    }
+    .vC-panel .pane { flex: 1; overflow: auto; display: none; flex-direction: column; }
+    .vC-panel .pane.active { display: flex; }
+    .vC-panel .history-item {
+      padding: 10px 12px;
+      border-bottom: 1px solid #2a3138;
+      font-size: 12px;
+      cursor: pointer;
+    }
+    .vC-panel .history-item:hover { background: #1f262c; }
+    .vC-panel .history-item small { display: block; color: var(--muted); margin-top: 2px; }
+
+    /* Switcher */
+    .switcher {
+      position: fixed;
+      left: 50%;
+      bottom: 18px;
+      transform: translateX(-50%);
+      z-index: 50;
+      display: flex;
+      align-items: center;
+      gap: 10px;
+      padding: 8px 12px;
+      background: #f4f1ea;
+      color: #1a1a1a;
+      border-radius: 999px;
+      box-shadow: 0 8px 24px rgba(0,0,0,.35);
+      font-size: 13px;
+      font-weight: 600;
+    }
+    .switcher button {
+      border: 0;
+      background: #1a1a1a;
+      color: #f4f1ea;
+      width: 32px;
+      height: 32px;
+      border-radius: 50%;
+      cursor: pointer;
+      font-size: 16px;
+      line-height: 1;
+    }
+    .switcher .label { min-width: 220px; text-align: center; }
+    .switcher .hint { font-weight: 400; font-size: 11px; color: #555; display: block; }
+  </style>
+</head>
+<body>
+  <!--
+    PROTOTYPE (throwaway): Three variants of the PoB Cursor Agent floating window,
+    switchable via ?variant=A|B|C. Answers: open/close, build vs research threads,
+    history, streaming+citations, proposal diff, confirm/reject.
+    One command: open this file in a browser (or npx --yes serve docs/pob-cursor-agent/prototype/agent-window).
+  -->
+  <div class="banner">
+    <strong>PROTOTYPE — throwaway.</strong>
+    Sidecar-owned Agent Window mock (not PoB Lua).     Flip variants with the bar below or
+    <code>?variant=D|A|B|C</code> — <strong>D</strong> is the chosen mix (A stack + C pill).
+  </div>
+
+  <div class="stage">
+    <div class="desk" id="desk">
+      <div class="desk-label">Fake Path of Building (backdrop only)</div>
+      <div class="desk-fake-pob">Tree / Items / Skills — agent window floats above</div>
+
+      <!-- VARIANT A -->
+      <!-- VARIANT D (winner sketch): A stack + C pill when closed -->
+      <div class="win vC-strip hidden" id="variantDStrip" data-name="A+C pill">
+        <span class="dot" title="Sidecar connected"></span>
+        <strong style="font-size:12px">Agent</strong>
+        <span class="pill">Build · Spark</span>
+        <span class="pill accent">62%</span>
+        <button class="btn" type="button" id="dOpen">Open</button>
+      </div>
+      <div class="win vA hidden" id="variantD" data-name="A stack + C pill">
+        <div class="titlebar">
+          <h1>PoB Agent</h1>
+          <span class="pill accent">Composer 2.5</span>
+          <button class="btn ghost" type="button" id="dMinimize" title="Collapse to pill">_</button>
+          <button class="btn ghost" type="button" id="dClose" title="Collapse to pill">✕</button>
+        </div>
+        <div class="threads">
+          <button class="active" type="button">Build · Spark Hierophant</button>
+          <button type="button">Research</button>
+          <button type="button">+ Build thread</button>
+        </div>
+        <div class="chat">
+          <div class="msg user">
+            <div class="meta">You · build thread</div>
+            Can we squeeze more DPS without losing spell suppression?
+          </div>
+          <div class="msg agent">
+            <div class="meta">Agent</div>
+            Trade life for cluster jewels on the right; keep Watcher’s Eye for suppression.
+            <a class="cite" href="#">poewiki · Spell Suppression</a>
+            <a class="cite" href="#">poe.ninja/poe1 · similar trees</a>
+          </div>
+        </div>
+        <div class="drawer">
+          <header>
+            Proposal · multi-surface · all-or-nothing
+            <span class="pill">ops JSON</span>
+          </header>
+          <div class="body">
+            <div class="diff"><span class="add">+ tree: allocate Midpoint (12 nodes)</span>
+<span class="del">− tree: refund Heart of Oak path</span>
+<span class="add">+ item: Large Cluster — Spell Blast</span>
+<span class="add">+ config: bossing = true</span></div>
+          </div>
+          <div class="actions">
+            <button class="btn primary" type="button">Apply</button>
+            <button class="btn danger" type="button">Reject</button>
+            <button class="btn" type="button">Undo last</button>
+          </div>
+        </div>
+        <div class="composer">
+          <textarea placeholder="Ask about this build…"></textarea>
+          <button class="btn primary" type="button">Send</button>
+        </div>
+        <div class="usage">
+          <span>Usage 62% of daily cap</span>
+          <div class="bar"><span></span></div>
+        </div>
+      </div>
+
+      <div class="win vA" id="variantA" data-name="Chat stack + proposal drawer">
+        <div class="titlebar">
+          <h1>PoB Agent</h1>
+          <span class="pill accent">Composer 2.5</span>
+          <button class="btn ghost" type="button" title="Close">✕</button>
+        </div>
+        <div class="threads">
+          <button class="active" type="button">Build · Spark Hierophant</button>
+          <button type="button">Research</button>
+          <button type="button">+ Build thread</button>
+        </div>
+        <div class="chat">
+          <div class="msg user">
+            <div class="meta">You · build thread</div>
+            Can we squeeze more DPS without losing spell suppression?
+          </div>
+          <div class="msg agent">
+            <div class="meta">Agent · streaming…</div>
+            I’d trade a bit of life for cluster jewels on the right side — suppression stays ≥100% if we keep the Watcher’s Eye.
+            <a class="cite" href="#">poewiki · Spell Suppression</a>
+            <a class="cite" href="#">poe.ninja/poe1 · similar trees</a>
+          </div>
+        </div>
+        <div class="drawer">
+          <header>
+            Proposal · multi-surface · all-or-nothing
+            <span class="pill">ops JSON</span>
+          </header>
+          <div class="body">
+            <div class="diff"><span class="add">+ tree: allocate Midpoint (12 nodes)</span>
+<span class="del">− tree: refund Heart of Oak path</span>
+<span class="add">+ item: Large Cluster — Spell Blast</span>
+<span class="add">+ config: bossing = true</span></div>
+          </div>
+          <div class="actions">
+            <button class="btn primary" type="button">Apply</button>
+            <button class="btn danger" type="button">Reject</button>
+            <button class="btn" type="button">Undo last</button>
+          </div>
+        </div>
+        <div class="composer">
+          <textarea placeholder="Ask about this build…"></textarea>
+          <button class="btn primary" type="button">Send</button>
+        </div>
+        <div class="usage">
+          <span>Usage 62% of daily cap</span>
+          <div class="bar"><span></span></div>
+        </div>
+      </div>
+
+      <!-- VARIANT B -->
+      <div class="win vB hidden" id="variantB" data-name="Split chat | proposal">
+        <div class="titlebar">
+          <h1>PoB Agent — floating</h1>
+          <span class="pill accent">Composer 2.5</span>
+          <button class="btn ghost" type="button">_</button>
+          <button class="btn ghost" type="button">✕</button>
+        </div>
+        <div class="body-row">
+          <div class="left">
+            <div class="rail">
+              <label class="pill">Thread</label>
+              <select>
+                <option>Build · Spark Hierophant</option>
+                <option>Research (no Apply)</option>
+              </select>
+              <button class="btn" type="button">History</button>
+            </div>
+            <div class="chat">
+              <div class="msg user">
+                <div class="meta">You</div>
+                Why doesn’t Unleash work the way I expect with this setup?
+              </div>
+              <div class="msg agent">
+                <div class="meta">Agent</div>
+                Checking PoE1 sources only…
+                <a class="cite" href="#">pathofexile.com · 3.25 notes</a>
+                <a class="cite" href="#">r/PathOfExileBuilds</a>
+              </div>
+            </div>
+            <div class="composer">
+              <textarea placeholder="Message…"></textarea>
+              <button class="btn primary" type="button">Send</button>
+            </div>
+          </div>
+          <div class="right">
+            <div class="prop-head">
+              <span>Proposal diff (always visible)</span>
+              <span class="pill">awaiting confirm</span>
+            </div>
+            <div class="prop-body">
+              <p style="font-size:12px;color:var(--muted);margin:0 0 8px">
+                Human summary from ops · Compare in PoB is optional
+              </p>
+              <div class="diff"><span class="add">+ gem: Unleash → Controlled Destruction</span>
+<span class="add">+ config: condition:EnemyIsRare = false</span></div>
+            </div>
+            <div class="prop-actions">
+              <button class="btn primary" type="button">Apply all</button>
+              <button class="btn danger" type="button">Reject</button>
+            </div>
+            <div class="usage">
+              <span>62% cap · hard-stop at 100%</span>
+              <div class="bar"><span></span></div>
+            </div>
+          </div>
+        </div>
+      </div>
+
+      <!-- VARIANT C strip + panel -->
+      <div class="win vC-strip" id="variantCStrip" data-name="Compact strip">
+        <span class="dot" title="Sidecar connected"></span>
+        <strong style="font-size:12px">Agent</strong>
+        <span class="pill">Build</span>
+        <button class="btn" type="button" id="cOpen">Open</button>
+        <button class="btn ghost" type="button">✕</button>
+      </div>
+      <div class="win vC-panel hidden" id="variantC" data-name="Compact strip + tabs">
+        <div class="titlebar">
+          <h1>Agent</h1>
+          <span class="pill accent">Composer 2.5</span>
+          <button class="btn ghost" type="button" id="cClose">✕</button>
+        </div>
+        <div class="tabs">
+          <button class="active" type="button" data-pane="chat">Chat</button>
+          <button type="button" data-pane="proposal">Proposal</button>
+          <button type="button" data-pane="history">History</button>
+        </div>
+        <div class="pane active" data-pane="chat">
+          <div class="msg user"><div class="meta">You · Research</div>Link the wiki page for Mageblood?</div>
+          <div class="msg agent">
+            <div class="meta">Agent</div>
+            PoE1 only:
+            <a class="cite" href="#">poewiki.net · Mageblood</a>
+          </div>
+          <div class="composer">
+            <textarea placeholder="Ask…"></textarea>
+            <button class="btn primary" type="button">Send</button>
+          </div>
+          <div class="usage"><span>Research thread · 62%</span><div class="bar"><span></span></div></div>
+        </div>
+        <div class="pane" data-pane="proposal">
+          <div class="prop-body" style="padding:12px">
+            <div class="diff"><span class="add">+ item: Mageblood</span>
+<span class="del">− item: Headhunter</span></div>
+            <div style="display:flex;gap:8px;margin-top:12px">
+              <button class="btn primary" type="button">Apply</button>
+              <button class="btn danger" type="button">Reject</button>
+              <button class="btn" type="button">Undo</button>
+            </div>
+          </div>
+        </div>
+        <div class="pane" data-pane="history">
+          <div class="history-item">Build · Spark Hierophant<small>Cursor agentId · 12 messages</small></div>
+          <div class="history-item">Research<small>Cursor agentId · 4 messages</small></div>
+          <div class="history-item">Build · RF Chieftain<small>Cursor agentId · 7 messages</small></div>
+        </div>
+      </div>
+    </div>
+  </div>
+
+  <div class="switcher" id="switcher" role="toolbar" aria-label="Prototype variant switcher">
+    <button type="button" id="prev" aria-label="Previous variant">←</button>
+    <div class="label">
+      <span id="variantLabel">A — Chat stack + proposal drawer</span>
+      <span class="hint">← → keys · not part of the design</span>
+    </div>
+    <button type="button" id="next" aria-label="Next variant">→</button>
+  </div>
+
+  <script>
+    const VARIANTS = [
+      { key: "D", name: "WINNER: A stack + C pill", show: ["variantD"] },
+      { key: "A", name: "Chat stack + proposal drawer", show: ["variantA"] },
+      { key: "B", name: "Split chat | proposal", show: ["variantB"] },
+      { key: "C", name: "Compact strip + tabs", show: ["variantCStrip", "variantC"] },
+    ];
+    const allIds = ["variantA", "variantB", "variantCStrip", "variantC", "variantD", "variantDStrip"];
+
+    function getVariant() {
+      const v = new URLSearchParams(location.search).get("variant") || "D";
+      return VARIANTS.find((x) => x.key === v) ? v : "D";
+    }
+
+    function setVariant(key) {
+      const params = new URLSearchParams(location.search);
+      params.set("variant", key);
+      history.replaceState(null, "", "?" + params.toString());
+      render();
+    }
+
+    function render() {
+      const key = getVariant();
+      const meta = VARIANTS.find((x) => x.key === key);
+      allIds.forEach((id) => document.getElementById(id).classList.add("hidden"));
+      meta.show.forEach((id) => document.getElementById(id).classList.remove("hidden"));
+      // C: panel starts open for evaluation; strip always visible when C
+      if (key === "C") {
+        document.getElementById("variantC").classList.remove("hidden");
+      }
+      // D: start expanded; pill shown when minimized
+      if (key === "D") {
+        document.getElementById("variantDStrip").classList.add("hidden");
+        document.getElementById("variantD").classList.remove("hidden");
+      }
+      document.getElementById("variantLabel").textContent = key + " — " + meta.name;
+      console.log("[prototype state]", { variant: key, name: meta.name, visible: meta.show });
+    }
+
+    function cycle(delta) {
+      const i = VARIANTS.findIndex((x) => x.key === getVariant());
+      const next = VARIANTS[(i + delta + VARIANTS.length) % VARIANTS.length];
+      setVariant(next.key);
+    }
+
+    document.getElementById("prev").onclick = () => cycle(-1);
+    document.getElementById("next").onclick = () => cycle(1);
+    document.addEventListener("keydown", (e) => {
+      const t = e.target;
+      if (t && (t.tagName === "INPUT" || t.tagName === "TEXTAREA" || t.isContentEditable)) return;
+      if (e.key === "ArrowLeft") cycle(-1);
+      if (e.key === "ArrowRight") cycle(1);
+    });
+
+    function dCollapse() {
+      document.getElementById("variantD").classList.add("hidden");
+      document.getElementById("variantDStrip").classList.remove("hidden");
+      console.log("[prototype state]", { d: "pill" });
+    }
+    function dExpand() {
+      document.getElementById("variantDStrip").classList.add("hidden");
+      document.getElementById("variantD").classList.remove("hidden");
+      console.log("[prototype state]", { d: "stack" });
+    }
+    document.getElementById("dOpen").onclick = dExpand;
+    document.getElementById("dMinimize").onclick = dCollapse;
+    document.getElementById("dClose").onclick = dCollapse;
+
+    document.getElementById("cOpen").onclick = () => {
+      document.getElementById("variantC").classList.remove("hidden");
+      console.log("[prototype state]", { cPanel: "open" });
+    };
+    document.getElementById("cClose").onclick = () => {
+      document.getElementById("variantC").classList.add("hidden");
+      console.log("[prototype state]", { cPanel: "closed" });
+    };
+    document.querySelectorAll("#variantC .tabs button").forEach((btn) => {
+      btn.onclick = () => {
+        document.querySelectorAll("#variantC .tabs button").forEach((b) => b.classList.remove("active"));
+        document.querySelectorAll("#variantC .pane").forEach((p) => p.classList.remove("active"));
+        btn.classList.add("active");
+        document.querySelector('#variantC .pane[data-pane="' + btn.dataset.pane + '"]').classList.add("active");
+        console.log("[prototype state]", { cTab: btn.dataset.pane });
+      };
+    });
+
+    render();
+  </script>
+</body>
+</html>
diff --git a/docs/research/cursor-sdk-pob-agent.md b/docs/research/cursor-sdk-pob-agent.md
new file mode 100644
index 00000000000..3b733cd2265
--- /dev/null
+++ b/docs/research/cursor-sdk-pob-agent.md
@@ -0,0 +1,215 @@
+# Research: Cursor SDK for a personal PoB desktop agent
+
+**Ticket:** [waltersmike/PathOfBuilding#3](https://github.com/waltersmike/PathOfBuilding/issues/3)  
+**Date:** 2026-07-17  
+**Scope:** Primary sources only (Cursor docs / help / dashboard pages). No implementation.
+
+## Question
+
+What does the Cursor SDK / agent APIs allow for a **personal desktop** integration that must:
+
+1. Bill only against the **owner’s Cursor subscription**
+2. Support a **floating chat UX with history** (prefer reusing Cursor history if feasible)
+3. Run via a **non-LLM local sidecar** talking to Lua Path of Building
+4. Support **usage guardrails**
+
+## Verdict (short)
+
+**Feasible architecture:** a local Node/Python **sidecar** owns the floating chat UI and PoB IPC; it drives Cursor via **`@cursor/sdk` / `cursor-sdk` local runtime** with the owner’s **user API key**. Inference is always Cursor-hosted; the sidecar is non-LLM plumbing.
+
+**Not feasible from Cursor APIs alone:** embedding Cursor’s IDE chat UI, reading **Cursor IDE** chat history, or hard spend caps on individual plans without **app-level** metering (SDK token usage + plan limits / `RateLimitError`).
+
+---
+
+## 1. Auth model (API keys)
+
+| Claim | Source |
+| --- | --- |
+| SDK auth is `CURSOR_API_KEY` env or explicit `apiKey` / `api_key` | [TypeScript SDK — Authentication](https://cursor.com/docs/sdk/typescript) |
+| Accepted key types: **user API keys** and **team service-account keys**; **Team Admin API keys are not yet supported** | [TypeScript SDK — Authentication](https://cursor.com/docs/sdk/typescript), [Python SDK](https://cursor.com/docs/sdk/python) |
+| User keys: Cursor Dashboard → API Keys (`https://cursor.com/dashboard/api`) | [TypeScript SDK — Authentication](https://cursor.com/docs/sdk/typescript), [API Overview](https://cursor.com/docs/api) |
+| Service-account keys: team settings (team/enterprise path) | [TypeScript SDK — Authentication](https://cursor.com/docs/sdk/typescript), [Cloud Agents API overview](https://cursor.com/docs/cloud-agent/api/overview) |
+| REST APIs use Basic auth (`API_KEY` as username, empty password); Cloud Agents API also accepts Bearer | [API Overview](https://cursor.com/docs/api) |
+| Cloud Agents API keys: user key or service-account key | [Cloud Agents API](https://cursor.com/docs/cloud-agent/api/endpoints) |
+| `Cursor.me()` / `GET /v1/me` (and legacy `GET /v0/me`) return API key / caller identity metadata | [TypeScript SDK — Cursor.me()](https://cursor.com/docs/sdk/typescript), [Cloud Agents API — API Key Info](https://cursor.com/docs/cloud-agent/api/endpoints), [v0 API Key Info](https://cursor.com/docs/cloud-agent/api/v0) |
+
+**Implication for PoB:** use a **user API key** belonging to the subscription owner so spend lands on that user’s plan (see §5). Do not use Team Admin keys. Friend handoff = share that key out-of-band (product decision; docs do not provide a delegated-user OAuth flow for SDK).
+
+---
+
+## 2. Local vs cloud runtimes
+
+| Claim | Source |
+| --- | --- |
+| One SDK interface for **local** and **cloud** | [TypeScript SDK — Overview](https://cursor.com/docs/sdk/typescript) |
+| **Local:** agent loop runs in the caller process; files from disk/`cwd` | [TypeScript SDK — Overview](https://cursor.com/docs/sdk/typescript) |
+| **Cloud:** Cursor-hosted VM; repo cloned; survives caller disconnect | [TypeScript SDK — Overview](https://cursor.com/docs/sdk/typescript), [Cloud Agents API](https://cursor.com/docs/cloud-agent/api/endpoints) |
+| **“Local” ≠ local model** — all inference goes through Cursor-hosted models in both modes | [TypeScript SDK — Local means local agent loop, not local model](https://cursor.com/docs/sdk/typescript) |
+| Same `CURSOR_API_KEY` for either runtime | [TypeScript SDK — Overview](https://cursor.com/docs/sdk/typescript) |
+| Local agent IDs: `agent-…`; cloud: `bc-…` | [TypeScript SDK — Creating agents / resume](https://cursor.com/docs/sdk/typescript) |
+| TS SDK requires **Node.js 22.13+**; ships platform binaries (sandbox/ripgrep) | [TypeScript SDK — Installation](https://cursor.com/docs/sdk/typescript) |
+| Cloud Agents API is **public beta**; oriented at repository workflows (repos, PRs, artifacts) | [Cloud Agents API overview](https://cursor.com/docs/cloud-agent/api/overview) |
+| Cloud create can omit repos for a **no-repo** agent, but still runs in Cursor’s cloud environment | [Cloud Agents API — Create An Agent](https://cursor.com/docs/cloud-agent/api/endpoints) |
+
+**Implication for PoB:** prefer **local runtime**. The live Lua PoB process and build state live on the desktop; cloud VMs cannot attach to that process. Cloud remains useful only for repo-bound chores (e.g. editing the fork), not for the advisor sitting beside PoB.
+
+---
+
+## 3. History / conversation APIs
+
+### What exists (SDK / Cloud Agents)
+
+| Capability | Notes | Source |
+| --- | --- | --- |
+| **Agent** = durable conversation container across prompts | Follow-ups via `agent.send` keep context | [TypeScript SDK — Core concepts / Sending messages](https://cursor.com/docs/sdk/typescript) |
+| **`Agent.resume(agentId)`** | Continue after process restart; runtime from ID prefix | [TypeScript SDK — Resuming agents](https://cursor.com/docs/sdk/typescript) |
+| **`run.conversation()`** | Structured turns for the current run | [TypeScript SDK — conversation()](https://cursor.com/docs/sdk/typescript) |
+| **`Agent.messages.list(agentId)`** (local) | Stored user/assistant messages for a local agent | [TypeScript SDK — Agent.messages.list()](https://cursor.com/docs/sdk/typescript) |
+| Python: **`agent.list_messages()`** | Same idea on the agent handle | [Python SDK](https://cursor.com/docs/sdk/python) |
+| Local persistence | Default on-disk SQLite under home; optional JSONL / custom `local.store` | [TypeScript SDK — Conversation context / Local store](https://cursor.com/docs/sdk/typescript) |
+| Cloud persistence | Server-side; list/get/archive/delete agents | [TypeScript SDK — Cloud agent lifecycle](https://cursor.com/docs/sdk/typescript), [Cloud Agents API](https://cursor.com/docs/cloud-agent/api/endpoints) |
+| Legacy **`GET /v0/agents/{id}/conversation`** | Full cloud agent transcript (user + assistant texts) | [Cloud Agents API v0 — Agent Conversation](https://cursor.com/docs/cloud-agent/api/v0) |
+| v1 Cloud API | Agents + runs + stream + usage; conversation continuity via follow-up runs on the same agent | [Cloud Agents API endpoints](https://cursor.com/docs/cloud-agent/api/endpoints) |
+
+### What is **not** documented
+
+| Gap | Impact |
+| --- | --- |
+| **No API to read Cursor IDE / Composer chat history** | “Reuse Cursor history” cannot mean IDE threads; only **SDK/Cloud agent** transcripts |
+| **No embeddable Cursor chat widget** | Floating UX must be **custom UI** in the sidecar (or other host), streaming `run.stream()` / Python `run.messages()` |
+| Cookbook mentions “embedded in-product agents” as a use case for the SDK (caller builds the product surface) | [TypeScript SDK — Cookbook](https://cursor.com/docs/sdk/typescript) |
+
+**Implication for PoB:** map **per-build threads** → durable SDK `agentId`s (one agent per build thread + one for research). Persist/resume those IDs in the sidecar. Render history from `Agent.messages.list` / stream events — not from the Cursor IDE.
+
+---
+
+## 4. Sidecar ↔ PoB (non-LLM local bridge)
+
+| Claim | Source |
+| --- | --- |
+| Local agents can register **`local.customTools`** (in-process functions exposed as MCP `custom-user-tools`) | [TypeScript SDK — Custom tools](https://cursor.com/docs/sdk/typescript) |
+| Custom tools are **local-only**; on cloud they throw `ConfigurationError` | [TypeScript SDK — Custom tools](https://cursor.com/docs/sdk/typescript) |
+| MCP servers (stdio/HTTP) can be passed inline on create/send | [TypeScript SDK — MCP servers](https://cursor.com/docs/sdk/typescript), [Cursor MCP](https://cursor.com/docs/mcp) |
+| Hooks are **file-based only** (`.cursor/hooks.json`); no programmatic hook callbacks | [TypeScript SDK — Hooks](https://cursor.com/docs/sdk/typescript) |
+| Default local sandbox is **off**; headless runs have no human approval UI | [TypeScript SDK — Sandbox options](https://cursor.com/docs/sdk/typescript) |
+| Optional `local.sandboxOptions.enabled` + `local.autoReview` for safer tool execution | [TypeScript SDK — Sandbox / Auto-review](https://cursor.com/docs/sdk/typescript) |
+
+**Implication for PoB:** the **sidecar** (Node 22+ or Python) should:
+
+1. Own IPC to Lua PoB (export build, apply confirmed diffs, etc.)
+2. Expose PoB operations to the agent via **custom tools** and/or a **stdio MCP** server
+3. Keep LLM calls exclusively through Cursor SDK (satisfies “no second LLM vendor”)
+
+Cursor does not need to know about Lua; the sidecar is the adapter.
+
+---
+
+## 5. Pricing / subscription pooling
+
+| Claim | Source |
+| --- | --- |
+| SDK runs use the **same pricing, request pools, and Privacy Mode rules** as IDE and Cloud Agents | [TypeScript SDK — Usage and billing](https://cursor.com/docs/sdk/typescript) |
+| Spend appears on the usage dashboard under an **SDK** tag | [TypeScript SDK — Usage and billing](https://cursor.com/docs/sdk/typescript) → [usage dashboard](https://cursor.com/dashboard/usage) |
+| **User API keys bill to that user’s plan**; service-account keys bill to the **team** | [TypeScript SDK — Usage and billing](https://cursor.com/docs/sdk/typescript) |
+| Individual plans: two pools — **First-party models** (Auto, Composer 2.5, Grok 4.5) and **API** (model API rates); included amounts by tier (e.g. Pro $20 API / month) | [Models & Pricing](https://cursor.com/docs/models-and-pricing), [Usage and limits](https://cursor.com/help/models-and-usage/usage-limits) |
+| Over included usage → on-demand pay-as-you-go or upgrade | [Models & Pricing](https://cursor.com/docs/models-and-pricing), [Usage and limits](https://cursor.com/help/models-and-usage/usage-limits) |
+| Usage resets with billing cycle; unused does not roll over | [Usage and limits](https://cursor.com/help/models-and-usage/usage-limits), [Billing](https://cursor.com/help/account-and-billing/billing) |
+| Team spend limits / Admin spend APIs are **Teams/Enterprise** features | [Team dashboard](https://cursor.com/docs/account/teams/dashboard), [Admin API](https://cursor.com/docs/account/teams/admin-api), [API Overview](https://cursor.com/docs/api) |
+| Cloud Agents API + TS/Python SDKs listed as available to **All users** (Cloud Agents beta) | [API Overview](https://cursor.com/docs/api) |
+
+**Implication for PoB:** owner’s **user key** → owner’s subscription pools. No separate Cursor “product billing” for a personal sidecar. Friend using the owner’s key also draws from the **owner’s** pools (same key → same plan). There is **no documented subscription pooling** across separate individual accounts without a Team/Enterprise arrangement.
+
+---
+
+## 6. Usage guardrails (what Cursor gives vs what you build)
+
+### Provided by Cursor
+
+| Mechanism | Source |
+| --- | --- |
+| Per-run **`TokenUsage`** (`inputTokens`, `outputTokens`, cache, `totalTokens`) on `run.usage` / `result.usage` and `"usage"` stream events | [TypeScript SDK — Token usage](https://cursor.com/docs/sdk/typescript) |
+| Cloud **`GET /v1/agents/{id}/usage`** (totals + per-run) | [Cloud Agents API — Get Agent Usage](https://cursor.com/docs/cloud-agent/api/endpoints) |
+| Plan monthly included usage + dashboard visibility | [Usage and limits](https://cursor.com/help/models-and-usage/usage-limits), [Models & Pricing](https://cursor.com/docs/models-and-pricing) |
+| SDK **`RateLimitError`** for burst limits or **usage limit exceeded** | [TypeScript SDK — Errors](https://cursor.com/docs/sdk/typescript) (via docs error table) |
+| HTTP **429** on REST APIs when rate-limited | [API Overview — Rate Limits](https://cursor.com/docs/api) |
+| Cloud Agents: “Standard rate limiting” (not a fixed published RPM in the overview table) | [API Overview](https://cursor.com/docs/api) |
+| Hooks / sandbox / auto-review for **tool-call** policy (not dollar caps) | [TypeScript SDK — Hooks / Sandbox / Auto-review](https://cursor.com/docs/sdk/typescript) |
+| Team Admin **user spend limits** (Enterprise Admin API) — not the personal Hobby/Pro path | [Admin API](https://cursor.com/docs/account/teams/admin-api) |
+
+### Not provided (hard gap for “usage guardrails”)
+
+- No documented **SDK method to set a personal hard dollar/token budget** before a run.
+- No documented API for an individual Pro user to programmatically read **remaining monthly allowance** (Admin/Analytics spend endpoints are team/enterprise-oriented).
+- Guardrails for the PoB product must be **implemented in the sidecar**: sum `TokenUsage`, stop/warn before `send`, choose cheaper models (`Cursor.models.list` / prefer First-party pool models), and handle `RateLimitError`.
+
+---
+
+## 7. Constraints & hard blockers for embedding beside PoB
+
+### Hard blockers / non-starters
+
+1. **No Cursor-hosted floating chat UI or IDE embed API** — you build the window; SDK is headless. ([TypeScript SDK](https://cursor.com/docs/sdk/typescript) describes programmatic agent control, not UI embedding.)
+2. **No access to Cursor IDE chat history** — only SDK/Cloud agent transcripts (§3).
+3. **Cloud runtime cannot drive live PoB** — isolated VM / repo workflow; no path to the local Lua process. ([Cloud Agents API](https://cursor.com/docs/cloud-agent/api/endpoints), [SDK local vs cloud](https://cursor.com/docs/sdk/typescript))
+4. **Inference is never fully local** — “local” agent still bills Cursor-hosted models. ([SDK — Local means local agent loop](https://cursor.com/docs/sdk/typescript))
+5. **Team Admin keys unsupported** by SDK. ([SDK Authentication](https://cursor.com/docs/sdk/typescript))
+
+### Soft constraints (design around them)
+
+| Constraint | Mitigation |
+| --- | --- |
+| Node **22.13+** for `@cursor/sdk` | Bundle/require that runtime in the sidecar, or use Python SDK |
+| Local tools unrestricted by default | Enable sandbox/auto-review; prefer confirm-before-apply in **your** UX (product already wants propose → confirm → apply) |
+| Inline MCP secrets not persisted across `resume` | Re-pass MCP/custom tools on resume ([SDK resume notes](https://cursor.com/docs/sdk/typescript)) |
+| Large context (full PoB export every turn) burns included usage quickly | Prefer First-party pool models where possible; meter tokens; optimize later |
+| Public beta surfaces (SDK + Cloud Agents API) | Expect breaking changes before GA ([Cloud Agents overview](https://cursor.com/docs/cloud-agent/api/overview); SDKs marked public beta in skill/docs) |
+
+### Fit vs requirements checklist
+
+| Requirement | Fit |
+| --- | --- |
+| (1) Bill only owner subscription | **Yes** with owner **user API key** |
+| (2) Floating chat + history | **Yes** with custom UI + SDK agent history; **No** reusing IDE history |
+| (3) Non-LLM sidecar ↔ Lua PoB | **Yes** (local SDK + custom tools / MCP) |
+| (4) Usage guardrails | **Partial** — telemetry + plan limits + app-enforced caps; no first-class personal budget API |
+
+---
+
+## 8. Recommended integration shape (research-only)
+
+```
+┌─────────────────────┐     IPC      ┌──────────────────────────────┐
+│ Path of Building    │◄────────────►│ Local sidecar (Node/Python)  │
+│ (Lua, desktop)      │  export/apply│  • floating chat UI          │
+└─────────────────────┘              │  • thread → agentId map      │
+                                     │  • usage metering/guardrails │
+                                     │  • customTools / MCP → PoB   │
+                                     └──────────────┬───────────────┘
+                                                    │ @cursor/sdk local
+                                                    │ CURSOR_API_KEY (user)
+                                                    ▼
+                                     ┌──────────────────────────────┐
+                                     │ Cursor hosted models / pools │
+                                     └──────────────────────────────┘
+```
+
+Do **not** route the advisor through Cloud Agents for day-to-day build advice.
+
+---
+
+## Primary sources consulted
+
+- [Cursor TypeScript SDK](https://cursor.com/docs/sdk/typescript)
+- [Cursor Python SDK](https://cursor.com/docs/sdk/python)
+- [Cursor APIs Overview](https://cursor.com/docs/api)
+- [Cloud Agents API (v1)](https://cursor.com/docs/cloud-agent/api/endpoints)
+- [Cloud Agents API v0 (legacy conversation endpoint)](https://cursor.com/docs/cloud-agent/api/v0)
+- [Models & Pricing](https://cursor.com/docs/models-and-pricing)
+- [Usage and limits (help)](https://cursor.com/help/models-and-usage/usage-limits)
+- [Pricing / plans (help)](https://cursor.com/help/account-and-billing/pricing)
+- [Billing (help)](https://cursor.com/help/account-and-billing/billing)
+- [Team dashboard (spend limits context)](https://cursor.com/docs/account/teams/dashboard)
+- [Admin API (team spend limits)](https://cursor.com/docs/account/teams/admin-api)
+- Cursor Dashboard links referenced by docs: [API Keys](https://cursor.com/dashboard/api), [Usage](https://cursor.com/dashboard/usage)
+
+Also cross-checked against the in-Cursor `/sdk` skill (`~/.cursor/skills-cursor/sdk/SKILL.md`), which points at the same official SDK docs as canonical.
diff --git a/docs/research/pob-agent-integration-surfaces.md b/docs/research/pob-agent-integration-surfaces.md
new file mode 100644
index 00000000000..dd21513fd61
--- /dev/null
+++ b/docs/research/pob-agent-integration-surfaces.md
@@ -0,0 +1,266 @@
+# Research: PoB integration surfaces for an agent bridge
+
+**Ticket:** [#4](https://github.com/waltersmike/PathOfBuilding/issues/4) (part of [#1](https://github.com/waltersmike/PathOfBuilding/issues/1))  
+**Question:** In this Path of Building codebase, what are the realistic integration surfaces for (1) a floating window open/close at will, (2) a full build export/snapshot every agent turn, (3) applying a confirmed proposal that mutates tree, items/gems, and Configuration, (4) optional handoff into the Compare tab, and (5) a non-LLM sidecar process talking to the Lua app?  
+**Scope:** Identify seams, gaps, and what would have to be invented. Do **not** implement the agent.  
+**Primary sources:** this repo's Lua app (`src/`), docs, and runtime host artifacts under `runtime/`.  
+**Date:** 2026-07-17
+
+---
+
+## Executive summary
+
+| Need | Realistic surface today | Verdict |
+|------|-------------------------|---------|
+| (1) Floating window | In-app `PopupDialog` / controls only; **one** OS window (`SimpleGraphic`) | **Invent** non-modal in-app panel *or* put the UI in an external sidecar window |
+| (2) Full build snapshot | `buildMode:SaveDB` → XML; optional Deflate+base64 share code | **Reuse** — strongest existing seam |
+| (3) Apply confirmed proposal | Full wipe via `Init`+XML, **or** per-tab Load/undo/copy helpers | **Partial reuse** — no cross-tab “proposal transaction” |
+| (4) Compare handoff | `CompareTab:ImportBuild` / Import-tab “Import as comparison” | **Reuse** — optional path already exists |
+| (5) Sidecar ↔ Lua | `LaunchSubScript`, `SpawnProcess`, files, clipboard, HTTP (`lcurl`); unused `socket.dll` | **Invent** the bridge protocol; host has primitives but no agent IPC |
+
+---
+
+## Host / UI architecture (context for all five)
+
+PoB is a LuaJIT app hosted by **SimpleGraphic** (see `docs/rundown.md`, `src/Launch.lua` `#@ SimpleGraphic`). There is a single OS window (`SetWindowTitle`, `vid_resizable`). The Lua UI is a custom control tree (`Control` / `ControlHost`), not a native widget toolkit.
+
+Two top-level modes live under `main.modes`: `LIST` (`Modules/BuildList`) and `BUILD` (`Modules/Build`). Inside BUILD, `build.viewMode` switches tabs (`TREE`, `SKILLS`, `ITEMS`, `CONFIG`, `IMPORT`, `COMPARE`, …) and each tab draws into a shared viewport (`buildMode:OnFrame`).
+
+Modal UI is a stack of in-window overlays: `main.popups` processed/drawn before normal controls (`main:OnFrame`, `main:OpenPopup` / `ClosePopup`). When a popup is open, input is consumed by the popup only.
+
+```text
+OS window (SimpleGraphic)
+└── main viewPort (full screen)
+    ├── mode UI (LIST or BUILD tabs)
+    ├── ToastNotification (non-blocking messages)
+    └── main.popups[1] (modal PopupDialog — blocks input underneath)
+```
+
+There is **no** Lua API in this tree for creating a second OS window or docking an external HWND.
+
+---
+
+## (1) Floating window open/close at will
+
+### Existing seams
+
+- **`PopupDialog`** (`src/Classes/PopupDialog.lua`) + **`main:OpenPopup` / `ClosePopup` / `OpenConfirmPopup` / `OpenMessagePopup`** (`src/Modules/Main.lua`): centered modal dialogs with controls, Escape/Enter handling. Used heavily (Options, Import Comparison, Save As, etc.).
+- **`ToastNotification`** (`src/Modules/ToastNotification.lua`): non-modal, auto-dismissing messages at the bottom of the main window — not a chat/workspace surface.
+- **Tab panels**: each BUILD tab is a `ControlHost` drawing into `tabViewPort` (`buildMode:OnFrame`). A new “Agent” tab would fit this pattern but is a full tab, not a floating window.
+- Window chrome is limited to title text (`main:SetWindowTitleSubtext`, `PassiveSpec:SetWindowTitleWithBuildClass`).
+
+### Gaps
+
+- Popups are **modal**: `main:OnFrame` routes all input to `self.popups[1]` and wipes events, so the user cannot edit the tree/items while a popup is open. That conflicts with “open/close at will” while continuing to use PoB.
+- No multi-window / always-on-top floating panel primitive in the Lua host surface documented in this repo.
+- No persisted window-placement system for arbitrary panels (placement persistence is listed as unspecified on the map issue).
+
+### What would have to be invented
+
+1. **In-app non-modal floating panel** (recommended if UI must live inside PoB): a new control host drawn on a high draw layer, with its own show/hide flag, that does **not** go through `main.popups` (so it does not steal all input). Would need hit-testing rules so clicks on the panel vs. the tab underneath behave correctly — pattern does not exist today (toasts are display-only).
+2. **External window owned by a sidecar** (fits “non-LLM sidecar OK”): agent UI is outside PoB; PoB only exposes snapshot/apply APIs. Avoids inventing non-modal overlay UX inside SimpleGraphic.
+3. **Misuse of `PopupDialog`**: technically open/close works, but modality makes it a poor fit for an advisor that must stay open while the user inspects the build.
+
+---
+
+## (2) Full build export / snapshot every agent turn
+
+### Existing seams (strong)
+
+Canonical serialization is XML with root element `PathOfBuilding`:
+
+- **`buildMode:SaveDB(fileName)`** (`src/Modules/Build.lua`): builds `{ elem = "PathOfBuilding" }`, writes the `Build` section via `buildMode:Save`, then each registered saver’s `Save`, then `common.xml.ComposeXML`. Returns the XML **string** (or shows an error).
+- **Savers registered in `buildMode:Init`**:
+
+  | XML elem | Object |
+  |----------|--------|
+  | `Config` | `configTab` |
+  | `Notes` | `notesTab` |
+  | `Party` | `partyTab` |
+  | `Tree` | `treeTab` |
+  | `TreeView` | `treeTab.viewer` |
+  | `Items` | `itemsTab` |
+  | `Skills` | `skillsTab` |
+  | `Calcs` | `calcsTab` |
+  | `Import` | `importTab` |
+
+- **Share-code encoding** (Import/Export tab):  
+  `common.base64.encode(Deflate(self.build:SaveDB("code"))):gsub("+","-"):gsub("/","_")`  
+  (`ImportTab` generate-code button; same pattern in `CompareTab:ImportFromCode` decode path).
+- **File persistence**: `SaveDBFile` / `LoadDBFile` read/write `*.xml` under the user’s build path.
+- **Headless helpers**: `HeadlessWrapper.loadBuildFromXML` / `newBuild` for offline loading (testing), not for talking to a live GUI session.
+
+Calling `SaveDB` does not require UI interaction; it reads live tab state. After edits, calcs refresh when `buildFlag` is set (`buildMode:OnFrame` → `calcsTab:BuildOutput`).
+
+### Gaps / caveats
+
+- **Compare entries are not savers**: comparison builds live only in `compareTab.compareEntries` memory; they are not part of `SaveDB` XML.
+- Snapshot size can be large (full items + tree + config). Product notes already say monitor usage — no compression-for-agent path beyond the existing Deflate share code.
+- `SaveDB` argument is only used for error messages; it does not change content.
+- Party “Export Support” buffs are optional via `partyTab.enableExportBuffs` (ImportTab checkbox); usually irrelevant for a solo build advisor.
+
+### What would have to be invented
+
+- A thin **agent-facing export API** (e.g. always return XML and/or share code + metadata like `dbFileName`, `buildName`, `outputRevision`) — wrapping existing `SaveDB`.
+- Optional **delta/hash** if full XML every turn becomes too large for the LLM context (optimization later; not required for a first bridge).
+- A place to dump the snapshot for a sidecar (clipboard, temp file, HTTP body) — see (5).
+
+---
+
+## (3) Applying a confirmed proposal (tree, items/gems, Configuration)
+
+### Existing seams
+
+**A. Full-build replace (nuclear, already used for Import)**
+
+`ImportTab` “Import to this build”:
+
+1. Confirm popup warning that import erases **ALL** existing data.
+2. `build:Shutdown()` then `build:Init(dbFileName, buildName, importCodeXML, …)`.
+
+That reloads the entire BUILD mode from XML. Correct for “replace whole build with proposed XML,” heavy-handed for partial proposals, and destroys unsaved in-memory-only state that isn’t in the XML path you supply.
+
+**B. Per-domain mutation / undo (granular)**
+
+Each major surface already has Load/Save and (usually) undo:
+
+| Domain | Load/Save | Undo | Notable mutators |
+|--------|-----------|------|------------------|
+| Passive tree | `TreeTab:Load` / `Save`; `PassiveSpec` | `PassiveSpec:CreateUndoState` / `RestoreUndoState`; `AllocNode` / `DeallocNode` | Compare: `CopyCompareSpecToPrimary` |
+| Items | `ItemsTab:Load` / `Save` | `CreateUndoState` / `RestoreUndoState`; `AddItem`, slot `SetSelItemId` | Compare: `CopyCompareItemToPrimary` |
+| Skills/gems | `SkillsTab:Load` / `Save` | `CreateUndoState` / `RestoreUndoState` | Socket-group structures in skills tab |
+| Configuration | `ConfigTab:Load` / `Save` | undo of `configSets[…].input`; `UpdateControls` + `BuildModList` | `ConfigOptions` var list drives keys |
+
+After mutations, callers typically set `build.buildFlag = true` so the next frame rebuilds calcs.
+
+**C. Compare → primary copy helpers (partial apply patterns)**
+
+`CompareTab:CopyCompareSpecToPrimary` and `CopyCompareItemToPrimary` show how to push pieces from a secondary XML-derived `CompareEntry` into the live build (with explicit limitations — e.g. jewels not copied with the tree because item IDs differ).
+
+**D. Undo model**
+
+`UndoHandler` (`src/Classes/UndoHandler.lua`) is **per object** (items tab, skills tab, config tab, passive spec, …), depth-capped (~100), not a single transactional undo spanning tree+items+skills+config.
+
+### Gaps
+
+- **No proposal/diff/apply API**: nothing accepts an agent “proposal” object and applies tree + items + gems + config atomically.
+- **No cross-tab undo**: map issue still lists undo/rollback semantics as unspecified; the code supports per-tab Ctrl+Z style undo only.
+- Full `Init` from XML is all-or-nothing and remounts UI.
+- Applying by writing a temp `.xml` and calling `LoadDB` mid-session is not a supported hot-reload path without going through `Init`/`Shutdown` (section load happens during `Init`).
+- Skills and items are coupled (socket groups, jewel sockets on the tree); order of application matters (tree deferred after items on load for jewel reasons — see comments in `buildMode:Init`).
+
+### What would have to be invented
+
+1. **Proposal representation** (likely proposed XML sections, or structured patches) owned by the agent UI — not present in PoB.
+2. **Apply orchestrator** that either:
+   - builds a full XML and runs the Import-to-this-build path, **or**
+   - applies section-wise via tab Load/RestoreUndoState / copy helpers, then sets `buildFlag`, with a documented order (Items → Skills → Tree → Config mirrors load constraints).
+3. **Rollback policy**: snapshot `SaveDB` before apply and re-`Init`, or push coordinated undo states on each tab (fragile), or rely on PoB Save + user revert.
+4. Agent-owned **diff display** (product decision: agent window owns the proposal diff; Compare is optional).
+
+---
+
+## (4) Optional handoff into the Compare tab
+
+### Existing seams (strong)
+
+- **`CompareTab:ImportBuild(xmlText, label)`** (`src/Classes/CompareTab.lua`): constructs `CompareEntry` from XML, appends to `compareEntries`, selects it. Returns success if calcs produced `mainOutput`.
+- **`CompareTab:ImportFromCode(code)`**: Deflate+base64 decode → `ImportBuild`.
+- **Import tab mode** `"Import as comparison"`: calls `compareTab:ImportBuild` and sets `build.viewMode = "COMPARE"`.
+- **UI import paths**: `OpenImportPopup` (paste code/URL), `OpenImportFolderPopup` (local `.xml` files via `BuildListHelpers.ScanFolder`).
+- **`CompareEntry`** (`src/Classes/CompareEntry.lua`): lightweight build wrapper — loads XML, creates tabs, runs calcs **without** primary BUILD chrome. Good model for “secondary build in memory.”
+- Compare sub-views: Summary / Tree / Skills / Items / Calcs / Config; tree overlay; power report; copy-to-primary helpers (see §3).
+
+### Gaps
+
+- Compare state is **not persisted** in the primary build’s `SaveDB`.
+- Handoff is manual today (user imports). Programmatic handoff only needs a caller to `ImportBuild` + optionally `viewMode = "COMPARE"` — small glue, not a new subsystem.
+- Compare is for **side-by-side analysis**, not for owning the proposal diff (aligned with product notes).
+
+### What would have to be invented
+
+- Optional one-liner bridge from the agent “Apply preview” / “Send to Compare” action → `ImportBuild(proposedXml, label)` (+ maybe switch tab). No deep Compare changes required for MVP.
+
+---
+
+## (5) Non-LLM sidecar talking to the Lua app
+
+### Existing host primitives
+
+| Primitive | Location | Role |
+|-----------|----------|------|
+| `LaunchSubScript` | SimpleGraphic host; used in `Launch:DownloadPage`, `CheckForUpdate`, `TreeTab`, `PoBArchivesProvider` | In-process Lua worker; callbacks via `launch:OnSubFinished` / `RegisterSubScript`. **Not** a long-lived external process server. |
+| `SpawnProcess` | `Launch:ApplyUpdate`, `UpdateApply.lua`; stubbed in `HeadlessWrapper` | Fire-and-forget OS process (updater). |
+| `launch:DownloadPage` | `lcurl` inside a subscript | Outbound HTTPS. |
+| `Copy` / `Paste` | Host clipboard | Manual or scripted exchange. |
+| `io.open` | Widespread | Read/write build XML and settings on disk. |
+| `HeadlessWrapper.lua` | CLI/test entry | Separate process loads PoB headless; **does not attach to a running GUI**. |
+| `socket.dll` | `runtime/socket.dll` | Present in the Windows runtime bundle; **no `require("socket")` (or similar) usage anywhere under `src/`**. Latent capability, not an existing API. |
+
+There is **no** first-party agent bridge, named-pipe protocol, localhost RPC, or message bus in the Lua codebase.
+
+### Gaps
+
+- GUI session and sidecar are separate processes with no shared memory API exposed to Lua.
+- Subscripts cannot replace a durable sidecar (they run short scripts and return).
+- Headless PoB cannot drive the user’s open build; it can only load another copy of XML offline.
+
+### What would have to be invented
+
+A bridge design choosing one (or combining) of:
+
+1. **File mailbox**: sidecar writes commands / reads snapshots under a known directory; Lua polls each `OnFrame` (or on a timer). Uses only `io.*` — lowest invention cost, highest latency/races.
+2. **Clipboard protocol**: fragile UX; already available via `Copy`/`Paste`.
+3. **Local HTTP**: sidecar listens; Lua uses `lcurl` or a new `LaunchSubScript` loop to POST/GET. Outbound from PoB is proven; inbound server **inside** the GUI process would need sockets (possibly via unused `socket.dll`) or the sidecar is the server and PoB only polls/pushes.
+4. **Lua `socket` module**: verify loadability from the shipped runtime, then invent a small JSON line protocol. Currently unused — treat as R&D, not a seam.
+5. **Injected Lua module in this fork**: e.g. `Modules/AgentBridge.lua` started from `Main:Init`, owning poll/connect logic — all fork-local (map forbids upstream merge).
+
+Cursor-side integration (SDK, chat history) is **outside** this PoB codebase and out of scope for this ticket’s primary sources.
+
+---
+
+## Recommended integration shape (research conclusion only)
+
+Without implementing anything, the lowest-friction architecture consistent with the code is:
+
+```text
+┌─────────────────────────────┐     snapshot XML / share code      ┌──────────────────┐
+│ PoB GUI (SimpleGraphic)     │ ─────────────────────────────────► │ Non-LLM sidecar  │
+│  SaveDB every turn          │                                    │  ↔ Cursor agent  │
+│  Apply via Init or tab APIs │ ◄───────────────────────────────── │  proposal XML    │
+│  optional CompareTab import │                                    │  (own UI window) │
+└─────────────────────────────┘         invented IPC               └──────────────────┘
+```
+
+- **Reuse:** `SaveDB`, Import encode/decode, `CompareTab:ImportBuild`, per-tab Load/undo mutators, `buildFlag` recalc.
+- **Invent:** agent UI window (prefer sidecar-owned OS window **or** new non-modal in-app panel), IPC protocol, proposal apply orchestrator + rollback policy, optional AgentBridge Lua module in this fork.
+
+---
+
+## Source index (primary)
+
+| Topic | Paths / symbols |
+|-------|-----------------|
+| Host entry | `src/Launch.lua` (`SetWindowTitle`, `LaunchSubScript`, `SpawnProcess`, `DownloadPage`) |
+| Main loop / popups | `src/Modules/Main.lua` (`OnFrame`, `OpenPopup`, `ClosePopup`, `popups`) |
+| Popup UI | `src/Classes/PopupDialog.lua` |
+| Build lifecycle | `src/Modules/Build.lua` (`Init`, `Shutdown`, `SaveDB`, `LoadDB`, `savers`, `viewMode`, `OnFrame`, `buildFlag`) |
+| Import/Export | `src/Classes/ImportTab.lua` (generate code, import modes, confirm wipe) |
+| Share sites | `src/Modules/BuildSiteTools.lua` |
+| Compare | `src/Classes/CompareTab.lua` (`ImportBuild`, `ImportFromCode`, copy helpers); `src/Classes/CompareEntry.lua` |
+| Config | `src/Classes/ConfigTab.lua` (`Load`/`Save`, `RestoreUndoState`, `BuildModList`) |
+| Tree | `src/Classes/TreeTab.lua`, `src/Classes/PassiveSpec.lua` |
+| Items / skills | `src/Classes/ItemsTab.lua`, `src/Classes/SkillsTab.lua` |
+| Undo | `src/Classes/UndoHandler.lua` |
+| Headless | `src/HeadlessWrapper.lua` |
+| Runtime host | `docs/rundown.md` (SimpleGraphic, lcurl, lzip); `runtime/socket.dll` (unused by `src/`) |
+| Layout docs | `docs/rundown.md` |
+
+---
+
+## Explicit non-findings
+
+- No existing “agent”, “Cursor”, or “sidecar bridge” module in `src/`.
+- No second-window API in the Lua bindings used by this app.
+- No `require("socket")` call sites despite `runtime/socket.dll`.
+- Implementation of the agent remains out of scope (per ticket and map issue #1).
diff --git a/docs/research/poe1-knowledge-sources-patch-notes.md b/docs/research/poe1-knowledge-sources-patch-notes.md
new file mode 100644
index 00000000000..bbe60027e5e
--- /dev/null
+++ b/docs/research/poe1-knowledge-sources-patch-notes.md
@@ -0,0 +1,289 @@
+# Research: PoE1 knowledge sources and patch-notes feeds
+
+**Ticket:** https://github.com/waltersmike/PathOfBuilding/issues/5  
+**Branch:** `research/poe1-knowledge-sources`  
+**Date:** 2026-07-17  
+**Scope:** Facts for Knowledge Pack allowlist/denylist and Patch-Notes Sync design. No scraper or agent implementation.
+
+**Critical constraint:** Path of Exile 1 only. Treating PoE2 data (including same-named items/skills) as PoE1 truth is a catastrophic failure mode for the planned agent.
+
+---
+
+## Question
+
+What high-trust PoE1 sources should seed the Knowledge Pack allowlist/denylist, and what machine-readable or scrapable PoE1 patch-notes feeds exist for Patch-Notes Sync?
+
+---
+
+## Short answers
+
+1. **Allowlist seeds (PoE1):** official `pathofexile.com` (especially the Patch Notes forum + news RSS as a secondary signal), `poewiki.net`, `poe.ninja/poe1/*`, Reddit `r/pathofexile` + `r/PathOfExileBuilds`, and PoB-adjacent community tools that already namespace PoE1 (`poedb.tw`, `maxroll.gg/poe`, `pobb.in`).
+2. **Denylist / PoE2 lookalike traps:** `pathofexile2.com`, GGG forum id `2212` (“Early Access Patch Notes”, `0.x` versions), `poe2wiki.net`, `poe2db.tw`, `poe.ninja/poe2/*`, `maxroll.gg/poe2`, `r/PathOfExile2`, and `grindinggear/poe2-skilltree-export`. Same skill/item **names** exist on both wikis with different mechanics.
+3. **Patch-Notes Sync:** there is **no** official dedicated patch-notes API or RSS. The durable primary surface is HTML forum listing + thread pages under `https://www.pathofexile.com/forum/view-forum/patch-notes`. Official news RSS exists but is incomplete for hotfixes and can mention PoE2. Discriminate games by **forum section** and **version scheme** (`3.x` PoE1 vs `0.x` PoE2 EA).
+
+---
+
+## 1. Official GGG / Path of Exile 1
+
+### 1.1 Site and forums (primary for patch notes)
+
+| Surface | URL | Role |
+| --- | --- | --- |
+| PoE1 site | https://www.pathofexile.com/ | Official home; news, forums, trade, shop |
+| **PoE1 Patch Notes forum** | https://www.pathofexile.com/forum/view-forum/patch-notes | Canonical chronological list of PoE1 patch/hotfix threads |
+| Example PoE1 thread | https://www.pathofexile.com/forum/view-thread/3985151 | `3.28.0k Patch Notes` (verified 2026-07-17) |
+| Example league patch | https://www.pathofexile.com/forum/view-thread/3985332 | `Content Update 3.29.0 - Path of Exile: Curse of the Allflame` |
+| Developer docs | https://www.pathofexile.com/developer/docs | OAuth API policies; **no patch-notes resource** |
+| Data exports | https://www.pathofexile.com/developer/docs/data | Official passive/atlas tree exports only |
+| PoE1 passive tree export | https://github.com/grindinggear/skilltree-export | First-party tree JSON |
+| PoE1 atlas tree export | https://github.com/grindinggear/atlastree-export | First-party atlas tree (linked from data docs) |
+| Trade leagues JSON | https://www.pathofexile.com/api/trade/data/leagues | Official league list (PoE1 trade stack) |
+
+**Observed (2026-07-17):** the Patch Notes forum listing currently shows PoE1 `3.28.x` / `3.29.0` threads (e.g. `3.28.0k`, Curse of the Allflame `3.29.0`). Thread bodies are ordinary HTML forum posts authored by GGG staff accounts — scrapable, not machine-schema’d.
+
+### 1.2 Official news RSS (partial, not patch-notes-complete)
+
+| Feed | URL | Notes |
+| --- | --- | --- |
+| PoE1 site news RSS | https://www.pathofexile.com/news/rss | Valid RSS 2.0; channel title `Path of Exile News`; category typically `news` |
+| PoE2 site news RSS | https://pathofexile2.com/news/rss | Separate host; **denylist for PoE1 sync** |
+
+**Facts:**
+
+- Feed is live and returns XML (HTTP 200 probed 2026-07-17).
+- Items link to forum news threads (e.g. expansion announcements), not every Patch Notes hotfix.
+- Community asked for a dedicated patch-notes RSS category; thread archived without an official feed: https://www.pathofexile.com/forum/view-thread/3554274
+- Cloudflare has historically blocked some RSS clients (`403` challenges reported): https://www.pathofexile.com/forum/view-thread/3648166
+- Sample titles on 2026-07-17 were mostly PoE1 league/marketing, but the same feed can carry PoE2-adjacent headlines (e.g. “Path of Exile 2: Return of the Ancients FAQ”). **Do not treat news RSS as a pure PoE1 patch-notes stream.**
+
+### 1.3 What GGG does *not* provide for patch notes
+
+From https://www.pathofexile.com/developer/docs :
+
+- Supported resources are only those in the API reference and data exports.
+- Reverse-engineering undocumented internal endpoints is against Terms of Use §7i.
+- Data exports explicitly cover **passive/atlas trees**, not patch notes, skill gems, or item text: https://www.pathofexile.com/developer/docs/data
+
+**Implication for Patch-Notes Sync:** design around **forum HTML polling** (list → thread), optionally using news RSS as a noisy secondary hint — not as the sole source of truth.
+
+---
+
+## 2. poewiki (PoE1) — high-trust community encyclopedia
+
+| Surface | URL | Role |
+| --- | --- | --- |
+| PoE1 wiki | https://www.poewiki.net/ | Canonical community wiki for Path of Exile 1 |
+| MediaWiki API | https://www.poewiki.net/w/api.php | Standard MW API (query, parse, etc.) |
+| Cargo / data query docs | https://www.poewiki.net/wiki/Path_of_Exile_Wiki:Data_query_API | Structured item/skill/mod queries (Cargo) |
+| PoB deep-link precedent | `src/Modules/ItemTools.lua` opens `https://www.poewiki.net/wiki/...` on F1 | First-party PoB integration signal |
+
+**Bot protection:** HTML and API fetches from this environment received Anubis proof-of-work interstitial pages (“Making sure you're not a bot!”). Design implication: allowlist the domain, but plan for polite human-browser or authenticated access patterns, caching, and rate limits — not naive bulk scrape.
+
+**Legacy Fandom host:** `pathofexile.fandom.com` is a historical Gamepedia/Fandom surface; not the current community home. Prefer `poewiki.net` only for PoE1 wiki facts.
+
+---
+
+## 3. poe.ninja — economy / builds (PoE1 namespace)
+
+poe.ninja hosts **both** games with explicit path prefixes:
+
+| PoE1 (allow) | PoE2 (deny) |
+| --- | --- |
+| https://poe.ninja/poe1/ | https://poe.ninja/poe2/ |
+| https://poe.ninja/poe1/builds | https://poe.ninja/poe2/builds |
+| https://poe.ninja/poe1/data | (PoE2 equivalents under `/poe2/`) |
+
+### Machine-readable PoE1 economy endpoints (verified 2026-07-17)
+
+Example (HTTP 200, JSON):
+
+```text
+https://poe.ninja/poe1/api/economy/stash/current/currency/overview?league=Standard&type=Currency
+```
+
+League index-ish JSON:
+
+```text
+https://poe.ninja/poe1/api/data/index-state
+```
+
+**Breaking change vs older community docs:** legacy URLs such as
+
+```text
+https://poe.ninja/api/data/currencyoverview?league=Standard&type=Currency
+```
+
+returned **HTTP 404** on 2026-07-17. Community trackers report the migration to `/poe1/api/...` paths (e.g. https://github.com/exilence-ce/exilence-ce/issues/49). Knowledge Pack tooling must prefer the **`/poe1/`** prefix.
+
+**PoB already namespaces PoE1 PoB share URLs** under `poe.ninja/poe1/pob/...` (`src/Modules/BuildSiteTools.lua`).
+
+---
+
+## 4. Reddit community surfaces
+
+| Subreddit | PoE game | Seed |
+| --- | --- | --- |
+| https://www.reddit.com/r/pathofexile/ | PoE1 primary discussion | **Allow** |
+| https://www.reddit.com/r/PathOfExileBuilds/ | PoE1 builds | **Allow** |
+| https://www.reddit.com/r/pathofexiledev/ | Tooling / API discussion | **Allow** (lower weight for build truth) |
+| https://www.reddit.com/r/pathofexile/wiki/tools | Community tool index | **Allow** as discovery, not ground truth |
+| https://www.reddit.com/r/PathOfExile2/ | PoE2 | **Deny** |
+
+**Notes:**
+
+- Reddit JSON endpoints often return `403` to non-browser clients; design sync/research around official Reddit API or browser-grade access, not anonymous scraping assumptions.
+- Community Discord (`discord.gg/pathofexile`) is mixed PoE1+PoE2; treat as low-trust / optional, not allowlist-default for factual claims.
+
+---
+
+## 5. Other PoE1-friendly community tools (secondary allow)
+
+These are not “official,” but are high-signal and already used by PoB or the PoE1 ecosystem. Prefer paths that **encode PoE1 in the URL**:
+
+| Tool | PoE1 URL pattern | PoE2 lookalike |
+| --- | --- | --- |
+| PoEDB | https://poedb.tw/ | https://poe2db.tw/ |
+| Maxroll | https://maxroll.gg/poe/ | https://maxroll.gg/poe2/ |
+| pobb.in | https://pobb.in/ | (PoB share; confirm content is PoE1 before trusting) |
+| FilterBlade / Awakened PoE Trade / etc. | listed on r/pathofexile wiki/tools | N/A — verify game |
+
+PoB’s own import/export allowlist (`src/Modules/BuildSiteTools.lua`) already distinguishes `maxroll.gg/poe/...` and `poe.ninja/poe1/...`.
+
+---
+
+## 6. PoE2 lookalike traps (denylist seeds)
+
+### 6.1 Domain / path traps
+
+| Trap | Why catastrophic |
+| --- | --- |
+| https://pathofexile2.com/ (+ `/news/rss`) | Separate official PoE2 site and news feed |
+| https://www.pathofexile.com/forum/view-forum/2212 | Title: **“Early Access Patch Notes”**; threads are `0.5.x` PoE2 patches (e.g. `0.5.4c`) — same GGG forum chrome as PoE1 |
+| https://www.poe2wiki.net/ | Parallel wiki; pages like `/wiki/Spark` exist with **PoE2** gem data |
+| https://poe2db.tw/ | Parallel DB site (e.g. `/us/Lightning_Strike`) |
+| https://poe.ninja/poe2/ | Explicit PoE2 builds/economy UI |
+| https://maxroll.gg/poe2/ | Explicit PoE2 Maxroll namespace |
+| https://github.com/grindinggear/poe2-skilltree-export | Official PoE2 tree export (pair of PoE1 `skilltree-export`) |
+| `r/PathOfExile2` | PoE2 subreddit |
+| Fandom / mirror pages that do not resolve to `poewiki.net` | Easy to confuse with PoE1 wiki |
+
+### 6.2 Same-name, wrong-game content (examples)
+
+These names exist as distinct entities in both games; wiki/DB pages are **not interchangeable**:
+
+| Name | PoE1 | PoE2 |
+| --- | --- | --- |
+| Spark | https://www.poewiki.net/wiki/Spark | https://www.poe2wiki.net/wiki/Spark |
+| Lightning Strike | (poewiki) | https://poe2db.tw/us/Lightning_Strike |
+| Ball Lightning / Flame Dash / many legacy skill names | PoE1 gems | Reworked / weapon-gated PoE2 skills |
+
+**Exclusion rule for implementers:** host + game namespace beats item/skill string equality. Never resolve a bare skill name to the first search hit across games.
+
+### 6.3 Version-scheme discriminator (patch notes)
+
+| Game | Typical version strings on GGG forums | Forum |
+| --- | --- | --- |
+| PoE1 | `3.28.0k`, `3.29.0`, `Content Update 3.x` | `/forum/view-forum/patch-notes` |
+| PoE2 EA | `0.5.4c`, `0.5.3 Hotfix N` | `/forum/view-forum/2212` |
+
+Sync should **hard-fail** (or quarantine) any candidate patch thread whose version matches `^0\.` or whose forum id is `2212`.
+
+---
+
+## 7. Patch-Notes Sync — feed / scrape options ranked
+
+| Rank | Source | Machine-readable? | PoE1 purity | Completeness for balance changes | Recommendation |
+| --- | --- | --- | --- | --- | --- |
+| 1 | Forum list + threads: `/forum/view-forum/patch-notes` | HTML only (scrape) | High if scoped to this forum | High (includes hotfixes) | **Primary sync input** |
+| 2 | News RSS: `/news/rss` | RSS/XML | Medium (PoE2 mentions possible) | Low–medium (misses many hotfixes) | Secondary “new post” hint only |
+| 3 | GGG OAuth / developer API | JSON (other resources) | N/A | **None for patch notes** | Do not use for notes |
+| 4 | Unofficial third-party “patch notes APIs” | Varies | Untrusted / often PoE2-focused | Unknown | Not for Knowledge Pack truth |
+| 5 | PoE2 forum `2212` or `pathofexile2.com/news/rss` | HTML/RSS | **Wrong game** | N/A | **Deny** |
+
+### Practical sync shape (design only)
+
+1. Poll `https://www.pathofexile.com/forum/view-forum/patch-notes` (and paginate if needed).
+2. Extract thread ids/titles/dates; filter by title/version heuristics (`3.` / `Content Update`).
+3. Fetch each new thread HTML; extract the first staff post body as the note text.
+4. Optionally cross-check news RSS for large league announcements — never as the only source.
+5. Reject anything from forum `2212`, `pathofexile2.com`, or `0.x` version strings.
+
+Cloudflare/WAF and forum markup changes are operational risks; there is no first-party schema guarantee.
+
+---
+
+## 8. Suggested Knowledge Pack seed lists
+
+### Allowlist (domains / path prefixes)
+
+```text
+pathofexile.com                 # prefer PoE1 paths; still filter patch forum vs 2212
+pathofexile.com/forum/view-forum/patch-notes
+pathofexile.com/news/rss        # secondary; content-filter required
+pathofexile.com/developer/docs
+pathofexile.com/api/trade       # PoE1 trade API family
+github.com/grindinggear/skilltree-export
+github.com/grindinggear/atlastree-export
+poewiki.net
+poe.ninja/poe1/
+reddit.com/r/pathofexile
+reddit.com/r/PathOfExileBuilds
+reddit.com/r/pathofexiledev
+poedb.tw                        # not poe2db.tw
+maxroll.gg/poe/                 # not /poe2/
+pobb.in
+```
+
+### Denylist (domains / path prefixes)
+
+```text
+pathofexile2.com
+pathofexile.com/forum/view-forum/2212
+poe2wiki.net
+poe2db.tw
+poe.ninja/poe2/
+maxroll.gg/poe2/
+github.com/grindinggear/poe2-skilltree-export
+reddit.com/r/PathOfExile2
+# Plus any URL whose path or title clearly encodes PoE2 / Early Access 0.x patch notes
+```
+
+### Content-level exclusion (beyond hosts)
+
+- Same-named skills/items: require `poewiki.net` / `poe.ninja/poe1` / PoE1 forum evidence before accepting claims.
+- Mixed Discord / YouTube / random guides: deny-by-default unless host is allowlisted.
+
+---
+
+## 9. Open risks for later tickets
+
+- **Anubis on poewiki.net** may block Cargo/API automation; need an access strategy before relying on live wiki sync.
+- **News RSS ≠ patch notes**; players already requested a dedicated feed and did not get one.
+- **poe.ninja API paths changed**; older community documentation is stale — pin `/poe1/api/...`.
+- **Shared GGG forum chrome** makes PoE1 vs PoE2 threads easy to confuse if filtering by “site:pathofexile.com” alone.
+- Whether Patch-Notes Sync auto-applies Knowledge Pack edits vs flags for human review remains a product decision (map issue #1).
+
+---
+
+## Sources consulted (primary)
+
+1. https://www.pathofexile.com/forum/view-forum/patch-notes  
+2. https://www.pathofexile.com/forum/view-forum/2212  
+3. https://www.pathofexile.com/news/rss  
+4. https://pathofexile2.com/news/rss  
+5. https://www.pathofexile.com/developer/docs  
+6. https://www.pathofexile.com/developer/docs/data  
+7. https://www.pathofexile.com/developer/docs/reference  
+8. https://www.pathofexile.com/api/trade/data/leagues  
+9. https://www.pathofexile.com/forum/view-thread/3554274  
+10. https://www.pathofexile.com/forum/view-thread/3648166  
+11. https://www.poewiki.net/ (incl. Anubis interstitial; Data query API page)  
+12. https://www.poe2wiki.net/wiki/Spark  
+13. https://poe.ninja/poe1/ , `/poe1/builds`, `/poe1/api/economy/...`, `/poe1/api/data/index-state`  
+14. https://poe.ninja/poe2/builds  
+15. https://github.com/grindinggear/skilltree-export  
+16. https://github.com/grindinggear/poe2-skilltree-export  
+17. https://poedb.tw/ , https://poe2db.tw/  
+18. https://maxroll.gg/poe , https://maxroll.gg/poe2  
+19. https://www.reddit.com/r/pathofexile/wiki/tools  
+20. In-repo PoB references: `src/Modules/BuildSiteTools.lua`, `src/Modules/ItemTools.lua`
diff --git a/knowledge-pack/README.md b/knowledge-pack/README.md
new file mode 100644
index 00000000000..b0ce5fe4bbb
--- /dev/null
+++ b/knowledge-pack/README.md
@@ -0,0 +1,26 @@
+# Knowledge Pack
+
+Versioned PoE1 knowledge layer for the PoB Cursor Agent. Design: [docs/pob-cursor-agent/KNOWLEDGE-PACK.md](../docs/pob-cursor-agent/KNOWLEDGE-PACK.md).
+
+## Layout
+
+| Path | Kind | Purpose |
+| --- | --- | --- |
+| `policy/allowlist.yaml` | Allowlist | Hosts and path prefixes the agent may fetch or cite for PoE1 |
+| `policy/denylist.yaml` | Denylist | PoE2 and lookalike traps (hosts, path prefixes) |
+| `policy/exclusion.yaml` | Exclusion extras | Forum ids, version patterns for non-URL gates |
+| `notes/*.md` | Notes | Mechanic/pitfall notes with YAML frontmatter |
+| `meta.yaml` | Meta | `current_patch`, `generation`, pack version |
+
+## Note frontmatter
+
+Every note under `notes/` must include:
+
+```yaml
+status: active | possibly_stale | retired
+verified_against_patch: "<PoE1 patch id>"
+```
+
+## Runtime enforcement
+
+Policy **data** lives here. PoE2 Exclusion **evaluators** live in `sidecar/src/policy/` and load these files.
diff --git a/knowledge-pack/meta.yaml b/knowledge-pack/meta.yaml
new file mode 100644
index 00000000000..676ddc40384
--- /dev/null
+++ b/knowledge-pack/meta.yaml
@@ -0,0 +1,5 @@
+# Pack-level staleness signals for the agent (see docs/pob-cursor-agent/KNOWLEDGE-PACK.md).
+pack_version: "0.1.0"
+current_patch: "3.29.0"
+generation: 1
+last_sync: null
diff --git a/knowledge-pack/notes/poe-ninja-api-paths.md b/knowledge-pack/notes/poe-ninja-api-paths.md
new file mode 100644
index 00000000000..4103fba2be9
--- /dev/null
+++ b/knowledge-pack/notes/poe-ninja-api-paths.md
@@ -0,0 +1,17 @@
+---
+status: active
+verified_against_patch: "3.29.0"
+---
+
+# poe.ninja API paths migrated to /poe1/
+
+Legacy URLs such as `https://poe.ninja/api/data/currencyoverview` return 404.
+Use the **`/poe1/api/...`** prefix for economy and index endpoints.
+
+Example:
+
+```text
+https://poe.ninja/poe1/api/economy/stash/current/currency/overview?league=Standard&type=Currency
+```
+
+Do not use `/poe2/` paths — those are PoE2 namespace.
diff --git a/knowledge-pack/policy/allowlist.yaml b/knowledge-pack/policy/allowlist.yaml
new file mode 100644
index 00000000000..042a3b7c005
--- /dev/null
+++ b/knowledge-pack/policy/allowlist.yaml
@@ -0,0 +1,22 @@
+# PoE1 sources the agent may fetch or cite. See docs/research/poe1-knowledge-sources-patch-notes.md.
+version: 1
+hosts:
+  - pathofexile.com
+  - poewiki.net
+  - poe.ninja
+  - reddit.com
+  - poedb.tw
+  - maxroll.gg
+  - pobb.in
+path_prefixes:
+  - pathofexile.com/forum/view-forum/patch-notes
+  - pathofexile.com/news/rss
+  - pathofexile.com/developer/docs
+  - pathofexile.com/api/trade
+  - github.com/grindinggear/skilltree-export
+  - github.com/grindinggear/atlastree-export
+  - poe.ninja/poe1/
+  - reddit.com/r/pathofexile
+  - reddit.com/r/PathOfExileBuilds
+  - reddit.com/r/pathofexiledev
+  - maxroll.gg/poe/
diff --git a/knowledge-pack/policy/denylist.yaml b/knowledge-pack/policy/denylist.yaml
new file mode 100644
index 00000000000..f220118ea36
--- /dev/null
+++ b/knowledge-pack/policy/denylist.yaml
@@ -0,0 +1,12 @@
+# PoE2 and lookalike traps — host/namespace beats name equality.
+version: 1
+hosts:
+  - pathofexile2.com
+  - poe2wiki.net
+  - poe2db.tw
+path_prefixes:
+  - pathofexile.com/forum/view-forum/2212
+  - poe.ninja/poe2/
+  - maxroll.gg/poe2/
+  - github.com/grindinggear/poe2-skilltree-export
+  - reddit.com/r/PathOfExile2
diff --git a/knowledge-pack/policy/exclusion.yaml b/knowledge-pack/policy/exclusion.yaml
new file mode 100644
index 00000000000..d5c6f180a81
--- /dev/null
+++ b/knowledge-pack/policy/exclusion.yaml
@@ -0,0 +1,6 @@
+# Non-URL exclusion rules for gates (forum ids, version schemes).
+version: 1
+denied_forum_ids:
+  - "2212"
+deny_version_patterns:
+  - "^0\\."
diff --git a/sidecar/.gitignore b/sidecar/.gitignore
new file mode 100644
index 00000000000..b9470778764
--- /dev/null
+++ b/sidecar/.gitignore
@@ -0,0 +1,2 @@
+node_modules/
+dist/
diff --git a/sidecar/README.md b/sidecar/README.md
new file mode 100644
index 00000000000..f319d80f563
--- /dev/null
+++ b/sidecar/README.md
@@ -0,0 +1,13 @@
+# PoB Cursor Agent sidecar
+
+Non-LLM sidecar process (Node 22.13+). Policy evaluators load `knowledge-pack/policy/` at runtime.
+
+## Policy tests
+
+```bash
+npm install
+npm test
+npm run typecheck
+```
+
+Fail-closed acceptance suite: URL/domain deny, mixed citation refuse, same-name Apply refuse.
diff --git a/sidecar/package-lock.json b/sidecar/package-lock.json
new file mode 100644
index 00000000000..94fc21e47a6
--- /dev/null
+++ b/sidecar/package-lock.json
@@ -0,0 +1,1641 @@
+{
+  "name": "@pob-cursor-agent/sidecar",
+  "version": "0.1.0",
+  "lockfileVersion": 3,
+  "requires": true,
+  "packages": {
+    "": {
+      "name": "@pob-cursor-agent/sidecar",
+      "version": "0.1.0",
+      "devDependencies": {
+        "@types/node": "^22.13.0",
+        "typescript": "^5.8.2",
+        "vitest": "^3.0.9",
+        "yaml": "^2.7.0"
+      },
+      "engines": {
+        "node": ">=22.13.0"
+      }
+    },
+    "node_modules/@esbuild/aix-ppc64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/aix-ppc64/-/aix-ppc64-0.28.1.tgz",
+      "integrity": "sha512-Svl7tq8k/08+p6CXPpRjQ1fKX+1odH/BQbb48fV6fj3CWHhsoIOoY87w1oHXm0qEpkIK3ZfVgp0hed3XBXzXMQ==",
+      "cpu": [
+        "ppc64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "aix"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/android-arm": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/android-arm/-/android-arm-0.28.1.tgz",
+      "integrity": "sha512-0k2F129Xdio1TdJfzJ8sy1Q47vUD2NnwdhiAf7drUN1EBTfPf4hsFCtmMgu/6m8JSzsBrlmVjudMBQqOfG8usQ==",
+      "cpu": [
+        "arm"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "android"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/android-arm64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/android-arm64/-/android-arm64-0.28.1.tgz",
+      "integrity": "sha512-34EGEbCIAgosYz6goLcopX6Mo7NyGv9tfwEM2/7Ce2VcVRk568iSvniGWcUXIy7wEDR1wzolcxcriFVrWYcwBg==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "android"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/android-x64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/android-x64/-/android-x64-0.28.1.tgz",
+      "integrity": "sha512-dbwY7ltSMDWsRatcRpCnES4F+im88OCUgGZjy52shC7GqHRE/cYlxNbB4Z4UpJswpcc4Qxd2oE/ufM0p61IKng==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "android"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/darwin-arm64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/darwin-arm64/-/darwin-arm64-0.28.1.tgz",
+      "integrity": "sha512-TZbWkQY7kvTAXbXUT7uVACR5cMHsDiSz9z7ZKAX/RTq/WJEk3QyRr0wZpNhBDX+/0CtdqUIJlOiodQcta6tY3Q==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/darwin-x64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/darwin-x64/-/darwin-x64-0.28.1.tgz",
+      "integrity": "sha512-zfdzgK9ACBNZLI/CyHTOx81SyNbM6YXn7rxSgX97VjyiPl9W1i4Ka4fgKECEoFCKGpvBj5qArWIGgQjOwkgskQ==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/freebsd-arm64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/freebsd-arm64/-/freebsd-arm64-0.28.1.tgz",
+      "integrity": "sha512-wG2EA8ENdEI0qhkSZMjfqrdY+ziCYCPMmtZjjIwOmXFjmyzEHn+UUxk5of+SYsjtfs3VpnlC7QLzSI5hY/rOAw==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "freebsd"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/freebsd-x64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/freebsd-x64/-/freebsd-x64-0.28.1.tgz",
+      "integrity": "sha512-i7dZ9vQgnvSCzi/rYCXNgtF/U+eKZNJBzu3eTQbRgHnM7tNSizLOkRFAl3qzVc/Op/u5YkHHa4pf/3DOYHthLQ==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "freebsd"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/linux-arm": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/linux-arm/-/linux-arm-0.28.1.tgz",
+      "integrity": "sha512-qVXBOHQS+d5Y722GwJzJUtOLlX7km3CraOaGormF1pDtPd2C/l1SHRPgjLunLGe51Sh5YYWKMFDyV4SxgMQYTQ==",
+      "cpu": [
+        "arm"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/linux-arm64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/linux-arm64/-/linux-arm64-0.28.1.tgz",
+      "integrity": "sha512-yHs+0uc8+nvEAfAfxrWQKK5peSNzBc4PegcMO0EJ2hT71uA7vB8Ihg2e77R2P7SG5uYjPbHlLLmve4LLLRCf0g==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/linux-ia32": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/linux-ia32/-/linux-ia32-0.28.1.tgz",
+      "integrity": "sha512-d1z4ZuP0ajrfz/FhGT4vv278rX8KnPPJx8i5+AtK7TYbx9Le9F1hyzurZpkEyjkGa9dUGhQow4C1NmeGvqxN2w==",
+      "cpu": [
+        "ia32"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/linux-loong64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/linux-loong64/-/linux-loong64-0.28.1.tgz",
+      "integrity": "sha512-M5sRjUVZrkm1OAPR3dlOYzNmN+loZKGVi1VUQGrwuqLcbR6qeAz+famMhjASeH3YVKvZz+zT1jlh/keC3Rj/lg==",
+      "cpu": [
+        "loong64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/linux-mips64el": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/linux-mips64el/-/linux-mips64el-0.28.1.tgz",
+      "integrity": "sha512-mRObBZeHh2OxcBFPWE/FjylkRgZdYuiTR3vaTozquCGOH14iP9oN4x4Ge81CoIDYQrXmIxpFumJBu5MtZpnQJQ==",
+      "cpu": [
+        "mips64el"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/linux-ppc64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/linux-ppc64/-/linux-ppc64-0.28.1.tgz",
+      "integrity": "sha512-slScBsMAb3GFDcdrCgLwZtPYRoH2H/youv10QiZyRjmsP48fznoveWytSgCI/R0ZcUgpc0ZhIUEx6LHts8yrfQ==",
+      "cpu": [
+        "ppc64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/linux-riscv64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/linux-riscv64/-/linux-riscv64-0.28.1.tgz",
+      "integrity": "sha512-kw0owk1o0GFETUJyW0jc0G4Yzs0BHZn0JDZ8JRT088vjJYX777BAs1fDGxAC+q831qOs2DTC96mNsG2opdfyyQ==",
+      "cpu": [
+        "riscv64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/linux-s390x": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/linux-s390x/-/linux-s390x-0.28.1.tgz",
+      "integrity": "sha512-/lAIjX8aYFRByhh6L5rYtPEDRqa9de/4V/juOXcta5frjvzXO4/sqEtyytse0g3zZFuWu5cDN0MkLz2qRDD2Ag==",
+      "cpu": [
+        "s390x"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/linux-x64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/linux-x64/-/linux-x64-0.28.1.tgz",
+      "integrity": "sha512-u/anNYF2mmVOEDwLtnQ1wOr3EZ9sTNGLWrsYGYwHWzGA3Si84IOkHXlbWTD1NB+9/1lcnweYKO54uhxZydNzfA==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/netbsd-arm64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/netbsd-arm64/-/netbsd-arm64-0.28.1.tgz",
+      "integrity": "sha512-oks0DYbLwWMmaakTsCb+zL4E+aHRVLom9IJZOAthMQEPiQmydXHkziYEsGYRx0uNV/IjEKGAV941JzH02pflqw==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "netbsd"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/netbsd-x64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/netbsd-x64/-/netbsd-x64-0.28.1.tgz",
+      "integrity": "sha512-aeL6lAnN89Hz43Mlh1G8ARasbuoYvSITDEx0tHh5b7jJnHcssqgjy9Yx430GDpmCa6OyrKoS0aNRjKundRizGg==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "netbsd"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/openbsd-arm64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/openbsd-arm64/-/openbsd-arm64-0.28.1.tgz",
+      "integrity": "sha512-MEFJe5C3R8pwXdZ5Y21oo6m7ePiS0d9pWucn99O/wvyJZChoIQKrQDxKrGeW8F5+T0okTHesAmDeiHDTIq0V/Q==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "openbsd"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/openbsd-x64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/openbsd-x64/-/openbsd-x64-0.28.1.tgz",
+      "integrity": "sha512-i/ZLIOafE0Z8cI/XANJAixoJL/uRAoS2xOA3rb0xN+KK0K177cMAsQYkzHtBrtMXAKuAc7HGgcWiZ/sRC1Nxgw==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "openbsd"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/openharmony-arm64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/openharmony-arm64/-/openharmony-arm64-0.28.1.tgz",
+      "integrity": "sha512-ge+Z7EXFNt2BO1oAMsVpiQ8EwndV9i1xXerAeTIK7AtPs3bKFXQM7nlRxDSIUIMeueR1CNXxqztLzdNeReKBJg==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "openharmony"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/sunos-x64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/sunos-x64/-/sunos-x64-0.28.1.tgz",
+      "integrity": "sha512-BEjgtECkL3vY+SaSQ6nzVfiALUeFxpawyp8Jmf5PtYhf1Ug40N1h/hxlhts+f1FvSvarEigdxS3BlSMI2PJLcQ==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "sunos"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/win32-arm64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/win32-arm64/-/win32-arm64-0.28.1.tgz",
+      "integrity": "sha512-lCv9eK/H6ZJWbE7bh2nw54CZ9M2nupBxJcTsdk/QQnWkdSjKGuxmmH8/GWrlT1eMmZfn4dGcCjRte397WqfQXA==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "win32"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/win32-ia32": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/win32-ia32/-/win32-ia32-0.28.1.tgz",
+      "integrity": "sha512-zvb/mB2bSCoJOpoCBgYKKpX6YM6mJBlBUVUtVj41DlZJVEB6/0CKlRYxP5wWl1C1ILiCoAU5wZZ4q1P3qeS6Eg==",
+      "cpu": [
+        "ia32"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "win32"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@esbuild/win32-x64": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/@esbuild/win32-x64/-/win32-x64-0.28.1.tgz",
+      "integrity": "sha512-bm4Mowrv+GXMlpWX++EcXw/iLyd1o3+bJkC2DkWXYVvgZCqD/bSj9ctZeAMC3cIxgjRVR2Dufaiu4YPxr5gW1A==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "win32"
+      ],
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/@jridgewell/sourcemap-codec": {
+      "version": "1.5.5",
+      "resolved": "https://registry.npmjs.org/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.5.5.tgz",
+      "integrity": "sha512-cYQ9310grqxueWbl+WuIUIaiUaDcj7WOq5fVhEljNVgRfOUhY9fy2zTvfoqWsnebh8Sl70VScFbICvJnLKB0Og==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@rollup/rollup-android-arm-eabi": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-android-arm-eabi/-/rollup-android-arm-eabi-4.62.2.tgz",
+      "integrity": "sha512-6o7ZLZK+BeenkZCFNDXqpbjw9bD6nuWonvS/lwQJp7NoVVxm6p3qE7qQ5jGuBjiFsgvqjD8mZAU5oWxTmbOeOg==",
+      "cpu": [
+        "arm"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "android"
+      ]
+    },
+    "node_modules/@rollup/rollup-android-arm64": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-android-arm64/-/rollup-android-arm64-4.62.2.tgz",
+      "integrity": "sha512-BaH7BllCACHoH1LguOU56UItGfUWjujlO65kS9LAodViaN4bwIKd7oeW/ZHJ/4ljr/7MIiENnNy3HJ0zXv8Zkw==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "android"
+      ]
+    },
+    "node_modules/@rollup/rollup-darwin-arm64": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-darwin-arm64/-/rollup-darwin-arm64-4.62.2.tgz",
+      "integrity": "sha512-v39RCCvj4He82I9sFmk+M1VZ0PLM9sfsLVikjfx2hYBNALhrrOR2D3JjQA6AhlaSOgcR+RzrKY7e1+bT6SUO/A==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "darwin"
+      ]
+    },
+    "node_modules/@rollup/rollup-darwin-x64": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-darwin-x64/-/rollup-darwin-x64-4.62.2.tgz",
+      "integrity": "sha512-yl0y2vq3S3lHeuXhEdss6TWfKW8vkujImO12tn4ZkG/4oghr09LvdYm2RElVjokTQiUvDUGXLGsYeLqUMCKpGA==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "darwin"
+      ]
+    },
+    "node_modules/@rollup/rollup-freebsd-arm64": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-freebsd-arm64/-/rollup-freebsd-arm64-4.62.2.tgz",
+      "integrity": "sha512-tT4pvt4qXD+vEoezupCWi+a1F0vvDiksiHc+PxRlYTOH1I6/X4id9jPxTP+Fg+545euaFT1jJVs4CEdHZAU1vw==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "freebsd"
+      ]
+    },
+    "node_modules/@rollup/rollup-freebsd-x64": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-freebsd-x64/-/rollup-freebsd-x64-4.62.2.tgz",
+      "integrity": "sha512-6nU5F2wCW+qvCBhTn1pdIU3bzsIoF7EUwsCDRxilWGprQR6yd508YnH9+OKFCwpfS8pjZqDUmnCAr7exax0XCg==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "freebsd"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-arm-gnueabihf": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-arm-gnueabihf/-/rollup-linux-arm-gnueabihf-4.62.2.tgz",
+      "integrity": "sha512-n1GJHPOvpIfhi3TmrCeh6S6URt9BFCt0KQE3qvexyGCTAKpR4Lg+eWvNZEqu7epxwus/8ElT3hacYEucm49SZg==",
+      "cpu": [
+        "arm"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-arm-musleabihf": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-arm-musleabihf/-/rollup-linux-arm-musleabihf-4.62.2.tgz",
+      "integrity": "sha512-JqgflS8wEB+UXV/vS1RpRbifGBeN4D5lz8D8oOFbFZw4vedvdOgCFAjfBmIMdW3yL10XpQQ0Ambepw6MXrhOnA==",
+      "cpu": [
+        "arm"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-arm64-gnu": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-arm64-gnu/-/rollup-linux-arm64-gnu-4.62.2.tgz",
+      "integrity": "sha512-wnFJkogWvN4jm/hQRF2UBaeUmk20j5+DmHvoyWii2b8HJDyvz1MF2OU/6ynXt2KR63rbZLWkFpoytpdc/yBuSA==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-arm64-musl": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-arm64-musl/-/rollup-linux-arm64-musl-4.62.2.tgz",
+      "integrity": "sha512-HVu2bp0zhvJ8xHEV9+UUs7S90VadmBSY3LcIMvozbPo4AuMGDWlz3ymHLHZPX4hR67TKTt8Qp5PJ5RBg/i+RMQ==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-loong64-gnu": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-loong64-gnu/-/rollup-linux-loong64-gnu-4.62.2.tgz",
+      "integrity": "sha512-mQqqAV8QaoSgr9I2fKDLY2BAVvmKjWoGiu/cSYQonsLvtqwEn1E4QYfnCOcp5zoEqNhsDYin1s6jx/VJmrxlZg==",
+      "cpu": [
+        "loong64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-loong64-musl": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-loong64-musl/-/rollup-linux-loong64-musl-4.62.2.tgz",
+      "integrity": "sha512-IxKLoxCQ2IWi6bT2akyDUBGsOImDKB+sPp4EsTmwFQ/fMwpCKm8uLSSgP/Kx/QYUgKis6SEZ5/Nlhup0DIA0PQ==",
+      "cpu": [
+        "loong64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-ppc64-gnu": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-ppc64-gnu/-/rollup-linux-ppc64-gnu-4.62.2.tgz",
+      "integrity": "sha512-Mk5ha2RQSgyFfmYYLkBpPnUk8D8FriBxesO1u9O75X0mHgXL1UQcH5Itl2lurWL2tj0RxV9b9tJgipac0hRY9A==",
+      "cpu": [
+        "ppc64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-ppc64-musl": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-ppc64-musl/-/rollup-linux-ppc64-musl-4.62.2.tgz",
+      "integrity": "sha512-CjvEnqJL/0/TQ3TXX3OPIJ/kmBellrWd4heXUmHeJlTnmwjKpSJzoehLaL6Xk0ZnMHBu9dZuFADNOrtjF4v+2w==",
+      "cpu": [
+        "ppc64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-riscv64-gnu": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-riscv64-gnu/-/rollup-linux-riscv64-gnu-4.62.2.tgz",
+      "integrity": "sha512-1SiZbzwdkaDURsew/tSOrooKiYy7EQGT6m8ufavAi9NEyQb/6VuIxFXAL1fqa4iZe3g4NbNk4P7J32z2tw5Mgg==",
+      "cpu": [
+        "riscv64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-riscv64-musl": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-riscv64-musl/-/rollup-linux-riscv64-musl-4.62.2.tgz",
+      "integrity": "sha512-nQts12zJ3NQRoE6uYljOH89v7szzLDvG2JD/vsX+vGXU8w/At1GowTZ5/7qeFQ8m7L55rpR8Okugnuo5bgjy2Q==",
+      "cpu": [
+        "riscv64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-s390x-gnu": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-s390x-gnu/-/rollup-linux-s390x-gnu-4.62.2.tgz",
+      "integrity": "sha512-E9/ll019jhPIJgpzfZoIkBGhcz+kKNgVWYRY0zr9srBdPPFVpvOKW8VaJKUbeK+eZXyQF9ltME+Kk6affeaPgg==",
+      "cpu": [
+        "s390x"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-x64-gnu": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-x64-gnu/-/rollup-linux-x64-gnu-4.62.2.tgz",
+      "integrity": "sha512-5BqxR/pshjey51iliyzTD5Xi3EN0aLmQ2lZ3lvefVV9c82BvrLo2/6OT55iifpWBufs6kdwWbuOKS841DrmK9A==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-linux-x64-musl": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-x64-musl/-/rollup-linux-x64-musl-4.62.2.tgz",
+      "integrity": "sha512-uNN83XxQrRAh/w0/pmAfibcwyb6YWt4gP+dpnQKPVJshAloQ785ii8CT8ZCIxkGg9opVsvAlGhFitSm6D1Jjpg==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "linux"
+      ]
+    },
+    "node_modules/@rollup/rollup-openbsd-x64": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-openbsd-x64/-/rollup-openbsd-x64-4.62.2.tgz",
+      "integrity": "sha512-srjEIxSH3LRnJN6THczDHWQplqEMFiAJrTab0msUryh9kwNpkICf3Ea6q6MN/2cZwRFUNx5w+h6Hpi4QuHS6Zg==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "openbsd"
+      ]
+    },
+    "node_modules/@rollup/rollup-openharmony-arm64": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-openharmony-arm64/-/rollup-openharmony-arm64-4.62.2.tgz",
+      "integrity": "sha512-8hOJnxgbyObnCm5AlRA3A931xX19xq80RjVTKgJOvEKWqJruP/Uf12IbAOaDjjEXYRewwHLfmF0YRIdK3OwKWA==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "openharmony"
+      ]
+    },
+    "node_modules/@rollup/rollup-win32-arm64-msvc": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-win32-arm64-msvc/-/rollup-win32-arm64-msvc-4.62.2.tgz",
+      "integrity": "sha512-mmF4AY1i0hG/bLWUctUq59gtmgaSIRa3cu/A3JFRp/sCNEme2bgDEiDS22P9FbnJB8NJNF4jPJiSP5RHQpUTDg==",
+      "cpu": [
+        "arm64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "win32"
+      ]
+    },
+    "node_modules/@rollup/rollup-win32-ia32-msvc": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-win32-ia32-msvc/-/rollup-win32-ia32-msvc-4.62.2.tgz",
+      "integrity": "sha512-DZgkknc6jhHrk46V25vbAM0zZkyP0nSDkJB8/dRkLTxv470dOmWDqGoEJl/9A0dFfS7yE3REOwNDxpHwSLSt0Q==",
+      "cpu": [
+        "ia32"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "win32"
+      ]
+    },
+    "node_modules/@rollup/rollup-win32-x64-gnu": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-win32-x64-gnu/-/rollup-win32-x64-gnu-4.62.2.tgz",
+      "integrity": "sha512-T6xr6ucWSFto+VGajA8YH26LdpHRuP4YLHEKAtCWvJDOlnmWcDZVCI2Jmjr+IFHDlt2zRaTAKE4tfjTaWLgJBg==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "win32"
+      ]
+    },
+    "node_modules/@rollup/rollup-win32-x64-msvc": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/@rollup/rollup-win32-x64-msvc/-/rollup-win32-x64-msvc-4.62.2.tgz",
+      "integrity": "sha512-BfzEnDJOt9T8M989/lA37EcJgat01wLRnoi5dQf3QzOH7jzpqTAzdDbVfRljVr5r+jzKqpbHeyOfAaXxAd0PAA==",
+      "cpu": [
+        "x64"
+      ],
+      "dev": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "win32"
+      ]
+    },
+    "node_modules/@types/chai": {
+      "version": "5.2.3",
+      "resolved": "https://registry.npmjs.org/@types/chai/-/chai-5.2.3.tgz",
+      "integrity": "sha512-Mw558oeA9fFbv65/y4mHtXDs9bPnFMZAL/jxdPFUpOHHIXX91mcgEHbS5Lahr+pwZFR8A7GQleRWeI6cGFC2UA==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/deep-eql": "*",
+        "assertion-error": "^2.0.1"
+      }
+    },
+    "node_modules/@types/deep-eql": {
+      "version": "4.0.2",
+      "resolved": "https://registry.npmjs.org/@types/deep-eql/-/deep-eql-4.0.2.tgz",
+      "integrity": "sha512-c9h9dVVMigMPc4bwTvC5dxqtqJZwQPePsWjPlpSOnojbor6pGqdk541lfA7AqFQr5pB1BRdq0juY9db81BwyFw==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@types/estree": {
+      "version": "1.0.9",
+      "resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.9.tgz",
+      "integrity": "sha512-GhdPgy1el4/ImP05X05Uw4cw2/M93BCUmnEvWZNStlCzEKME4Fkk+YpoA5OiHNQmoS7Cafb8Xa3Pya8m1Qrzeg==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/@types/node": {
+      "version": "22.20.1",
+      "resolved": "https://registry.npmjs.org/@types/node/-/node-22.20.1.tgz",
+      "integrity": "sha512-EANqOCF9QFyra+4pfxUcX9STKJpCLjMbObVzljIJomAWSnuSIEAvyzEU53GaajbXJEgdh0iEcPL+DGvpUd4k1Q==",
+      "dev": true,
+      "license": "MIT",
+      "peer": true,
+      "dependencies": {
+        "undici-types": "~6.21.0"
+      }
+    },
+    "node_modules/@vitest/expect": {
+      "version": "3.2.7",
+      "resolved": "https://registry.npmjs.org/@vitest/expect/-/expect-3.2.7.tgz",
+      "integrity": "sha512-E8eBXaKibuvH2pSZErOjdVb5vF4PbKYcrnluBTYxEk1l/VhhwZg1kZQsdtjq+CsF5CFydf2Rdkz7jDHKSisi3w==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/chai": "^5.2.2",
+        "@vitest/spy": "3.2.7",
+        "@vitest/utils": "3.2.7",
+        "chai": "^5.2.0",
+        "tinyrainbow": "^2.0.0"
+      },
+      "funding": {
+        "url": "https://opencollective.com/vitest"
+      }
+    },
+    "node_modules/@vitest/mocker": {
+      "version": "3.2.7",
+      "resolved": "https://registry.npmjs.org/@vitest/mocker/-/mocker-3.2.7.tgz",
+      "integrity": "sha512-Trr0hYO9CM3Wj6ksWHRhK9IZpIY6wTMO5u/MqXurMxT57sWBaOPEtP3Oq60ihZuh5JsiagKfz95OcxdEP6dBrA==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@vitest/spy": "3.2.7",
+        "estree-walker": "^3.0.3",
+        "magic-string": "^0.30.17"
+      },
+      "funding": {
+        "url": "https://opencollective.com/vitest"
+      },
+      "peerDependencies": {
+        "msw": "^2.4.9",
+        "vite": "^5.0.0 || ^6.0.0 || ^7.0.0-0"
+      },
+      "peerDependenciesMeta": {
+        "msw": {
+          "optional": true
+        },
+        "vite": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/@vitest/pretty-format": {
+      "version": "3.2.7",
+      "resolved": "https://registry.npmjs.org/@vitest/pretty-format/-/pretty-format-3.2.7.tgz",
+      "integrity": "sha512-KUHlwqVu0sRlhCdyPdQ/wBoTfRahjUky1MubOmYw9fWfIZy1gNoHpuaaQBPAaMaVYdQYHJLurzj8ECCj5OwTqA==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "tinyrainbow": "^2.0.0"
+      },
+      "funding": {
+        "url": "https://opencollective.com/vitest"
+      }
+    },
+    "node_modules/@vitest/runner": {
+      "version": "3.2.7",
+      "resolved": "https://registry.npmjs.org/@vitest/runner/-/runner-3.2.7.tgz",
+      "integrity": "sha512-sB9y4ovltoQP+WaUPwmSxO9WIg9Ig694Di5PalVPsYHklAdE027mehpWF2SQSVq+k6sFgaivbTjTJwZLSHbedA==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@vitest/utils": "3.2.7",
+        "pathe": "^2.0.3",
+        "strip-literal": "^3.0.0"
+      },
+      "funding": {
+        "url": "https://opencollective.com/vitest"
+      }
+    },
+    "node_modules/@vitest/snapshot": {
+      "version": "3.2.7",
+      "resolved": "https://registry.npmjs.org/@vitest/snapshot/-/snapshot-3.2.7.tgz",
+      "integrity": "sha512-7C+MwShwtBSI5Buwoyg3s/iY1eHL9PKAf+O1wVh/TdnjXUtkoL/9YQtre90i4MtNXM6edP1wJ2zOBpfCyhIS7g==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@vitest/pretty-format": "3.2.7",
+        "magic-string": "^0.30.17",
+        "pathe": "^2.0.3"
+      },
+      "funding": {
+        "url": "https://opencollective.com/vitest"
+      }
+    },
+    "node_modules/@vitest/spy": {
+      "version": "3.2.7",
+      "resolved": "https://registry.npmjs.org/@vitest/spy/-/spy-3.2.7.tgz",
+      "integrity": "sha512-Q2eQGI6d2L/hBtZ0qNuKcAGid68XK6cv1xsoaIma6PaJhHPoqcEJhYpXZ/5myCMqkNgtP6UKuBhbc0nHKnrkuQ==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "tinyspy": "^4.0.3"
+      },
+      "funding": {
+        "url": "https://opencollective.com/vitest"
+      }
+    },
+    "node_modules/@vitest/utils": {
+      "version": "3.2.7",
+      "resolved": "https://registry.npmjs.org/@vitest/utils/-/utils-3.2.7.tgz",
+      "integrity": "sha512-x6BDOd7dyo3PFLY3I9/HJ25X/6OurhGXk2/B9gOZNPF7XDVjeBK4k01lQE5uvDpbuheErh91qYuE1E2OEjK3Rw==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@vitest/pretty-format": "3.2.7",
+        "loupe": "^3.1.4",
+        "tinyrainbow": "^2.0.0"
+      },
+      "funding": {
+        "url": "https://opencollective.com/vitest"
+      }
+    },
+    "node_modules/assertion-error": {
+      "version": "2.0.1",
+      "resolved": "https://registry.npmjs.org/assertion-error/-/assertion-error-2.0.1.tgz",
+      "integrity": "sha512-Izi8RQcffqCeNVgFigKli1ssklIbpHnCYc6AknXGYoB6grJqyeby7jv12JUQgmTAnIDnbck1uxksT4dzN3PWBA==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12"
+      }
+    },
+    "node_modules/cac": {
+      "version": "6.7.14",
+      "resolved": "https://registry.npmjs.org/cac/-/cac-6.7.14.tgz",
+      "integrity": "sha512-b6Ilus+c3RrdDk+JhLKUAQfzzgLEPy6wcXqS7f/xe1EETvsDP6GORG7SFuOs6cID5YkqchW/LXZbX5bc8j7ZcQ==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/chai": {
+      "version": "5.3.3",
+      "resolved": "https://registry.npmjs.org/chai/-/chai-5.3.3.tgz",
+      "integrity": "sha512-4zNhdJD/iOjSH0A05ea+Ke6MU5mmpQcbQsSOkgdaUMJ9zTlDTD/GYlwohmIE2u0gaxHYiVHEn1Fw9mZ/ktJWgw==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "assertion-error": "^2.0.1",
+        "check-error": "^2.1.1",
+        "deep-eql": "^5.0.1",
+        "loupe": "^3.1.0",
+        "pathval": "^2.0.0"
+      },
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/check-error": {
+      "version": "2.1.3",
+      "resolved": "https://registry.npmjs.org/check-error/-/check-error-2.1.3.tgz",
+      "integrity": "sha512-PAJdDJusoxnwm1VwW07VWwUN1sl7smmC3OKggvndJFadxxDRyFJBX/ggnu/KE4kQAB7a3Dp8f/YXC1FlUprWmA==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 16"
+      }
+    },
+    "node_modules/debug": {
+      "version": "4.4.3",
+      "resolved": "https://registry.npmjs.org/debug/-/debug-4.4.3.tgz",
+      "integrity": "sha512-RGwwWnwQvkVfavKVt22FGLw+xYSdzARwm0ru6DhTVA3umU5hZc28V3kO4stgYryrTlLpuvgI9GiijltAjNbcqA==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "ms": "^2.1.3"
+      },
+      "engines": {
+        "node": ">=6.0"
+      },
+      "peerDependenciesMeta": {
+        "supports-color": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/deep-eql": {
+      "version": "5.0.2",
+      "resolved": "https://registry.npmjs.org/deep-eql/-/deep-eql-5.0.2.tgz",
+      "integrity": "sha512-h5k/5U50IJJFpzfL6nO9jaaumfjO/f2NjK/oYB2Djzm4p9L+3T9qWpZqZ2hAbLPuuYq9wrU08WQyBTL5GbPk5Q==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=6"
+      }
+    },
+    "node_modules/es-module-lexer": {
+      "version": "1.7.0",
+      "resolved": "https://registry.npmjs.org/es-module-lexer/-/es-module-lexer-1.7.0.tgz",
+      "integrity": "sha512-jEQoCwk8hyb2AZziIOLhDqpm5+2ww5uIE6lkO/6jcOCusfk6LhMHpXXfBLXTZ7Ydyt0j4VoUQv6uGNYbdW+kBA==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/esbuild": {
+      "version": "0.28.1",
+      "resolved": "https://registry.npmjs.org/esbuild/-/esbuild-0.28.1.tgz",
+      "integrity": "sha512-HrJrvZv5ayxBzPfwphOoNzkzOIIlifzk0KJrGK2c8R4+LKpMtpYLQeUdjnwjWv/LZlkH2laZk+4w78pi99D4Vw==",
+      "dev": true,
+      "hasInstallScript": true,
+      "license": "MIT",
+      "bin": {
+        "esbuild": "bin/esbuild"
+      },
+      "engines": {
+        "node": ">=18"
+      },
+      "optionalDependencies": {
+        "@esbuild/aix-ppc64": "0.28.1",
+        "@esbuild/android-arm": "0.28.1",
+        "@esbuild/android-arm64": "0.28.1",
+        "@esbuild/android-x64": "0.28.1",
+        "@esbuild/darwin-arm64": "0.28.1",
+        "@esbuild/darwin-x64": "0.28.1",
+        "@esbuild/freebsd-arm64": "0.28.1",
+        "@esbuild/freebsd-x64": "0.28.1",
+        "@esbuild/linux-arm": "0.28.1",
+        "@esbuild/linux-arm64": "0.28.1",
+        "@esbuild/linux-ia32": "0.28.1",
+        "@esbuild/linux-loong64": "0.28.1",
+        "@esbuild/linux-mips64el": "0.28.1",
+        "@esbuild/linux-ppc64": "0.28.1",
+        "@esbuild/linux-riscv64": "0.28.1",
+        "@esbuild/linux-s390x": "0.28.1",
+        "@esbuild/linux-x64": "0.28.1",
+        "@esbuild/netbsd-arm64": "0.28.1",
+        "@esbuild/netbsd-x64": "0.28.1",
+        "@esbuild/openbsd-arm64": "0.28.1",
+        "@esbuild/openbsd-x64": "0.28.1",
+        "@esbuild/openharmony-arm64": "0.28.1",
+        "@esbuild/sunos-x64": "0.28.1",
+        "@esbuild/win32-arm64": "0.28.1",
+        "@esbuild/win32-ia32": "0.28.1",
+        "@esbuild/win32-x64": "0.28.1"
+      }
+    },
+    "node_modules/estree-walker": {
+      "version": "3.0.3",
+      "resolved": "https://registry.npmjs.org/estree-walker/-/estree-walker-3.0.3.tgz",
+      "integrity": "sha512-7RUKfXgSMMkzt6ZuXmqapOurLGPPfgj6l9uRZ7lRGolvk0y2yocc35LdcxKC5PQZdn2DMqioAQ2NoWcrTKmm6g==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/estree": "^1.0.0"
+      }
+    },
+    "node_modules/expect-type": {
+      "version": "1.4.0",
+      "resolved": "https://registry.npmjs.org/expect-type/-/expect-type-1.4.0.tgz",
+      "integrity": "sha512-KfYbmpRm0VbLjEvVa9yGwCi9GI34xvi7A/HXYWQO65CSD2u3MczUJSuwXKFIxlGsgBQizV9q5J9NHj4VG0n+pA==",
+      "dev": true,
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=12.0.0"
+      }
+    },
+    "node_modules/fdir": {
+      "version": "6.5.0",
+      "resolved": "https://registry.npmjs.org/fdir/-/fdir-6.5.0.tgz",
+      "integrity": "sha512-tIbYtZbucOs0BRGqPJkshJUYdL+SDH7dVM8gjy+ERp3WAUjLEFJE+02kanyHtwjWOnwrKYBiwAmM0p4kLJAnXg==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12.0.0"
+      },
+      "peerDependencies": {
+        "picomatch": "^3 || ^4"
+      },
+      "peerDependenciesMeta": {
+        "picomatch": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/fsevents": {
+      "version": "2.3.3",
+      "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz",
+      "integrity": "sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw==",
+      "dev": true,
+      "hasInstallScript": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
+      "engines": {
+        "node": "^8.16.0 || ^10.6.0 || >=11.0.0"
+      }
+    },
+    "node_modules/js-tokens": {
+      "version": "9.0.1",
+      "resolved": "https://registry.npmjs.org/js-tokens/-/js-tokens-9.0.1.tgz",
+      "integrity": "sha512-mxa9E9ITFOt0ban3j6L5MpjwegGz6lBQmM1IJkWeBZGcMxto50+eWdjC/52xDbS2vy0k7vIMK0Fe2wfL9OQSpQ==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/loupe": {
+      "version": "3.2.1",
+      "resolved": "https://registry.npmjs.org/loupe/-/loupe-3.2.1.tgz",
+      "integrity": "sha512-CdzqowRJCeLU72bHvWqwRBBlLcMEtIvGrlvef74kMnV2AolS9Y8xUv1I0U/MNAWMhBlKIoyuEgoJ0t/bbwHbLQ==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/magic-string": {
+      "version": "0.30.21",
+      "resolved": "https://registry.npmjs.org/magic-string/-/magic-string-0.30.21.tgz",
+      "integrity": "sha512-vd2F4YUyEXKGcLHoq+TEyCjxueSeHnFxyyjNp80yg0XV4vUhnDer/lvvlqM/arB5bXQN5K2/3oinyCRyx8T2CQ==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@jridgewell/sourcemap-codec": "^1.5.5"
+      }
+    },
+    "node_modules/ms": {
+      "version": "2.1.3",
+      "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz",
+      "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/nanoid": {
+      "version": "3.3.16",
+      "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.16.tgz",
+      "integrity": "sha512-bzlKTyNJ7+LdGIIwy8ijFpIqEQIvafahV7eYykJ8Cvh42EdJeODoJ6gUJXpQJvej1BddH8OqTXZNE/KfbWAu8Q==",
+      "dev": true,
+      "funding": [
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "bin": {
+        "nanoid": "bin/nanoid.cjs"
+      },
+      "engines": {
+        "node": "^10 || ^12 || ^13.7 || ^14 || >=15.0.1"
+      }
+    },
+    "node_modules/pathe": {
+      "version": "2.0.3",
+      "resolved": "https://registry.npmjs.org/pathe/-/pathe-2.0.3.tgz",
+      "integrity": "sha512-WUjGcAqP1gQacoQe+OBJsFA7Ld4DyXuUIjZ5cc75cLHvJ7dtNsTugphxIADwspS+AraAUePCKrSVtPLFj/F88w==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/pathval": {
+      "version": "2.0.1",
+      "resolved": "https://registry.npmjs.org/pathval/-/pathval-2.0.1.tgz",
+      "integrity": "sha512-//nshmD55c46FuFw26xV/xFAaB5HF9Xdap7HJBBnrKdAd6/GxDBaNA1870O79+9ueg61cZLSVc+OaFlfmObYVQ==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">= 14.16"
+      }
+    },
+    "node_modules/picocolors": {
+      "version": "1.1.1",
+      "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.1.1.tgz",
+      "integrity": "sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/picomatch": {
+      "version": "4.0.5",
+      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-4.0.5.tgz",
+      "integrity": "sha512-RvwwcruNjI1ncT5xRakeyS9Lf8lcItv34KD+aif+VH9kduAyfYBipGh12274xtenIPZ119/R9BdTBa8gAwSh0A==",
+      "dev": true,
+      "license": "MIT",
+      "peer": true,
+      "engines": {
+        "node": ">=12"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/jonschlinkert"
+      }
+    },
+    "node_modules/postcss": {
+      "version": "8.5.19",
+      "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.5.19.tgz",
+      "integrity": "sha512-Mz8SaolMd8nB+G13WkORcxQKHZ/NE4xXevtkJHVuG+guo9/wYKlIMTKAqGdEmYOXR2ijPjTYNHssizdaVSUNdQ==",
+      "dev": true,
+      "funding": [
+        {
+          "type": "opencollective",
+          "url": "https://opencollective.com/postcss/"
+        },
+        {
+          "type": "tidelift",
+          "url": "https://tidelift.com/funding/github/npm/postcss"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/ai"
+        }
+      ],
+      "license": "MIT",
+      "dependencies": {
+        "nanoid": "^3.3.12",
+        "picocolors": "^1.1.1",
+        "source-map-js": "^1.2.1"
+      },
+      "engines": {
+        "node": "^10 || ^12 || >=14"
+      }
+    },
+    "node_modules/rollup": {
+      "version": "4.62.2",
+      "resolved": "https://registry.npmjs.org/rollup/-/rollup-4.62.2.tgz",
+      "integrity": "sha512-RFnrW4lhXA3s3eqHDZvN654g8OTjzRfqpIRJYczCGB6HzphckVAi/Qh4tbPUbRuDi7s1Llv8g/NspLkttY3gTA==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/estree": "1.0.9"
+      },
+      "bin": {
+        "rollup": "dist/bin/rollup"
+      },
+      "engines": {
+        "node": ">=18.0.0",
+        "npm": ">=8.0.0"
+      },
+      "optionalDependencies": {
+        "@rollup/rollup-android-arm-eabi": "4.62.2",
+        "@rollup/rollup-android-arm64": "4.62.2",
+        "@rollup/rollup-darwin-arm64": "4.62.2",
+        "@rollup/rollup-darwin-x64": "4.62.2",
+        "@rollup/rollup-freebsd-arm64": "4.62.2",
+        "@rollup/rollup-freebsd-x64": "4.62.2",
+        "@rollup/rollup-linux-arm-gnueabihf": "4.62.2",
+        "@rollup/rollup-linux-arm-musleabihf": "4.62.2",
+        "@rollup/rollup-linux-arm64-gnu": "4.62.2",
+        "@rollup/rollup-linux-arm64-musl": "4.62.2",
+        "@rollup/rollup-linux-loong64-gnu": "4.62.2",
+        "@rollup/rollup-linux-loong64-musl": "4.62.2",
+        "@rollup/rollup-linux-ppc64-gnu": "4.62.2",
+        "@rollup/rollup-linux-ppc64-musl": "4.62.2",
+        "@rollup/rollup-linux-riscv64-gnu": "4.62.2",
+        "@rollup/rollup-linux-riscv64-musl": "4.62.2",
+        "@rollup/rollup-linux-s390x-gnu": "4.62.2",
+        "@rollup/rollup-linux-x64-gnu": "4.62.2",
+        "@rollup/rollup-linux-x64-musl": "4.62.2",
+        "@rollup/rollup-openbsd-x64": "4.62.2",
+        "@rollup/rollup-openharmony-arm64": "4.62.2",
+        "@rollup/rollup-win32-arm64-msvc": "4.62.2",
+        "@rollup/rollup-win32-ia32-msvc": "4.62.2",
+        "@rollup/rollup-win32-x64-gnu": "4.62.2",
+        "@rollup/rollup-win32-x64-msvc": "4.62.2",
+        "fsevents": "~2.3.2"
+      }
+    },
+    "node_modules/siginfo": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/siginfo/-/siginfo-2.0.0.tgz",
+      "integrity": "sha512-ybx0WO1/8bSBLEWXZvEd7gMW3Sn3JFlW3TvX1nREbDLRNQNaeNN8WK0meBwPdAaOI7TtRRRJn/Es1zhrrCHu7g==",
+      "dev": true,
+      "license": "ISC"
+    },
+    "node_modules/source-map-js": {
+      "version": "1.2.1",
+      "resolved": "https://registry.npmjs.org/source-map-js/-/source-map-js-1.2.1.tgz",
+      "integrity": "sha512-UXWMKhLOwVKb728IUtQPXxfYU+usdybtUrK/8uGE8CQMvrhOpwvzDBwj0QhSL7MQc7vIsISBG8VQ8+IDQxpfQA==",
+      "dev": true,
+      "license": "BSD-3-Clause",
+      "engines": {
+        "node": ">=0.10.0"
+      }
+    },
+    "node_modules/stackback": {
+      "version": "0.0.2",
+      "resolved": "https://registry.npmjs.org/stackback/-/stackback-0.0.2.tgz",
+      "integrity": "sha512-1XMJE5fQo1jGH6Y/7ebnwPOBEkIEnT4QF32d5R1+VXdXveM0IBMJt8zfaxX1P3QhVwrYe+576+jkANtSS2mBbw==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/std-env": {
+      "version": "3.10.0",
+      "resolved": "https://registry.npmjs.org/std-env/-/std-env-3.10.0.tgz",
+      "integrity": "sha512-5GS12FdOZNliM5mAOxFRg7Ir0pWz8MdpYm6AY6VPkGpbA7ZzmbzNcBJQ0GPvvyWgcY7QAhCgf9Uy89I03faLkg==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/strip-literal": {
+      "version": "3.1.0",
+      "resolved": "https://registry.npmjs.org/strip-literal/-/strip-literal-3.1.0.tgz",
+      "integrity": "sha512-8r3mkIM/2+PpjHoOtiAW8Rg3jJLHaV7xPwG+YRGrv6FP0wwk/toTpATxWYOW0BKdWwl82VT2tFYi5DlROa0Mxg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "js-tokens": "^9.0.1"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/antfu"
+      }
+    },
+    "node_modules/tinybench": {
+      "version": "2.9.0",
+      "resolved": "https://registry.npmjs.org/tinybench/-/tinybench-2.9.0.tgz",
+      "integrity": "sha512-0+DUvqWMValLmha6lr4kD8iAMK1HzV0/aKnCtWb9v9641TnP/MFb7Pc2bxoxQjTXAErryXVgUOfv2YqNllqGeg==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/tinyexec": {
+      "version": "0.3.2",
+      "resolved": "https://registry.npmjs.org/tinyexec/-/tinyexec-0.3.2.tgz",
+      "integrity": "sha512-KQQR9yN7R5+OSwaK0XQoj22pwHoTlgYqmUscPYoknOoWCWfj/5/ABTMRi69FrKU5ffPVh5QcFikpWJI/P1ocHA==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/tinyglobby": {
+      "version": "0.2.17",
+      "resolved": "https://registry.npmjs.org/tinyglobby/-/tinyglobby-0.2.17.tgz",
+      "integrity": "sha512-wXR/dYpcqKmfWpEdZjiKJOwCNFndD0DMnrW/cYjVGttEkBfVgcLFHoNrlj47mjOVic9yyNu65alsgF4NQyTa2g==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "fdir": "^6.5.0",
+        "picomatch": "^4.0.4"
+      },
+      "engines": {
+        "node": ">=12.0.0"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/SuperchupuDev"
+      }
+    },
+    "node_modules/tinypool": {
+      "version": "1.1.1",
+      "resolved": "https://registry.npmjs.org/tinypool/-/tinypool-1.1.1.tgz",
+      "integrity": "sha512-Zba82s87IFq9A9XmjiX5uZA/ARWDrB03OHlq+Vw1fSdt0I+4/Kutwy8BP4Y/y/aORMo61FQ0vIb5j44vSo5Pkg==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": "^18.0.0 || >=20.0.0"
+      }
+    },
+    "node_modules/tinyrainbow": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/tinyrainbow/-/tinyrainbow-2.0.0.tgz",
+      "integrity": "sha512-op4nsTR47R6p0vMUUoYl/a+ljLFVtlfaXkLQmqfLR1qHma1h/ysYk4hEXZ880bf2CYgTskvTa/e196Vd5dDQXw==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=14.0.0"
+      }
+    },
+    "node_modules/tinyspy": {
+      "version": "4.0.4",
+      "resolved": "https://registry.npmjs.org/tinyspy/-/tinyspy-4.0.4.tgz",
+      "integrity": "sha512-azl+t0z7pw/z958Gy9svOTuzqIk6xq+NSheJzn5MMWtWTFywIacg2wUlzKFGtt3cthx0r2SxMK0yzJOR0IES7Q==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=14.0.0"
+      }
+    },
+    "node_modules/typescript": {
+      "version": "5.9.3",
+      "resolved": "https://registry.npmjs.org/typescript/-/typescript-5.9.3.tgz",
+      "integrity": "sha512-jl1vZzPDinLr9eUt3J/t7V6FgNEw9QjvBPdysz9KfQDD41fQrC2Y4vKQdiaUpFT4bXlb1RHhLpp8wtm6M5TgSw==",
+      "dev": true,
+      "license": "Apache-2.0",
+      "bin": {
+        "tsc": "bin/tsc",
+        "tsserver": "bin/tsserver"
+      },
+      "engines": {
+        "node": ">=14.17"
+      }
+    },
+    "node_modules/undici-types": {
+      "version": "6.21.0",
+      "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-6.21.0.tgz",
+      "integrity": "sha512-iwDZqg0QAGrg9Rav5H4n0M64c3mkR59cJ6wQp+7C4nI0gsmExaedaYLNO44eT4AtBBwjbTiGPMlt2Md0T9H9JQ==",
+      "dev": true,
+      "license": "MIT"
+    },
+    "node_modules/vite": {
+      "version": "7.3.6",
+      "resolved": "https://registry.npmjs.org/vite/-/vite-7.3.6.tgz",
+      "integrity": "sha512-4XP60spRGjSZFf1qYH+dJIkK2znL3zQfl9KkOV9MkkRR/3Dls0dxaBsQPTloEc5BLXWPL9vsOxopxyKoMmDueg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "esbuild": "^0.27.0 || ^0.28.0",
+        "fdir": "^6.5.0",
+        "picomatch": "^4.0.3",
+        "postcss": "^8.5.6",
+        "rollup": "^4.43.0",
+        "tinyglobby": "^0.2.15"
+      },
+      "bin": {
+        "vite": "bin/vite.js"
+      },
+      "engines": {
+        "node": "^20.19.0 || >=22.12.0"
+      },
+      "funding": {
+        "url": "https://github.com/vitejs/vite?sponsor=1"
+      },
+      "optionalDependencies": {
+        "fsevents": "~2.3.3"
+      },
+      "peerDependencies": {
+        "@types/node": "^20.19.0 || >=22.12.0",
+        "jiti": ">=1.21.0",
+        "less": "^4.0.0",
+        "lightningcss": "^1.21.0",
+        "sass": "^1.70.0",
+        "sass-embedded": "^1.70.0",
+        "stylus": ">=0.54.8",
+        "sugarss": "^5.0.0",
+        "terser": "^5.16.0",
+        "tsx": "^4.8.1",
+        "yaml": "^2.4.2"
+      },
+      "peerDependenciesMeta": {
+        "@types/node": {
+          "optional": true
+        },
+        "jiti": {
+          "optional": true
+        },
+        "less": {
+          "optional": true
+        },
+        "lightningcss": {
+          "optional": true
+        },
+        "sass": {
+          "optional": true
+        },
+        "sass-embedded": {
+          "optional": true
+        },
+        "stylus": {
+          "optional": true
+        },
+        "sugarss": {
+          "optional": true
+        },
+        "terser": {
+          "optional": true
+        },
+        "tsx": {
+          "optional": true
+        },
+        "yaml": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/vite-node": {
+      "version": "3.2.4",
+      "resolved": "https://registry.npmjs.org/vite-node/-/vite-node-3.2.4.tgz",
+      "integrity": "sha512-EbKSKh+bh1E1IFxeO0pg1n4dvoOTt0UDiXMd/qn++r98+jPO1xtJilvXldeuQ8giIB5IkpjCgMleHMNEsGH6pg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "cac": "^6.7.14",
+        "debug": "^4.4.1",
+        "es-module-lexer": "^1.7.0",
+        "pathe": "^2.0.3",
+        "vite": "^5.0.0 || ^6.0.0 || ^7.0.0-0"
+      },
+      "bin": {
+        "vite-node": "vite-node.mjs"
+      },
+      "engines": {
+        "node": "^18.0.0 || ^20.0.0 || >=22.0.0"
+      },
+      "funding": {
+        "url": "https://opencollective.com/vitest"
+      }
+    },
+    "node_modules/vitest": {
+      "version": "3.2.7",
+      "resolved": "https://registry.npmjs.org/vitest/-/vitest-3.2.7.tgz",
+      "integrity": "sha512-KrxIJ62Fd89gfysR4WotlgZABiz2dqFPgqGzX7s+CwsqLFomRH7777ZcrOD6+WVAh7khPQP41A+BKbpcJFrdEg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@types/chai": "^5.2.2",
+        "@vitest/expect": "3.2.7",
+        "@vitest/mocker": "3.2.7",
+        "@vitest/pretty-format": "^3.2.7",
+        "@vitest/runner": "3.2.7",
+        "@vitest/snapshot": "3.2.7",
+        "@vitest/spy": "3.2.7",
+        "@vitest/utils": "3.2.7",
+        "chai": "^5.2.0",
+        "debug": "^4.4.1",
+        "expect-type": "^1.2.1",
+        "magic-string": "^0.30.17",
+        "pathe": "^2.0.3",
+        "picomatch": "^4.0.2",
+        "std-env": "^3.9.0",
+        "tinybench": "^2.9.0",
+        "tinyexec": "^0.3.2",
+        "tinyglobby": "^0.2.14",
+        "tinypool": "^1.1.1",
+        "tinyrainbow": "^2.0.0",
+        "vite": "^5.0.0 || ^6.0.0 || ^7.0.0-0",
+        "vite-node": "3.2.4",
+        "why-is-node-running": "^2.3.0"
+      },
+      "bin": {
+        "vitest": "vitest.mjs"
+      },
+      "engines": {
+        "node": "^18.0.0 || ^20.0.0 || >=22.0.0"
+      },
+      "funding": {
+        "url": "https://opencollective.com/vitest"
+      },
+      "peerDependencies": {
+        "@edge-runtime/vm": "*",
+        "@types/debug": "^4.1.12",
+        "@types/node": "^18.0.0 || ^20.0.0 || >=22.0.0",
+        "@vitest/browser": "3.2.7",
+        "@vitest/ui": "3.2.7",
+        "happy-dom": "*",
+        "jsdom": "*"
+      },
+      "peerDependenciesMeta": {
+        "@edge-runtime/vm": {
+          "optional": true
+        },
+        "@types/debug": {
+          "optional": true
+        },
+        "@types/node": {
+          "optional": true
+        },
+        "@vitest/browser": {
+          "optional": true
+        },
+        "@vitest/ui": {
+          "optional": true
+        },
+        "happy-dom": {
+          "optional": true
+        },
+        "jsdom": {
+          "optional": true
+        }
+      }
+    },
+    "node_modules/why-is-node-running": {
+      "version": "2.3.0",
+      "resolved": "https://registry.npmjs.org/why-is-node-running/-/why-is-node-running-2.3.0.tgz",
+      "integrity": "sha512-hUrmaWBdVDcxvYqnyh09zunKzROWjbZTiNy8dBEjkS7ehEDQibXJ7XvlmtbwuTclUiIyN+CyXQD4Vmko8fNm8w==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "siginfo": "^2.0.0",
+        "stackback": "0.0.2"
+      },
+      "bin": {
+        "why-is-node-running": "cli.js"
+      },
+      "engines": {
+        "node": ">=8"
+      }
+    },
+    "node_modules/yaml": {
+      "version": "2.9.0",
+      "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.9.0.tgz",
+      "integrity": "sha512-2AvhNX3mb8zd6Zy7INTtSpl1F15HW6Wnqj0srWlkKLcpYl/gMIMJiyuGq2KeI2YFxUPjdlB+3Lc10seMLtL4cA==",
+      "dev": true,
+      "license": "ISC",
+      "peer": true,
+      "bin": {
+        "yaml": "bin.mjs"
+      },
+      "engines": {
+        "node": ">= 14.6"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/eemeli"
+      }
+    }
+  }
+}
diff --git a/sidecar/package.json b/sidecar/package.json
new file mode 100644
index 00000000000..fbba5abbb23
--- /dev/null
+++ b/sidecar/package.json
@@ -0,0 +1,20 @@
+{
+  "name": "@pob-cursor-agent/sidecar",
+  "version": "0.1.0",
+  "private": true,
+  "type": "module",
+  "engines": {
+    "node": ">=22.13.0"
+  },
+  "scripts": {
+    "typecheck": "tsc --noEmit",
+    "test": "vitest run",
+    "test:watch": "vitest"
+  },
+  "devDependencies": {
+    "@types/node": "^22.13.0",
+    "typescript": "^5.8.2",
+    "vitest": "^3.0.9",
+    "yaml": "^2.7.0"
+  }
+}
diff --git a/sidecar/src/policy/apply.ts b/sidecar/src/policy/apply.ts
new file mode 100644
index 00000000000..a222344f6d3
--- /dev/null
+++ b/sidecar/src/policy/apply.ts
@@ -0,0 +1,45 @@
+import type { ApplyOp, PolicyOutcome } from "./types.js";
+
+export function evaluateApplyOps(
+  ops: ApplyOp[],
+  knownPoe1Ids: ReadonlySet<string>,
+  knownBuildNames: ReadonlySet<string>,
+): PolicyOutcome {
+  const rejectedOps: ApplyOp[] = [];
+
+  for (const op of ops) {
+    if (op.entityId && !knownPoe1Ids.has(op.entityId)) {
+      rejectedOps.push(op);
+      continue;
+    }
+
+    if (!op.entityId && op.entityName && !knownBuildNames.has(op.entityName)) {
+      rejectedOps.push(op);
+    }
+  }
+
+  if (rejectedOps.length === 0) {
+    return { kind: "allowed" };
+  }
+
+  const first = rejectedOps[0]!;
+  const name = first.entityName ?? first.entityId ?? "unknown entity";
+
+  if (first.entityId && !knownPoe1Ids.has(first.entityId)) {
+    return {
+      kind: "refused",
+      reason: `Apply refused: unknown PoE1 entity id "${first.entityId}" (possible PoE2 smuggle)`,
+      rule: "apply.unknown_id",
+      path: "apply",
+      rejectedOps,
+    };
+  }
+
+  return {
+    kind: "refused",
+    reason: `Apply refused: same-named entity "${name}" is not present in the loaded build or PoE1 id set (PoE2 collision risk)`,
+    rule: "apply.same_name",
+    path: "apply",
+    rejectedOps,
+  };
+}
diff --git a/sidecar/src/policy/citation.ts b/sidecar/src/policy/citation.ts
new file mode 100644
index 00000000000..ddac69ca806
--- /dev/null
+++ b/sidecar/src/policy/citation.ts
@@ -0,0 +1,73 @@
+import type { PolicyOutcome, PolicyPack } from "./types.js";
+import { classifyUrl } from "./url.js";
+
+const URL_PATTERN =
+  /https?:\/\/[^\s<>"')\]]+/gi;
+
+export function extractUrls(input: string | string[]): string[] {
+  if (Array.isArray(input)) {
+    return input;
+  }
+  const matches = input.match(URL_PATTERN) ?? [];
+  return [...new Set(matches)];
+}
+
+export function evaluateCitations(
+  input: string | string[],
+  policy: PolicyPack,
+): PolicyOutcome {
+  const urls = extractUrls(input);
+  if (urls.length === 0) {
+    return { kind: "allowed" };
+  }
+
+  const classifications = urls.map((url) => ({
+    url,
+    classification: classifyUrl(url, policy),
+  }));
+
+  const denied = classifications.filter((entry) => entry.classification === "deny");
+  const allowed = classifications.filter((entry) => entry.classification === "allow");
+  const neutral = classifications.filter((entry) => entry.classification === "neutral");
+
+  if (denied.length === 0 && neutral.length === 0) {
+    return { kind: "allowed" };
+  }
+
+  const contaminatedUrls = [
+    ...denied.map((entry) => entry.url),
+    ...neutral.map((entry) => entry.url),
+  ];
+
+  if (allowed.length > 0 && denied.length > 0) {
+    return {
+      kind: "refused",
+      reason:
+        "Mixed PoE1 and PoE2 citations detected — refuse answer and re-ask on allowlisted PoE1 sources only",
+      rule: "citation.mixed",
+      path: "research",
+      action: "re-ask",
+      contaminatedUrls: denied.map((entry) => entry.url),
+    };
+  }
+
+  if (denied.length > 0) {
+    return {
+      kind: "refused",
+      reason: "Answer cites denylisted PoE2 or lookalike sources",
+      rule: "citation.denylisted",
+      path: "research",
+      action: "re-ask",
+      contaminatedUrls: denied.map((entry) => entry.url),
+    };
+  }
+
+  return {
+    kind: "refused",
+    reason: "Answer cites sources outside the PoE1 allowlist",
+    rule: "citation.not_allowlisted",
+    path: "research",
+    action: "re-ask",
+    contaminatedUrls: neutral.map((entry) => entry.url),
+  };
+}
diff --git a/sidecar/src/policy/index.ts b/sidecar/src/policy/index.ts
new file mode 100644
index 00000000000..d34cf623773
--- /dev/null
+++ b/sidecar/src/policy/index.ts
@@ -0,0 +1,11 @@
+export type {
+  ApplyOp,
+  PolicyAllow,
+  PolicyOutcome,
+  PolicyPack,
+  PolicyRefusal,
+} from "./types.js";
+export { loadPolicyPack } from "./load.js";
+export { evaluateUrl, evaluateUrls, classifyUrl, evaluateVersionString } from "./url.js";
+export { evaluateCitations, extractUrls } from "./citation.js";
+export { evaluateApplyOps } from "./apply.js";
diff --git a/sidecar/src/policy/load.ts b/sidecar/src/policy/load.ts
new file mode 100644
index 00000000000..b340b358f52
--- /dev/null
+++ b/sidecar/src/policy/load.ts
@@ -0,0 +1,66 @@
+import fs from "node:fs";
+import path from "node:path";
+import { parse as parseYaml } from "yaml";
+import type {
+  AllowlistPolicy,
+  DenylistPolicy,
+  ExclusionPolicy,
+  PolicyPack,
+} from "./types.js";
+
+function readYamlFile<T>(filePath: string): T {
+  const raw = fs.readFileSync(filePath, "utf8");
+  return parseYaml(raw) as T;
+}
+
+export function loadPolicyPack(repoRoot: string): PolicyPack {
+  const policyDir = path.join(repoRoot, "knowledge-pack", "policy");
+  return {
+    allowlist: readYamlFile<AllowlistPolicy>(
+      path.join(policyDir, "allowlist.yaml"),
+    ),
+    denylist: readYamlFile<DenylistPolicy>(
+      path.join(policyDir, "denylist.yaml"),
+    ),
+    exclusion: readYamlFile<ExclusionPolicy>(
+      path.join(policyDir, "exclusion.yaml"),
+    ),
+  };
+}
+
+export function normalizeUrl(raw: string): { host: string; pathKey: string } {
+  const withScheme = raw.includes("://") ? raw : `https://${raw}`;
+  const url = new URL(withScheme);
+  const host = url.hostname.replace(/^www\./, "").toLowerCase();
+  const pathKey = `${host}${url.pathname}`.replace(/\/+$/, "").toLowerCase();
+  return { host, pathKey };
+}
+
+export function matchesHost(host: string, candidates: string[]): boolean {
+  return candidates.some(
+    (candidate) => host === candidate || host.endsWith(`.${candidate}`),
+  );
+}
+
+export function matchesPathPrefix(
+  pathKey: string,
+  prefixes: string[],
+): boolean {
+  return prefixes.some((prefix) => {
+    const normalized = prefix.toLowerCase().replace(/\/+$/, "");
+    return pathKey === normalized || pathKey.startsWith(`${normalized}/`);
+  });
+}
+
+export function matchesForumId(
+  rawUrl: string,
+  deniedForumIds: string[],
+): string | null {
+  for (const forumId of deniedForumIds) {
+    const pattern = new RegExp(`/forum/view-forum/${forumId}(?:/|$)`, "i");
+    if (pattern.test(rawUrl)) {
+      return forumId;
+    }
+  }
+  return null;
+}
diff --git a/sidecar/src/policy/types.ts b/sidecar/src/policy/types.ts
new file mode 100644
index 00000000000..15873b7b730
--- /dev/null
+++ b/sidecar/src/policy/types.ts
@@ -0,0 +1,45 @@
+export type PolicyAllow = { kind: "allowed" };
+
+export type PolicyRefusal = {
+  kind: "refused";
+  reason: string;
+  rule: string;
+  path?: "apply" | "research";
+  action?: "re-ask";
+  contaminatedUrls?: string[];
+  rejectedOps?: ApplyOp[];
+};
+
+export type PolicyOutcome = PolicyAllow | PolicyRefusal;
+
+export type AllowlistPolicy = {
+  version: number;
+  hosts: string[];
+  path_prefixes: string[];
+};
+
+export type DenylistPolicy = {
+  version: number;
+  hosts: string[];
+  path_prefixes: string[];
+};
+
+export type ExclusionPolicy = {
+  version: number;
+  denied_forum_ids: string[];
+  deny_version_patterns: string[];
+};
+
+export type PolicyPack = {
+  allowlist: AllowlistPolicy;
+  denylist: DenylistPolicy;
+  exclusion: ExclusionPolicy;
+};
+
+export type ApplyOp = {
+  surface: "skills" | "items" | "tree" | "config";
+  entityId?: string;
+  entityName?: string;
+};
+
+export type UrlClassification = "allow" | "deny" | "neutral";
diff --git a/sidecar/src/policy/url.ts b/sidecar/src/policy/url.ts
new file mode 100644
index 00000000000..93bc8b0dcc0
--- /dev/null
+++ b/sidecar/src/policy/url.ts
@@ -0,0 +1,97 @@
+import type { PolicyOutcome, PolicyPack, UrlClassification } from "./types.js";
+import {
+  matchesForumId,
+  matchesHost,
+  matchesPathPrefix,
+  normalizeUrl,
+} from "./load.js";
+
+export function classifyUrl(
+  rawUrl: string,
+  policy: PolicyPack,
+): UrlClassification {
+  const { host, pathKey } = normalizeUrl(rawUrl);
+
+  if (matchesForumId(rawUrl, policy.exclusion.denied_forum_ids)) {
+    return "deny";
+  }
+
+  if (
+    matchesHost(host, policy.denylist.hosts) ||
+    matchesPathPrefix(pathKey, policy.denylist.path_prefixes)
+  ) {
+    return "deny";
+  }
+
+  if (
+    matchesHost(host, policy.allowlist.hosts) ||
+    matchesPathPrefix(pathKey, policy.allowlist.path_prefixes)
+  ) {
+    return "allow";
+  }
+
+  return "neutral";
+}
+
+export function evaluateUrl(rawUrl: string, policy: PolicyPack): PolicyOutcome {
+  const classification = classifyUrl(rawUrl, policy);
+
+  if (classification === "deny") {
+    const forumId = matchesForumId(rawUrl, policy.exclusion.denied_forum_ids);
+    if (forumId) {
+      return {
+        kind: "refused",
+        reason: `PoE2 Early Access forum ${forumId} is denylisted for PoE1 agent`,
+        rule: `exclusion.forum.${forumId}`,
+      };
+    }
+
+    const { host, pathKey } = normalizeUrl(rawUrl);
+    return {
+      kind: "refused",
+      reason: `URL is on the PoE2/denylist: ${host}${pathKey.slice(host.length) || "/"}`,
+      rule: "denylist.url",
+    };
+  }
+
+  if (classification === "neutral") {
+    const { host } = normalizeUrl(rawUrl);
+    return {
+      kind: "refused",
+      reason: `URL host is not on the PoE1 allowlist: ${host}`,
+      rule: "allowlist.missing",
+    };
+  }
+
+  return { kind: "allowed" };
+}
+
+export function evaluateUrls(
+  urls: string[],
+  policy: PolicyPack,
+): PolicyOutcome {
+  for (const url of urls) {
+    const result = evaluateUrl(url, policy);
+    if (result.kind === "refused") {
+      return result;
+    }
+  }
+  return { kind: "allowed" };
+}
+
+export function evaluateVersionString(
+  version: string,
+  policy: PolicyPack,
+): PolicyOutcome {
+  for (const pattern of policy.exclusion.deny_version_patterns) {
+    const regex = new RegExp(pattern);
+    if (regex.test(version)) {
+      return {
+        kind: "refused",
+        reason: `Version "${version}" matches PoE2 Early Access pattern (${pattern})`,
+        rule: "exclusion.version_pattern",
+      };
+    }
+  }
+  return { kind: "allowed" };
+}
diff --git a/sidecar/test/apply.test.ts b/sidecar/test/apply.test.ts
new file mode 100644
index 00000000000..b7402284a15
--- /dev/null
+++ b/sidecar/test/apply.test.ts
@@ -0,0 +1,71 @@
+import { describe, expect, it } from "vitest";
+import { evaluateApplyOps } from "../src/policy/apply.js";
+import type { ApplyOp } from "../src/policy/types.js";
+
+const knownPoe1Ids = new Set(["Metadata/Items/Gems/GemDexterity3"]);
+const knownBuildNames = new Set(["Spark", "Arc"]);
+
+describe("same-name Apply refuse (fail-closed)", () => {
+  it("allows ops referencing entities present in PoB by id and name", () => {
+    const ops: ApplyOp[] = [
+      {
+        surface: "skills",
+        entityId: "Metadata/Items/Gems/GemDexterity3",
+        entityName: "Spark",
+      },
+    ];
+    const result = evaluateApplyOps(ops, knownPoe1Ids, knownBuildNames);
+    expect(result).toEqual({ kind: "allowed" });
+  });
+
+  it("hard-refuses unknown entity id (possible PoE2 smuggle)", () => {
+    const ops: ApplyOp[] = [
+      {
+        surface: "skills",
+        entityId: "Metadata/Items/Gems/PoE2OnlyGem",
+        entityName: "Spark",
+      },
+    ];
+    const result = evaluateApplyOps(ops, knownPoe1Ids, knownBuildNames);
+    expect(result).toMatchObject({
+      kind: "refused",
+      reason: expect.stringMatching(/unknown|PoE2|id/i),
+      path: "apply",
+    });
+  });
+
+  it("hard-refuses same-named skill absent from build (Spark collision)", () => {
+    const ops: ApplyOp[] = [
+      { surface: "skills", entityName: "Lightning Strike" },
+    ];
+    const result = evaluateApplyOps(ops, knownPoe1Ids, knownBuildNames);
+    expect(result).toMatchObject({
+      kind: "refused",
+      reason: expect.stringMatching(/same-name|Lightning Strike|PoE2/i),
+      path: "apply",
+    });
+  });
+
+  it("does not partially apply — entire proposal refused", () => {
+    const ops: ApplyOp[] = [
+      { surface: "skills", entityId: "Metadata/Items/Gems/GemDexterity3", entityName: "Spark" },
+      { surface: "skills", entityName: "Ball Lightning" },
+    ];
+    const result = evaluateApplyOps(ops, knownPoe1Ids, knownBuildNames);
+    expect(result.kind).toBe("refused");
+    if (result.kind === "refused" && result.rejectedOps) {
+      expect(result.rejectedOps).toHaveLength(1);
+      expect(result.rejectedOps[0]?.entityName).toBe("Ball Lightning");
+    }
+  });
+
+  it("refusal is explicit — no silent stripping of bad ops", () => {
+    const ops: ApplyOp[] = [{ surface: "items", entityName: "Tabula Rasa" }];
+    const result = evaluateApplyOps(ops, knownPoe1Ids, knownBuildNames);
+    expect(result.kind).toBe("refused");
+    if (result.kind === "refused") {
+      expect(result.reason.length).toBeGreaterThan(0);
+      expect(result.rejectedOps?.length).toBeGreaterThan(0);
+    }
+  });
+});
diff --git a/sidecar/test/citation.test.ts b/sidecar/test/citation.test.ts
new file mode 100644
index 00000000000..8c17ed381b1
--- /dev/null
+++ b/sidecar/test/citation.test.ts
@@ -0,0 +1,83 @@
+import { describe, expect, it } from "vitest";
+import { evaluateCitations } from "../src/policy/citation.js";
+import { loadPolicyPack } from "../src/policy/load.js";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+
+const repoRoot = path.resolve(
+  path.dirname(fileURLToPath(import.meta.url)),
+  "../..",
+);
+
+describe("mixed citation refuse (fail-closed)", () => {
+  const policy = loadPolicyPack(repoRoot);
+
+  it("allows answer with only PoE1 citations", () => {
+    const result = evaluateCitations(
+      [
+        "https://www.poewiki.net/wiki/Spark",
+        "https://www.pathofexile.com/forum/view-forum/patch-notes",
+      ],
+      policy,
+    );
+    expect(result).toEqual({ kind: "allowed" });
+  });
+
+  it("refuses when PoE1 and PoE2 links appear together", () => {
+    const result = evaluateCitations(
+      [
+        "https://www.poewiki.net/wiki/Spark",
+        "https://www.poe2wiki.net/wiki/Spark",
+      ],
+      policy,
+    );
+    expect(result).toMatchObject({
+      kind: "refused",
+      reason: expect.stringMatching(/mixed/i),
+      action: "re-ask",
+    });
+  });
+
+  it("refuses PoE2-only answer explicitly (not silent strip)", () => {
+    const result = evaluateCitations(
+      ["https://pathofexile2.com/news/rss"],
+      policy,
+    );
+    expect(result.kind).toBe("refused");
+    if (result.kind === "refused") {
+      expect(result.reason).toBeTruthy();
+      expect(result.contaminatedUrls).toContain(
+        "https://pathofexile2.com/news/rss",
+      );
+    }
+  });
+
+  it("extracts URLs from prose and refuses mixed citations", () => {
+    const text = `
+      Spark works differently in PoE1 (see https://www.poewiki.net/wiki/Spark)
+      vs PoE2 (see https://www.poe2wiki.net/wiki/Spark for comparison).
+    `;
+    const result = evaluateCitations(text, policy);
+    expect(result).toMatchObject({
+      kind: "refused",
+      reason: expect.stringMatching(/mixed/i),
+      action: "re-ask",
+    });
+  });
+
+  it("does not show PoE2 link as allowed when mixed — full refuse", () => {
+    const result = evaluateCitations(
+      [
+        "https://poe.ninja/poe1/builds",
+        "https://poe.ninja/poe2/builds",
+      ],
+      policy,
+    );
+    expect(result.kind).toBe("refused");
+    if (result.kind === "refused") {
+      expect(result.contaminatedUrls).toEqual(
+        expect.arrayContaining(["https://poe.ninja/poe2/builds"]),
+      );
+    }
+  });
+});
diff --git a/sidecar/test/url.test.ts b/sidecar/test/url.test.ts
new file mode 100644
index 00000000000..d7d6d1859ca
--- /dev/null
+++ b/sidecar/test/url.test.ts
@@ -0,0 +1,90 @@
+import { describe, expect, it } from "vitest";
+import { evaluateUrl } from "../src/policy/url.js";
+import { loadPolicyPack } from "../src/policy/load.js";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+
+const repoRoot = path.resolve(
+  path.dirname(fileURLToPath(import.meta.url)),
+  "../..",
+);
+
+describe("URL/domain deny (fail-closed)", () => {
+  const policy = loadPolicyPack(repoRoot);
+
+  it("allows PoE1 patch notes forum", () => {
+    const result = evaluateUrl(
+      "https://www.pathofexile.com/forum/view-forum/patch-notes",
+      policy,
+    );
+    expect(result).toEqual({ kind: "allowed" });
+  });
+
+  it("allows poewiki.net", () => {
+    const result = evaluateUrl("https://www.poewiki.net/wiki/Spark", policy);
+    expect(result).toEqual({ kind: "allowed" });
+  });
+
+  it("allows poe.ninja/poe1 paths", () => {
+    const result = evaluateUrl(
+      "https://poe.ninja/poe1/api/data/index-state",
+      policy,
+    );
+    expect(result).toEqual({ kind: "allowed" });
+  });
+
+  it("refuses pathofexile2.com explicitly", () => {
+    const result = evaluateUrl("https://pathofexile2.com/news/rss", policy);
+    expect(result.kind).toBe("refused");
+    if (result.kind === "refused") {
+      expect(result.reason).toMatch(/PoE2|denylist/i);
+      expect(result.rule).toBeTruthy();
+    }
+  });
+
+  it("refuses poe2wiki.net explicitly", () => {
+    const result = evaluateUrl("https://www.poe2wiki.net/wiki/Spark", policy);
+    expect(result).toMatchObject({
+      kind: "refused",
+      reason: expect.stringMatching(/PoE2|denylist/i),
+    });
+  });
+
+  it("refuses poe.ninja/poe2 paths", () => {
+    const result = evaluateUrl("https://poe.ninja/poe2/builds", policy);
+    expect(result.kind).toBe("refused");
+  });
+
+  it("refuses GGG forum 2212 (PoE2 Early Access patch notes)", () => {
+    const result = evaluateUrl(
+      "https://www.pathofexile.com/forum/view-forum/2212",
+      policy,
+    );
+    expect(result).toMatchObject({
+      kind: "refused",
+      reason: expect.stringMatching(/2212|PoE2|denylist/i),
+    });
+  });
+
+  it("refuses maxroll.gg/poe2/", () => {
+    const result = evaluateUrl("https://maxroll.gg/poe2/builds", policy);
+    expect(result.kind).toBe("refused");
+  });
+
+  it("refuses non-allowlisted hosts explicitly", () => {
+    const result = evaluateUrl("https://www.youtube.com/watch?v=example", policy);
+    expect(result).toMatchObject({
+      kind: "refused",
+      rule: "allowlist.missing",
+    });
+  });
+
+  it("does not silently strip — denial carries rule id and reason", () => {
+    const result = evaluateUrl("https://poe2db.tw/us/Lightning_Strike", policy);
+    expect(result.kind).toBe("refused");
+    if (result.kind === "refused") {
+      expect(result.rule).toBeTruthy();
+      expect(result.reason.length).toBeGreaterThan(0);
+    }
+  });
+});
diff --git a/sidecar/test/version.test.ts b/sidecar/test/version.test.ts
new file mode 100644
index 00000000000..45716b92fe2
--- /dev/null
+++ b/sidecar/test/version.test.ts
@@ -0,0 +1,28 @@
+import { describe, expect, it } from "vitest";
+import { evaluateVersionString } from "../src/policy/url.js";
+import { loadPolicyPack } from "../src/policy/load.js";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+
+const repoRoot = path.resolve(
+  path.dirname(fileURLToPath(import.meta.url)),
+  "../..",
+);
+
+describe("version pattern exclusion", () => {
+  const policy = loadPolicyPack(repoRoot);
+
+  it("refuses PoE2 Early Access 0.x version strings", () => {
+    const result = evaluateVersionString("0.5.4c", policy);
+    expect(result).toMatchObject({
+      kind: "refused",
+      reason: expect.stringMatching(/0\.5\.4c|PoE2/i),
+      rule: "exclusion.version_pattern",
+    });
+  });
+
+  it("allows PoE1 3.x version strings", () => {
+    const result = evaluateVersionString("3.29.0", policy);
+    expect(result).toEqual({ kind: "allowed" });
+  });
+});
diff --git a/sidecar/tsconfig.json b/sidecar/tsconfig.json
new file mode 100644
index 00000000000..c23f04c99de
--- /dev/null
+++ b/sidecar/tsconfig.json
@@ -0,0 +1,16 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "NodeNext",
+    "moduleResolution": "NodeNext",
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "skipLibCheck": true,
+    "rootDir": ".",
+    "outDir": "dist",
+    "declaration": true,
+    "esModuleInterop": true,
+    "forceConsistentCasingInFileNames": true
+  },
+  "include": ["src/**/*.ts", "test/**/*.ts"]
+}
diff --git a/sidecar/vitest.config.ts b/sidecar/vitest.config.ts
new file mode 100644
index 00000000000..8b5840acac7
--- /dev/null
+++ b/sidecar/vitest.config.ts
@@ -0,0 +1,7 @@
+import { defineConfig } from "vitest/config";
+
+export default defineConfig({
+  test: {
+    include: ["test/**/*.test.ts"],
+  },
+});
diff --git a/skills-lock.json b/skills-lock.json
new file mode 100644
index 00000000000..0dce9cb8650
--- /dev/null
+++ b/skills-lock.json
@@ -0,0 +1,137 @@
+{
+  "version": 1,
+  "skills": {
+    "ask-matt": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/ask-matt/SKILL.md",
+      "computedHash": "5ec84a4c2d9021d99780e5222b2a9f532b53cca8237024eb6cb40ad370c667c5"
+    },
+    "code-review": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/code-review/SKILL.md",
+      "computedHash": "7c3170d8b1b904418358af0474f82e74c89a2dd66c12c956caefdc0aa81ea09f"
+    },
+    "codebase-design": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/codebase-design/SKILL.md",
+      "computedHash": "cdc3d683881cbe5ca367c954571e158861176aa9af8adad1b2c5edd9eb72fe05"
+    },
+    "diagnosing-bugs": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/diagnosing-bugs/SKILL.md",
+      "computedHash": "44417076a76b40331f3816f21e76ea7c9d129e3f73cca2e159b69a56aaa838b2"
+    },
+    "domain-modeling": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/domain-modeling/SKILL.md",
+      "computedHash": "b747e8b4dcd0f367ef940c290b14f858bf9576ad9961fd6684bacff5688f4a2b"
+    },
+    "grill-me": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/productivity/grill-me/SKILL.md",
+      "computedHash": "7edd436132b43ea2973710f0c28a9879c9b0910651eb89a991a7e98cb6dbbacb"
+    },
+    "grill-with-docs": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/grill-with-docs/SKILL.md",
+      "computedHash": "96718e0a89e48c7d76cc9759c7094a82ff34eb89ddc46a30388063fa9812356f"
+    },
+    "grilling": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/productivity/grilling/SKILL.md",
+      "computedHash": "ac63b22655a6fa4a59468dda21415b773c0aaf5a7e2e27e2259eaabf02a840bc"
+    },
+    "handoff": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/productivity/handoff/SKILL.md",
+      "computedHash": "7b03a812d5ca10fa8fe69d4cf8a34542684db51f5db0271254b96074e9f3a243"
+    },
+    "implement": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/implement/SKILL.md",
+      "computedHash": "130cac2d72bfde8cd526bf3b754211e2fe00e84bc4d9f9c56f749b9541a3afad"
+    },
+    "improve-codebase-architecture": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/improve-codebase-architecture/SKILL.md",
+      "computedHash": "569299a60c8e93880f3b3c1eca55578f58f7e1a4155876edb4cb814da3d6b3ea"
+    },
+    "prototype": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/prototype/SKILL.md",
+      "computedHash": "aa385376b4bf4b5d69378e606f1cce3d98578ecba02c25273cd4a3e4deaceedb"
+    },
+    "research": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/research/SKILL.md",
+      "computedHash": "0ce7d7a48175ab30c80240df350a73c216489f775324c8d27c8a10b1b38a49bf"
+    },
+    "resolving-merge-conflicts": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/resolving-merge-conflicts/SKILL.md",
+      "computedHash": "6a005119c18c477c2122321a380a43d40242bae3cc7027125f13497d90875be2"
+    },
+    "setup-matt-pocock-skills": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/setup-matt-pocock-skills/SKILL.md",
+      "computedHash": "509889c1c4970485fdd558df50142d4bf28d6f40866923637c32e64689c9fbda"
+    },
+    "tdd": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/tdd/SKILL.md",
+      "computedHash": "7ac19bf391ceb23266ed5b4f81068201eaa38dcf76d0b59850d49c2c9e426d63"
+    },
+    "teach": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/productivity/teach/SKILL.md",
+      "computedHash": "0c06821a21052b8a054f04c74223db2f1fb5868bbe0da76674d0892a872b3c56"
+    },
+    "to-spec": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/to-spec/SKILL.md",
+      "computedHash": "4049d9955a79642ca945e844362d889060787167719bcca0b0cd6f53a95dc9e0"
+    },
+    "to-tickets": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/to-tickets/SKILL.md",
+      "computedHash": "733df2a51c28078b6b3b8b96ee0c0a70e846163444bf202422d5a1f17bfabea6"
+    },
+    "triage": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/triage/SKILL.md",
+      "computedHash": "8695824ffe756567f6cf3b758853a094a9c974bf96226cde88b0b6c08099dabc"
+    },
+    "wayfinder": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/wayfinder/SKILL.md",
+      "computedHash": "731db837ef3b7e03d6742b296a58ab48c8a0867320d5af269611e21a80059607"
+    },
+    "writing-great-skills": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/productivity/writing-great-skills/SKILL.md",
+      "computedHash": "141d1a43348257160910bdb5d828ca6f404fb8bb1dff72ec7c619434381fde6d"
+    }
+  }
+}