Businesses

---
name: businesses
description: "Business lifecycle skill (DOMAIN-AGNOSTIC). Creates, lists, inspects, validates, and migrates businesses — autonomous multi-agent organizations — following the Business Protocol v2 (v1 businesses still load unchanged). Works for ANY domain: marketing, healthcare, engineering, legal, real-estate, gaming, foodtech, trading, education, research, government, etc. Triggers: list businesses, inspect business, create business, validate business, migrate business, manage org chart, library/dna ops. For EXECUTION of production briefs ('use as empresas', 'produza X via empresa Y'), invoke the `harness` skill instead — it carries the maestro intelligence. Default: zero_human."
compatibility: "Requires the Nirvana-OS engine: the `nrv` CLI and Bun on PATH. Install: npx @nirvana-os/cli. Runtime-agnostic — no dependency on any specific agent CLI. Creation flows need an interactive question primitive; without one, use the non-interactive list/inspect/validate paths."
tools: [Read, Write, Edit, Glob, Grep, Bash, AgentTool, TaskCreate, AskUserQuestion]
maxTurns: 100
metadata:
  openclaw:
    emoji: "🏢"
    requires:
      # Todo script do Nirvana é Bun-nativo: sem bun a skill aparece e falha.
      bins: ["bun"]
---

# Business Protocol Engine v2.0

Multi-agent business orchestrator following `BUSINESS_PROTOCOL_V2.md` (the delta) over `BUSINESS_PROTOCOL_V1.md` (everything the delta does not change). Runtime-agnostic (Claude Code, Codex, Gemini-CLI). Zero external dependencies beyond the runtime and the centralized validators in `~/.nirvana/skills/_shared/`.

---

## Scope of this skill

This skill is for **business lifecycle operations**: list / inspect / create / validate / migrate businesses; manage the `~/businesses/_library/dna/` mind-clone library; bootstrap structure; consult registries.

For **execution requests** ("use as empresas", "rode pela empresa X", "produza um livro/post/vídeo", any production brief), invoke the **`harness` skill** instead. The harness skill carries the maestro intelligence — it reads the brief, optionally researches, picks the right business, dispatches its org chart, and runs the quality gate. This skill is not the entry point for orchestration.

### Verifying real dispatch (when execution does happen via harness)

After delivery, confirm in `~/.harness-logs/$(date +%Y-%m-%d)/audit.jsonl`:
- `event=brief_received` (from brief-business.ts)
- `event=dispatch_business` (or `dispatch_squad` for fallback) with this trace_id
- `event=mind_clone_injected` for each DNA file loaded (from buildEmployeePrompt)
- `event=handoff_phase_advanced` for `plan → execute` and `execute → complete`
- `event=verify_passed` (from verify-deliverable.ts)
- `event=gate_passed` (from quality-gate.ts) with the rubrics list
- The actual artifact at the dispatched target's declared `outputs[]` location

If absent, the orchestration didn't happen — claiming "I used business X + squad Y" without those events is fiction. Iterate, don't fake.

---

## Protocol Compliance for Employees (HARD RULES)

When an employee is spawned via subagent (using `buildEmployeePrompt()` from `lib/employee-prompt.ts`), the prompt already includes a "PROTOCOL COMPLIANCE" section. Reinforced here for the runtime:

1. **Read multi-target coordination artifacts in this order, every time:**
   1. `<project_dir>/brief-enriched.md` — the full project context.
   2. `<your_target_dir>/DISPATCH-INSTRUCTION.md` (if it exists) — your specific scope, upstream deps, downstream consumers.
   3. `<each_upstream>/outputs/_SUMMARY.md` for every phase in your `depends_on` — 1 page each.
   4. Specific files under `<upstream>/outputs/` only when your DISPATCH-INSTRUCTION calls them out by name.
