opennori 0.1.7 → 0.1.9

package/.agents/plugins/marketplace.json

@@ -0,0 +1,20 @@
+{
+  "name": "opennori",
+  "interface": {
+    "displayName": "OpenNori"
+  },
+  "plugins": [
+    {
+      "name": "opennori",
+      "source": {
+        "source": "local",
+        "path": "./plugins/opennori"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Productivity"
+    }
+  ]
+}

package/.opennori/protocol.md

@@ -6,6 +6,7 @@ The human-facing surface is acceptance state:
 
 - goal
 - user acceptance criteria
+- architecture baseline decision
 - current acceptance gap
 - evidence summary
 - final status
@@ -13,6 +14,20 @@ The human-facing surface is acceptance state:
 Implementation plans are allowed inside the agent's private reasoning, but they are not the default
 progress surface and they are not completion evidence.
 
+For non-trivial goals, OpenNori also carries an Architecture Baseline. Product AC answers what the
+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.
@@ -63,6 +78,7 @@ The operator layer proves that Codex can actually use OpenNori as the work proto
 | AC-O-6 | Codex conversation | Revise an AC after new facts appear | The changed acceptance basis is preserved. | Updated ACs become the basis for `current_gap` and completion; old criteria are not silently reused. |
 | AC-O-7 | Codex conversation | Ask OpenNori to brainstorm a fuzzy idea | The user sees selectable acceptance directions without remembering CLI syntax. | Brainstorm candidates describe user value, observable acceptance direction, and risk; they are not treated as a contract or completion evidence. |
 | AC-O-8 | Codex conversation | State required Skills, preferred stacks, avoided tools, or execution constraints | The agent records a Nori Profile without making the user remember CLI syntax. | Must/avoid profile items are shown in contract and report; unsatisfied must items or violated avoid items block completion unless waived. |
+| AC-O-9 | Codex conversation | Ask OpenNori to use a good architecture for a non-trivial goal | The user sees Product AC and an Architecture Baseline before implementation starts. | The baseline is not a plan; it names the architecture profile, boundaries, build-vs-buy policy, and challenge rule. |
 
 ### L3 Productization AC
 
@@ -71,18 +87,24 @@ a durable workflow asset.
 
 | ID | Tool / entrypoint | User operation | User acceptance criterion | Passing threshold |
 | --- | --- | --- | --- | --- |
-| AC-Z-1 | CLI | Run `opennori skill export` | The user gets a usable Codex Skill draft for OpenNori. | The Skill tells agents to drive work through resume, next, evidence, evaluate, status, and report. |
-| 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-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 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. |
 | AC-Z-6 | Project file browser | Inspect the project after running OpenNori | The user sees OpenNori-owned state under `.opennori/` instead of a generic project `process/` directory. | Install, draft, brainstorm, report, and archive write OpenNori state under `.opennori/` by default. |
-| AC-Z-7 | CLI / project file browser | Run `opennori install` | The user can inspect project OpenNori registration and judge version, managed entries, active goals, Skill status, and protocol capabilities. | Install output uses create, skip, overwrite, or update semantics; `.opennori/manifest.json` records version, managed files, active goals, Skill state, and capabilities. |
-| AC-Z-8 | CLI | Run `opennori doctor` | The user can judge whether the project is `ready`, `needs-action`, or `broken`, and see the next recovery action. | Doctor checks `.opennori` structure, manifest consistency, active goal recoverability, Skill sync, CLI runtime, and recovery suggestions. |
+| AC-Z-7 | CLI / project file browser | Run `opennori install` | The user can inspect project OpenNori registration and judge version, managed entries, active goals, Plugin Skill availability, and protocol capabilities. | Install output uses create, skip, overwrite, or update semantics; `.opennori/manifest.json` records version, managed files, active goals, Plugin state, architecture state, and capabilities. |
+| AC-Z-8 | CLI | Run `opennori doctor` | The user can judge whether the project is `ready`, `needs-action`, or `broken`, and see the next recovery action. | Doctor checks `.opennori` structure, manifest consistency, active goal recoverability, packaged Plugin Skills, CLI runtime, and recovery suggestions. |
 | 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 | CLI / Codex Skills | Install OpenNori Skill Pack | The agent gets focused OpenNori Skills for acceptance, evidence, Nori Profile, project health, and reporting while the user keeps using natural language. | `opennori skill export --pack` exposes the pack; `opennori install --skill` writes it; manifest records `skill_pack`; doctor detects missing or stale pack 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
 
@@ -92,6 +114,7 @@ OpenNori writes its project-local state under `.opennori/`.
 .opennori/
   manifest.json
   protocol.md
+  agent-guide.md
   active/
     <goal>.acceptance.md
     <goal>.evidence.json
@@ -99,6 +122,13 @@ OpenNori writes its project-local state under `.opennori/`.
   blocked/
   reports/
   brainstorms/
+  architecture/
+    baseline.json
+    baseline.md
+    profiles/
+    challenges/
+    decisions/
+    evidence/
 ```
 
 Each active goal has:
@@ -112,11 +142,13 @@ Each active goal has:
 - OpenNori package version
 - managed `.opennori` files and directories
 - active goals recoverable from `.opennori/active`
-- optional repo-local OpenNori Skill state
-- optional repo-local OpenNori Skill Pack state
+- OpenNori Plugin and package Skill asset state
+- 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:
@@ -134,30 +166,48 @@ Real `opennori install --force` can overwrite OpenNori-managed files, so it requ
 Run `opennori install --dry-run --force` first to inspect destructive actions, then rerun with
 `--confirm` only if those writes are acceptable.
 
-`opennori uninstall --dry-run` returns an uninstall plan. By default it removes entry assets such as the
-repo-local OpenNori Skill and manifest, while preserving Nori Contracts, evidence records,
-reports, archives, and brainstorms. Real uninstall requires `--confirm`. Deleting the whole `.opennori`
-state directory requires both `--include-state` and `--confirm`.
+`opennori uninstall --dry-run` returns an uninstall plan. By default it removes the manifest while
+preserving Nori Contracts, evidence records, reports, archives, brainstorms, protocol, guide, and
+architecture state. Real uninstall requires `--confirm`. Deleting the whole `.opennori` state
+directory requires both `--include-state` and `--confirm`.
 
-## Skill Pack
+## OpenNori Plugin Skills
 
-OpenNori exposes a Skill Pack for agent use. 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
 - `nori-evidence`: record reviewable evidence without forcing fixed adapters
 - `nori-capability-profile`: record required Skills, preferred stacks, avoided tools, and install policy
-- `nori-project-health`: install, uninstall, doctor, manifest, and Skill Pack sync
-- `nori-reporting`: status, report, current gap, user intervention, and changes
-
-`opennori install --skill` installs the pack under `.agents/skills/`. The manifest records `skill_pack`
-state, and `opennori doctor` checks whether the pack is installed and in sync.
+- `nori-architecture-brainstorm`: select or create an Architecture Baseline before non-trivial implementation
+- `nori-architecture-apply`: read and apply the confirmed baseline before implementation
+- `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, 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`
+writes project state under `.opennori/`; it does not copy OpenNori Skills into the user's project.
+The manifest records `plugin` state, and `opennori doctor` checks whether packaged Plugin Skills are
+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 and reports `acceptance_quality` warnings for vague ACs
-such as "modify profile fields" or "show an error". It does not rewrite existing contracts, evidence,
-reports, archives, or brainstorms. The user decides whether to revise affected criteria.
+`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
 
@@ -180,12 +230,76 @@ 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
 need to remember `opennori profile` commands.
 
+## Architecture Baseline
+
+Architecture Baseline is separate from Product AC. It is not a plan, phase list, task list, or
+implementation checklist. It is sticky architecture guidance for agents and maintainers:
+
+- selected Architecture Profile
+- goal it applies to
+- architecture principles and boundaries
+- Architecture Checks for maintainers or agents
+- preferred libraries or technologies
+- avoid policy
+- build-vs-buy policy
+- challenge policy
+- agent-readable surfaces
+
+OpenNori includes built-in profiles and supports project profiles under:
+
+```text
+.opennori/architecture/profiles/<profile-id>.json
+```
+
+Use `opennori architecture profiles --root <project> --json` to list built-ins and project profiles.
+The output is intentionally reviewable before baseline confirmation: each profile includes suitable
+use cases, reference sources, architecture principles, checks, preferred libraries, avoid
+boundaries, validation issues, and build-vs-buy policy.
+Use `opennori architecture profile --root <project> --from <profile.json> --json` to add a reviewed
+project profile. Existing profiles are not overwritten unless the agent uses `--force` after review.
+
+Use `opennori architecture baseline --root <project> --goal "<goal>" --profile <profile-id> --json`
+to preview a baseline. Preview has no side effect. After the user accepts it, rerun with `--confirm`.
+
+Once confirmed, the baseline is written to:
+
+- `.opennori/architecture/baseline.json`
+- `.opennori/architecture/baseline.md`
+- `.opennori/agent-guide.md`
+
+Agent route files such as `AGENTS.md` or `CLAUDE.md` should point new sessions to these surfaces.
+`opennori doctor` checks that the baseline exists when an active goal requires it, that the schema is
+valid, and that at least one agent route references `.opennori/architecture/baseline.md`.
+
+If project evidence conflicts with a confirmed baseline, the agent must create an Architecture
+Challenge instead of silently changing stack, dependency policy, directory boundaries, state model,
+or project architecture:
+
+```bash
+opennori architecture challenge --root <project> --summary "<conflict>" --evidence "<evidence>" --recommendation "<change>" --json
+```
+
+Build-vs-buy decisions are first-class architecture evidence. Before self-building infrastructure,
+the agent checks current project dependencies, standard libraries, official SDKs, mature
+open-source libraries, and documented reference projects:
+
+```bash
+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
@@ -194,7 +308,17 @@ need to remember `opennori profile` commands.
 - `blocked`: user decision or external condition required
 - `waived`: user explicitly accepts the unmet criterion with a reason
 
-The workflow is complete only when every required criterion is `passing` or `waived`.
+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, `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
 
@@ -239,6 +363,9 @@ When the agent submits evidence, the user-facing record should explain:
 
 The shape is intentionally open. OpenNori should preserve arbitrary source metadata instead of forcing
 all evidence through a narrow adapter taxonomy.
+`evidence_health` audits that reviewability surface without forcing an adapter taxonomy: it warns
+about missing sources, missing reviewability, missing limitations, stale timestamps, and broad batch
+summaries.
 
 ## Agent Rule
 
@@ -253,13 +380,20 @@ On every turn:
 7. Show the draft acceptance criteria and ask the user to approve or revise them.
 8. After approval, run `opennori approve --root <repo> --summary "<approval>" --json`.
 9. If the user states required Skills, preferred stacks, avoided tools, install policy, or execution constraints, run `opennori profile add --root <repo> ... --json` and keep those items out of the user acceptance criteria.
-10. If the user revises a criterion later, run `opennori criterion update --root <repo> --criterion <id> ... --json`; old evidence for the changed criterion is cleared.
-11. If the user asks to upgrade an existing OpenNori project, run `opennori doctor`, preview and confirm `opennori upgrade`, then run `opennori check`; ask the user before revising any existing AC flagged by `acceptance_quality`.
-12. Run `opennori resume --root <repo>` or `opennori next --root <repo>` to recover the active goal and current acceptance gap from repository files.
-13. Work only to produce evidence for that gap.
-14. 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.
+10. For non-trivial goals, run `opennori architecture profiles --root <repo> --json`, preview a baseline, show it to the user, and confirm it before implementation.
+11. If the user provides a preferred architecture, add it with `opennori architecture profile --root <repo> --from <profile.json> --json` before previewing the baseline.
+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 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:
 
@@ -268,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.
@@ -277,7 +413,7 @@ Useful commands:
 - `opennori install --root <repo>`: create or refresh project-local OpenNori assets and manifest.
 - `opennori upgrade --root <repo>`: preview and refresh project-local OpenNori assets without rewriting active contracts or evidence.
 - `opennori doctor --root <repo>`: inspect project OpenNori health and recovery actions.
-- `opennori check --root <repo>`: validate active contract structure and audit active ACs for underspecified acceptance quality.
+- `opennori check --root <repo>`: validate active contract structure, audit active ACs for underspecified acceptance quality, surface Architecture Baseline health for the active goal, and report evidence health.
 - `opennori resume --root <repo>`: recover the active goal, current gap, completion answer, and intervention state.
 - `opennori status --root <repo>`: answer whether the goal is complete and whether the user needs to act.
 - `opennori report --root <repo>`: generate the human acceptance report.