@agimon-ai/doompi 0.0.1-alpha.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Vuong Ngo
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,546 @@
+# Doompi
+
+**A coding agent that loads only the skills and tools you name.**
+
+Plugin systems scope what an agent knows. Nothing scopes what it can reach. Claude Code
+gives you `enableAllProjectMcpServers` and a static denylist, both repository-wide, so
+every session pays for every MCP server's tool schemas whether the task is a database
+migration or a landing page.
+
+Doompi makes both a declared input. Three YAML files decide what a session loads, and
+`--explain` prints the bill before you launch.
+
+## Install
+
+```bash
+npm install -g @agimon-ai/doompi @earendil-works/pi-coding-agent
+```
+
+## Quickstart
+
+```bash
+doompi init                                  # seed ~/.pi/.doom, once per machine
+mkdir .doom && cp ~/.pi/.doom/*.yaml .doom/  # the repository config Doompi reads
+doompi --explain                             # what would load, and why
+doompi                                       # start a session
+```
+
+`.doom/` is committed to git, so a checkout carries its own agent configuration. Edit a
+YAML file and the next launch picks it up.
+
+```bash
+doompi --major-mode dev --domains development
+doompi --domains marketing --profile marketing
+doompi --domains analytics --explain
+```
+
+## The three axes
+
+Doompi wraps [Pi](https://www.npmjs.com/package/@earendil-works/pi-coding-agent) and
+resolves a declared configuration into a session rather than asking you to wire one up.
+The three choices are independent: adding a domain requires no knowledge of major modes,
+and swapping a profile changes nothing about either.
+
+| Choice         | Decides                              | Declared in           |
+| -------------- | ------------------------------------ | --------------------- |
+| **Major mode** | what the agent is wrapped in         | `.doom/modes.yaml`    |
+| **Domains**    | what it knows, and what it can reach | `.doom/domains.yaml`  |
+| **Profile**    | who it speaks as                     | `.doom/profiles.yaml` |
+
+A domain names plugins and an MCP allowlist together, so `--domains marketing` and
+`--domains development` are the same agent with different knowledge and a different reach,
+not two different agents. That is the lever for keeping context small, and
+[`--explain`](#minimal-context) prices it before you commit.
+
+## What is actually different
+
+**Compaction reads state, it does not summarize prose.** When the context fills, Doompi
+does not guess at coordination state from the transcript. It reads the live plan, task
+graph, and team snapshot, and commits them next to the summary as authoritative. The agent
+comes out the other side knowing what it was doing, what is still running, and who is doing
+what. See [Long runs](#long-runs).
+
+**Spec-driven and meta-prompting systems change what the agent is told. Doompi changes what
+it loads.** The two compose fine. This one is about the context window, not the prompt.
+
+**One configuration serves two readers.** A human gets a keyboard surface that does not
+move; an autonomous agent gets a small tool surface and a context window that compacts
+itself.
+
+## Philosophy
+
+**Give the agent fewer things to choose between.** [Major modes, domains, and
+profiles](#major-modes-domains-profiles) decide what loads, so a session carries the skills
+and MCP servers its domains named and nothing else. Whatever still overflows [compacts in
+the background](#long-runs).
+
+**Shift the work onto deterministic workflows.** Autonomous runs are [GitHub Actions
+shaped](#workflows), with jobs, dependencies, steps, timeouts, and declared artifacts, so
+the same job resolves the same way every time.
+
+**Keep the keyboard ergonomic.** `SPC` is the whole surface, Spacemacs and Doom Emacs
+style, and [it opens only when the draft is empty](#leader-space), so a half-written prompt
+is never a casualty.
+
+**Batteries included, without the bloat.** Plan mode, tasks, teams, a supervised runner,
+voice, and workflows ship in the box, but [core is not a
+layer](#core-is-not-a-layer) and every opinion waits behind a layer or a domain.
+
+**One major mode, several minor modes.** A session runs under exactly one major mode, which
+is what selects its layers. [Plan, loop, and workflow](#minor-modes) are minor modes: you
+toggle them mid-session, they stack, and they report themselves on a shared status line.
+
+## Two ways to run
+
+The launcher resolves your three choices per run and spawns Pi with them. Skills, agents,
+MCP configs, and the persona prompt are assembled into a temporary directory that is
+deleted on exit. Nothing is written back into the repository, and every session pays the
+resolution cost.
+
+`doompi sync` is the other way in, and the Doom Emacs one. Resolve once, write the
+result where Pi looks, then run `pi` yourself.
+
+```bash
+doompi init          # seed ~/.pi/.doom, once per machine
+doompi sync          # resolve the selection into .pi/
+pi                   # the agent
+
+doompi sync --check  # exit non-zero when the synced config is out of date
+```
+
+A synced session takes `--major-mode`, `--domains`, `--profile`, and `--mute` the same way
+the launcher does, and `/major-mode`, `/domains`, and `/profile` all switch in place: the
+extension set is composed on every load rather than frozen at startup, so a reload is
+enough.
+
+Both paths compose the extension set from the same function, `assembleExtensions`, which
+owns load order. Two things differ. A synced session forces `--auto-stop` off, and it
+reads mute from `DOOMPI_MUTE` instead of an argument.
+
+Syncing does not disturb the launcher. Pi merges the extensions a project declares with
+the ones passed on the command line, so the synced entry stands down whenever it sees the
+composed set already there, which is what the launcher and every detached subagent pass.
+
+## For humans
+
+### Leader Space
+
+`@agimon-ai/doompi-ui` owns the leader state machine, rendering, conflict handling, and the
+core bindings.
+
+Space opens the leader **only when the draft is empty**. With text in the editor, space is
+a space. `ctrl+space` opens the leader either way, and the draft survives the sequence, so
+you never lose a half-written prompt to a keystroke. That is the space the human keeps.
+
+Inside a sequence: `escape` cancels, `backspace` pops one segment, and any key that
+matches nothing cancels. There is no partial state to get stuck in.
+
+Core groups. Every level of the map renders in leader-key alphabetical order, so the table
+below is the order you see:
+
+| Key | Group     | Bindings                                 |
+| --- | --------- | ---------------------------------------- |
+| `e` | extension | `e` external editor, `t` tools browser   |
+| `h` | help      | `h` hotkeys, `l` log metrics             |
+| `m` | models    | `m` select, `n` next, `t` thinking level |
+| `q` | quit      | `q` exit                                 |
+| `s` | sessions  | `f` fork, `n` new, `r` resume, `t` tree  |
+
+`t` is deliberately left out of core at the root and reserved for doom-task.
+
+Optional feature extensions own the bindings for their own commands. The UI never
+hardcodes a binding for a layer that may not be loaded, so a group appears only while its
+extension is loaded:
+
+| Chord                | Source                        | Opens                          |
+| -------------------- | ----------------------------- | ------------------------------ |
+| `SPC a`              | `@agimon-ai/doompi-team`      | subagent fleet                 |
+| `SPC h l`            | `@agimon-ai/doompi-log`       | log metrics                    |
+| `SPC l s`, `SPC l l` | `@agimon-ai/doompi-loop`      | start loops, list/stop loops   |
+| `SPC p p/c/d/f`      | `@agimon-ai/doompi-plan`      | plan normal/cancel/debug/fable |
+| `SPC t t`            | `@agimon-ai/doompi-task`      | tasks                          |
+| `SPC r r`            | `@agimon-ai/doompi-runner`    | background processes           |
+| `SPC v v`            | `@agimon-ai/doompi-voice`     | record or transcribe           |
+| `SPC w w/l/r`        | `@agimon-ai/doompi-workflow`  | launch/manage/recover          |
+| `SPC e f`            | `@agimon-ai/doompi-file-edit` | session edits                  |
+| `SPC e s`            | `@agimon-ai/doompi`           | skills catalog                 |
+| `SPC e c`            | `@agimon-ai/doompi-ui`        | config panel (core binding)    |
+
+Contributions go through the public `@agimon-ai/doompi-ui/leader` API:
+
+```ts
+registerDoomLeaderContribution(pi, {
+  source: '@agimon-ai/doompi-log',
+  bindings: [
+    {
+      id: 'log.metrics',
+      path: [
+        { key: 'h', label: 'help', order: 70 },
+        { key: 'l', label: 'logs', detail: 'telemetry' },
+      ],
+      command: { name: 'log-metrics' },
+    },
+  ],
+});
+```
+
+A path excludes the leading `SPC`. The UI turns this into `SPC h l`, dispatches
+`/log-metrics` through the normal editor submission path, and preserves the draft. A
+binding carries either a `command` descriptor or an `action` name, never both. Commands
+stay owned by the extension that registered the slash command; actions route back to the
+contributor through `registerDoomLeaderActionHandlers`, which is what doom-plan uses.
+
+The map is deterministic because the registry is strict:
+
+- Keys are a single lowercase alphanumeric character, paths are at most four segments.
+- Shared group prefixes must agree on label, detail, and order, or the contribution is
+  rejected.
+- Exact chord conflicts are rejected rather than silently overridden. A conflict in a core
+  binding throws; a conflict from a contributor produces a diagnostic and a warning.
+- Re-registering the same `source` replaces that source's complete binding set. Registering
+  an empty set removes it.
+- Rebuilds sort by source name then binding id, so load order does not affect the result.
+- Options render in leader-key alphabetical order at every level. A segment's `order` is
+  group identity that shared prefixes must agree on, not a display position.
+
+Registration runs over Pi's shared extension event bus with a 250 ms timeout. A timeout is
+swallowed, so an extension loaded without the UI degrades quietly instead of failing.
+
+### Major modes, domains, profiles
+
+Three choices, three files, committed to git. They are independent. Adding a domain
+requires no knowledge of major modes, and swapping a profile changes nothing about either.
+
+| Choice          | Loads                                 | Declared in           |
+| --------------- | ------------------------------------- | --------------------- |
+| **Major modes** | a named set of layers                 | `.doom/modes.yaml`    |
+| **Domains**     | plugins, meaning skills and MCP       | `.doom/domains.yaml`  |
+| **Profiles**    | a persona and the brand it speaks for | `.doom/profiles.yaml` |
+
+**Layers are protection and steering.** A layer is a set of Pi extensions plus a set of
+hook groups. The extensions add behavior the agent runs with; the hooks fire around its
+tool calls and can block it, warn it, or steer it back. You define the set you want, along
+the lines of `guardrails`, `lint`, `code-intel`, `team`, `plan-mode`, `runner`, and
+`ask-user`. The hooks themselves live in `.doom/hooks.yaml`, one registry shared by every
+frontend, where a group is either `core` and always loads, or is pulled in by whichever
+layer wants it.
+
+**A major mode is the one you actually pick.** You do not assemble layers one by one at the
+prompt. You select one named major mode with `--major-mode <name>`, and
+`.doom/modes.yaml` says which layers it contains. A session has exactly one, the way
+an Emacs buffer has exactly one major mode.
+
+The flag is `--major-mode` and not `--mode` because Pi already owns `--mode` for its output
+mode (`text`, `json`, `rpc`), and for any other value it consumes the argument and ignores
+it without a diagnostic. Use `--output-format` for Pi's output mode.
+
+**Domains are plugins, and a plugin is skills plus MCP.** Selecting a domain decides which
+plugins contribute their skills and subagents, which MCP servers the session can reach,
+and whether the always-on shared skills apply. A domain can take a whole plugin or a named
+subset of one. This is the choice that decides how much the agent can see, so it is also
+the lever for keeping context small.
+
+**Profiles are a persona and a brand.** `.doom/profiles.yaml` points at a directory under
+`agents/<brand>/<person>/`, and doom concatenates that person's `profile.md`, `SOUL.md`,
+and `AGENTS.md` into the system prompt: identity and the brand it represents, then voice,
+then role and rules. A profile also carries environment defaults, and nothing else. It
+cannot select domains, major modes, models, presets, or policy, and an exported value
+always beats a profile default.
+
+Switching is live. `/major-mode`, `/domains`, and `/profile` re-resolve into the running
+session and reload. A domain or profile switch always applies in place. A major mode switch
+applies in place too unless the new mode changes which extension packages load, since Pi
+freezes the `--extension` set at construction; the picker tells you when a relaunch is
+needed.
+
+### Minor modes
+
+A major mode is chosen once per session and selects layers. Minor modes are the opposite:
+you toggle them while the session runs, several can be on at once, and none of them changes
+which extensions are loaded.
+
+| Minor mode | Toggle               | Owned by                     |
+| ---------- | -------------------- | ---------------------------- |
+| plan       | `/plan`, `SPC p`     | `@agimon-ai/doompi-plan`     |
+| loop       | `/loop`, `SPC l`     | `@agimon-ai/doompi-loop`     |
+| workflow   | `/workflow`, `SPC w` | `@agimon-ai/doompi-workflow` |
+
+Each one publishes a label to a shared `MODES` line rather than painting a row of its own,
+so three enabled modes cost one line rather than three. The registry is
+`@agimon-ai/doompi-extension-contracts/mode`.
+
+## For autonomous agents
+
+### Minimal context
+
+Fewer options, better choices. Domains cut the skill list and the tool list together. A
+domain that names three plugins gives the agent those plugins' skills and nothing else,
+and one with an `mcp` allowlist reaches only the servers and proxy upstreams it names.
+
+`--explain` prints what any combination costs before you launch it, and ends with the bill:
+
+```
+$ doompi --domains development --explain
+...
+skills: 24 (from 3 directories)
+
+context cost (tokens)
+  skills prompt       3,772  always on
+  persona                 0  always on
+  startup total       3,772
+  skill bodies       54,145  read on demand
+
+  Excludes MCP tool schemas, which the servers only report once connected,
+  and skills contributed by extensions, which register after startup.
+```
+
+Every figure comes from files on disk, so two runs of the same selection print the same
+numbers and you can reproduce them on your own repository rather than trusting these.
+
+MCP tool schemas are the one cost this cannot price. They exist only after a server
+connects, and pricing them would mean spawning every configured server on a command meant
+to be instant. Scoping them is still a declared choice; the saving is just not counted here.
+
+A domain without an `mcp` key admits everything, and one unscoped domain in the selection
+unfilters the rest. Scoping applies only when every selected domain declares it.
+
+A domain can also take a named subset of one plugin's skills, by name or glob.
+
+### Workflows
+
+Long autonomous work runs as workflows, in the shape a GitHub Actions user already knows:
+`on:`, `jobs:`, `needs:`, `steps:`, timeouts, and declared artifacts.
+
+The payoff is that every step names the session it wants. A workflow is where
+`--major-mode`, `--domains`, and `--profile` stop being things you type and become part of
+the definition, so one run can hand each job exactly the context that job needs and nothing
+else:
+
+```yaml
+jobs:
+  implement:
+    needs: intake
+    steps:
+      - name: Implement
+        timeout-minutes: 180
+        artifacts: [implementation/report.md]
+        interactiveRun:
+          default: |
+            doompi --major-mode dev --domains development --auto-stop \
+              --cwd "$PWD" "$JOB_SYSTEM_PROMPT"
+
+  announce:
+    needs: implement
+    steps:
+      - name: Draft the release note
+        timeout-minutes: 30
+        artifacts: [marketing/release-note.md]
+        interactiveRun:
+          default: |
+            doompi --major-mode marketing --domains marketing \
+              --profile brand-voice --auto-stop \
+              --cwd "$PWD" "$JOB_SYSTEM_PROMPT"
+```
+
+Two jobs, two different agents. `implement` runs under a major mode carrying lint and code
+intelligence and a domain carrying coding skills. `announce` drops both, takes a domain
+scoped to a handful of MCP servers, and adds a profile, so the release note comes out in a
+named persona's voice rather than the agent's own. Neither job can drift into the other's
+context, and the same job resolves the same way on every run.
+
+The one real departure from GitHub Actions is `extends:`, which lets a job inherit shared
+setup from a named template rather than repeating it.
+
+The engine itself is not in this package. `@agimon-ai/doompi-workflow` provides the in-session
+surface on `SPC w`, and its dispatcher exposes `list_workflows` to any session but scopes
+`launch_workflow` to the root session, so a subagent can look but not spawn. The `workflow`
+hook group is `core`, so it loads in any major mode.
+
+### Long runs
+
+Tasks, teams, runners, and compaction share one working state, so a long autonomous run
+does not lose its place.
+
+- **Tasks** (`SPC t`) are a file-backed graph with dependencies and delegation, not a
+  scratch list.
+- **Teams** (`SPC a`) run named subagents asynchronously against that same board,
+  sequentially or in parallel.
+- **Runners** (`SPC r`) replace the bash tool and detach long commands, then reconcile
+  them afterwards.
+- **Compaction** runs on a three-pass ladder in a worker thread, so the session never
+  blocks on it.
+
+The integration is the point. When compaction summarizes, it does not guess at
+coordination state: it reads the live plan, tasks, and team snapshot, and commits them
+next to the summary as authoritative rather than leaving them to be reconstructed from
+prose. Detached runners reconcile themselves once the context has been rewritten. The
+agent comes out the other side knowing what it was doing, what is still running, and who
+is doing what.
+
+## Core is not a layer
+
+Telemetry, workflow orchestration, the dispatch loop, and editor plumbing ship
+unconditionally and are absent from `modes.yaml` on purpose. They are the reason the
+harness exists, so making them optional would only create broken configurations. Layers
+are for opinions, not foundations.
+
+## Who owns what
+
+Doom Pi is a meta-package. It depends on the Doom closure (`@agimon-ai/doompi-*`) and composes
+it, and it depends on nothing that belongs to the repository consuming it. The Agiflow and
+Agent Hooks extensions are consumer-owned: the repository declares them in its own
+`.doom/modes.yaml` and installs them itself, and they load after the Doom packages.
+
+That split decides where a specifier resolves. A package the repository declares resolves
+from the repository root, walking its module chain; anything that does not resolve there
+falls back to what ships with the installed meta-package. So a consumer can add a layer
+without Doom Pi knowing the package exists, and Doom Pi can ship its own closure without
+the consumer declaring it.
+
+Package resources follow the same rule: the UI theme is shipped by `@agimon-ai/doompi-ui`
+and the workflow-recovery skill by `@agimon-ai/doompi-workflow`, each declared in its own
+manifest, so an installed package is discoverable without this checkout. Every Doom package
+publishes through an explicit `files` allowlist, which keeps repository material such as
+`docs/ideas/` out of any tarball.
+
+A repository is recognised by a Doom or trusted Pi marker: a `.doom/` directory, or an
+existing `.pi/settings.json`. No Nx, pnpm workspace, or plugins profile is required, so a
+plain repository that installs the package can launch it.
+
+## Lazy config
+
+Under the launcher, everything is resolved per run and nothing is written back into the
+repository. Editing a YAML file is the entire change.
+
+`doompi sync` trades that for a pinned setup: the same resolution runs once and lands in
+`.pi/doom/`, and a Pi session reads it instead of recomputing it. Edit a YAML file and the
+next session says the config changed, the way doom emacs asks you to re-run `doom sync`.
+
+`doompi init` seeds `~/.pi/.doom` with all five file names, but only `config.yaml` from
+there is read at runtime. Major modes, domains, profiles, and hooks are always read from the
+repository `.doom/`, so the other four seeded files affect nothing beyond the inputs hash.
+
+Either way the hook registry compiles to the files other frontends read before any harness
+code runs, and `doompi sync` regenerates them.
+
+## Other frontends
+
+Pi is the primary frontend. Claude Code, Codex, and Antigravity run through
+`doompi compat <provider>` and share the same domain config as far as each can:
+
+|                     | Pi                | Claude Code                   | Codex                    | Antigravity         |
+| ------------------- | ----------------- | ----------------------------- | ------------------------ | ------------------- |
+| domains to plugins  | yes               | yes                           | yes                      | yes                 |
+| hooks               | from the registry | generated `settings.json`     | generated `hooks.json`   | copied `hooks.json` |
+| MCP servers         | scoped            | scoped                        | unscoped                 | scoped              |
+| MCP proxy upstreams | scoped            | scoped                        | scoped                   | scoped              |
+| major mode          | packages + hooks  | shared hook groups            | shared hook groups       | shared hook groups  |
+| personas            | system prompt     | `--append-system-prompt-file` | `developer_instructions` | no                  |
+
+Compatibility frontends use the selected major mode for shared hook state. Layer packages
+and Pi extensions are loaded only by Pi.
+
+Antigravity is the odd one. It reads its configuration from the workspace and from the
+user's home directory rather than from arguments, so every selection is written to disk
+before launch and reverted when it is no longer selected. Everything the harness writes is
+tracked in a managed-state file, so a file you created by hand is never silently replaced.
+Its hooks are copied from `.antigravity-local/hooks.json`, which is maintained by hand
+rather than generated from the registry.
+
+Where a concept has no equivalent, it is left out rather than approximated.
+
+## Files
+
+All Doompi configuration lives in `.doom/`, committed to git.
+
+```
+.doom/
+  config.yaml               projectTrust, plus the selection sync pins
+  domains.yaml              domains, plus aliases for shorthand bundles
+  modes.yaml          layer definitions and the named major modes built from them
+  hooks.yaml                canonical hooks for all three frontends
+  profiles.yaml             persona and environment profiles
+
+agents/<product>/<person>/  persona source, referenced never copied
+```
+
+`doompi sync` writes into `.pi/`:
+
+```
+.pi/settings.json           committed; sync owns extensions, themes, and theme
+.pi/doom/                   generated and gitignored
+  state.json                environment, resolved paths, and the inputs hash
+  mcp.json  mcp-extension.ts  agents/  persona.md  doom-pi-dark.json
+  run/<pid>/                one session's live switches, never the baseline
+    harness-state.json      that session's own state, owned by its process
+```
+
+### One owner for the state
+
+The resolved matrix a session runs on is a file, not a set of variables.
+`DOOMPI_STATE` points at it, and everything else the harness exports is derived from
+it: a projection published for the readers that can only see an environment, which are bash
+hooks, the shell launchers, `agent-hooks`, and any process spawned by any of them. Two
+fields never appear there at all, because nothing outside `@agimon-ai/doompi-config` reads
+them and every hook spawn would otherwise copy them: the plugin hook list and the profile's
+environment defaults.
+
+Ownership is per process, and that is the point. Doom Team subagents run detached, from an
+environment snapshot, and can outlive the parent that spawned them. So a spawner writes the
+child a file of its own in that run's directory, and any process that finds a file it does
+not own copies it before its first write. A child can neither corrupt its parent's session
+nor lose its own when the parent cleans up.
+
+It also regenerates the two hook files the other frontends read before any harness code
+runs, which live outside `.pi/`:
+
+```
+.claude/settings.json       the "hooks" key only; every other key is preserved
+.codex-local/hooks.json     the whole file
+```
+
+Edit `hooks.yaml` and re-run `doompi sync` to regenerate both.
+
+## Selection
+
+Use singular `--profile <name>` for one persona and its environment defaults. Use
+`--domains <name[,name...]>` for plugin bundles. Both `--major-mode` and `--profile` take
+exactly one name, reject a comma, and can be given only once. The removed `--layer`,
+`--layers`, `--profiles`, and `--target` flags throw and point at the replacement, and so
+does the removed `DOOMPI_LAYER` variable: a stale export is worth an error rather than a
+session quietly starting on the default.
+
+Defaults when you name nothing: major mode `copilot`, domains `default`. The `marketing`
+major mode is the one exception and defaults to the `marketing` domain. That is the only
+place where one choice influences another.
+
+Environment equivalents are `DOOMPI_MAJOR_MODE`, `DOOMPI_DOMAINS`, and `DOOMPI_PROFILE`.
+`DOOMPI_PRESET` and `DOOMPI_ADDITIONAL_DIRS` work the same way for `--preset` and
+`--add-dir`. An empty `DOOMPI_DOMAINS` means no domains, not the default. No profile is
+selected unless one is named.
+
+There is one variable per axis. A nested run inherits its launcher's choice because the
+launcher writes the resolved value into the child environment under the same name, so
+anything you exported yourself is what a top-level run uses and what a spawned run
+overrides. These used to be two variables, `DOOM_PI_*` for the selection and
+`AGENT_HARNESS_*` for the resolved projection, with the second outranking the first. Any
+surviving `AGENT_HARNESS_*` variable now throws and names its replacement, because a stale
+export in a shell profile is worth an error.
+
+`DOOMPI_LAYERS`, plural, is a different variable from `DOOMPI_LAYER`. It carries the
+resolved layer components rather than the mode that selected them.
+
+A repository can declare what it selects by default, which is what a bare `doompi sync`
+pins. A flag still wins, then an exported variable, then this:
+
+```yaml
+# .doom/config.yaml
+selection:
+  majorMode: dev
+  domains: [development]
+  profile: house-voice
+```
+
+Pi asks once before it trusts a project and loads `.pi` resources, so a synced session
+prompts on first run regardless of `projectTrust`, which reaches Pi as a launcher flag.
+Answer yes, or run `/trust`.

package/dist/_virtual/_rolldown/runtime.cjs

@@ -0,0 +1 @@
+var e=Object.create,t=Object.defineProperty,n=Object.getOwnPropertyDescriptor,r=Object.getOwnPropertyNames,i=Object.getPrototypeOf,a=Object.prototype.hasOwnProperty,o=(e,i,o,s)=>{if(i&&typeof i==`object`||typeof i==`function`)for(var c=r(i),l=0,u=c.length,d;l<u;l++)d=c[l],!a.call(e,d)&&d!==o&&t(e,d,{get:(e=>i[e]).bind(null,d),enumerable:!(s=n(i,d))||s.enumerable});return e},s=(n,r,a)=>(a=n==null?{}:e(i(n)),o(r||!n||!n.__esModule?t(a,`default`,{value:n,enumerable:!0}):a,n));exports.__toESM=s;

package/dist/bin/cli.cjs

@@ -0,0 +1,3 @@
+#!/usr/bin/env node
+const e=require(`../cli/cliApp.cjs`);require(`../cli/index.cjs`),e.runCli(process.argv.slice(2)).then(e=>{process.exitCode=e},e=>{let t=e instanceof Error?e.message:String(e);process.stderr.write(`[doompi] ${t}\n`),process.exitCode=1});
+//# sourceMappingURL=cli.cjs.map

package/dist/bin/cli.cjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli.cjs","names":["runCli"],"sources":["../../src/bin/cli.ts"],"sourcesContent":["#!/usr/bin/env node\n\n/**\n * CLI Entry Point for doom-pi\n *\n * The executable installed as the `doom-pi` binary, and the file the repository\n * launchers (pi.sh, claude.sh, codex.sh) invoke directly from source.\n */\n\nimport { runCli } from '../cli/index.ts';\n\nrunCli(process.argv.slice(2)).then(\n  (exitCode) => {\n    process.exitCode = exitCode;\n  },\n  (error: unknown) => {\n    const message = error instanceof Error ? error.message : String(error);\n    process.stderr.write(`[doompi] ${message}\\n`);\n    process.exitCode = 1;\n  },\n);\n"],"mappings":";iEAWAA,EAAAA,OAAO,QAAQ,KAAK,MAAM,EAAE,CAAC,CAAC,KAC3B,GAAa,CACZ,QAAQ,SAAW,GAEpB,GAAmB,CAClB,IAAM,EAAU,aAAiB,MAAQ,EAAM,QAAU,OAAO,EAAM,CACtE,QAAQ,OAAO,MAAM,YAAY,EAAQ,IAAI,CAC7C,QAAQ,SAAW,GAEtB"}

package/dist/bin/cli.d.cts

@@ -0,0 +1 @@
+export { };

package/dist/bin/cli.d.mts

@@ -0,0 +1 @@
+export { };

package/dist/bin/cli.mjs

@@ -0,0 +1,3 @@
+#!/usr/bin/env node
+import{runCli as e}from"../cli/cliApp.mjs";import"../cli/index.mjs";e(process.argv.slice(2)).then(e=>{process.exitCode=e},e=>{let t=e instanceof Error?e.message:String(e);process.stderr.write(`[doompi] ${t}\n`),process.exitCode=1});export{};
+//# sourceMappingURL=cli.mjs.map

package/dist/bin/cli.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli.mjs","names":[],"sources":["../../src/bin/cli.ts"],"sourcesContent":["#!/usr/bin/env node\n\n/**\n * CLI Entry Point for doom-pi\n *\n * The executable installed as the `doom-pi` binary, and the file the repository\n * launchers (pi.sh, claude.sh, codex.sh) invoke directly from source.\n */\n\nimport { runCli } from '../cli/index.ts';\n\nrunCli(process.argv.slice(2)).then(\n  (exitCode) => {\n    process.exitCode = exitCode;\n  },\n  (error: unknown) => {\n    const message = error instanceof Error ? error.message : String(error);\n    process.stderr.write(`[doompi] ${message}\\n`);\n    process.exitCode = 1;\n  },\n);\n"],"mappings":";oEAWA,EAAO,QAAQ,KAAK,MAAM,EAAE,CAAC,CAAC,KAC3B,GAAa,CACZ,QAAQ,SAAW,GAEpB,GAAmB,CAClB,IAAM,EAAU,aAAiB,MAAQ,EAAM,QAAU,OAAO,EAAM,CACtE,QAAQ,OAAO,MAAM,YAAY,EAAQ,IAAI,CAC7C,QAAQ,SAAW,GAEtB"}

package/dist/bin/doomRunner.cjs

@@ -0,0 +1,3 @@
+#!/usr/bin/env node
+require(`../_virtual/_rolldown/runtime.cjs`),(0,require(`@agimon-ai/doompi-runner/bin/cli`).main)(process.argv.slice(2)).then(e=>{process.exitCode=e},e=>{let t=e instanceof Error?e.message:String(e);process.stderr.write(`[doom-runner] ${t}\n`),process.exitCode=1});
+//# sourceMappingURL=doomRunner.cjs.map

package/dist/bin/doomRunner.cjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"doomRunner.cjs","names":[],"sources":["../../src/bin/doomRunner.ts"],"sourcesContent":["#!/usr/bin/env node\n\n/**\n * CLI Entry Point for doom-runner\n *\n * The `doom-runner` binary lives in @agimon-ai/doompi-runner, but npm only\n * links a package's own bins. Installing doompi would therefore leave\n * doom-runner off PATH even though doompi depends on it and the packaged\n * doom-runner skill tells agents to call it by name. Re-declaring the bin here\n * is what makes `npm i -g @agimon-ai/doompi` install both executables.\n *\n * The runner's own entry only self-invokes when it is argv[1], which it is not\n * once this shim is the entry point, so main() is called explicitly.\n */\n\nimport { main } from '@agimon-ai/doompi-runner/bin/cli';\n\nmain(process.argv.slice(2)).then(\n  (exitCode) => {\n    process.exitCode = exitCode;\n  },\n  (error: unknown) => {\n    const message = error instanceof Error ? error.message : String(error);\n    process.stderr.write(`[doom-runner] ${message}\\n`);\n    process.exitCode = 1;\n  },\n);\n"],"mappings":";kGAiBK,QAAQ,KAAK,MAAM,EAAE,CAAC,CAAC,KACzB,GAAa,CACZ,QAAQ,SAAW,GAEpB,GAAmB,CAClB,IAAM,EAAU,aAAiB,MAAQ,EAAM,QAAU,OAAO,EAAM,CACtE,QAAQ,OAAO,MAAM,iBAAiB,EAAQ,IAAI,CAClD,QAAQ,SAAW,GAEtB"}

package/dist/bin/doomRunner.d.cts

@@ -0,0 +1 @@
+export { };

package/dist/bin/doomRunner.d.mts

@@ -0,0 +1 @@
+export { };

package/dist/bin/doomRunner.mjs

@@ -0,0 +1,3 @@
+#!/usr/bin/env node
+import{main as e}from"@agimon-ai/doompi-runner/bin/cli";e(process.argv.slice(2)).then(e=>{process.exitCode=e},e=>{let t=e instanceof Error?e.message:String(e);process.stderr.write(`[doom-runner] ${t}\n`),process.exitCode=1});export{};
+//# sourceMappingURL=doomRunner.mjs.map

package/dist/bin/doomRunner.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"doomRunner.mjs","names":[],"sources":["../../src/bin/doomRunner.ts"],"sourcesContent":["#!/usr/bin/env node\n\n/**\n * CLI Entry Point for doom-runner\n *\n * The `doom-runner` binary lives in @agimon-ai/doompi-runner, but npm only\n * links a package's own bins. Installing doompi would therefore leave\n * doom-runner off PATH even though doompi depends on it and the packaged\n * doom-runner skill tells agents to call it by name. Re-declaring the bin here\n * is what makes `npm i -g @agimon-ai/doompi` install both executables.\n *\n * The runner's own entry only self-invokes when it is argv[1], which it is not\n * once this shim is the entry point, so main() is called explicitly.\n */\n\nimport { main } from '@agimon-ai/doompi-runner/bin/cli';\n\nmain(process.argv.slice(2)).then(\n  (exitCode) => {\n    process.exitCode = exitCode;\n  },\n  (error: unknown) => {\n    const message = error instanceof Error ? error.message : String(error);\n    process.stderr.write(`[doom-runner] ${message}\\n`);\n    process.exitCode = 1;\n  },\n);\n"],"mappings":";wDAiBA,EAAK,QAAQ,KAAK,MAAM,EAAE,CAAC,CAAC,KACzB,GAAa,CACZ,QAAQ,SAAW,GAEpB,GAAmB,CAClB,IAAM,EAAU,aAAiB,MAAQ,EAAM,QAAU,OAAO,EAAM,CACtE,QAAQ,OAAO,MAAM,iBAAiB,EAAQ,IAAI,CAClD,QAAQ,SAAW,GAEtB"}

package/dist/cli/cliApp.cjs

@@ -0,0 +1,2 @@
+Object.defineProperty(exports,Symbol.toStringTag,{value:`Module`});const e=require(`../_virtual/_rolldown/runtime.cjs`),t=require(`../logSinkTelemetry.cjs`),n=require(`../config/harnessState.cjs`);require(`../config/index.cjs`);const r=require(`../utils/repository.cjs`);require(`../utils/index.cjs`);const i=require(`../services/harnessContext.cjs`);require(`../services/index.cjs`);const a=require(`../commands/compatibilityCommand.cjs`),o=require(`../commands/emitMcpCommand.cjs`),s=require(`../commands/explainCommand.cjs`),c=require(`../commands/initCommand.cjs`),l=require(`../commands/launchCommand.cjs`),u=require(`./options.cjs`),d=require(`../commands/syncCommand.cjs`);require(`../commands/index.cjs`);const f=require(`./help.cjs`);let p=require(`node:path`);p=e.__toESM(p,1);var m=class{commands=[];compatibilityCommand;initCommand;syncCommand;telemetry;constructor(e=t.createHarnessTelemetry()){this.telemetry=e,this.compatibilityCommand=new a.CompatibilityCommand(e),this.initCommand=new c.InitCommand,this.syncCommand=new d.SyncCommand,this.initializeCommands()}initializeCommands(){this.commands.push(new o.EmitMcpCommand),this.commands.push(new s.ExplainCommand),this.commands.push(new l.LaunchCommand)}selectCommand(e){let t=this.commands.find(t=>t.matches(e));if(!t)throw Error(`No command matched the given options`);return t}async runHarness(e){return this.telemetry.runInSpan(`doom_pi.run`,{"harness.major_mode":e.majorMode,"harness.domain_count":e.domains.length,"harness.agents":e.agents,"harness.mcp":e.mcp,"harness.hooks":e.hooks,...e.profile?{"harness.profile":e.profile}:{},...e.preset?{"harness.preset":e.preset}:{}},async()=>{let n=await i.buildHarnessContext(e,this.telemetry),r=this.selectCommand(n.options);try{return await r.execute(n,this.telemetry)}catch(e){throw await this.telemetry.recordError(t.HARNESS_EVENT.cliFailed,e),e}finally{await n.cleanup()}})}async run(e){if(this.initCommand.matches(e))return this.initCommand.execute(e);if(this.syncCommand.matches(e))return this.syncCommand.execute(e);if(this.compatibilityCommand.matches(e))return this.compatibilityCommand.execute(e);let i=u.parseHarnessArgs(e);if(i.help)return f.printHelp(),0;if(i.version)return process.stdout.write(`${f.HARNESS_VERSION}\n`),0;let a=n.readHarnessState(process.env,t.toFailureReporter(this.telemetry)).root,o=a?p.default.resolve(a):r.findRepositoryRoot(i.options.cwd);return this.runHarness({repoRoot:o,...i.options})}};async function h(e){let n=t.createHarnessTelemetry();try{return await new m(n).run(e)}finally{await n.shutdown()}}async function g(e){let n=t.createHarnessTelemetry();try{return await new m(n).runHarness(e)}finally{await n.shutdown()}}exports.CliApp=m,exports.runCli=h,exports.runHarness=g;
+//# sourceMappingURL=cliApp.cjs.map

package/dist/cli/cliApp.cjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"cliApp.cjs","names":["createHarnessTelemetry","CompatibilityCommand","InitCommand","SyncCommand","EmitMcpCommand","ExplainCommand","LaunchCommand","buildHarnessContext","HARNESS_EVENT","parseHarnessArgs","HARNESS_VERSION","readHarnessState","toFailureReporter","path","findRepositoryRoot"],"sources":["../../src/cli/cliApp.ts"],"sourcesContent":["import path from 'node:path';\nimport {\n  BaseCommand,\n  CompatibilityCommand,\n  EmitMcpCommand,\n  ExplainCommand,\n  InitCommand,\n  LaunchCommand,\n  SyncCommand,\n} from '../commands/index.ts';\nimport { readHarnessState } from '../config/index.ts';\nimport type { HarnessOptions } from '../interfaces/index.ts';\nimport { buildHarnessContext } from '../services/index.ts';\nimport {\n  createHarnessTelemetry,\n  HARNESS_EVENT,\n  toFailureReporter,\n  type HarnessTelemetry,\n} from '../logSinkTelemetry.ts';\nimport { findRepositoryRoot } from '../utils/index.ts';\nimport { HARNESS_VERSION, printHelp } from './help.ts';\nimport { parseHarnessArgs } from './options.ts';\n\n/**\n * Main CLI Application\n *\n * Owns command registration and dispatch. Preparation is shared: the context\n * is built once and handed to whichever command claims the run.\n */\nexport class CliApp {\n  private readonly commands: BaseCommand[] = [];\n  private readonly compatibilityCommand: CompatibilityCommand;\n  private readonly initCommand: InitCommand;\n  private readonly syncCommand: SyncCommand;\n  private readonly telemetry: HarnessTelemetry;\n\n  // Fields are declared and assigned explicitly rather than as constructor\n  // parameter properties: the launcher scripts run this file straight from\n  // source under Node's strip-only TypeScript mode, which rejects them.\n  constructor(telemetry: HarnessTelemetry = createHarnessTelemetry()) {\n    this.telemetry = telemetry;\n    this.compatibilityCommand = new CompatibilityCommand(telemetry);\n    this.initCommand = new InitCommand();\n    this.syncCommand = new SyncCommand();\n    this.initializeCommands();\n  }\n\n  /**\n   * Initialize all available commands.\n   *\n   * Order matters. The first match wins and LaunchCommand matches everything,\n   * so the diagnostic commands have to come before it.\n   */\n  private initializeCommands(): void {\n    this.commands.push(new EmitMcpCommand());\n    this.commands.push(new ExplainCommand());\n    this.commands.push(new LaunchCommand());\n  }\n\n  /** Picks the command the parsed options select. */\n  selectCommand(options: HarnessOptions): BaseCommand {\n    const command = this.commands.find((candidate) => candidate.matches(options));\n    if (!command) throw new Error('No command matched the given options');\n    return command;\n  }\n\n  /**\n   * Builds the context, runs the selected command, and always cleans up.\n   *\n   * The whole run is one span so the sink shows preparation and the child\n   * process as a single timeline: a slow launch is almost always a slow stage\n   * inside here, and that is only visible when the stages share a trace.\n   */\n  async runHarness(options: HarnessOptions): Promise<number> {\n    return this.telemetry.runInSpan(\n      'doom_pi.run',\n      {\n        'harness.major_mode': options.majorMode,\n        'harness.domain_count': options.domains.length,\n        'harness.agents': options.agents,\n        'harness.mcp': options.mcp,\n        'harness.hooks': options.hooks,\n        ...(options.profile ? { 'harness.profile': options.profile } : {}),\n        ...(options.preset ? { 'harness.preset': options.preset } : {}),\n      },\n      async () => {\n        const context = await buildHarnessContext(options, this.telemetry);\n        const command = this.selectCommand(context.options);\n        try {\n          // Selection uses the same resolved options used to build the context.\n          return await command.execute(context, this.telemetry);\n        } catch (error) {\n          await this.telemetry.recordError(HARNESS_EVENT.cliFailed, error);\n          throw error;\n        } finally {\n          await context.cleanup();\n        }\n      },\n    );\n  }\n\n  /** Entry point for raw process arguments. */\n  async run(args: string[]): Promise<number> {\n    if (this.initCommand.matches(args)) return this.initCommand.execute(args);\n    // Config management rather than a launch: it resolves the matrix and writes\n    // it out for plain Pi, so it never builds a launch context of its own.\n    if (this.syncCommand.matches(args)) return this.syncCommand.execute(args);\n    if (this.compatibilityCommand.matches(args)) return this.compatibilityCommand.execute(args);\n\n    const parsed = parseHarnessArgs(args);\n    if (parsed.help) {\n      printHelp();\n      return 0;\n    }\n    if (parsed.version) {\n      process.stdout.write(`${HARNESS_VERSION}\\n`);\n      return 0;\n    }\n    // An inherited root wins, which is how a nested run stays pinned to the\n    // outer repository rather than re-deriving one from its own cwd.\n    const inheritedRoot = readHarnessState(process.env, toFailureReporter(this.telemetry)).root;\n    const repoRoot = inheritedRoot ? path.resolve(inheritedRoot) : findRepositoryRoot(parsed.options.cwd);\n    return this.runHarness({ repoRoot, ...parsed.options });\n  }\n}\n\n/**\n * Convenience wrapper kept so the binary and tests need no CliApp knowledge.\n *\n * Telemetry is shut down here rather than inside runHarness, because this is\n * the only scope that owns the process: flushing earlier would drop the records\n * a later command still emits.\n */\nexport async function runCli(args: string[]): Promise<number> {\n  const telemetry = createHarnessTelemetry();\n  try {\n    return await new CliApp(telemetry).run(args);\n  } finally {\n    await telemetry.shutdown();\n  }\n}\n\n/** Runs an already-resolved option set, skipping argument parsing. */\nexport async function runHarness(options: HarnessOptions): Promise<number> {\n  const telemetry = createHarnessTelemetry();\n  try {\n    return await new CliApp(telemetry).runHarness(options);\n  } finally {\n    await telemetry.shutdown();\n  }\n}\n"],"mappings":"mxBA6BA,IAAa,EAAb,KAAoB,CAClB,SAA2C,EAAE,CAC7C,qBACA,YACA,YACA,UAKA,YAAY,EAA8BA,EAAAA,wBAAwB,CAAE,CAClE,KAAK,UAAY,EACjB,KAAK,qBAAuB,IAAIC,EAAAA,qBAAqB,EAAU,CAC/D,KAAK,YAAc,IAAIC,EAAAA,YACvB,KAAK,YAAc,IAAIC,EAAAA,YACvB,KAAK,oBAAoB,CAS3B,oBAAmC,CACjC,KAAK,SAAS,KAAK,IAAIC,EAAAA,eAAiB,CACxC,KAAK,SAAS,KAAK,IAAIC,EAAAA,eAAiB,CACxC,KAAK,SAAS,KAAK,IAAIC,EAAAA,cAAgB,CAIzC,cAAc,EAAsC,CAClD,IAAM,EAAU,KAAK,SAAS,KAAM,GAAc,EAAU,QAAQ,EAAQ,CAAC,CAC7E,GAAI,CAAC,EAAS,MAAU,MAAM,uCAAuC,CACrE,OAAO,EAUT,MAAM,WAAW,EAA0C,CACzD,OAAO,KAAK,UAAU,UACpB,cACA,CACE,qBAAsB,EAAQ,UAC9B,uBAAwB,EAAQ,QAAQ,OACxC,iBAAkB,EAAQ,OAC1B,cAAe,EAAQ,IACvB,gBAAiB,EAAQ,MACzB,GAAI,EAAQ,QAAU,CAAE,kBAAmB,EAAQ,QAAS,CAAG,EAAE,CACjE,GAAI,EAAQ,OAAS,CAAE,iBAAkB,EAAQ,OAAQ,CAAG,EAAE,CAC/D,CACD,SAAY,CACV,IAAM,EAAU,MAAMC,EAAAA,oBAAoB,EAAS,KAAK,UAAU,CAC5D,EAAU,KAAK,cAAc,EAAQ,QAAQ,CACnD,GAAI,CAEF,OAAO,MAAM,EAAQ,QAAQ,EAAS,KAAK,UAAU,OAC9C,EAAO,CAEd,MADA,MAAM,KAAK,UAAU,YAAYC,EAAAA,cAAc,UAAW,EAAM,CAC1D,SACE,CACR,MAAM,EAAQ,SAAS,GAG5B,CAIH,MAAM,IAAI,EAAiC,CACzC,GAAI,KAAK,YAAY,QAAQ,EAAK,CAAE,OAAO,KAAK,YAAY,QAAQ,EAAK,CAGzE,GAAI,KAAK,YAAY,QAAQ,EAAK,CAAE,OAAO,KAAK,YAAY,QAAQ,EAAK,CACzE,GAAI,KAAK,qBAAqB,QAAQ,EAAK,CAAE,OAAO,KAAK,qBAAqB,QAAQ,EAAK,CAE3F,IAAM,EAASC,EAAAA,iBAAiB,EAAK,CACrC,GAAI,EAAO,KAET,OADA,EAAA,WAAW,CACJ,EAET,GAAI,EAAO,QAET,OADA,QAAQ,OAAO,MAAM,GAAGC,EAAAA,gBAAgB,IAAI,CACrC,EAIT,IAAM,EAAgBC,EAAAA,iBAAiB,QAAQ,IAAKC,EAAAA,kBAAkB,KAAK,UAAU,CAAC,CAAC,KACjF,EAAW,EAAgBC,EAAAA,QAAK,QAAQ,EAAc,CAAGC,EAAAA,mBAAmB,EAAO,QAAQ,IAAI,CACrG,OAAO,KAAK,WAAW,CAAE,WAAU,GAAG,EAAO,QAAS,CAAC,GAW3D,eAAsB,EAAO,EAAiC,CAC5D,IAAM,EAAYd,EAAAA,wBAAwB,CAC1C,GAAI,CACF,OAAO,MAAM,IAAI,EAAO,EAAU,CAAC,IAAI,EAAK,QACpC,CACR,MAAM,EAAU,UAAU,EAK9B,eAAsB,EAAW,EAA0C,CACzE,IAAM,EAAYA,EAAAA,wBAAwB,CAC1C,GAAI,CACF,OAAO,MAAM,IAAI,EAAO,EAAU,CAAC,WAAW,EAAQ,QAC9C,CACR,MAAM,EAAU,UAAU"}