2. **Read `HANDOFF.json` on start.** Phase tells you where to resume after rate-limit / kill / restart.
3. **Advance phases:** import `updateHandoffPhase` from `~/.nirvana/skills/_shared/lib/handoff.js`:
   - Before first artifact write → `updateHandoffPhase(projectDir, "execute", {nextTaskId: "T-001"})`
   - After last artifact written → `updateHandoffPhase(projectDir, "complete", {lastTaskCompleted: ...})`
   - On interruption → leave `phase: "execute"` with `last_task_completed` set; next session resumes.
4. **Prefer squads — discover, shortlist the TOP 5, then pick the best agentically (§13.4).** You are an orchestrator, not just a doer: before producing an atomic deliverable by hand, look for a squad that covers it. If the brief names a squad, use it. Otherwise:
   a. **Discover candidates** by capability over the squad registry — match the brief against each squad's `capabilities[].domains` + `produces` + `example_briefs` + `keywords` (`agentic` mode, default; or seed the shortlist fast with `nrv find "<need>"` BM25).
   b. **Shortlist the top 5** best-matching squads.
   c. **Analyze those 5 deeply** — read each one's full capability block (`description`, `examples`, `produces`, `not_for`, `domains`, `fidelity`, `score_boost`), judge fit against the brief and your role, then **pick the single best**. Tiebreak: higher `produces`/capability coverage → `fidelity: validated` → `score_boost`. Record in the audit why it beat the other four.
   d. Only if **none** of the 5 genuinely fit, produce it directly (and say so).
   Businesses do not whitelist squads by default: `squads_authorized` empty **and** absent both mean **all squads are permitted** (v2 §6.10), so this **top-5 agentic choice is THE gate** that keeps routing sharp. A non-empty `squads_authorized` is a hard restriction, and a per-employee list narrows it further; `squads_preferred` only reorders — listed squads come first, nothing is excluded. Don't pass the raw brief down: build a **brief-context** shaped by your role and (if `type: mind_clone`) your incorporated persona, hand that to the squad, then integrate its output. Executing directly what a squad already covers breaks the audit chain.
5. **Verify before declaring done.** Run `verify-deliverable.ts` and `quality-gate.ts` from the harness; **write `outputs/_SUMMARY.md`** (1 page max — your public API for downstream phases); only emit `delivered` audit event after gates PASS.
6. **Scope isolation.** Write only under your own target directory. Coordination with siblings is audit-only (`plan_change_request`, `mention`, `notify_human`) — never modify other targets' outputs.

These rules turn employees from "general-purpose subagents with persona text" into real Nirvana-OS citizens with auditable, resumable state.

**Event vocabulary.** `buildEmployeePrompt()` already shows the working example (`nrv audit emit x_clone_choice --business=<slug> --trace=<trace> --json='{...}'`) at the point an employee records its mind-clone choice — measured at zero rogue event names across 61 businesses (event-contract cut, 2026-08-28), so no separate block was added here the way squads got one. Same rule as squads: an event outside the closed enum (`references/03-audit.md` in the harness skill) gets the explicit `x_` prefix at the call site, never a bare invented name.

---

## First invocation (auto-bootstrap)

When this skill activates for the first time, ensure the minimal structure exists. Idempotent:

```bash
mkdir -p ~/businesses ~/businesses/_library/dna ~/businesses/_library/frameworks
mkdir -p ~/.businesses-state ~/.businesses-logs/$(date +%Y-%m-%d)
[ -f ~/.businesses-registry.json ] || echo '{"schema_version":"1.0.0","generated_at":"","businesses":{}}' > ~/.businesses-registry.json
```

Report: number of businesses found, registry status, dependencies (Python 3.9+, Node 18+ — only for validators).

## Project scoping (NIRVANA_SCOPE)

When invoked from inside a project tree with `<project>/.env` containing `NIRVANA_SCOPE=project|merge`, all loaders (list/index/inspect/validate) honor that scope automatically. Project-local businesses live at `<project>/.nirvana/businesses/<slug>/` and the registry persists at `<project>/.nirvana/.businesses-registry.json`. From global cwd or with `NIRVANA_SCOPE=global` (default), behavior is identical to the home installation. Full contract: `~/.nirvana/skills/_shared/SCOPE_CONTRACT.md`.

## Protocol source

