geneseed 3.10.0 → 3.11.0

package/docs/web/migrate.md

@@ -1,39 +0,0 @@
----
-group: howto
-order: 8
-title: "Migrate an existing install to npx"
-kind: "concept"
----
-If you installed Geneseed by cloning the repository, your hooks currently run through a small machine-wide shim at `~/.geneseed/bin/geneseed-hook` that hands every call to *your checkout*. Installing from npm changes where that code lives. **`geneseed migrate` moves every install you already have onto the new shape, in one pass, without touching your own settings.**
-
-### What it does
-
-```
-geneseed migrate --dry-run     # survey and print the plan; writes nothing
-geneseed migrate               # do it
-```
-
-It surveys every registered install, re-emits each one **in its own theme, emit, footprint, posture and mode** — nothing is defaulted, so a rebuild never silently changes what you chose — re-bakes the machine-wide hook shim so it points at the new location, and reports anything it is not allowed to fix for you.
-
-Run it once, from the new install. A second run says `already on the npm shape` and writes nothing.
-
-### It is all-or-nothing
-
-Before it changes anything, `migrate` copies every host settings file and the hook shim into `~/.geneseed/.migrate-backup/`. If any install fails to rebuild, **everything is put back** and the run exits non-zero. You are never left half on one shape and half on the other. `rebuild-all` deliberately continues past a broken install so one failure cannot block the rest; a migration deliberately does the opposite.
-
-### It refuses rather than guesses
-
-If a registered install carries a `.geneseed-emit` marker that names something this generator does not recognise — a truncated or hand-edited file — `migrate` **refuses the whole run**, names the install, and changes nothing. Rebuilding it would mean guessing which host and scope you installed, and re-emitting an install as something its owner never chose is worse than stopping. Fix or delete the marker and re-run.
-
-### What it will not touch
-
-Two things are yours, and `migrate` reports them instead of rewriting them:
-
-- **Hooks it did not write.** Your own hooks, and any third-party ones, are left exactly as they are — the re-emit only replaces the hook groups Geneseed's own manifest claims.
-- **Autostart entries.** If you set the web UI to [start at login](#/docs/autostart), that VBS script or LaunchAgent is a file you hand-wrote — Geneseed has never created one. If it still names your old checkout, `migrate` prints its path and the command to put there. Edit it yourself.
-
-If your `settings.json` has comments in it, Geneseed will not rewrite the file at all (it never has — your edits are safe), so the hooks in it stay pointing at the old shim until you update them by hand.
-
-### Your old clone keeps working
-
-Nothing breaks the day you install from npm. A cloned checkout continues to work for one full release, printing the migration instructions when you `git pull`. There is no cliff — migrate when it suits you.

package/docs/web/model.md

@@ -1,20 +0,0 @@
----
-group: concepts
-order: 0
-title: "The harness model"
-kind: "concept"
----
-Geneseed assembles its runtime pieces around a single `AGENT.md` entrypoint: an **Ethos** (how the agent thinks, decides and speaks — always on), **Rules** (the always-on invariants it never breaks), **Doctrines** (practice packs this repository chose at build time), **Agents** (capability specialists you delegate to), **Skills** (repeatable workflows the agent can invoke), **Memory** (one-fact-per-file durable knowledge), and a **Notebook** (the agent's own sovereign space). The first three are the [constitution](#/docs/rules), in that order of precedence — with your own `user-rules.md` sitting between the Rules and the Doctrines.
-<!--harness:opencode-->
-On OpenCode, {N_PLUGINS} **Plugins** bind the pieces to the host: context injection, learn-at-session-end, the safety guard, the saved workflow runner, end-of-run notifications, a live-activity feed for this console, and an opt-in minimal-code mode.
-<!--/harness-->
-<!--harness:claude-->
-On Claude Code, four settings.json **hooks** bind the pieces to the host — context injection, the git consent gate (wired only when the **process** doctrine pack is built in), the rule gate on writes to `user-rules.md` and memory, and learn-at-session-end. See [How Geneseed binds to Claude Code](#/docs/claude-hooks).
-<!--/harness-->
-The structure is theme-independent — a theme only changes the *voice* (banner, sigil, prose), never a folder or a link. Four dials are fixed at build time and preserved across every rebuild: **[posture](#/docs/collaboration)** (the relationship register), **mode** ([direct vs foreman](#/docs/foreman-mode) — one agent turn by turn, or a foreman triaging tasks into [pipelines](#/docs/pipelines)), **[doctrine packs](#/docs/setup-choices)** (which practice rules bind — the only dial that changes *which* rules apply), and **[footprint](#/docs/footprint)** (how much of the constitution loads inline each turn, full vs lean). Around them the **[collaboration layer](#/docs/collaboration)** — posture, the Pact, typed memory, your profile — shapes how the agent works *with you*.
-
-### What this UI actually shows
-
-The **Library** and **Graph** render the Geneseed source live — they show the harness that *would* be deployed if you rebuilt right now. The **Settings** panes and the **Memory** drawer read from the deployed harness on disk (the harness install dir, e.g. `~/.config/opencode/…` for an OpenCode global install).
-
-If you've built recently, the two match. If you edit a file under `src/` and reload this panel, the Library updates immediately — the deployed bundle does not, until the next `geneseed update` or `build`.

package/docs/web/pipelines.md

@@ -1,24 +0,0 @@
----
-group: concepts
-order: 13
-title: "Agent pipelines"
-kind: "concept"
-link: {"hash": "#/section/agents", "label": "Browse the agents →"}
----
-An **agent pipeline** is the isolated crew that [foreman mode](#/docs/foreman-mode) spawns for a substantial task. Where [agents](#/section/agents) are capability specialists you delegate to one at a time, a pipeline chains them into a single, self-contained unit of work that runs apart from your session.
-
-### The default crew
-
-- **analyst** — turns the request into a concrete plan and acceptance criteria.
-- **developer** — implements against that plan.
-- **tester** — exercises the result and gates the outcome.
-
-The foreman adds whatever other specialists the task calls for — a reviewer, a security pass, a docs writer — routing each subtask to the agent that owns it.
-
-### Isolated, and gated on green
-
-A pipeline runs in its own context so the main session stays free to keep answering you, and it **merges only once its own tests and lint pass** — a crew that can't get to green reports back rather than landing broken work. It's the same *decompose → route to the owning specialist → converge* shape the saved workflow runner uses, but driven live by the foreman rather than a pre-written script.
-
----
-
-**Related:** [Foreman mode](#/docs/foreman-mode) · [Agents](#/section/agents)

package/docs/web/plugin-activity.md

@@ -1,23 +0,0 @@
----
-group: plugins
-order: 7
-title: "geneseed-activity"
-kind: "concept"
----
-Feeds this console's **Activity** view: writes one small JSON file per session (`activity/<session_id>.json` beside the OpenCode config) recording what the harness is *doing* — current phase, model, token and cost totals, turn-elapsed, files touched, the plan, and the last error. The web server reads and prunes those files; writer and reader only ever meet on the filesystem, so a crash on either side never blocks a session.
-
-- **One entry per top-level session** — sub-agent child sessions and the learn plugin's throwaway distil sessions are skipped.
-- **Self-cleaning** — the reader prunes entries whose process is dead or whose timestamp went stale, so a crashed writer's file disappears on its own.
-
-### Install
-
-Installs with the other plugins in one step — see [Plugin setup](#/docs/plugin-setup).
-
-### Configure
-
-- `GENESEED_ACTIVITY=off` — hard kill switch at startup.
-- The **Activity** page's toggle writes a `.geneseed-activity` flag file read per event — takes effect without restarting OpenCode.
-
-### Verify
-
-Start a session, then open **Activity** in this console — a card for the session appears. `GENESEED_DEBUG=1` logs each write as `[geneseed-activity] …` to stderr.

package/docs/web/plugin-context.md

@@ -1,26 +0,0 @@
----
-group: plugins
-order: 1
-title: "geneseed-context"
-kind: "concept"
----
-Enforces the project-context load by injection, not instruction: on `session.created` it auto-discovers the repo's docs by convention and injects the `eager` ones before your first turn, so the harness needs **zero per-repo files**.
-
-- **Eager** (injected in full, budget-capped): root `AGENTS.md` / `AGENT.md` / `CLAUDE.md` / `.cursorrules`, `README.md`, `CONTRIBUTING.md`.
-- **Lazy** (path + first heading, read on demand): `docs/`, `doc/`, `architecture/`, `adr/`, monorepo `packages/*/README.md`, other root `*.md`. `node_modules`, `.git`, `dist`, `build` are never scanned.
-- It re-pushes eager docs on `session.compacting` so context survives a summarised long session, and carries your machine wiki (`wiki.jsonc`) on the same budgets.
-
-### Install
-
-Installs with the other plugins in one step — see [Plugin setup](#/docs/plugin-setup).
-
-### Configure
-
-- `GENESEED_CONTEXT` — path to an explicit `context.json` manifest (or drop `.harness/context.json` in the repo) to take control: same schema, plus glob `path`s, `load: exclude`, and `"extend": true` to layer on top of discovery.
-- `GENESEED_EAGER_FILE_KB` (default 16) / `GENESEED_EAGER_TOTAL_KB` (default 48) — budget caps; an oversized eager file is demoted to a lazy listing, never silently truncated.
-- `GENESEED_CONTEXT_VISIBLE=1` — force the visible `PROJECT CONTEXT` block instead of the invisible per-request transform.
-- `GENESEED_CONTEXT_INJECT=off` — disable injection entirely; the load falls back to prose the agent has to honour itself — AGENT.md's own **Context** section, and **Doctrine process 4** (read the project's documentation for a part of the system before changing it) where the process pack is built in.
-
-### Verify
-
-Start a session with `GENESEED_DEBUG=1` set — the plugin logs what it discovered and injected to stderr. Silence means it didn't load: re-check the filename and that the path is exactly the plugins dir above.

package/docs/web/plugin-guard.md

@@ -1,24 +0,0 @@
----
-group: plugins
-order: 3
-title: "geneseed-guard"
-kind: "concept"
----
-Enforces the safety Laws at the tool boundary (`tool.execute.before`) — the same *enforce by injection, don't just instruct* stance as the context plugin. The guard ships whole on every install, whatever [doctrine packs](#/docs/setup-choices) it built in — its blocking arms are **invariant** territory, and the speed-bump below is about which store a note belongs in, which is your call either way. The one boundary that does follow a pack is the commit/push consent gate, and that lives in the permission block rather than here. High-confidence patterns only, so legitimate work is never caught:
-
-- **Blocks** — writes to private-key / credential files (**Sealed Secrets**), catastrophic shell like `rm -rf /` (**Deletion Is Deliberate**), and any mutation under a declared wiki's `protected` folders (AGENT.md §8, from `wiki.jsonc`).
-- **Warns** (logged, allowed) — `.env` writes and force-push.
-- **Speed-bumps** — the *first* write to `user-rules.md` or a memory file is refused, naming **Persist Insight**: a standing rule or a durable fact is the user's call, settled through the rule skill. A re-issued write goes through, so a legitimate write is never trapped. (On Claude Code and Bob the same guard is a `geneseed-hook rule-gate` hook, which can *ask* the user instead of refusing — OpenCode's `tool.execute.before` has no ask tier.)
-
-### Install
-
-Installs with the other plugins in one step — see [Plugin setup](#/docs/plugin-setup). The `protected` wiki folders are read from `wiki.jsonc` (`GENESEED_WIKI` → `$GENESEED_HARNESS/wiki.jsonc` → beside the install).
-
-### Configure
-
-- `GENESEED_GUARD=off` — disable the guard entirely.
-- `GENESEED_GUARD=warn` — downgrade every block to a warning (log, but allow).
-
-### Verify
-
-Ask the agent to do something the guard blocks (e.g. write to a `.pem` file) — it should be refused with a `[geneseed-guard] blocked: …` message naming the Law.

package/docs/web/plugin-learn.md

@@ -1,27 +0,0 @@
----
-group: plugins
-order: 2
-title: "geneseed-learn"
-kind: "concept"
----
-The runtime-agnostic counterpart of the Claude Code `Stop` hook: on `session.idle` it distils durable memories from the conversation into the bundle's `memory/` dir and maintains `MEMORY.md`, deduping against what's already stored — exactly what `geneseed learn` does, but self-contained in JS, so no Python and no model CLI are required.
-
-It distils with the **same model the session already used** (read from the transcript), inheriting your OpenCode provider config — no API key, nothing to set. Trivial sessions are skipped and any error is swallowed, so it never blocks a session.
-
-### Install
-
-Installs with the other plugins in one step — see [Plugin setup](#/docs/plugin-setup).
-
-### Configure — where it writes
-
-Memories land in the first location that resolves:
-
-1. `GENESEED_MEMORY` — an explicit memory dir;
-2. `$GENESEED_HARNESS/memory` (or `/anamnesis` for the imperial theme);
-3. `./memory` or `./Harness/memory` when the bundle lives in the project.
-
-Because the bundle is global, set `GENESEED_HARNESS` once to its absolute path so the plugin always writes to the same store no matter where you launch OpenCode. If it can't read the session's model from the transcript, set a fallback `GENESEED_MODEL=provider/model`.
-
-### Verify
-
-Start a session, do a little work, end it. On `session.idle` the plugin logs `[geneseed-learn] wrote N memory file(s): …` or a skip reason to stderr. Total silence means it didn't load.

package/docs/web/plugin-notify.md

@@ -1,24 +0,0 @@
----
-group: plugins
-order: 5
-title: "geneseed-notify"
-kind: "concept"
----
-Pings the OS when the agent finishes a turn, so you can start a long run, walk away, and be called back when it's your move again. It hooks `session.idle` like the learn plugin.
-
-- **Anti-spam:** only fires when the turn actually took a while — the gap between the session's last user prompt and now must exceed `GENESEED_NOTIFY_MIN_SECONDS` (default 30). Native subagent child sessions and the learn plugin's throwaway distil sessions are skipped.
-- **Native, dependency-free:** macOS `osascript`, Linux `notify-send` (libnotify), Windows a PowerShell balloon. Spawned detached; any failure is swallowed, so it never blocks a session.
-
-### Install
-
-Installs with the other plugins in one step — see [Plugin setup](#/docs/plugin-setup). On Linux, install `libnotify` (for `notify-send`) if nothing appears.
-
-### Configure
-
-- `GENESEED_NOTIFY=off` — disable it.
-- `GENESEED_NOTIFY_MIN_SECONDS=N` — tune the threshold (`0` notifies on every turn).
-- `GENESEED_NOTIFY_TITLE="…"` — override the title (default `Geneseed`).
-
-### Verify
-
-With `GENESEED_DEBUG=1`, end a session that ran longer than the threshold — you'll see `[geneseed-notify] notified for …` and a desktop notification.

package/docs/web/plugin-ponytail.md

@@ -1,23 +0,0 @@
----
-group: plugins
-order: 6
-title: "geneseed-ponytail"
-kind: "concept"
----
-The sustained counterpart to the `ponytail` skill: once you opt in, it appends the laziest-that-works ruleset to the system prompt **every turn**, so the agent doesn't drift back to over-building mid-session, and it persists the level across turns.
-
-- **Opt-in:** the mode starts at `off` and injects nothing until you switch it on. Geneseed treats ponytail as a skill you reach for, not as part of the [constitution](#/docs/rules): it is neither an always-on invariant nor a doctrine pack you build in, so nothing about it binds until you ask for it.
-- **Toggle:** `/ponytail lite|full|ultra|off` (a bare `/ponytail` means `full`). The level is written to `.geneseed-ponytail` beside OpenCode's config and applies from the next turn.
-- **Hooks:** `experimental.chat.system.transform` appends the ruleset; `command.execute.before` records the switch. Every failure is swallowed; on a build without the system-transform hook it simply never injects (the skill still covers the invokable path).
-
-### Install
-
-Installs with the other plugins in one step — see [Plugin setup](#/docs/plugin-setup).
-
-### Configure
-
-- `GENESEED_PONYTAIL=lite|full|ultra` — make a level the default for new installs (default `off`, i.e. dormant until asked).
-
-### Verify
-
-With `GENESEED_DEBUG=1`, run `/ponytail full` — you'll see `[geneseed-ponytail] ponytail full`, and the next turn's replies favour the minimal solution.

package/docs/web/plugin-setup.md

@@ -1,7 +0,0 @@
----
-group: plugins
-order: 0
-title: "Plugin setup"
-kind: "markdown"
-source: "docs/opencode-plugin-setup.md"
----

package/docs/web/plugin-workflow.md

@@ -1,25 +0,0 @@
----
-group: plugins
-order: 4
-title: "geneseed-workflow"
-kind: "concept"
----
-Registers one custom tool, `workflow`, that runs saved, code-driven orchestration scripts — the deterministic counterpart to the model-driven [[council]] / [[parallel-agents]] skills: the script, not the model, drives the control flow.
-
-- **Saved scripts only (v1):** the tool loads `<name>.js` from the sibling `workflows/` dir. No model-authored scripts are eval'd.
-- **Call shape:** `workflow({ name, args })` — call with no name to list what's available. Shipped: `council`, `review`, `research-plan-implement`.
-- **Runtime API:** scripts get `agent()`, `parallel()`, `pipeline()`, `phase()`, `log()`, `budget`, `args`. Child work runs as real OpenCode sessions; concurrency is capped at `min(16, cores − 2)`.
-- **Worktree isolation:** `agent(prompt, { isolation: "worktree" })` runs that child on its own branch in its own git worktree (under the OS temp dir), the same option Claude Code's Workflow takes. A worktree with no change is removed with its branch; one with changes is kept, and the tool's summary lists every kept branch and every file more than one agent changed (`rt.worktrees()`, `rt.overlaps()` inside the script). Nothing is merged or committed for you. The worktree holds tracked files only — an agent that must build or test installs dependencies first. Without git the agent fails; it never falls back to the shared tree.
-
-### Install
-
-Installs with the other plugins in one step — see [Plugin setup](#/docs/plugin-setup). The build copies the plugin **and** the sibling `workflows/` dir, so the saved scripts resolve out of the box; a manual `cp` only moves the `*.js`, so copy `adapters/opencode/workflows/` alongside it too.
-
-### Configure
-
-- `GENESEED_WORKFLOWS_DIR` — override the scripts dir (defaults to `.opencode/workflows/` per-repo, `<config>/workflows/` global).
-- A phase-by-phase trace plus the full result land in `.geneseed/workflow-runs/<runId>.log`; `GENESEED_DEBUG=1` adds stderr logging.
-
-### Verify
-
-Ask the agent to *"list available workflows"* — it should call `workflow` with no name and return `council`, `review`, `research-plan-implement`.

package/docs/web/plugins.md

@@ -1,17 +0,0 @@
----
-group: concepts
-order: 10
-title: "Plugins (OpenCode)"
-kind: "concept"
-harness: "opencode"
-link: {"hash": "#/docs/plugin-context", "label": "One page per plugin →"}
----
-OpenCode loads {N_PLUGINS} plugins from the deployed bundle:
-
-- **geneseed-context** — injects the project's docs *and* your machine wiki at every session start (and after compaction).
-- **geneseed-learn** — distils memory at session end (powers the `learn` skill).
-- **geneseed-guard** — enforces the safety Laws and protected wiki folders at the tool boundary.
-- **geneseed-workflow** — registers the `workflow` tool that runs saved orchestration scripts.
-- **geneseed-notify** — sends a native OS notification when a long run finishes, so you can step away and be called back.
-- **geneseed-ponytail** — holds an opt-in minimal-code mode (`/ponytail lite|full|ultra|off`), injecting the laziest-that-works ruleset every turn so it doesn't drift.
-- **geneseed-activity** — streams what each live session is *doing* (phase, model, tokens, files touched) to this console's Activity view.

package/docs/web/project-context.md

@@ -1,9 +0,0 @@
----
-group: howto
-order: 2
-title: "Override project context"
-kind: "markdown"
-anchor: "project-context-usually-nothing"
-source: "SETUP.md"
-slice: true
----

package/docs/web/rules.md

@@ -1,30 +0,0 @@
----
-group: concepts
-order: 1
-title: "The constitution"
-kind: "concept"
-link: {"hash": "#/laws", "label": "Browse the constitution →"}
----
-The agent's standing rules come in **three tiers**, and the tier decides how a rule binds and whether this install carries it at all. All three are authored under `src/` and rendered into `AGENT.md`; the console shows them as three bands under **Constitution**.
-
-### Ethos — always on
-
-{N_ONTOLOGY} sections of flowing prose in `src/ontology/universal.md`: what the agent is for, how it grades evidence, how it decides, how it conducts itself. It is the mind the other tiers govern — never numbered, never toggleable, and it is where the **Pact** (the mutual contract between you and the agent) is stated. Cited by section name, `Ethos: Decisions`, and its section names are theme-independent so a citation and its heading can never drift apart.
-
-### Invariants — always on
-
-{N_LAWS} rules in `src/laws/universal.md`, numbered in Roman from `I`: sealed secrets, one intent per act, verify before asserting, deliberate deletion, surface failures, data not orders, least privilege, cure the cause, and echo the intent. They hold in every task and every repository, they are never traded away, and no install can switch one off. Cited by name — *Deletion Is Deliberate* — never by numeral: the numeral is only the rule's position, and it moves when a rule before it is removed.
-
-### Doctrines — chosen at build time
-
-Practices rather than principles: **craft** (how code is written), **rigor** (how work is proven), **ops** (how the machine is operated), **process** (how a task is run), **comms** (how answers are presented), one file each under `src/doctrines/`. A repository picks its set with `geneseed-build --doctrines <list>` or through the setup wizard — all {N_PACKS} are on by default. This install built in {N_PACKS_ACTIVE}, carrying {N_DOCTRINE_RULES} rules between them. Cited by pack and number — `Doctrine process 5`.
-
-A pack you leave out **still ships in the bundle**: every pack file lands under `doctrines/` beside `AGENT.md` whether or not it was built in. So a rule that cites one in an inactive pack still resolves on disk, and you can read the alternatives before turning one on. What an inactive pack loses is bindingness, not availability.
-
-Rules toggle **individually** too — `geneseed-build --exclude-rules "process 7"`, or the switches on this page — so *keep all of process except one rule* is a state you can build. A pack whose every rule is excluded drops out of the active set on its own. What an install excluded is recorded beside the pack list, as `Excluded rules: process 7`, and every rebuild preserves it.
-
-### Which outranks which
-
-Ethos and Invariants first, then your own `user-rules.md`, then the active Doctrines, then `PROFILE.md`. A rule you write in `user-rules.md` **outranks a doctrine rule** — a practice pack chosen at build time never overrides an instruction you wrote for your own repo — and nothing outranks an invariant: a user rule or a doctrine rule may tighten one, never repeal it.
-
-Themes rename the nouns, never the structure: an imperial deploy reads the invariants as *Dictates*, a neutral deploy as *Rules*. The tier, the address and the rule itself do not move.

package/docs/web/run-anywhere.md

@@ -1,9 +0,0 @@
----
-group: howto
-order: 5
-title: "Run `geneseed` from anywhere"
-kind: "markdown"
-anchor: "run-geneseed-from-anywhere"
-source: "SETUP.md"
-slice: true
----

package/docs/web/self-improve.md

@@ -1,8 +0,0 @@
----
-group: howto
-order: 9
-title: "The self-improvement loop"
-kind: "concept"
-link: {"hash": "#/diff", "label": "Open the diff page →"}
----
-Local edits the agent makes to its own deployed agent/skill files survive the next rebuild. Before `setup`, re-theme, or `upgrade` overwrites them, any drift is auto-exported to a markdown **improvements file** under `improvements/` inside the deployed harness dir — untouched by rebuilds and uninstall. Hand it to an agent in *this* repo to back-port the changes into `src/`. On demand: `geneseed diff --out FILE`, or the **Changes** page in this UI.

package/docs/web/setup-choices.md

@@ -1,64 +0,0 @@
----
-group: start
-order: 1
-title: "Posture, doctrines & footprint"
-kind: "concept"
----
-The setup wizard asks five starting parameters. The first, the **theme**, is the *voice* — banner, sigil, prose register — previewed live as you move through the wizard; it never changes structure or rules, so pick whatever reads best to you ([voice vs structure](#/docs/themes)). The other four shape how the agent works and are explained below. All five have safe defaults — accept them and move on, or pick deliberately here. All are set-and-forget: preserved across every rebuild and re-theme, changeable later from **Settings**, the **Harnesses** page, or the wizard.
-
-### Posture — the relationship register
-
-How the agent works *with you*, fixed at build time so it doesn't drift mid-session:
-
-- **peer** *(default)* — candid equal: dense, challenges, no flattery.
-- **mentor** — explains the why, checks understanding.
-- **expert** — maximum density, no basics.
-- **assistant** — precise execution, low initiative; you steer.
-- **artisan** — peer with toolsmith reflexes, terminal-first.
-
-Pick **peer** unless you know you want another register. Posture is orthogonal to theme: theme changes the prose, posture changes the relationship.
-
-### Mode — how work gets executed
-
-How the session runs the work you hand it, fixed at build time:
-
-- **direct** *(default)* — the agent works every task itself, turn by turn, exactly as it does today.
-- **foreman** — the session triages incoming tasks: trivial ones get a direct answer, substantial ones spawn an isolated crew (analyst → developer → tester) that reports back and merges only once its tests and lint pass — while the session keeps answering you. Costs more per substantial task (a small crew runs instead of one agent) in exchange for staying responsive.
-
-Pick **direct** unless you want the session managing a crew for you. Switch back any time with `--mode direct`.
-
-### Doctrine packs — which practices bind
-
-Which practice rules this install adopts, fixed at build time. Unlike the dials above this one really does change *which rules apply*: the [Ethos and the Rules](#/docs/rules) are always on, the doctrines are yours to pick. All four ship enabled, and leaving one out is a deliberate choice, not a default:
-
-- **craft** — how code is written: reuse first, house conventions, docs in step, the smallest diff.
-- **rigor** — how work is proven: idempotence, honest tests, coverage, gates that can actually fail.
-- **ops** — how the machine is driven: tool discovery, commands that return, complete teardowns.
-- **process** — how a session runs: planning, context economy, docs first, and the **consent gate on every commit and push**.
-
-Turning **process 5** off takes that consent gate with it, at the tool boundary as well as in the prose: the OpenCode permission block and the Claude/Bob `PreToolUse` hook that ask before a commit or a push are wired only when that rule is built in, because a boundary that keeps asking for a rule the install never adopted is a gate arguing with its own harness. The invariant-territory refusals — `rm -rf`, a force-push — stay in every build; they are the Rules' territory, not the pack's.
-
-A pack you leave out still ships in the bundle under `doctrines/`, so you can read it before turning it on, and a rule that cites it still resolves. Change the set with `geneseed-build --doctrines craft,rigor` (or `--doctrines none`), or in `harness.config.json`.
-
-### One rule at a time
-
-The pack is the coarse axis. `--exclude-rules` is the fine one, and it takes rule addresses — so *keep all of process, drop just `process 7`* is expressible:
-
-    geneseed-build --exclude-rules "process 7"
-    geneseed-build --exclude-rules "process 5,craft 2"
-    geneseed-build --exclude-rules none
-
-Either spelling of an address works, `process 7` or `process.7`. The two axes compose: a pack whose every rule is excluded leaves `Active packs:` entirely, so no pack header is ever rendered with nothing under it. An install records its exclusions in a second marker line — `Excluded rules: process 7` — written only when something *is* excluded, and every rebuild path reads it back and preserves it.
-
-The switches are on the **Constitution** page, one per rule, staged locally and applied in a single rebuild.
-
-### Footprint — how much of the constitution loads inline
-
-How much of the constitution `AGENT.md` carries inline every turn. A token-cost dial, not a rules cut — whatever this install adopted always applies:
-
-- **lean** *(default)* — the Ethos, each Rule and each doctrine rule in an authored short form — the rule and its mechanism, hand-written beside the full text — with a pointer to the complete text shipped beside `AGENT.md` and read on demand.
-- **full** — every Rule's and every active doctrine rule's complete text *and* rationale inline. Best when token cost is a non-issue or you run a smaller model, which applies a rule's nuance more reliably with the *why* eagerly in context.
-
----
-
-**Deeper:** [The constitution](#/docs/rules) · [The collaboration layer](#/docs/collaboration) · [Footprint (lean vs full)](#/docs/footprint) · **Next:** [Verify it works](#/docs/verify)

package/docs/web/skills.md

@@ -1,8 +0,0 @@
----
-group: concepts
-order: 3
-title: "Skills"
-kind: "concept"
-link: {"hash": "#/section/skills", "label": "Browse the catalog →"}
----
-{N_SKILLS} repeatable workflows the agent can invoke by name — from [[brainstorm]], [[plan]], [[develop]] and [[debug]] through [[council]], [[research]] and [[ship]] to [[roast-me]]. A skill is a markdown playbook under `src/skills/`; the agent reads it before acting. The catalog link lists every one, live.

package/docs/web/themes-author.md

@@ -1,20 +0,0 @@
----
-group: extend
-order: 1
-title: "Write a new theme"
-kind: "concept"
-link: {"hash": "#/harness", "label": "Open the voice gallery →"}
----
-A theme is one JSON file under `themes/` declaring voice tokens only: `BANNER`, `TAGLINE`, `LOADED_SIGIL`, `VOICE`, the core nouns (`ONTOLOGY`/`LAW(S)`/`DOCTRINE(S)`/`AGENT(S)`/`SKILL(S)`/`MEMORY`/`NOTEBOOK`/`WIKI`), the section intros `INTRO_*`, the epigraphs `EPI_*`, the `BENEDICTION`, the `ROAST_PERSONA`, and `DESC_*` blurbs. Copy `themes/neutral.json` and edit. `geneseed build --theme yours` renders it; `doctor` checks for missing tokens.
-
-### The constitution's titles
-
-Every rule in the constitution gets its title from a theme key, and a theme that omits one ships a rule with a blank heading:
-
-- `LEX_<ID>` — one title per invariant, keyed by the law's permanent id (`LEX_VERIFY_BEFORE_ASSERTING`), never by its number. `doctor` holds this to an **equality**, not mere presence: a `LEX_*` no law declares is a title for a rule that does not exist and fails the check too.
-- `DOC_<ID>` — one title per doctrine rule, keyed by its id (`DOC_AUTOMATE_REPETITION`, `DOC_CONSENT_BEFORE_PUSH`, …). `doctor` reads the pack files under `src/doctrines/` and requires exactly the set they declare — a missing one is a blank heading, an extra one is a dead key. A title is the rule's heading only: a citation of the rule renders as its English principle name in every voice.
-- `PACK_*` — one name per pack (`PACK_CRAFT`, `PACK_RIGOR`, `PACK_OPS`, `PACK_PROCESS`, `PACK_COMMS`), used for the pack's own sub-heading.
-
-The Ethos section names are **not** theme keys: a citation reads `({{ONTOLOGY}}: {{ONT_TELOS}})`, token on both sides, so heading and reference always move together. They live in the build's fixed structure table and you neither declare nor rename them.
-
-> ⚠ `LAW` and `DOCTRINE` must each be a **single word**. Both heading parsers match the tier noun with `\S+`, so a two-word value does not error — the heading simply stops matching and the whole tier parses to nothing, in silence. `doctor` gates this for every real voice (`_TEMPLATE.json` is exempt; its values are placeholders).

package/docs/web/themes.md

@@ -1,9 +0,0 @@
----
-group: concepts
-order: 7
-title: "Voice vs structure (themes)"
-kind: "markdown"
-anchor: "decisions"
-source: "DESIGN.md"
-slice: true
----

package/docs/web/token-footprint.md

@@ -1,7 +0,0 @@
----
-group: deeper
-order: 5
-title: "Token footprint"
-kind: "markdown"
-source: "docs/token-footprint.md"
----

package/docs/web/trouble.md

@@ -1,38 +0,0 @@
----
-group: reference
-order: 3
-title: "Troubleshooting"
-kind: "concept"
----
-MCP server issues have their own page: [MCP — won't connect?](#/docs/mcp-trouble).
-
-### `geneseed: command not found`
-Run `./geneseed link` (macOS/Linux) or `.\geneseed.cmd link` (Windows) from the cloned repo. On Windows, open a new terminal after `link` — the PATH update only applies to fresh shells.
-
-<!--harness:opencode-->
-### The agent doesn't load my project docs
-On OpenCode the `geneseed-context` plugin must be installed. Re-run `geneseed setup` or `geneseed build --emit opencode-global`. Verify with `geneseed doctor`.
-<!--/harness-->
-
-### `doctor` reports unresolved theme tokens
-A theme JSON is missing a key the templates reference. Compare with `themes/neutral.json` — every key there must exist in your theme. Re-render: `geneseed build --theme <yours>`.
-
-### `doctor` reports drift between bundle and src
-A committed `Harness/` snapshot fell behind. Re-render and commit: `geneseed build && git add Harness`. If the drift is intentional local edits, use the **Changes** page to export them as an improvements file and back-port.
-
-### Web UI shows 'no deployed harness'
-Run `geneseed setup` to install. The UI works read-only without a deployment but most actions are disabled.
-
-### Windows PATH didn't update
-`geneseed.cmd link` writes to `%LOCALAPPDATA%\Geneseed\bin` and adds it to user PATH — but only new shells see it. Close and reopen your terminal.
-
-<!--harness:opencode-->
-### Plugin not registering on OpenCode
-Plugins ship in `~/.config/opencode/plugin/` for the global emit. Confirm with `ls ~/.config/opencode/plugin/` — you should see `geneseed-*.js`. If empty, re-run the build with `--emit opencode-global`.
-
-### Full `PROJECT CONTEXT` block visible in the terminal
-Either `GENESEED_CONTEXT_VISIBLE=1` (or legacy `GENESEED_CONTEXT_TRANSFORM=0/off`) is set, or your OpenCode build lacks the experimental transform hook and the plugin fell back to visible delivery — run with `GENESEED_DEBUG=1` to see which.
-<!--/harness-->
-
-### `could not determine a model`
-Set `GENESEED_MODEL=provider/model` in your environment.

package/docs/web/upgrade.md

@@ -1,9 +0,0 @@
----
-group: howto
-order: 7
-title: "Upgrade & local edits"
-kind: "markdown"
-anchor: "upgrade"
-source: "SETUP.md"
-slice: true
----

package/docs/web/verify.md

@@ -1,30 +0,0 @@
----
-group: start
-order: 2
-title: "Verify it works"
-kind: "concept"
----
-Three quick checks confirm everything wired up.
-
-### 1. The readiness sigil
-
-Open your agent in any repo. The first reply opens with the readiness line — `✅` for neutral, `🧬` for imperial, or your theme's equivalent. If it's missing, the agent isn't pointed at `AGENT.md` — re-check your tool's instructions setting.
-
-### 2. The harness itself
-
-```
-./geneseed doctor       # macOS / Linux
-.\geneseed.cmd doctor   # Windows
-```
-
-Should print `ok`. Failures include unresolved theme tokens, dead links, missing files, or a drifted bundle — each comes with a fix hint. Press the **Run doctor** button above to run it from here.
-
-<!--harness:opencode-->
-### 3. Context delivery
-
-Start a session with `GENESEED_DEBUG=1` set. The context plugin logs what it discovered and injected; you should see the repo's `README.md` and any docs listed.
-<!--/harness-->
-
----
-
-Trouble? See [Troubleshooting](#/docs/trouble).

package/docs/web/wiki.md

@@ -1,7 +0,0 @@
----
-group: concepts
-order: 6
-title: "Wiki (machine knowledge base)"
-kind: "markdown"
-source: "docs/wiki.md"
----

package/docs/web/worktree.md

@@ -1,10 +0,0 @@
----
-group: howto
-order: 4
-title: "Add git-worktree isolation (OpenCode)"
-kind: "markdown"
-harness: "opencode"
-anchor: "optional-add-on-git-worktree-isolation-third-party-not-vendored"
-source: "adapters/opencode/README.md"
-slice: true
----

package/docs/wiki.md

@@ -1,43 +0,0 @@
-# Wiki — your machine's knowledge base
-
-The **wiki** is *your* knowledge base — an Obsidian vault, or any folder of
-interlinked markdown — that the agent reads from and writes to as a citizen of
-your own structure. Unlike memory (private, one-fact-per-file, machine-local)
-and the notebook (the agent's sovereign scratch space), the wiki is durable,
-cross-project knowledge **you** own and curate. You declare it once per machine
-in `wiki.jsonc`; nothing about it is committed to a repo.
-
-## How it works
-
-Each wiki you declare gives the agent:
-
-- **entries** — notes that load each session (`eager`) or on demand (`lazy`),
-  the same semantics as project context. An entry can name a single note or a
-  whole folder (`"."` = the entire vault).
-- **conventions** — the note the agent must read before its first write, so new
-  notes match your naming, frontmatter, and folder rules.
-- **inbox** — where the agent drops a note it can't confidently file, instead of
-  guessing.
-- **protected** folders — write-blocked at the tool boundary by the guard plugin.
-
-## What the agent does with it
-
-**Reading.** It starts from your entry notes and navigates by your structure —
-following `[[wikilinks]]` and index notes outward — rather than reading the vault
-wholesale. What it reads is treated as your knowledge, current as of when it was
-written, and verified against the live system before being built on.
-
-**Writing.** Durable, reusable, cross-project facts get written back as proper
-citizens of the graph: wikilinked, in your house style, filed where your
-structure says they belong (or the inbox). Session detail stays in memory;
-secrets are never written anywhere. It never restructures the vault or touches
-`protected` folders — moving and renaming your notes is your call.
-
-When a memory fact or notebook note hardens into knowledge worth keeping across
-projects, the agent promotes it into the wiki so there's one home for the truth.
-
-## Set it up
-
-The `wiki` skill drives the read/write procedure. To declare a vault, see the
-**Wiki — your own knowledge base** section of `SETUP.md` for the `wiki.jsonc`
-shape and resolution order. An empty `wikis` list keeps the feature off.