geneseed 3.10.0 → 3.12.0

package/docs/web/_groups.json

@@ -1,45 +0,0 @@
-[
-  {
-    "id": "start",
-    "label": "Get started"
-  },
-  {
-    "id": "concepts",
-    "label": "Core concepts"
-  },
-  {
-    "id": "howto",
-    "label": "How-to"
-  },
-  {
-    "id": "mcp",
-    "label": "MCP servers"
-  },
-  {
-    "id": "lsp",
-    "label": "Language servers",
-    "harness": "opencode"
-  },
-  {
-    "id": "plugins",
-    "label": "Plugins",
-    "harness": "opencode"
-  },
-  {
-    "id": "hooks",
-    "label": "Hooks",
-    "harness": "claude"
-  },
-  {
-    "id": "reference",
-    "label": "Reference"
-  },
-  {
-    "id": "extend",
-    "label": "Extend"
-  },
-  {
-    "id": "deeper",
-    "label": "Deeper"
-  }
-]

package/docs/web/about.md

@@ -1,6 +0,0 @@
----
-group: deeper
-order: 6
-title: "About — version, license, links"
-kind: "about"
----

package/docs/web/adapters-claude-code.md

@@ -1,8 +0,0 @@
----
-group: deeper
-order: 4
-title: "Claude Code adapter"
-kind: "markdown"
-harness: "claude"
-source: "adapters/claude-code/README.md"
----

package/docs/web/adapters-opencode-loads.md

@@ -1,8 +0,0 @@
----
-group: deeper
-order: 3
-title: "OpenCode — how it loads"
-kind: "markdown"
-harness: "opencode"
-source: "adapters/opencode/HOW-OPENCODE-LOADS.md"
----

package/docs/web/adapters-opencode-spec.md

@@ -1,8 +0,0 @@
----
-group: deeper
-order: 2
-title: "OpenCode — global harness spec"
-kind: "markdown"
-harness: "opencode"
-source: "adapters/opencode/GLOBAL-HARNESS-SPEC.md"
----

package/docs/web/adapters-opencode.md

@@ -1,8 +0,0 @@
----
-group: deeper
-order: 1
-title: "OpenCode adapter"
-kind: "markdown"
-harness: "opencode"
-source: "adapters/opencode/README.md"
----

package/docs/web/agents.md

@@ -1,8 +0,0 @@
----
-group: concepts
-order: 2
-title: "Agents"
-kind: "concept"
-link: {"hash": "#/section/agents", "label": "Browse the catalog →"}
----
-{N_AGENTS} capability specialists — `reviewer`, `tester`, `architect`, `developer`, `docs`, `security`, `explorer`, `researcher`, plus a debate **council** the [[council]] skill convenes (`advocate`, `skeptic`, `pragmatist`, `steward`, `visionary`, `user-advocate`, `framer`, `empiricist`, `operator`, `historian`). You delegate by capability, not by folder: the harness picks the right specialist from the request.

package/docs/web/authoring.md

@@ -1,11 +0,0 @@
----
-group: extend
-order: 0
-title: "Edit the source"
-kind: "concept"
----
-Everything theme-independent lives under `src/` — the constitution (`ontology/`, `laws/`, `doctrines/`), the `postures/` and `modes/` registers, agents, skills, memory and notebook conventions, and the `AGENT.md.tmpl` entrypoint. Voice tokens live under `themes/` as one JSON file per theme. After editing, `geneseed build --emit opencode-global` (or `geneseed update`) re-renders the deployed bundle. The `doctor` action verifies the result: unresolved theme tokens, dead links, hermetic escapes, theme-key parity, and that the committed bundle matches a fresh render.
-
-Each agent and skill also carries a lifecycle status — `experimental`, `approved` or `deprecated` — recorded in `registry.json` at the repo root alongside its version, owner and add-date. The file is maintainer-side: it is never rendered into a bundle, so a status costs no session context. Adding a spec means adding its row; `doctor` fails on a spec with no row and on a row with no spec, and the catalog badges anything that is not `approved`. The same pass refuses to let a credential ship, and holds every vendored skill folder to an immutable upstream commit rather than a moving branch.
-
-A skill you wrote yourself and dropped into the install has no row and never will — the registry describes what Geneseed ships. Those read **personal** and gather under their own class in the Skills ledger, apart from the six-class taxonomy they were never given a place in. A badge reading **no status** means something else entirely: `registry.json` could not be read at all, so nothing is known about anything — run `doctor`.