Source of truth, in this directory: `BUSINESS_PROTOCOL_V2.md` (the v2 delta) plus `BUSINESS_PROTOCOL_V1.md` for every section v2 leaves untouched. A v1 business loads, routes and dispatches exactly as before; v2 fields are optional.

**The validator that runs is Zod**, in `~/.nirvana/skills/_shared/validators/validators.ts`. `validators.py` is the canonical mirror for hosts with Python. `~/.nirvana/skills/_shared/schemas/business.schema.json` and `core-schemas.json` are **documentation mirrors** — they describe the contract, they do not execute it, and a divergence between them and the Zod schema is a defect in the JSON. Always delegate validation to the validators instead of re-implementing it.

DNA library of mind-clones in `~/businesses/_library/dna/` (61 categories, 393 validated canonical mind-clones).

Canonical domain catalog in `~/.nirvana/skills/_shared/catalogs/CAPABILITY_CATALOG_V1.yaml`.

Read on demand. NEVER preemptively load the full protocol into context.

## Principles (BP1-BP13 + inherited Squad P1-P11)

- BP1 Zero-human is the default. A run that needs a human says so explicitly; nothing pauses on its own.
- BP2 Hierarchy is real, not decorative.
- BP3 Handoffs are structured. 3 mechanisms in v2: delegation, escalation, auto-routing.
- BP4 Acceptance is declared per seat (`acceptance[]`), judged by the gate — not self-scored by the author (v2 §11).
- BP5 3-tier memory with isolation by construction (Permanent, Project, Session).
- BP6 Brief is the unit of entry. Routing via `routing.yaml`.
- BP7 Antagonist mandatory above 5 employees.
- BP8 Default `functional_specialist`, not `mind_clone`.
- BP9 Retired in v2 (approval chains were never implemented; adversarial review is BP7).
- BP10 Retired in v2 (heartbeats were never scheduled; recurring work belongs to the host scheduler).
- BP11 Project outputs are source-of-truth, memory is cache.
- BP12 Audit trail is non-negotiable.
- BP13 Writing contract — every prose deliverable follows the contract appended to `AGENTS.md` / `CLAUDE.md` / `GEMINI.md` (prevention-by-injection, no post-hoc rewrite).

## Filesystem layout (canonical)

```
~/businesses/                              # business root (one folder per business)
├── _library/
│   ├── dna/                               # canonical mind-clones (symlinks to disk)
│   └── frameworks/                        # reusable frameworks
└── <business-slug>/
    ├── business.yaml                      # manifest (protocol 1.0 or 2.0)
    ├── employees/<slug>.md                # employee frontmatter + body
    ├── org-chart.yaml                     # hierarchy + reporting + escalation_path
    ├── routing.yaml                       # brief intake + auto_routes (the only place auto_routes live)
    ├── .nirvana-surface.json              # contract surface — engine-owned, never hand-edited
    ├── memory/permanent.md                # curated, replaced on pack update
    ├── memory/learned.md                  # promoted by a human, survives pack updates
    └── projects/                          # per-project state (created on-demand)

~/.businesses-registry.json                # index generated by `*business index`
~/.businesses-state/                       # local skill state
~/.businesses-logs/<YYYY-MM-DD>/           # audit trail jsonl
```

Project outputs live in `${PROJECTS_OUTPUT_DIR}/<project-id>/businesses/<biz-slug>/` (default: `<repo-root>/.projects-outputs/`).

Project-root resolution:
1. `$PROJECTS_OUTPUT_DIR` env var
2. Walk up until `.git/` or `CLAUDE.md` or `package.json` or `pyproject.toml`
3. Fallback `cwd()`

## Intent classification

When the user invokes this skill, map the input to one of the actions below. Use AskUserQuestion to disambiguate when needed.

