opennori 0.1.8 → 0.1.9

package/.opennori/protocol.md

@@ -18,6 +18,16 @@ For non-trivial goals, OpenNori also carries an Architecture Baseline. Product A
 human user must be able to accept. Architecture Baseline answers what technical architecture the
 agent must follow while producing that outcome. These are reported together but kept separate.
 
+OpenNori is installed and used as one agent capability bundle:
+
+- Codex Plugin distributes and discovers packaged OpenNori Skills.
+- Skills define the agent behavior protocols and natural-language routing.
+- `opennori` is the deterministic state layer those Skills call.
+- `.opennori/` is the project-local contract, evidence, profile, architecture, health, and report store.
+
+Do not present Plugin, Skills, CLI, or `.opennori` state as separate user workflows. Direct CLI use
+is an advanced, automation, or debugging route for the same state layer.
+
 ## Layered Acceptance Criteria v1
 
 OpenNori itself is accepted only when it satisfies user-tool-operation acceptance criteria.
@@ -78,7 +88,7 @@ a durable workflow asset.
 | ID | Tool / entrypoint | User operation | User acceptance criterion | Passing threshold |
 | --- | --- | --- | --- | --- |
 | AC-Z-1 | Codex Plugin / package assets | Install or inspect the OpenNori package | The user's agent can discover focused OpenNori Skills without the user memorizing CLI flags. | `.agents/plugins/marketplace.json` points to `./plugins/opennori`; `plugins/opennori/.codex-plugin/plugin.json` points to package-local `skills/`; the `nori` Skill routes natural-language work through acceptance, evidence, profile, architecture, health, and reporting. |
-| AC-Z-2 | CLI | Run `opennori install` | The user can install OpenNori into a project without unexpected overwrites. | Install shows created/skipped assets; existing user content is not overwritten by default. |
+| AC-Z-2 | CLI | Run `opennori init` or `opennori install` | The user can initialize OpenNori project state without unexpected overwrites. | Init/install shows created/skipped assets; existing user content is not overwritten by default. |
 | AC-Z-3 | Git / PR diff | Review the agent's changes | The user can separate acceptance evidence changes from implementation noise. | Summary defaults to AC status changes, evidence changes, and user impact. |
 | AC-Z-4 | CLI | Run `opennori list` and select a goal | The user can see multiple active goals and choose one explicitly. | Multiple active goals are listed with status, gap, and paths; `--goal` selects the target. |
 | AC-Z-5 | CLI | Archive a completed or blocked goal | The user removes it from active work while preserving evidence and report. | Active no longer lists the goal; contract, ledger, and report remain recoverable. |
@@ -88,11 +98,13 @@ a durable workflow asset.
 | AC-Z-9 | CLI | Preview install with `opennori install --dry-run` | The user can judge what OpenNori would create, skip, update, or overwrite before writing to the project. | Install plan lists action, kind, managed status, write intent, destructive flag, and reason; dry-run reports zero actual writes. |
 | AC-Z-10 | CLI | Apply force install | The user must preview and explicitly confirm destructive install actions before files are overwritten. | Real `opennori install --force` fails without confirmation; dry-run previews destructive overwrites; confirmed force install may write. |
 | AC-Z-11 | CLI | Preview and apply uninstall | The user can uninstall OpenNori entry assets without losing acceptance state by default. | Uninstall plan shows removals and preserved state; real uninstall requires confirmation; `.opennori` state is deleted only with `--include-state --confirm`. |
-| AC-Z-12 | Codex Plugin / Codex Skills | Use OpenNori Plugin Skills | The agent gets focused OpenNori Skills for acceptance, evidence, Nori Profile, architecture, project health, and reporting while the user keeps using natural language. | The npm package ships `.agents/plugins/marketplace.json`, `plugins/opennori/.codex-plugin/plugin.json`, and `plugins/opennori/skills/nori*/SKILL.md`; install does not copy Skills into the project; manifest records `plugin`; doctor detects missing packaged Plugin Skills. |
+| AC-Z-12 | Codex Plugin / Codex Skills | Use OpenNori Plugin Skills | The agent gets focused OpenNori Skills for acceptance, evidence, Nori Profile, architecture, project health, reporting, and next-loop candidates while the user keeps using natural language. | The npm package ships `.agents/plugins/marketplace.json`, `plugins/opennori/.codex-plugin/plugin.json`, and `plugins/opennori/skills/nori*/SKILL.md`; each Skill is an agent behavior protocol with trigger semantics, state reading, natural-language mapping, state write boundaries, handoffs, user reply shape, and misuse guards; install does not copy Skills into the project; manifest records `plugin`; doctor detects missing packaged Plugin Skills. |
 | AC-Z-13 | CLI / project file browser | Establish an Architecture Baseline | The user can see what architecture the agent must follow while implementing Product AC. | `.opennori/architecture/baseline.json`, `.opennori/architecture/baseline.md`, and `.opennori/agent-guide.md` expose the baseline to agents and reviewers. |
 | AC-Z-14 | CLI / project file browser | Add a project Architecture Profile | The user can extend built-in profiles with a reviewed project profile. | `opennori architecture profile --from <profile.json>` writes `.opennori/architecture/profiles/<id>.json`; `architecture profiles` lists it before built-ins. |
 | AC-Z-15 | CLI / report | Challenge a baseline | The user can review evidence before an agent changes architecture. | `opennori architecture challenge` records current baseline, conflict evidence, recommendation, and user confirmation requirement. |
 | AC-Z-16 | CLI / report | Record build-vs-buy decisions | The user can see whether existing dependencies, standard libraries, official SDKs, and mature OSS were checked before self-building infrastructure. | `opennori architecture build-vs-buy` records the decision under `.opennori/architecture/decisions/` and status/report summarize it. |