package/docs/web/autostart.md

@@ -1,9 +0,0 @@
----
-group: start
-order: 5
-title: "Start the web UI at login"
-kind: "markdown"
-anchor: "start-the-web-ui-at-login"
-source: "SETUP.md"
-slice: true
----

package/docs/web/claude-hooks.md

@@ -1,37 +0,0 @@
----
-group: hooks
-order: 0
-title: "How Geneseed binds to Claude Code"
-kind: "concept"
----
-Claude Code has no `instructions` array and no JS plugin dir — the harness reaches it through **`settings.json` hooks** instead: the same capabilities the OpenCode plugins provide, each driven by a `geneseed-hook` subcommand. `CLAUDE.md` itself auto-loads by location, so it needs no hook at all.
-
-### The hooks
-
-- **Context injection** — `SessionStart` (startup, clear, resume) runs `geneseed-hook context`: auto-discovers the repo's docs by convention and injects them before your first turn, plus your machine wiki. It honours the same `GENESEED_CONTEXT` manifest as the OpenCode context plugin.
-- **Git gate** — `PreToolUse` on Bash runs `geneseed-hook git-gate`: a `git commit` or `git push` anywhere in the command line — a compound one-liner and a `-C <path>` form included — asks first, at the tool boundary and before the shell runs it (**Doctrine process 5**). It is the one hook that rides a doctrine pack: an install built without **process** never gets this group, because a boundary that keeps asking for a rule the install did not adopt is a gate arguing with its own harness.
-- **Rule gate** — `PreToolUse` on the write tools runs `geneseed-hook rule-gate`: a write to `user-rules.md` or to a memory file asks first, because whether something you want kept is a standing rule or a durable fact is *your* call, settled through the [rule skill](#/docs/skills) (**Doctrine process 1**). Ordinary edits are untouched.
-- **Tool gate** — `geneseed-hook tool-gate` is the git gate and the rule gate fused behind one command, for hosts whose hook config has no per-tool matcher (Bob). Claude Code matches per tool, so its `settings.json` wires the two gates above instead.
-- **Learn** — `Stop` and `SubagentStop` run `geneseed-hook learn`: distils durable memories into the install's `memory/` store at session end; a subagent's stop routes to the per-agent lesson path (`memory/agents/<name>.md`).
-
-### Where they live
-
-The emit merges the hook groups surgically into your `settings.json` (global `~/.claude/settings.json`, or the project's), preserving every other key and any hooks of your own. The install manifest records exactly which groups Geneseed owns, so an upgrade replaces and an uninstall removes precisely those — never yours.
-
-### The hook shim
-
-Hooks run with the project as their working directory, so every command has to be an absolute path. Rather than write the interpreter and this checkout into your `settings.json`, the emit points every hook at one stable file — the **hook shim**, at `~/.geneseed/bin/geneseed-hook` (`geneseed-hook.cmd` on Windows). The shim holds the two volatile paths; the config holds none.
-
-That indirection is what lets the checkout move. Before it, relocating or replacing the clone silently broke the gates in every install at once, and the only repair was re-emitting every config. Now a single build rewrites the shim and every install is live again. The shim is refreshed on **every** emit, so an ordinary `geneseed build` is the repair; `geneseed doctor` reports it if it was ever stale.
-
-Set `GENESEED_HOME` to keep the shim somewhere other than `~/.geneseed`.
-
-The shim prints nothing of its own, deliberately: the gates return success on every path and signal their verdict as JSON on **stdout**, so a single stray byte from the shim would corrupt that verdict and turn a blocking gate into a silently permissive one.
-
-### Verify
-
-Open Claude Code in any repo: the first reply opens with the readiness sigil and your project's docs are already in context. End a session and check the install's `memory/` dir for distilled files.
-
----
-
-**Deeper:** [Claude Code adapter](#/docs/adapters-claude-code)

package/docs/web/cli.md

@@ -1,6 +0,0 @@
----
-group: reference
-order: 0
-title: "CLI — every subcommand"
-kind: "cli"
----

package/docs/web/collaboration.md

@@ -1,27 +0,0 @@
----
-group: concepts
-order: 11
-title: "The collaboration layer"
-kind: "concept"
----
-Beside the [constitution](#/docs/rules), a handful of mechanisms shape *how* the agent works with you — the two registers, the mutual contract, how memory binds, and who you are. All of them are plain content in `AGENT.md` and its neighbours, so they ride to every host (OpenCode, Claude, Bob, OpenClaude) unchanged.
-
-### Postures — the register
-
-A **posture** is the relationship register the agent works in, chosen by *you* at setup and fixed at build time so it holds steady instead of drifting back toward plain execution mid-session. Five ship: **peer** (default — a candid equal), **mentor** (explains the why), **expert** (maximum density), **assistant** (precise, low-initiative), **artisan** (peer with toolsmith reflexes). Posture is orthogonal to theme: theme is the *voice*, posture is the *relationship*. Change it in the setup wizard, from the **Harnesses** page here (the per-install posture dropdown, next to voice and footprint), or with `geneseed-build --posture <name>`. A rebuild or re-theme preserves it.
-
-### Modes — how work executes
-
-A **mode** is the session's operating register — *how* work gets executed, as opposed to posture's *relationship* register. Two ship: **direct** (default — the agent works every task itself, turn by turn) and **foreman** (the session triages incoming tasks: trivial ones get a direct answer, substantial ones spawn an isolated pipeline — a crew of an analyst, a developer, and a tester, plus whatever specialists the task needs — that reports back and merges only once its own tests and lint pass, while the session keeps answering you). Expect foreman mode to cost more per substantial task, in exchange for a session that never blocks on one. Change it in the setup wizard, from the **Harnesses** page here (the per-install mode dropdown, next to posture), or with `geneseed-build --mode <name>`; switch back any time with `--mode direct`. A rebuild or re-theme preserves it. See [Foreman mode](#/docs/foreman-mode) and [agent pipelines](#/docs/pipelines) for the dedicated pages.
-
-### The Pact — a two-way contract
-
-Where the Rules bind the agent, the **Pact** binds the collaboration — and it is not a layer beside them: it is stated inside **Telos**, the first Ethos section, the tier that is always in force, so it holds in every task and every repository. It carries three ranked laws — protect the user, the code's future maintainer included; serve their intent; keep the agent's own honesty — each yielding only to the one above, and — unusually — names what *you* owe back: don't punish candour that honours the pact, give context up front, decide when shown a fork. Your half is not enforceable against you; the agent's half is binding on it.
-
-### Typed memory — binding force
-
-A memory may carry an optional `force` — **constraint** (imposed, not the agent's to relax), **choice** (revisable with consent), **conviction** (revisable on evidence), or **tempered** (a relaxed constraint). When new evidence contradicts a forced memory, the Bridge rule requires revising it in the open rather than dropping it silently.
-
-### Your profile — identity
-
-`PROFILE.md`, seeded once beside `AGENT.md` and never overwritten, holds *who you are*: role, habits, register preferences. It is identity, not rules — it colours how the agent works but never binds (precedence is the Ethos and the Rules, then `user-rules.md`, then the active Doctrines, then the profile). Edit it here under the **Profile** tab, or in the file directly — or let the agent draft it: the [[profile]] skill interviews you (who you are, how you work, how you like answers pitched) and writes the file only with your consent, routing anything that is really a standing rule to `user-rules.md` instead.

package/docs/web/configure-wiki.md

@@ -1,9 +0,0 @@
----
-group: howto
-order: 1
-title: "Configure a wiki (knowledge base)"
-kind: "markdown"
-anchor: "wiki-your-own-knowledge-base-optional"
-source: "SETUP.md"
-slice: true
----

package/docs/web/design.md

@@ -1,7 +0,0 @@
----
-group: deeper
-order: 0
-title: "DESIGN.md — the spec"
-kind: "markdown"
-source: "DESIGN.md"
----

package/docs/web/env-knobs.md

@@ -1,9 +0,0 @@
----
-group: reference
-order: 1
-title: "Environment variables"
-kind: "markdown"
-anchor: "environment-knobs"
-source: "SETUP.md"
-slice: true
----

package/docs/web/exclusions.md

@@ -1,26 +0,0 @@
----
-group: concepts
-order: 9
-title: "Sovereign repos (exclusions)"
-kind: "concept"
-link: {"hash": "#/harness", "label": "Manage in Harness →"}
----
-A **sovereign repo** is a folder where every GLOBAL harness install goes fully dormant: hooks stay silent and the global preamble (`AGENT.md`/`CLAUDE.md`) is never loaded there. A repo that ships its own agent config you don't want a global harness layered onto is the usual case.
-
-### Total dormancy, not a filter
-
-Exclusion is all-or-nothing per folder — it doesn't trim which Rules apply or which Skills load, the global harness simply never engages inside that tree. A per-repo Geneseed install in the same folder is unaffected; exclusions only ever suppress GLOBAL installs.
-
-### How it's wired, per host
-
-- **Claude Code** — native suppression via `claudeMdExcludes` in the repo's `.claude/settings.local.json`.
-- **OpenClaude** — the same `claudeMdExcludes`, in the repo's `.openclaude/settings.local.json`.
-- **Bob** — a shadow `rules/geneseed.md` stub that shadows the global one (never overwrites a hand-written stub already there).
-- **OpenCode** — the hook entry's sovereign-bypass guard and its twin in the plugins short-circuit at session start.
-
-### Manage it
-
-- **CLI** — `harness exclude add <path>` / `remove <path>` / `list`.
-- **This console** — the **Excluded folders** card on the **Harnesses** page (shown once a global install exists).
-
-Exclusions live in each global install's own `excludes.json`, so add/remove re-wires every global install in one call — nothing to repeat per host.

package/docs/web/first-session.md

@@ -1,28 +0,0 @@
----
-group: start
-order: 3
-title: "Your first session"
-kind: "concept"
----
-Once installed, the agent doesn't change *how* you talk to your tool — it changes what the tool already knows when you do.
-
-### What loaded automatically
-
-- **`AGENT.md`** — the [constitution](#/docs/rules): the {N_ONTOLOGY} Ethos sections, {N_LAWS} always-on Rules, and the {N_DOCTRINE_RULES} doctrine rules from the packs this install built in.
-- **Your repo's docs** — `README.md`, `CONTRIBUTING.md`, anything under `docs/` the harness discovers.
-- **Your machine's wiki** (if you [set one up](#/docs/configure-wiki)) — eager entries and a lazy listing of the rest.
-- **The skill and agent catalogue** — invokable by name.
-
-### Try these prompts
-
-- *"Use the **profile** skill"* — a short interview that drafts `PROFILE.md` (seeded empty at install), so the agent knows who you are and how you like answers pitched.
-- *"Use the **brainstorm** skill on this feature request."*
-- *"Delegate to the **reviewer** agent on the staged diff."*
-- *"Use **brainstorm** then **plan** for how to add X."*
-- *"Use **council** to debate whether we should ship Y now."*
-
-Skills are repeatable workflows; agents are capability specialists. You invoke them by name in plain English.
-
----
-
-**Catalog:** [Skills](#/section/skills) · [Agents](#/section/agents) · [Constitution](#/laws)

package/docs/web/footprint.md

@@ -1,38 +0,0 @@
----
-group: concepts
-order: 8
-title: "Footprint (lean vs full)"
-kind: "concept"
-link: {"hash": "#/settings", "label": "Toggle it in Settings →"}
----
-**Footprint** controls how much of the [constitution](#/docs/rules) your agent carries *inline* in `AGENT.md` every turn. Two states — **lean** (the default) and **full** — set per install. It's a token-cost dial, not a change to which rules apply: whatever this install adopted is in force at either setting, and across lean and full the emitted files are otherwise identical — same Agents, Skills, plugins, commands, Memory, and Notebook. (The dial that *does* change which rules apply is the [doctrine packs](#/docs/setup-choices), a separate choice.)
-
-### The difference
-
-- **Full** — `AGENT.md` inlines the Ethos, every Rule and every rule of the **active** doctrine packs, complete text and reasoning included, on every single turn.
-- **Lean** — each Rule and each doctrine rule is carried as its **heading + an authored short form** — the rule and its mechanism, written by hand rather than cut at the first full stop — each tier closing with a pointer to its complete text shipped beside `AGENT.md` — the agent reads the reasoning on demand when a rule's application is unclear. The Ethos is condensed the same way, as **one authored short form for the whole tier**: it is flowing prose rather than numbered blocks, so cutting it section by section would have left orphan fragments instead of a shorter argument.
-
-### What ships on disk either way
-
-Neither setting hides text from the agent; they hide it from *every turn*.
-
-- **Lean** writes `laws/`, `ontology/` and `doctrines/` in full text into the install, beside `AGENT.md`, because the inline copy has lost text the agent may still need.
-- **Full** writes `doctrines/` for the mirror-image reason: full inlines only the packs this install built in, so the ones it left out have to be on disk for a citation into them to resolve, and for you to read before turning one on.
-
-### Which to choose
-
-- Keep **lean** — the default — on long sessions, large repos, or cost-sensitive runs, trusting the agent to pull the complete text when it needs the *why*. Lean is **safe**: that text still ships, and the harness explicitly points the agent there before acting on secrets, deletion, git history, scope, or untrusted content. It's an optimization, not a rules cut.
-- Switch to **full** if token cost is a non-issue, you want the reasoning always present, or you run a smaller/cheaper model — with the *why* eagerly in context, a model applies a rule's nuance more reliably.
-
-### How to set it
-
-It's set-and-forget — stored in the `.geneseed-footprint` marker, preserved across every rebuild, identical on every host (OpenCode, Claude Code, Bob, OpenClaude). Changing it re-emits the install.
-
-- **Settings** — the **Footprint** toggle flips the current install (full ⇄ lean) and rebuilds it in place.
-- **Harness tab** — on an active install, a per-harness dropdown sets it for that install independently, then **Apply**. On a host that is not installed yet, it is step 2 of **Install…**.
-- **Setup / re-theme wizard** — asks for footprint alongside voice, posture, mode, and doctrine packs.
-- **CLI** — `geneseed-build --footprint lean` (with any `--emit`).
-
----
-
-**Related:** [The constitution](#/docs/rules) · [Voice vs structure](#/docs/themes) · [Token footprint — the numbers](#/docs/token-footprint)

package/docs/web/foreman-mode.md

@@ -1,33 +0,0 @@
----
-group: concepts
-order: 12
-title: "Foreman mode"
-kind: "concept"
-link: {"hash": "#/harness", "label": "Set the mode in Harness →"}
----
-**Mode** is the session's *operating* register — how work gets executed — one of four build-time dials, beside posture (the *relationship* register), [doctrine packs](#/docs/setup-choices) (which practice rules bind) and footprint (how much of the constitution loads inline). Two modes ship, set at build time so the choice holds steady instead of drifting mid-session, and preserved across every rebuild and re-theme.
-
-### direct — the default
-
-The agent works every task itself, turn by turn — exactly as it does without the dial. Nothing spawns; you talk to one agent from start to finish. Keep it unless you specifically want the session managing work for you.
-
-### foreman — a session that triages
-
-The session becomes a triage layer instead of a single worker. It sorts each incoming request:
-
-- **Trivial** — answered directly, in-line, just like direct mode.
-- **Substantial** — handed to an isolated [agent pipeline](#/docs/pipelines): a crew that runs on its own, reports back, and merges only once its own tests and lint pass.
-
-Because the crew runs apart from the conversation, the session stays responsive — you keep talking to the foreman while the work proceeds. Expect foreman to cost more per substantial task (a crew runs instead of one agent), in exchange for a session that never blocks on a long job.
-
-### How to set it
-
-Set-and-forget, stored beside the install and preserved across rebuilds and re-themes:
-
-- **Harness tab** — on an active install, the per-install **Mode** dropdown (beside Voice, Footprint, and Posture), then **Apply**. On a host that is not installed yet, the same four choices are steps inside **Install…**.
-- **Setup / re-theme wizard** — asks for mode alongside voice, posture, doctrine packs, and footprint.
-- **CLI** — `geneseed-build --mode foreman`; switch back with `--mode direct`.
-
----
-
-**Related:** [Agent pipelines](#/docs/pipelines) · [The collaboration layer](#/docs/collaboration)

package/docs/web/glossary.md

@@ -1,6 +0,0 @@
----
-group: reference
-order: 2
-title: "Glossary (in your deployed voice)"
-kind: "glossary"
----

package/docs/web/harnesses.md

@@ -1,30 +0,0 @@
----
-group: start
-order: 4
-title: "Supported harnesses"
-kind: "concept"
----
-One source, **five emit targets** — each with a per-repo and a global (`-global`) variant, plus a portable `files` bundle any `AGENT.md`-aware tool can read. **OpenCode** runs its own engine (JS plugins, colour themes, LSP); **Claude Code**, **Bob**, and **OpenClaude** share one Claude-shaped engine that diverges only by host dialect.
-
-The harness *content* — the constitution (Ethos, Rules, Doctrines), Agents, Skills, Memory, and the preamble voice — is **identical on every host**: one build renders the same text for all five targets. What differs is how much of it the host can *automate* (via plugins or hooks) versus carry as preamble discipline.
-
-| Capability | OpenCode | Claude | Bob | OpenClaude |
-| --- | :---: | :---: | :---: | :---: |
-| Agents · Skills · Memory | ✅ | ✅ | ✅ | ✅ |
-| Context injection | ⚙️ plugin | 🪝 hook | 🪝 hook¹ | 🪝 hook² |
-| Memory write-back (learn) | ⚙️ plugin | 🪝 hook | 🪝 hook¹ | 🪝 hook² |
-| Git-gate consent (Consent Before Push) | ⚙️ plugin | 🪝 hook | 🪝 hook¹ | 🪝 hook² |
-| Sovereign-repo excludes | ⚙️ plugin | ✅ | ✅ | ✅ |
-| MCP server wiring | ✅ | ✅ | ✅ | ✅ |
-| Colour themes | ✅ | ➖ | ➖ | ➖ |
-| LSP · workflows · primary-agent · `/`-commands | ✅ | ➖ | ➖ | ➖ |
-
-✅ native · ⚙️ OpenCode plugin · 🪝 `settings.json` hook · 📄 preamble prose only · ➖ no host mechanism (harness discipline still applies). ¹ Bob honours Claude-dialect hooks best-effort — inert if unsupported, harness still holds via the preamble. ² OpenClaude is a Claude Code fork: Claude's hooks verbatim, under `~/.openclaude` or a repo's `.openclaude/`.
-
-**The git-gate row is the one capability that is not always present**, on any host. It implements **Consent Before Push** (`process 5`), so it is wired only on an install that built the **process** [doctrine pack](#/docs/setup-choices) in — drop that pack and the boundary drops with it, because a gate that keeps asking for a rule the install never adopted is a gate arguing with its own harness. One asymmetry: on OpenCode that holds for a *fresh* install, but a pack-off rebuild of an install whose `opencode.json` already carries a `git commit*` entry leaves it in place and reports it — Geneseed cannot tell its own entry from one you typed, so it removes neither ([doctrine packs](#/docs/setup-choices)). The invariant-territory refusals in the same neighbourhood (`rm -rf`, a force-push) are the Rules' territory, not the pack's, and stay in every build.
-
-**No host drops an Agent, Skill, or the memory convention.** The asymmetry is otherwise entirely in *automation mechanism*: OpenCode's plugins and Claude/Bob/OpenClaude's hooks enforce a few of these rules for you at the tool boundary; what no host can automate rides the preamble. The OpenCode-only extras (themes, LSP, workflow runner, primary-agent) have no analogue on a Claude-shaped host.
-
----
-
-**Deeper:** [The harness model](#/docs/model) · [Footprint per host](#/docs/footprint)

package/docs/web/headless.md

@@ -1,9 +0,0 @@
----
-group: howto
-order: 6
-title: "Run in CI / headless"
-kind: "markdown"
-anchor: "headless-ci-opencode"
-source: "SETUP.md"
-slice: true
----

package/docs/web/ingest-docs.md

@@ -1,9 +0,0 @@
----
-group: howto
-order: 3
-title: "Read PDFs / Office docs"
-kind: "markdown"
-anchor: "reading-non-markdown-docs"
-source: "SETUP.md"
-slice: true
----

package/docs/web/install-paths.md

@@ -1,9 +0,0 @@
----
-group: howto
-order: 0
-title: "Choose your install path"
-kind: "markdown"
-anchor: "choose-your-path"
-source: "SETUP.md"
-slice: true
----

package/docs/web/install-quick.md

@@ -1,35 +0,0 @@
----
-group: start
-order: 0
-title: "Install in 5 minutes"
-kind: "concept"
----
-Two steps. The only prerequisite is **Node ≥ 22.3** — Geneseed ships as an npm package with zero dependencies.
-
-### 1. Run the setup wizard
-
-```
-npx geneseed setup
-```
-
-The same command on macOS, Linux and Windows (cmd, PowerShell, or any POSIX shell). The wizard asks for a theme and an install mode (OpenCode global is recommended — one install, every repo inherits it), then builds and offers a health check.
-
-To keep the command around: `npm install -g geneseed`, then plain `geneseed …` from any directory.
-
-### 2. Open your agent
-
-Open OpenCode (or Claude Code, Bob, OpenClaude, or any `AGENT.md`-aware tool) in any repo. The first reply opens with the readiness sigil (`✅` neutral / `🧬` imperial / your theme's equivalent) and your project's docs are already in context.
-
-### Prefer a clone?
-
-```
-git clone https://github.com/Arylmera/Geneseed.git
-cd Geneseed
-./geneseed setup            # Windows: .\geneseed.cmd setup
-```
-
-A checkout needs **git** and the same **Node ≥ 22.3** as everything else — there is nothing extra to install — and is what you want if you intend to change the harness rather than use it. Already installed this way? [Migrate to npx](#/docs/migrate) moves every install across in one pass.
-
----
-
-**Next:** [Posture, doctrines & footprint](#/docs/setup-choices) · [Verify it works](#/docs/verify) · [What you just installed](#/docs/model) · [Install by hand instead](#/docs/install-paths)

package/docs/web/lsp-overview.md

@@ -1,37 +0,0 @@
----
-group: lsp
-order: 0
-title: "Code intelligence (LSP)"
-kind: "concept"
-link: {"hash": "#/docs/adapters-opencode", "label": "OpenCode adapter →"}
----
-OpenCode can drive Language Server Protocol servers so the agent sees real diagnostics, type errors, and go-to-definition — not just text. Geneseed turns this on for every language OpenCode ships a server for.
-
-### What's covered out of the box
-
-| Language | Server | You install? |
-|---|---|---|
-| JavaScript / TypeScript / React / React Native | typescript-language-server | No — OpenCode self-downloads |
-| Python | pyright | No — OpenCode self-downloads |
-| Java | jdtls | **JDK 21+** (OpenCode downloads jdtls itself) |
-| SQL / PostgreSQL / Oracle | *none — by design* | — |
-
-One server covers JavaScript, TypeScript, React, and React Native — they are all TS/JS, so no extra server is needed.
-
-### The one prerequisite the harness can't self-install
-
-OpenCode downloads the JS-runtime servers automatically on first use. It cannot install a JVM, and jdtls needs one — so the setup wizard checks for it and prints an install hint if missing:
-
-- **Java 21+** — `brew install openjdk@21`, SDKMAN `sdk install java 21-tem`, or your distro's JDK.
-
-### Why no SQL server
-
-A SQL language server is dialect-locked — a Postgres server flags Oracle SQL as errors and vice versa — and a `.sql` file can map to only one server, with no signal for which dialect a repo uses. Rather than guess wrong for half of all SQL codebases, we ship none. A project that knows its dialect can add the matching server in its own `opencode.json` under the `lsp` key.
-
-### How it's wired
-
-`"lsp": true` in your emitted `opencode.json` enables every built-in server (LSP is off by default). To turn auto-download off (air-gapped machines), set `OPENCODE_DISABLE_LSP_DOWNLOAD=true` and pre-install each server.
-
----
-
-**Verify:** open a `.ts` and a `.py` file in a session and ask the agent for diagnostics — the first open triggers the download.

package/docs/web/mcp-claude-code.md

@@ -1,10 +0,0 @@
----
-group: mcp
-order: 4
-title: "Claude Code"
-kind: "markdown"
-harness: "claude"
-anchor: "claude-code"
-source: "SETUP.md"
-slice: true
----

package/docs/web/mcp-filesystem.md

@@ -1,9 +0,0 @@
----
-group: mcp
-order: 3
-title: "Filesystem"
-kind: "markdown"
-anchor: "filesystem"
-source: "SETUP.md"
-slice: true
----

package/docs/web/mcp-gitlab.md

@@ -1,9 +0,0 @@
----
-group: mcp
-order: 2
-title: "GitLab"
-kind: "markdown"
-anchor: "gitlab-one-entry-per-instance"
-source: "SETUP.md"
-slice: true
----

package/docs/web/mcp-markitdown.md

@@ -1,9 +0,0 @@
----
-group: mcp
-order: 1
-title: "MarkItDown (PDF/Office)"
-kind: "markdown"
-anchor: "markitdown-via-mcp"
-source: "SETUP.md"
-slice: true
----

package/docs/web/mcp-overview.md

@@ -1,34 +0,0 @@
----
-group: mcp
-order: 0
-title: "MCP overview"
-kind: "concept"
----
-The Harness ships **three** ready-to-wire MCP servers as presets — **MarkItDown** (PDF/Office → Markdown), **GitLab** (shipped as two entries, one per instance), and **Filesystem** (scoped file access) — four config entries in all. Each is a *local* server the agent launches on demand: registering one only points the agent at a command — *you* install the tool (or let `npx`/`pipx` fetch it) and supply any credentials.
-
-### Where they live
-
-<!--harness:opencode-->
-They sit under the `mcp` key of an `opencode.json` (global `~/.config/opencode/opencode.json` or per-repo), each entry shaped:
-
-```json
-"<name>": { "type": "local", "command": ["…"], "environment": {}, "enabled": true }
-```
-<!--/harness-->
-<!--harness:claude-->
-They live in `.mcp.json` under `mcpServers` — note the key is `env` (not `environment`) and the command and its args are split into `command` + `args`. See [Claude Code wiring](#/docs/mcp-claude-code).
-<!--/harness-->
-
-<!--harness:opencode-->
-### Toggle them without hand-editing JSON
-
-`./geneseed` → **Settings** → **MCP servers** toggles any of the presets into your project or global `opencode.json` — and enables, disables, or removes them — for you. The reference config ships MarkItDown enabled and the GitLab / Filesystem entries disabled, so a merge never activates a credential-less server: fill the blanks, then flip the one(s) you want on.
-<!--/harness-->
-
-> **Never commit a real token.** The presets ship with **empty** `GITLAB_PERSONAL_ACCESS_TOKEN` placeholders (and a sample filesystem path) — fill them in your own config, never in a tracked file (universal Law I — secrets).
-
----
-
-**Wire one up:** [MarkItDown](#/docs/mcp-markitdown) · [GitLab](#/docs/mcp-gitlab) · [Filesystem](#/docs/mcp-filesystem) · [Verify](#/docs/mcp-verify) · [Won't connect?](#/docs/mcp-trouble)
-
-> **Listed ≠ working.** A `local` server is just a command the agent runs — it appears in the list whether or not that command actually launches. The usual cause of "shown but not working" is the command not being on PATH (e.g. `markitdown-mcp` with no `uvx`/pipx install) or a filesystem entry left on its placeholder path. [Walk the fixes →](#/docs/mcp-trouble)

package/docs/web/mcp-trouble.md

@@ -1,9 +0,0 @@
----
-group: mcp
-order: 6
-title: "Won't connect?"
-kind: "markdown"
-anchor: "mcp-server-wont-connect"
-source: "SETUP.md"
-slice: true
----

package/docs/web/mcp-verify.md

@@ -1,9 +0,0 @@
----
-group: mcp
-order: 5
-title: "Verify"
-kind: "markdown"
-anchor: "verify"
-source: "SETUP.md"
-slice: true
----