| Intent (keywords) | Action | Reference |
|---|---|---|
| **CREATE**: create, new business, scaffold, init | `*business init <name>` | §Wizard flow (in this file) |
| **LIST**: list, view all, which businesses | `*business list` | `scripts/list-businesses.ts` |
| **INSPECT**: view, show, inspect, detail | `*business inspect <slug>` | `scripts/inspect-business.ts` |
| **VALIDATE**: validate, check, verify | `nrv validate business <slug>` | `scripts/validate-business.ts` |
| **INDEX**: index, rebuild, refresh registry | `*business index` | `scripts/index-businesses.ts` |
| **BRIEF**: brief, process, execute, run | `*business brief <slug> "<text>"` | `scripts/brief-business.ts` |
| **EMPLOYEES**: add employee, new employee, hire | `BUSINESS_PROTOCOL_V2.md` §7 + `BUSINESS_PROTOCOL_V1.md` §7 |
| **ORG**: org chart, hierarchy, reporting | `BUSINESS_PROTOCOL_V1.md` §8 |
| **HANDOFFS**: delegate, escalate, route | `BUSINESS_PROTOCOL_V2.md` §13 |
| **MEMORY**: edit memory, maintenance | `*business memory edit <slug>` |

Multi-intent: process in dependency order. Always lazy-load (never load the full protocol).

## Quick commands (operational)

> ⛔ **Run loaders from your PROJECT's working directory, with the ABSOLUTE path
> below. NEVER `cd` into the skill directory to run a loader.** Scope is detected
> by walking up from the current directory; `cd`-ing into `~/.nirvana/skills/businesses`
> moves your shell out of the project tree, so the loader silently resolves
> `scope=global` and lists the home registry instead of your project's. From a
> scoped project (`NIRVANA_SCOPE=project|merge`) that means you get the WRONG
> answer. If a loader prints `scope=global` when you expected `project`, you
> almost certainly `cd`-ed out. (Pin it cwd-independently with
> `export NIRVANA_PROJECT_ROOT=<project>`.)

| Command | Implementation | Description |
|---|---|---|
| `*business init <name>` | `bun ~/.nirvana/skills/businesses/scripts/init-business.ts <name>` + wizard via AskUserQuestion | Scaffold new business in `~/businesses/<slug>/` |
| `nrv validate business <slug>` | `bun ~/.nirvana/skills/businesses/scripts/validate-business.ts <slug>` | Admission gate: the 39 criteria of `BUSINESS_PROTOCOL_V2.md` §16 (`--fix` applies the mechanical repairs, `--strict` also fails on warnings, `--all` walks the library, `--report` writes the JSON under `.audit-state/<slug>/`) |
| `*business index` | `bun ~/.nirvana/skills/businesses/scripts/index-businesses.ts` | Regenerates `~/.businesses-registry.json` |
| `*business list` | `bun ~/.nirvana/skills/businesses/scripts/list-businesses.ts` | Table of businesses from the registry |
| `*business inspect <slug>` | `bun ~/.nirvana/skills/businesses/scripts/inspect-business.ts <slug>` | Manifest + employees + org-chart formatted |
| `*business brief <slug> "<text>"` | `bun ~/.nirvana/skills/businesses/scripts/brief-business.ts <slug> "<text>"` | Records brief, validates, prepares invocation plan |
| `*business memory edit <slug>` | opens `~/businesses/<slug>/memory/permanent.md` in write mode | Maintenance mode |
| `*business audit <project> --business <slug>` | tail `~/.businesses-logs/.../audit.jsonl` filtered | Audit trail |

Interactive wizards follow the round pattern below (§Wizard flow), which is the full detail — there is no separate reference file.

## Wizard flow (executed by the skill when intent = CREATE)

When intent = CREATE, follow this sequence without skipping steps.

> **This flow IS the system's business creator** — creation is engine work,
> executed agentically by this skill, never dispatched to a creator squad.
> The goal is the best possible business for the role, not a valid one.

**Round 0 — Archaeology + research (before asking anything)**
- Intent archaeology: which recurring pain the business serves, who consumes
  the outputs, and what already exists in the portfolio that covers part of it
  (`nrv find --no-amplify` with 3-5 hypothetical briefs). Overlap is legitimate
  — the owner may want two organisations covering the same sector, to name one
  when they want it and let the maestro choose when they do not. What the
  search tells you is what this business must be visibly better at. Never fence
  a neighbour off; boundaries carry genuine refusals only.