+| AC-Z-18 | README / website / Plugin description | First read the OpenNori entry material | The user understands OpenNori as one agent capability bundle: Plugin discovery, packaged Skills, deterministic CLI state layer, and `.opennori` project state work together. | README Install/Quick Start, website Start, Plugin longDescription, and nori/project-health Skills do not present Plugin, Skills, or CLI as separate user paths; they explain that missing bundle parts should be recovered through doctor/health rather than used as a half-installed workflow. |
+| AC-Z-19 | CLI / Codex / npm | Run `npx opennori setup`, then use `opennori init` in projects | The user installs the complete OpenNori capability bundle from one explicit setup entry and can initialize projects with the global CLI. | Setup previews Codex Plugin registration, packaged Skill availability, global CLI install, project `.opennori` initialization, and doctor; unconfirmed setup writes nothing; confirmed setup uses official `codex plugin` and npm commands plus OpenNori project initialization. |
 
 ## Required Artifact Pair
 
@@ -134,7 +146,9 @@ Each active goal has:
 - Architecture Baseline, profile, challenge, build-vs-buy, and agent-readable surface state
 - protocol capabilities exposed by this CLI
 
-`opennori install` creates or refreshes the manifest. State-changing OpenNori commands refresh it when
+`opennori init` creates project state through the same preview-first lifecycle used by install.
+`opennori install` remains a deterministic project-asset command for agents and automation.
+State-changing OpenNori commands refresh the manifest when
 `.opennori/` already exists.
 
 `opennori install --dry-run` returns an install plan. The plan uses deterministic action semantics:
@@ -159,8 +173,9 @@ directory requires both `--include-state` and `--confirm`.
 
 ## OpenNori Plugin Skills
 
-OpenNori exposes Codex Skills through its Plugin and package assets. The user should not need to
-remember these Skill names; the root `nori` Skill routes natural-language requests to focused Skills:
+OpenNori exposes Codex Skills through its Plugin and package assets. These Skills are agent
+behavior protocols, not CLI manuals for users. The user should not need to remember Skill names or
+command flags; the root `nori` Skill routes natural-language requests to focused Skills:
 
 - `nori`: root router for OpenNori turns
 - `nori-acceptance`: discover AC gaps, brainstorm, draft, approve, and revise human-facing ACs
@@ -171,7 +186,11 @@ remember these Skill names; the root `nori` Skill routes natural-language reques
 - `nori-architecture-challenge`: raise evidence-backed requests to revise a baseline
 - `nori-build-vs-buy`: record dependency/library/self-build decisions before infrastructure work
 - `nori-project-health`: install, upgrade, uninstall, doctor, manifest, Plugin health, and project recoverability
-- `nori-reporting`: status, report, current gap, user intervention, and changes
+- `nori-reporting`: status, report, current gap, user intervention, changes, and context export
+
+Each packaged Skill states its mission, starting state reads, natural-language mapping, allowed
+state writes, handoff rules, user-facing reply shape, and misuse guards. This lets agents use
+OpenNori from natural language while the CLI remains a deterministic state layer.
 
 The package ships `.agents/plugins/marketplace.json` pointing to `./plugins/opennori`, where
 `plugins/opennori/.codex-plugin/plugin.json` declares `skills: "./skills/"`. `opennori install`
@@ -180,13 +199,15 @@ The manifest records `plugin` state, and `opennori doctor` checks whether packag
 present and whether the manifest Plugin state is stale.
 
 When upgrading an existing OpenNori project, upgrade entry assets first, then run `opennori check`.