- Domain research (web, mandatory): CURRENT practices, tools, and services of
  the sector, with date and source — they become the employees' knowledge and
  the real vocabulary of `domains`/`example_briefs`/keywords (PT and EN).
- Mind-clones by NEED: for each planned role, search the library
  (`nrv find-clone "<necessidade do papel>"`) and pre-select
  `assigned_mind_clones` with grounding — an employee without the right clone
  is a generic persona. Empty library (clean engine install, no pack)? Two
  honest paths: create the clone first (`_shared/MIND_CLONE_CREATION_PIPELINE.md`)
  or proceed without a clone, declaring the employee as a built persona, never
  as a clone that does not exist.

**Round 1 — Identity**
- AskUserQuestion: "What is the business name?" (single, with hint about kebab-case)
- AskUserQuestion: "Brief description (≥20 chars)? Include domains."
- Validate that the slug does not collide with an existing `~/businesses/<slug>/`.

**Round 2 — Template**
- AskUserQuestion with options: solo (1 employee), council (5 advisors + CEO), agency (CEO + 4-7 specialists + antagonist), custom.
- Each option has a preview in the appropriate `templates/example-business/`.

**Round 3 — Employees**
- For each employee in the template, AskUserQuestion confirming role + adjustments.
- If template = custom, ask for the role list (multi-select of canonical roles + "Other").
- Auto-promote the first alphabetically to CEO if none is explicit. BP7 force-adds an antagonist if there are >5 employees and none is marked.

**Round 4 — Review**
- Generate `business.yaml`, `org-chart.yaml`, `employees/*.md` in a staging directory.
- Run `scripts/validate-business.ts` against staging.
- AskUserQuestion: "Confirm creation?" showing the preview.
- If approved, move to `~/businesses/<slug>/` and update the registry.

**Round 5 — Readiness gate (MANDATORY, after the registry update — creation is NOT done until it passes)**
- **Admission gate (blocking).** Run and require exit 0:
  `nrv validate business <slug> --strict`
  It is the single verb that carries the criteria catalog of `BUSINESS_PROTOCOL_V2.md` §16 — manifest, employees, org chart, routing metadata, acceptance, surface. `--fix` repairs the mechanical findings; authorship (fences, acceptance, thin seats) stays with you. `init-business.ts` already ran it in `--fix` mode over the scaffold, so the engine-owned `.nirvana-surface.json` is on disk before you start writing.
- Optimization pass: reread each employee as a hostile reviewer — a generic
  persona, a role without a clear deliverable, or knowledge Round 0 researched
  that the employee does not use are defects; fix them before declaring ready.
- **Seat sufficiency (blocking script gate).** Under the per-task clone model
  a dispatch may legitimately run with no clone, so every seat must stand on
  its own method. Run and require exit 0:
  `bun ~/.nirvana/skills/_shared/scripts/check-seat-sufficiency.ts <slug> --strict`
  The measure is sections + decision lines (seat-sufficiency.js), calibrated
  against the whole library — a dense-short seat passes, a role label does not.
- **Routing metadata, contract-complete** — fill `business.yaml` (+
  `routing.yaml`) per `~/.nirvana/skills/_shared/ROUTING_METADATA_CONTRACT.md`.
  No field may be left empty or truncated:
  - `description`: canonical English, concrete, front-loaded (§1);
  - `domains`: from `CAPABILITY_CATALOG_V1.yaml` (§2);
  - `produces`: artifact-type slugs (§3);
  - `keywords`: multilingual synonym groups — EN + PT (+ES where natural),
    accented AND unaccented forms (§4);
  - `example_briefs`: ≥3, at least one EN and one PT, symptom-phrased, covering
    conjugated and infinitive verb forms (§5);
  - `not_for`: short token lists of 2-4 content words, never sentences (§6);
  - `auto_routes` in `routing.yaml`: patterns derived from the example_briefs,
    firing on infinitive AND conjugated forms (§7).