-`check` validates active Nori Contracts, reports `acceptance_quality` warnings for vague ACs
-such as "modify profile fields" or "show an error", and reports `architecture_check` warnings when
-the active goal has no confirmed Architecture Baseline, stale agent-readable surface, or unresolved
-Architecture Challenges. It also reports `evidence_health` warnings when a complete-looking goal
-relies on stale, broad, source-free, or non-reviewable evidence. It does not rewrite existing
-contracts, evidence, reports, archives, brainstorms, or baselines. The user decides whether to
-revise affected criteria, architecture, or evidence.
+`check` validates active Nori Contract integrity as hard state structure, then reports
+`acceptance_review` findings for vague or possibly implementation-centered ACs such as "modify
+profile fields" or "show an error". These review findings are questions for the agent and user,
+not hard protocol rejection. `check` also reports `architecture_check` warnings when the active goal
+has no confirmed Architecture Baseline, stale agent-readable surface, or unresolved Architecture
+Challenges. It reports `evidence_health` warnings when a complete-looking goal relies on stale,
+broad, source-free, or non-reviewable evidence. It does not rewrite existing contracts, evidence,
+reports, archives, brainstorms, or baselines. The user decides whether to revise affected criteria,
+confirm assumptions, accept review risk, revise architecture, or refresh evidence.
 
 ## Nori Profile
 
@@ -209,7 +230,7 @@ Profile items have:
 Completion rules:
 
 - `must` blocks completion until satisfied or waived.
-- `prefer` is reported but does not block completion.
+- `prefer` does not block objective completion, but unknown or violated preferences become `profile_review` risk before confident completion.
 - `avoid` blocks completion if violated.
 
 Agents translate the user's natural-language preferences into profile records. Users should not
@@ -272,6 +293,13 @@ open-source libraries, and documented reference projects:
 opennori architecture build-vs-buy --root <project> --area "<area>" --need "<need>" --recommendation <reuse|buy|self-build> --summary "<decision>" --json
 ```
 
+Architecture state affects completion confidence, not Product AC shape. When every required Product
+AC is `passing` or `waived` but the active goal has a missing/draft/invalid/challenged baseline,
+stale agent-readable architecture surface, or unhealthy build-vs-buy decisions, OpenNori reports
+`objective_complete: true` with `confidence: review-risk`. It must not create synthetic ARCH
+acceptance criteria or replace `current_gap` unless a real Product AC or blocking Profile item is
+still incomplete.
+
 ## Status Model
 
 - `unknown`: no user-understandable evidence exists
@@ -282,7 +310,15 @@ opennori architecture build-vs-buy --root <project> --area "<area>" --need "<nee
 
 The workflow ledger is complete only when every required criterion is `passing` or `waived`.
 The user-facing completion answer is not confidently complete while `evidence_health` has review
-findings, even if the ledger status is already `complete`.
+findings, `profile_review` is unresolved, `architecture_review` remains, or `build_vs_buy` is
+unhealthy, even if the ledger status is already `complete`.
+
+When a goal is confidently complete, `next_recommendation` may include `candidate_goals`.
+These candidates help the agent continue when the user has asked to keep going. Each candidate
+names a possible next human-facing goal, the user value, acceptance directions, and risks.
+Candidates are not phases, task lists, approved acceptance criteria, or completion evidence. The
+agent must turn a selected or revised candidate into a new draft Nori Contract before using it for
+completion judgment.
 
 ## Risk Gate
 
@@ -349,13 +385,15 @@ On every turn:
 12. Before implementing an acceptance gap, read `.opennori/architecture/baseline.md` and keep Product AC separate from Architecture Checks.
 13. Before self-building infrastructure, record a build-vs-buy decision.
 14. If project evidence conflicts with the baseline, run `opennori architecture challenge`; do not silently replace the baseline.
-15. If the user revises a criterion later, run `opennori criterion update --root <repo> --criterion <id> ... --json`; old evidence for the changed criterion is cleared.
-16. If the user asks to update an existing OpenNori project, run `opennori doctor`, use `opennori upgrade --dry-run/--confirm` for manifest/protocol/guide refreshes, then run `opennori check`; ask the user before revising any existing AC flagged by `acceptance_quality`. If packaged Plugin Skills are missing, reinstall or update the OpenNori package instead of copying Skills into the project.
-17. Run `opennori resume --root <repo>` or `opennori next --root <repo>` to recover the active goal and current acceptance gap from repository files.
-18. Work only to produce evidence for that gap under the confirmed Architecture Baseline.
-19. Add acceptance evidence with `opennori evidence add`; choose any suitable verification method, but record basis, sources, reviewability, confidence, and limitations. Add profile compliance evidence with `opennori profile evidence` when profile items exist.
-15. Run `opennori evaluate`.
-16. Report acceptance state, profile compliance, and evidence, not implementation steps.
+15. If the user adds a new acceptance boundary after approval, run `opennori criterion add --root <repo> --id <id> ... --json`; the new criterion becomes an evidence gap without forcing the agent to edit state files manually.
+16. If the user revises a criterion later, run `opennori criterion update --root <repo> --criterion <id> ... --json`; old evidence for the changed criterion is cleared.
+17. If the user asks to update an existing OpenNori project, run `opennori doctor`, use `opennori upgrade --dry-run/--confirm` for manifest/protocol/guide refreshes, then run `opennori check`; ask the user before revising any existing AC flagged by `acceptance_review`. If packaged Plugin Skills are missing, reinstall or update the OpenNori package instead of copying Skills into the project.
+18. Run `opennori resume --root <repo>` or `opennori next --root <repo>` to recover the active goal and current acceptance gap from repository files.
+19. Work only to produce evidence for that gap under the confirmed Architecture Baseline.
+20. Add acceptance evidence with `opennori evidence add`; choose any suitable verification method, but record basis, sources, reviewability, confidence, and limitations. If existing evidence is invalid or obsolete, run `opennori evidence prune` first so stale proof does not occupy active context. Add profile compliance evidence with `opennori profile evidence` when profile items exist.
+21. Run `opennori evaluate`.
+22. Report acceptance state, profile compliance, and evidence, not implementation steps.
+23. If the goal is complete and the user asked to continue, review `next_recommendation.candidate_goals`, choose or refine the strongest human-facing next goal, then run discovery or draft for a new Nori Contract. Do not treat candidate goals as approved AC, phases, task lists, or evidence.
 
 Useful commands:
 
@@ -364,8 +402,10 @@ Useful commands:
 - `opennori draft --goal "<goal>" --root <repo>`: create a draft Nori Contract that needs user approval.
 - `opennori draft --from-brainstorm <brainstorm-id> --candidate <A|B|C> --root <repo>`: convert a selected brainstorm direction into a draft contract.
 - `opennori approve --root <repo>`: mark the acceptance basis as approved so completion can be decided.
+- `opennori criterion add --root <repo> --id <id> ...`: add a newly confirmed acceptance boundary to the active contract and ledger.
 - `opennori criterion update --root <repo> --criterion <id> ...`: preserve a user revision as the new acceptance basis.
 - `opennori evidence add --root <repo> --criterion <id> --kind <kind> --summary "<summary>" --result <passing|failing|blocked|waived> --basis <basis> --source '<json-or-label>' --reviewability "<how to review>" --limitations "<known limits>"`: attach user-understandable, reviewable evidence without forcing a fixed adapter.
+- `opennori evidence prune --root <repo> --criterion <id> --reason "<reason>"`: remove invalid or obsolete evidence from an active criterion so reports and context exports only carry current proof.
 - `opennori profile add --root <repo> --type <skill|stack|constraint> --name "<name>" --strength <must|prefer|avoid>`: record user execution preferences separately from ACs.
 - `opennori profile evidence --root <repo> --item <item-id> --result <satisfied|violated|waived>`: record whether the agent followed the profile.
 - `opennori profile show --root <repo>`: show profile compliance and blocking items.

package/README.md

@@ -14,62 +14,67 @@ plan internally, but the user-facing loop stays centered on what the user wants,
 what acceptance checks define done, what evidence supports each check, and
 whether the goal is complete.
 
-## Install
+## Install OpenNori Capability Bundle
 
-Choose one path.
+OpenNori is one agent capability bundle, not three separate products:
 
-### Install the Codex Plugin
+- Codex Plugin distributes and discovers the packaged OpenNori Skills.
+- OpenNori Skills are agent behavior protocols for natural-language work.
+- `opennori` is the deterministic state layer those Skills call.
+- `.opennori/` stores project contracts, evidence, profile, architecture, health, and reports.
 
-Use this when you want Codex to discover OpenNori Skills from natural language:
+First-time setup installs the complete bundle with preview and explicit
+confirmation:
 
 ```bash
-codex plugin marketplace add okbexx/opennori --ref main
-codex plugin add opennori@opennori
+npx opennori setup
+```
+
+Setup previews the Codex Plugin registration, packaged Skill availability,
+global `opennori` CLI installation, current project `.opennori/` initialization,
+and final doctor check before it writes anything.
+
+After setup, initialize any project from that project directory:
+
+```bash
+opennori init
 ```
 
-For local development from a checkout:
+For local OpenNori development from a checkout:
 
 ```bash
 codex plugin marketplace add .
 codex plugin add opennori@opennori
 ```
 
-After installing the plugin, open a new Codex session and say:
+After installing the capability bundle, open a new Codex session and say:
 
 ```text
 Use OpenNori for this goal.
 ```
 
-### Try the CLI once
+For advanced recovery, the setup command is equivalent to previewing and then
+confirming the same official Codex and npm actions:
 
 ```bash