- **Self-retrieval gate (blocking):**
  ```bash
  bun ~/.nirvana/skills/_shared/scripts/self-retrieval-gate.ts <slug>
  ```
  Every `example_brief` must route back to this business top-1 (exit 0). Also
  probe 2-3 extra SYMPTOM briefs (as the owner would type them in a panic, PT)
  and confirm the home briefs of the Round 0 neighbor businesses still route to
  their owners. On a miss, the defect is in the discovery metadata — never "the
  router"; iterate the metadata and rerun until the gate exits 0. **Do not
  report the business as created while this gate is red.**

## Memory isolation (BP5 enforcement)

During brief invocation, REFUSE any operation outside `${PROJECTS_OUTPUT_DIR}/<current-project>/`. Allowed exceptions:
- Read-only on `~/businesses/<current-biz>/` (manifest, employees, org-chart, permanent memory).
- Read-only on `~/businesses/_library/dna/` (mind-clone refs).
- Append on `~/.businesses-logs/<date>/audit.jsonl`.

Permanent memory (`~/businesses/<slug>/memory/permanent.md`) is writable ONLY in `*business memory edit` mode.

**Two files, two owners.** `permanent.md` (or `memory/permanent/`) ships with the business and is **replaced on pack update** — it is curated content, not a place to accumulate. `memory/learned.md` is where a human promotes what past runs proposed; it is in `RUNSTATE_EXCLUDES` and **survives pack updates**. Both are read at dispatch; only `learned.md` grows. A run never writes either one — it writes its own project's memory and lists promotion candidates in the final report (see `harness/SKILL.md` → Memory levels).

A violation emits `audit_event: isolation_violation` and aborts.

## Handoff mechanisms (v2 §22)

Three of the v1 five survive, and they are the three the engine implements:

1. **Delegation** (downward): manager → direct report, restricted to `manages:`.
2. **Escalation** (upward): direct report → manager, along `reports_to` and `org-chart.yaml` `routing_rules.escalation_path`.
3. **Auto-routing** (`routing.yaml` only): the first `auto_routes` pattern that fires on the brief selects the seat that receives it (v2 §13.2).

Mentions and tickets are retired (v2 §22): no business ever had a `tickets/` directory and no code read a mention. Every handoff still produces a `handoff_artifact` (Squad v4 §9 + Business extensions), ≤ 800 tokens.

## Acceptance per seat (BP4, v2 §11)

Each seat declares `acceptance[]` in its frontmatter: `{id, description, blocking, minimum_score, capability?, path?, min_bytes?}`. Every entry maps 1:1 onto a `SuccessRequirement`, the same shape squad capabilities use, so the judge and `verify-deliverable.ts` evaluate a seat's output against what the seat itself declared. Ids are unique within the business.

`self_score_contract` is retired (v2 §0): the loader still accepts it, the gate warns, and `nrv validate business <slug> --fix` converts `criteria[].{id, description, threshold}` into `acceptance[]`. An author's own score was never evidence, and nothing read it.

## Zero-human operation (BP1)

Default `operation_mode: zero_human`, and it is the only mode honored this cycle — `hybrid` and `human_in_loop` parse and warn.

Escalation inside the business is the org chart: `reports_to` / `manages` and `org-chart.yaml` `routing_rules.escalation_path`. `escalation_triggers` in employee frontmatter and the `escalation-triggers.yaml` file are retired (v2 §22): 234 seats declared triggers and nothing ever fired one. A run that genuinely needs a human emits `notify_human` to the audit and the harness surfaces it.

## Writing contract (BP13)

Every prose deliverable follows the writing contract appended to `AGENTS.md` / `CLAUDE.md` / `GEMINI.md`. The contract is auto-loaded by every runtime (Claude Code, Antigravity CLI, Gemini CLI, Codex) before the agent generates anything, so prevention happens at write time. No post-hoc correction loop, no separate skill invocation, no extra cost.

Employees that produce only technical artifacts (JSON, schemas, code) ignore the contract by content — none of the prose rules apply to non-prose output.

## Skill layout