-npx opennori
-```
-
-### Pin the CLI to a project
-
-```bash
-npm install -D opennori
-opennori
+codex plugin marketplace add okbexx/opennori --ref main
+codex plugin add opennori@opennori
+npm install -g opennori@latest
 ```
 
-The Codex Plugin gives agents the Skills. The `opennori` CLI is the
-deterministic state layer those Skills call to create `.opennori/`, update
-contracts, record evidence, run doctor checks, and generate reports. Project
-installs expose `opennori` through npm scripts, package-manager exec, and
-agent/tool environments that load `node_modules/.bin`. Use `npx opennori` when
-you want npm to resolve OpenNori for a one-off command.
+Direct CLI use is an advanced or automation path, not a separate product path
+from the Plugin and Skills.
 
 ## Quick Start
 
-Run OpenNori in a project:
+If OpenNori is already installed on this machine, run the project initializer:
 
 ```bash
-opennori
+opennori init
 ```
 
-The interactive entry previews the `.opennori/` state it would create and asks
-before writing. Agents and CI can use `--json` for deterministic machine-readable
+The initializer previews the `.opennori/` state it would create and asks before
+writing. Agents and CI can use `--json` for deterministic machine-readable
 output.
 
 Then talk to your agent:
@@ -81,9 +86,8 @@ non-trivial work, and keep working from acceptance gaps until the report can
 say whether it is complete.
 ```
 
-Users do not need to memorize CLI flags. OpenNori ships Codex Plugin Skills and
-a Codex marketplace entry; those Skills map natural language to the
-deterministic `opennori` state layer.
+Users do not need to memorize CLI flags or Skill names. The bundled Skills map
+natural language to the deterministic `opennori` state layer.
 
 ## What It Creates
 
@@ -125,14 +129,17 @@ A Nori Contract combines:
 - current acceptance gap
 - completion judgment
 
-Acceptance checks describe user-visible operations and judgments, not files,
-commands, modules, tests, Skills, or technology choices.
+Acceptance checks should describe user-visible operations and judgments, not
+implementation files, modules, tests, Skills, or technology choices. OpenNori
+surfaces likely mistakes as review questions for the agent and user; it does
+not reject a contract just because a heuristic sees a technical word.
 
 ### Acceptance Discovery
 
-Nori should not accept vague criteria such as "modify fields" or "show an
-error". Before drafting a contract, OpenNori helps the agent ask the questions
-that decide whether the user can accept the result:
+Nori should review vague criteria such as "modify fields" or "show an error"
+with the user instead of silently treating them as done. Before drafting or
+claiming confident completion, OpenNori helps the agent ask the questions that
+decide whether the user can accept the result:
 
 - which fields can be changed
 - what validation rules apply
@@ -153,6 +160,11 @@ project evidence conflicts with it, the agent creates an Architecture Challenge
 instead of silently changing the technology stack, state model, dependency
 policy, or directory boundary.
 
+Missing, challenged, or stale architecture state is reported as
+`architecture_review`: the Product AC can be objectively complete, but OpenNori
+will not report confident completion until the agent or user reviews the
+architecture risk.
+
 ### Evidence Record
 
 Evidence can come from tests, screenshots, URLs, artifacts, logs, human
@@ -160,12 +172,28 @@ confirmation, waivers, or other reviewable sources. OpenNori keeps evidence
 flexible, but high-risk completion should not rely only on an agent's
 self-summary.
 
+### Next Loop Candidates
+
+When a goal is confidently complete, `resume`, `status`, `next`, `report`, and
+context export include `next_recommendation.candidate_goals`. These are small
+candidate starts for the next Nori Contract: each candidate names the goal, user
+value, acceptance directions, and risks.
+
+Candidate goals are not phases, task lists, approved acceptance checks, or
+completion evidence. They help the agent continue after the user says
+"continue" without making the user invent the next prompt from scratch.
+
 ### Nori Profile
 
 Nori Profile records execution preferences such as required Skills, preferred
 stacks, avoided tools, and install policy. These preferences influence
 completion risk and blocking status, but they are not user acceptance checks.
 
+Build-vs-buy findings work the same way. They are architecture review risks,
+not Product AC. If self-built infrastructure lacks reuse research or a
+self-build reason, status/report say `build_vs_buy` review is required before
+claiming mature completion.
+
 ## Example Uses
 
 ### Frontend Feature