```
~/.nirvana/skills/businesses/
├── SKILL.md                                # this file
├── BUSINESS_PROTOCOL_V2.md                 # the v2 delta (source of truth)
├── BUSINESS_PROTOCOL_V1.md                 # everything v2 leaves untouched
├── templates/
│   ├── business-types/<type>/              # solo · council · agency · conglomerate
│   └── example-business/                   # runnable solo template (validation passes)
├── lib/
│   ├── loader.ts                           # loads + validates an entire business
│   ├── registry.ts                         # generates ~/.businesses-registry.json
│   ├── employee-prompt.ts                  # builds the seat's prompt
│   └── business-audit-criteria.js          # audit scoring
├── scripts/
│   ├── init-business.ts                    # scaffold + wizard kickoff
│   ├── validate-business.ts                # admission gate entry point
│   ├── index-businesses.ts                 # rebuild registry
│   ├── list-businesses.ts                  # table
│   ├── inspect-business.ts                 # formatted tree
│   ├── brief-business.ts                   # prepare invocation plan
│   └── verify-deliverable.ts               # artifact existence + acceptance paths
└── tests/
    ├── smoke.test.ts                       # E2E: init → validate → index → list
    ├── registry-description.test.ts        # what the registry emits to the router
    ├── protocol-v2-spec-parity.test.ts     # §16 table == gate catalog
    └── employee-clone-choice.test.ts       # clone ladder in the seat prompt
```

## Invocation pipeline (when intent = BRIEF)

1. Load business via `lib/loader.ts` (manifest + employees + org-chart + routing).
2. Run `validateBusinessIntegrity` (BP7 antagonist, exactly 1 brief_intake, no cycles, etc.).
3. Resolve the `brief_intake` employee (typically the CEO).
4. Create `${PROJECTS_OUTPUT_DIR}/<project-id>/businesses/<biz-slug>/` with `brief.md`, `audit.jsonl`, empty dirs.
5. Spawn AgentTool with `subagent_type` = brief_intake employee. The prompt includes brief + culture + permanent memory (read-only) + isolation guard rules. This is **in-process** (the native Agent tool / runtime subagent), not a child `claude -p`; the `--exec` headless path (`runHeadless`) is reserved for the standalone dispatch script and sub-process-only runtimes (legacy gemini-cli, hermes).
6. Wait for the handoff_artifact JSON. It does NOT come back as the spawn's tool result — that is a launch receipt. It arrives in the `<task-notification>` the runtime delivers when the employee finishes, inside `<result>`. Read it there: no handoff, nothing to judge against the seat's `acceptance[]` and no `business_extensions.type` to decide step 7 on. Waiting does not mean blocking; the session stays free while the employee works.
7. If `business_extensions.type == "delegation"` or `"mention"`, spawn the next employee. Repeat until the CEO returns `next_action: deliver_to_user`.
8. Emit `audit_event: invocation_end` with cost summary.
9. Return the deliverable to the user.

For each handoff: judge the seat's `acceptance[]`, log to audit, persist to `handoffs/<n>.json`.

## Anti-patterns (DO NOT)

- DO NOT process briefs in `human_in_loop` mode without explicit config.
- DO NOT ship a seat's deliverable without its declared `acceptance[]` being judged.
- DO NOT allow filesystem access outside the project root + own business scope.
- DO NOT use `mind_clone` without `disclosure_required: true`.
- DO NOT create businesses with >5 employees without an antagonist (BP7).
- DO NOT bypass the antagonist (BP7) on client-facing output.
- DO NOT load the full BUSINESS_PROTOCOL_V1.md — read the v2 delta, then the v1 TOC on demand.
- DO NOT emit prose output that violates the writing contract in `AGENTS.md` / `CLAUDE.md` / `GEMINI.md` (BP13).

## Backward compat

- Squads referenced in `squads_authorized` may be v4 or v5 (the squads skill resolves both).

---

*Protocol: 2.0 (1.0 still loads) · Status: operational · Spec: BUSINESS_PROTOCOL_V2.md + BUSINESS_PROTOCOL_V1.md*