@@ -176,10 +204,11 @@ User prompt:
 Use OpenNori for a settings page where users edit profile details.
 ```
 
-Nori should reject vague acceptance checks like "modify fields" and ask which
-fields, validation rules, save feedback, persistence behavior, failed-save
-states, and out-of-scope boundaries matter. The final contract should describe
-what the user opens, edits, saves, refreshes, and expects to see.
+Nori should flag vague acceptance checks like "modify fields" as
+`acceptance_review` findings and ask which fields, validation rules, save
+feedback, persistence behavior, failed-save states, and out-of-scope boundaries
+matter. The final contract should describe what the user opens, edits, saves,
+refreshes, and expects to see.
 
 ### Skill And Stack Preference
 
@@ -191,7 +220,9 @@ and avoid adding another UI framework.
 ```
 
 Nori records these as Profile items, not acceptance checks. A violated `must` or
-`avoid` item can block completion unless the user waives it.
+`avoid` item can block completion unless the user waives it. An unknown or
+violated `prefer` item becomes `profile_review`: objectively complete work can
+still require user or agent review before it is reported as confidently complete.
 
 ### Architecture Baseline
 
@@ -206,6 +237,10 @@ Nori lists available architecture profiles, previews the baseline, and asks the
 user to confirm before implementation. Status and report then show Product
 decision and Architecture decision separately.
 
+If all Product ACs pass while the Architecture Baseline is missing, challenged,
+or build-vs-buy is unhealthy, status/report answer: objectively complete with
+review risk, not confidently complete.
+
 ### Existing OpenNori Project
 
 User prompt:
@@ -226,7 +261,8 @@ Users should start with natural language through an agent. These commands are
 the deterministic state layer for agents and automation:
 
 ```bash
-opennori bootstrap
+opennori setup
+opennori init
 opennori doctor --root .
 opennori check --root .
 opennori architecture profiles --root . --json
@@ -237,19 +273,21 @@ opennori draft --goal "Ship a user-visible result" --root .
 opennori approve --root . --summary "User approved the acceptance checks."
 opennori status --root .
 opennori evidence add --root . --criterion AC-1 --kind review-result --summary "..." --result passing
+opennori evidence prune --root . --criterion AC-1 --reason "Evidence no longer proves the current AC"
 opennori report --root .
 ```
 
 ## Product Boundaries
 
-- `bootstrap` gives agents one short entry for readiness checks and first-time
-  preview.
+- `setup` is the first-time machine installer for the complete capability
+  bundle: Codex Plugin, packaged Skills, global CLI, project state, and doctor.
+- `init` prepares or refreshes `.opennori/` state in the current project.
 - `install`, `upgrade`, and `uninstall` support preview-first workflows;
   destructive writes require explicit confirmation.
-- OpenNori Plugin Skills are package assets. Install and upgrade write project
-  state, not project-local copies of OpenNori Skills.
-- In a human terminal, `opennori` is interactive. With `--json` or
-  non-interactive stdio it returns structured JSON.
+- OpenNori Plugin Skills are package behavior protocols for agents. Install and
+  upgrade write project state, not project-local copies of OpenNori Skills.
+- In a human terminal, `opennori setup` and `opennori init` are interactive.
+  With `--json` or non-interactive stdio they return structured JSON.
 - `discover` finds underspecified acceptance gaps before draft, so vague ACs
   become user questions instead of weak contracts.
 - `doctor` reports whether project state is `ready`, `needs-action`, or
@@ -264,6 +302,9 @@ opennori report --root .
 - Context export can give review tools the current goal, checks, profile,
   Architecture Baseline, evidence, and report, but review tools do not take over
   the agent loop.
+- Complete goals can expose `candidate_goals` for the next acceptance loop; the
+  agent still turns the chosen candidate into a new draft Nori Contract before
+  completion judgment begins.
 
 ## Development
 

package/dist/bin/opennori.js

@@ -6,7 +6,7 @@ import { main } from "../src/cli.js";
 export function commandArgsFromProcessArgs(args) {
     const firstArg = args[0];
     return args.length === 0 || (firstArg !== undefined && firstArg.startsWith("-") && !["--help", "-h"].includes(firstArg))
-        ? ["bootstrap", ...args]
+        ? ["setup", ...args]
         : args;
 }
 function printFatalError(error) {

package/dist/bin/opennori.js.map

@@ -1 +1 @@
-{"version":3,"file":"opennori.js","sourceRoot":"","sources":["../../bin/opennori.ts"],"names":[],"mappings":";AACA,OAAO,EAAE,MAAM,SAAS,CAAC;AACzB,OAAO,IAAI,MAAM,WAAW,CAAC;AAC7B,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AACzC,OAAO,EAAE,IAAI,EAAE,MAAM,eAAe,CAAC;AAErC,MAAM,UAAU,0BAA0B,CAAC,IAAc;IACvD,MAAM,QAAQ,GAAG,IAAI,CAAC,CAAC,CAAC,CAAC;IACzB,OAAO,IAAI,CAAC,MAAM,KAAK,CAAC,IAAI,CAAC,QAAQ,KAAK,SAAS,IAAI,QAAQ,CAAC,UAAU,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,QAAQ,EAAE,IAAI,CAAC,CAAC,QAAQ,CAAC,QAAQ,CAAC,CAAC;QACtH,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,IAAI,CAAC;QACxB,CAAC,CAAC,IAAI,CAAC;AACX,CAAC;AAED,SAAS,eAAe,CAAC,KAAc;IACrC,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC;QAC3B,EAAE,EAAE,KAAK;QACT,KAAK,EAAE;YACL,IAAI,EAAE,kBAAkB;YACxB,OAAO,EAAE,KAAK,YAAY,KAAK,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC;SAChE;KACF,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;AACf,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,eAAe,CAAC,IAAI,GAAG,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC;IAChE,MAAM,IAAI,CAAC,0BAA0B,CAAC,IAAI,CAAC,CAAC,CAAC;AAC/C,CAAC;AAED,SAAS,kBAAkB;IACzB,MAAM,WAAW,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IACpC,IAAI,WAAW,KAAK,SAAS;QAAE,OAAO,KAAK,CAAC;IAC5C,MAAM,WAAW,GAAG,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACnD,IAAI,CAAC;QACH,OAAO,EAAE,CAAC,YAAY,CAAC,IAAI,CAAC,OAAO,CAAC,WAAW,CAAC,CAAC,KAAK,EAAE,CAAC,YAAY,CAAC,WAAW,CAAC,CAAC;IACrF,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,IAAI,CAAC,OAAO,CAAC,WAAW,CAAC,KAAK,WAAW,CAAC;IACnD,CAAC;AACH,CAAC;AAED,IAAI,kBAAkB,EAAE,EAAE,CAAC;IACzB,eAAe,EAAE,CAAC,KAAK,CAAC,CAAC,KAAc,EAAE,EAAE;QACzC,eAAe,CAAC,KAAK,CAAC,CAAC;QACvB,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;IACvB,CAAC,CAAC,CAAC;AACL,CAAC"}
+{"version":3,"file":"opennori.js","sourceRoot":"","sources":["../../bin/opennori.ts"],"names":[],"mappings":";AACA,OAAO,EAAE,MAAM,SAAS,CAAC;AACzB,OAAO,IAAI,MAAM,WAAW,CAAC;AAC7B,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AACzC,OAAO,EAAE,IAAI,EAAE,MAAM,eAAe,CAAC;AAErC,MAAM,UAAU,0BAA0B,CAAC,IAAc;IACvD,MAAM,QAAQ,GAAG,IAAI,CAAC,CAAC,CAAC,CAAC;IACzB,OAAO,IAAI,CAAC,MAAM,KAAK,CAAC,IAAI,CAAC,QAAQ,KAAK,SAAS,IAAI,QAAQ,CAAC,UAAU,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,QAAQ,EAAE,IAAI,CAAC,CAAC,QAAQ,CAAC,QAAQ,CAAC,CAAC;QACtH,CAAC,CAAC,CAAC,OAAO,EAAE,GAAG,IAAI,CAAC;QACpB,CAAC,CAAC,IAAI,CAAC;AACX,CAAC;AAED,SAAS,eAAe,CAAC,KAAc;IACrC,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC;QAC3B,EAAE,EAAE,KAAK;QACT,KAAK,EAAE;YACL,IAAI,EAAE,kBAAkB;YACxB,OAAO,EAAE,KAAK,YAAY,KAAK,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC;SAChE;KACF,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;AACf,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,eAAe,CAAC,IAAI,GAAG,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC;IAChE,MAAM,IAAI,CAAC,0BAA0B,CAAC,IAAI,CAAC,CAAC,CAAC;AAC/C,CAAC;AAED,SAAS,kBAAkB;IACzB,MAAM,WAAW,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IACpC,IAAI,WAAW,KAAK,SAAS;QAAE,OAAO,KAAK,CAAC;IAC5C,MAAM,WAAW,GAAG,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACnD,IAAI,CAAC;QACH,OAAO,EAAE,CAAC,YAAY,CAAC,IAAI,CAAC,OAAO,CAAC,WAAW,CAAC,CAAC,KAAK,EAAE,CAAC,YAAY,CAAC,WAAW,CAAC,CAAC;IACrF,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,IAAI,CAAC,OAAO,CAAC,WAAW,CAAC,KAAK,WAAW,CAAC;IACnD,CAAC;AACH,CAAC;AAED,IAAI,kBAAkB,EAAE,EAAE,CAAC;IACzB,eAAe,EAAE,CAAC,KAAK,CAAC,CAAC,KAAc,EAAE,EAAE;QACzC,eAAe,CAAC,KAAK,CAAC,CAAC;QACvB,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;IACvB,CAAC,CAAC,CAAC;AACL,CAAC"}

package/dist/src/acceptance.d.ts

@@ -5,7 +5,8 @@ export declare function discoverAcceptanceGaps(text: string, { fallback, allowed
     allowedIds?: Set<string> | null | undefined;
 }): AcceptanceDiscoveryGap[];
 export declare function discoverAcceptance(goal: string, explicitId?: string | undefined): AcceptanceDiscovery;
-export declare function auditAcceptanceQuality(contract: NoriContract): AcceptanceQualityAudit;
+export declare function reviewAcceptanceQuality(contract: NoriContract): AcceptanceQualityAudit;
+export declare const auditAcceptanceQuality: typeof reviewAcceptanceQuality;
 export declare function renderDiscoveryMarkdown(discovery: AcceptanceDiscovery): string;
 export declare function renderBrainstormMarkdown(brainstorm: Brainstorm): string;
 export declare function briefFromGoal(goal: string, goalId?: string | undefined): NoriBrief;

package/dist/src/acceptance.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"acceptance.d.ts","sourceRoot":"","sources":["../../src/acceptance.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EACV,mBAAmB,EACnB,mBAAmB,EACnB,sBAAsB,EACtB,sBAAsB,EAEtB,UAAU,EAEV,SAAS,EACT,YAAY,EACb,MAAM,YAAY,CAAC;AAyCpB,eAAO,MAAM,gBAAgB,EAAE,mBAAmB,EAsBjD,CAAC;AA0DF,wBAAgB,sBAAsB,CAAC,IAAI,EAAE,MAAM,EAAE,EAAE,QAAgB,EAAE,UAAuC,EAAE;;;CAAK,GAAG,sBAAsB,EAAE,CAyBjJ;AAMD,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,MAAM,EAAE,UAAU,GAAE,MAAM,GAAG,SAAqB,GAAG,mBAAmB,CAkBhH;AAED,wBAAgB,sBAAsB,CAAC,QAAQ,EAAE,YAAY,GAAG,sBAAsB,CA4ErF;AAED,wBAAgB,uBAAuB,CAAC,SAAS,EAAE,mBAAmB,GAAG,MAAM,CA+B9E;AAED,wBAAgB,wBAAwB,CAAC,UAAU,EAAE,UAAU,GAAG,MAAM,CAiCvE;AAED,wBAAgB,aAAa,CAAC,IAAI,EAAE,MAAM,EAAE,MAAM,GAAE,MAAM,GAAG,SAAqB,GAAG,SAAS,CAO7F;AAED,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,EAAE,UAAU,GAAE,MAAM,GAAG,SAAqB,GAAG,UAAU,CAUpG;AAED,wBAAgB,mBAAmB,CAAC,UAAU,EAAE,UAAU,EAAE,WAAW,EAAE,MAAM,GAAG,SAAS,CAkB1F"}
+{"version":3,"file":"acceptance.d.ts","sourceRoot":"","sources":["../../src/acceptance.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EACV,mBAAmB,EACnB,mBAAmB,EACnB,sBAAsB,EACtB,sBAAsB,EAEtB,UAAU,EAEV,SAAS,EACT,YAAY,EACb,MAAM,YAAY,CAAC;AAyCpB,eAAO,MAAM,gBAAgB,EAAE,mBAAmB,EAsBjD,CAAC;AA0MF,wBAAgB,sBAAsB,CAAC,IAAI,EAAE,MAAM,EAAE,EAAE,QAAgB,EAAE,UAAuC,EAAE;;;CAAK,GAAG,sBAAsB,EAAE,CAyBjJ;AAMD,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,MAAM,EAAE,UAAU,GAAE,MAAM,GAAG,SAAqB,GAAG,mBAAmB,CAkBhH;AAED,wBAAgB,uBAAuB,CAAC,QAAQ,EAAE,YAAY,GAAG,sBAAsB,CAsJtF;AAED,eAAO,MAAM,sBAAsB,gCAA0B,CAAC;AAE9D,wBAAgB,uBAAuB,CAAC,SAAS,EAAE,mBAAmB,GAAG,MAAM,CA+B9E;AAED,wBAAgB,wBAAwB,CAAC,UAAU,EAAE,UAAU,GAAG,MAAM,CAiCvE;AAED,wBAAgB,aAAa,CAAC,IAAI,EAAE,MAAM,EAAE,MAAM,GAAE,MAAM,GAAG,SAAqB,GAAG,SAAS,CAO7F;AAED,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,EAAE,UAAU,GAAE,MAAM,GAAG,SAAqB,GAAG,UAAU,CAUpG;AAED,wBAAgB,mBAAmB,CAAC,UAAU,EAAE,UAAU,EAAE,WAAW,EAAE,MAAM,GAAG,SAAS,CAkB1F"}