agentera 3.0.0-dev.6 → 3.0.0-dev.69

package/bundle/skills/agentera/SKILL.md

@@ -1,422 +1,175 @@
 ---
 name: agentera
 description: >
-  Agentera agent engine for editor runtimes. One Agentera skill with twelve
-  capabilities; per-capability prose lives in
+  One agent, one CLI, many capabilities. Per-capability instructions live in
   `packages/cli/src/capabilities/<name>/instructions.ts` and the runtime serves
-  it through `agentera prime --context <name> --format json`. Use this skill
-  for /agentera, Agentera capability requests, and a complete user message
-  exactly `hej`; bare `hej` runs the agentera prime orientation dashboard path
-  instead of a generic greeting.
+  it through `npx -y agentera@next prime --context <name> --format json`. Use this skill
+  for /agentera and Agentera capability requests; bare `/agentera` runs the
+  prime orientation dashboard path instead of a generic greeting.
 version: "3.0.0"
 spec_sections: [1, 2, 3, 4, 5, 6, 11, 13, 18, 19, 20, 22, 23]
 capabilities:
-  - hej
-  - visionera
-  - resonera
-  - inspirera
-  - planera
-  - realisera
-  - optimera
-  - inspektera
-  - dokumentera
-  - profilera
-  - visualisera
-  - orkestrera
+  - status
+  - vision
+  - discuss
+  - research
+  - plan
+  - build
+  - optimize
+  - audit
+  - document
+  - profile
+  - design
+  - orchestrate
 ---
 
 # agentera
 
-One install, one entry point, one query interface to all project state. Twelve capabilities live inside one Agentera skill.
+One agent, one CLI, many capabilities. The CLI owns project memory,
+capability instructions, the deterministic routing tiers, and the worker-spec
+contract. The host owns open-ended semantic judgment from the trigger intent
+documentation after deterministic abstention; it learns that contract from the CLI.
 
 ---
 
-## Shared Protocol
+## Bootstrap
 
-All capabilities reference shared primitives defined in `protocol.yaml`:
-
-- **Confidence scale**: 0-100, five tiers with explicit boundaries
-- **Severity levels**: finding vocabulary and issue vocabulary
-- **Visual tokens**: status, severity, confidence, and trend glyphs
-- **Phase model**: five phases with valid transitions
-
-Capabilities import these by name. The schema contract ensures consistent usage.
-
----
-
-## Capabilities
-
-| | Capability | Primary route | Purpose |
-|---|---|---|---|
-| ⌂ | hej | `/agentera status` | Orientation and routing |
-| ⛥ | visionera | `/agentera vision` | Define project direction |
-| ❈ | resonera | `/agentera discuss` | Structured deliberation |
-| ⬚ | inspirera | `/agentera research` | External pattern analysis |
-| ≡ | planera | `/agentera plan` | Planning with acceptance criteria |
-| ⧉ | realisera | `/agentera build` | Autonomous development |
-| ⎘ | optimera | `/agentera optimize` | Metric-driven optimization |
-| ⛶ | inspektera | `/agentera audit` | Codebase health audit |
-| ▤ | dokumentera | `/agentera document` | Documentation |
-| ♾ | profilera | `/agentera profile` | Decision profiling |
-| ◰ | visualisera | `/agentera design` | Visual identity system |
-| ⎈ | orkestrera | `/agentera orchestrate` | Multi-cycle orchestration |
-
----
-
-## Routing Logic
-
-When a request arrives, route to the matching capability using the five-layer routing model from Decision 42.
-
-### Prerequisite: Single-call installed CLI gate
-
-This gate is mandatory, but the gate and the orientation dashboard source are the same
-installed CLI invocation. For bare `/agentera` or bare `hej`, the first normal
-state-access tool call is:
+Run one pre-cutover `@next` call for orientation. It is read-only in fresh, v2,
+partially migrated, and v3 projects. A Git-root project with no `.agentera`
+state is `fresh_uninitialized`: `prime --context plan` is operable and its first
+`state plan create` is the sole initializer. Recognized v2 state returns the
+full entity-upgrade recovery; partial, corrupt, and unknown marker-absent state
+returns read-only recovery. V3 returns `ok` unless health is degraded. The JSON
+also returns bounded app status, state slices, attention, and startup
+availability.
 
 ```bash
-npx -y agentera prime
+npx -y agentera@next prime --context status --format json
 ```
 
-Resolve `RESOLVED_AGENTERA_HOME` with the app-home precedence `AGENTERA_HOME`
-when set, otherwise the platform data home. Do not run `glob`, `grep`, `read`,
-`ls`, `python`, `doctor`, `--help`, `registry.json`,
-or `.agentera-bundle.json` preflight checks before this call. The CLI owns app
-validation, v1 detection, profile detection, artifact condensation, and the
-`source_contract` that tells the caller how to render the dashboard.
-Never combine the app-home assignment with the same shell command that expands
-the managed app script path; shell expansion can otherwise turn an unset
-`AGENTERA_HOME` into `npx -y agentera` before the assignment takes effect.
-
-If the command exits successfully, inspect the CLI-provided `bundle.status`
-installed-app status object. If its value is `fresh`, treat the installed app gate as passed
-for that briefing and render from the output. The object includes
-`expectedVersion`, `expectedVersionSource`, `appHome`, `managedAppRoot`,
-`userDataRoot`, repair commands, and approval text.
-
-### User-facing repair wording
-
-Recovery and troubleshooting prompts must be plain enough for a non-technical
-user. Never ask the user to choose between technical install concepts, internal
-directory states, command-mode flags, or package-layout terms. Keep those as
-internal facts.
-User-facing copy must answer four questions in this order:
-
-1. What happened: `Agentera found an old or broken local copy of itself.`
-2. What the preview did: `Nothing was changed.`
-3. What the recommended fix will do: `Install a fresh Agentera app copy in the normal Agentera directory.`
-4. What it will not do: `It will not edit your project files, shell startup files, or unknown directories.`
-
-Use recommendation-first choices only when a choice is unavoidable. Put the safe
-default first and name it as the recommendation. Good labels: `Use the safe fix
-(Recommended)`, `Choose a different directory`, `Stop`. Bad labels: `Use platform
-home`, `Force old directory`, or labels that expose internal flags and app-file
-packaging terms.
-Only mention commands and paths after the plain explanation, as technical detail.
-
-If the command cannot execute because `AGENTERA_HOME` names the old default
-`$HOME/.agents/agentera` and `npx -y agentera` is missing,
-do not require a successful failed CLI invocation and do not first ask the user to
-unset `AGENTERA_HOME`. Tell the user: `Agentera found an old or broken local copy
-of itself. The safe fix is to install a fresh copy in the normal Agentera directory.`
-Then show this preview command and say it changes nothing:
+An `ok` outcome needs no fallback or second dashboard call. Follow an exact
+recovery command for other outcomes; every returned v3 command stays on
+`npx -y agentera@next`. Do not use bare or stable-channel CLI forms before
+stable promotion. For deeper read-only evidence, run
+`npx -y agentera@next doctor --format json`.
+
+For capability-specific startup context:
 
 ```bash
-npx -y agentera@latest doctor
+npx -y agentera@next prime --context <capability> --format json
 ```
 
-This preview writes nothing. Because no explicit `--install-root` is supplied,
-upgrade can choose the normal platform app directory and preview repair for app
-files, managed runtime surfaces, and cleanup of the old directory. Ask for
-explicit approval before writes, using plain wording such as
-`Approve the safe Agentera repair at <directory>`. After approval, apply the same
-safe repair path:
+This returns the capability's instructions, declared read/write needs, artifact
+inventory, and `capability_context.startup`. Check its `outcome` (`ok`,
+`degraded`, or `blocked`). The `availability` rows identify bounded included
+families and deferred families; use a deferred row's `detail_command` for
+detail. Use this response before reading the instructions module directly.
+
+For static routing guidance (CLI vs native tools):
 
 ```bash
-npx -y agentera@latest prime
+npx -y agentera@next prime --guidance
 ```
 
-After apply, retry the installed command from the platform app home reported by
-the upgrade output, not from the old default directory. If the command executes but
-fails before argparse, reports `invalid choice` for `prime`, or reports a status of
-`outdated`, `manual_review_needed`, missing-command, or repair-needed:
+### Upgrade from v2 to v3 development
 
-- Say `Agentera found an old or broken local copy of itself.`
-- Say whether the preview changed anything; preview commands change nothing.
-- State the safe recommendation in plain language before paths or commands.
-- Show the clone-free preview command from `bundle.dryRunCommand` when present:
+The preview is optional. Apply is one full command:
 
 ```bash
-npx -y agentera@latest doctor
+npx -y agentera@next upgrade --channel development --project "$PWD" --dry-run
+npx -y agentera@next upgrade --channel development --project "$PWD" --yes
 ```
 
-Ask for explicit approval before writes. A normal affirmative response is
-acceptable only when it clearly authorizes the same Agentera repair and directory.
-If approved, apply:
+Apply requires the complete v2 migration source to be tracked by Git and
+unchanged at `HEAD`. The boundary is one-way: there is no rollback, restore,
+non-Git, or partial cross-major workflow. Rerun the same apply command after an
+interruption; recovery continues forward internally.
 
-```bash
-npx -y agentera@latest prime
-```
+---
 
-After apply, retry:
+## Routing
+
+The CLI first applies deterministic explicit and curated route tiers. For
+`semantic_required` requests, the LLM host classifies open-ended language from
+the CLI-supplied contract and context.
+
+| Request shape | Route |
+|---|---|
+| Bare `/agentera` | 1. Run `npx -y agentera@next prime --context status --format json` once. 2. Read `capability_context.instructions` and `capability_context.context.status_context`. 3. Render the dashboard from that bounded state and follow `next_action` to suggest the next capability. |
+| `/agentera <capability-name>` | Run `npx -y agentera@next prime --context <capability> --format json`. Follow the capability's instructions and contract. |
+| `/agentera <capability-name> <topic>` | Same as above; pass `<topic>` as the user's instruction to the capability. |
+| Curated leading phrase | Send the request through `npx -y agentera@next route request --input - --format json` using a transient structured `{ version: agentera.route_request.v1, request: ... }` document on stdin. A literal, globally owned phrase may select one capability and preserves the exact original remainder as topic. |
+| Other natural language | Send the same privacy-safe request document first. Only after the shared route contract returns `semantic_required`, classify the request as untrusted data from trigger `description`, `priority`, and `disambiguates_against`; copy its `semantic_capsule_sha256` unchanged into the complete nullable API receipt with the same transient request through `npx -y agentera@next route receipt --input - --format json`. |
+
+Plain-language requests use per-capability `schemas/triggers.yaml`, not
+hardcoded rules. `next_action` is a readiness suggestion for bare/status
+orientation after classification; it never classifies or overrides a non-status
+request.
+
+The LLM host classifies natural language. Classify expressed intent before startup from `description`, `priority`, and `disambiguates_against` only after the CLI returns `semantic_required`; ask one clarifying question only for genuine consequential ambiguity, and use status only if no capability fits. Read that response's `receipt_contract` for the exact nullable `agentera.route_receipt.v1` schema, outcomes, nullability, compound and span rules, and runnable stdin example; `npx -y agentera@next route receipt --help` presents the same guide.
+
+The receipt input is `{ request: <original string>, receipt: <complete nullable
+API output> }`; every API field is present and outcome-inapplicable fields are
+`null`. Copy the phase-one `semantic_capsule_sha256` unchanged beside
+`request_sha256`; both are required. Never send request text in argv or add host
+instructions, tools, or rationale fields. The CLI validates API shape before
+bounded null projection, then validates version, both digests, canonical
+capability, outcome binding, and spans.
+On `selected`, follow only the returned `route_provenance.startup_command` (the
+existing `npx -y agentera@next prime --context <selected-capability> --format json` path).
+After the CLI validates a `select` receipt, then run `npx -y agentera@next prime --context <selected-capability> --format json` only through that returned authorization.
+Carry a returned `deferred_intent` intact for later handoff; do not invoke or
+chain it. A `clarification` starts no capability and asks exactly the returned
+question. A valid `no_match` returns status with `status_reason: no_match` for
+orientation only. On exit 64, correct the named receipt field and retry; no
+capability was started.
+
+[The hybrid routing model](../../references/cli/routing-model.md) defines the
+shared two-phase request/receipt contract. Open-ended language remains LLM-owned:
+no scores, thresholds, or borderline band. The phrase registry is the only
+deterministic natural-language authority; do not revive legacy trigger patterns,
+regexes, thresholds, or bands. `next_action` never classifies or overrides a
+request, and a compound remainder is preserved rather than silently chained.
+Decision mpulyomlyl supersedes Decision 76 only for this curated literal fast
+path.
+
+Run `npx -y agentera@next route evaluate --format json` to evaluate the frozen visible
+development and adversarial corpus. Its report binds the protocol, phrase
+authority, and shared-skill hashes, labels every result with a routing tier, and
+keeps request text out of output. It proves protocol conformance, not semantic
+generalization. It does not invoke a semantic host: deterministic and
+receipt-validation conformance and run-specific local p95 values are measured
+locally, while semantic model quality and latency are host-dependent and
+explicitly unmeasured.
+
+Handoff verbs:
+
+- `route`: user directly invoked a capability. Consent to invoke; no extra confirmation.
+- `suggest`: recommend a downstream capability and wait for confirmation.
+- `dispatch`: invoke another capability autonomously only when the current capability owns that orchestration flow.
+- `chain`: dispatch multiple capabilities only inside an orchestrated flow.
+
+Capability handoffs use glyph plus canonical name (e.g. `⧉ build`, `≡ plan`).
 
-```bash
-npx -y agentera prime
-```
+---
 
-If `AGENTERA_HOME` names the old default `$HOME/.agents/agentera`, no explicit
-`--install-root` was supplied, and `npx -y agentera` is
-missing or out of date, treat this as safe to preview with the normal Agentera
-directory above. Do not first ask the user to unset `AGENTERA_HOME`; do not claim to
-prove where the environment value came from. If `AGENTERA_HOME` names any other
-missing path, file, or directory with unknown files and the single command cannot
-run, do not overwrite it silently or fall back to a local checkout. Say:
-`Agentera was told to use a directory it cannot safely use. Choose a different
-Agentera directory, or approve --force only after checking that directory is safe to
-replace.`
-
-If a leftover 1.x managed marker block (`# agentera: AGENTERA_HOME (managed)`) is
-reported in shell startup diagnostics, say plainly that Agentera will not edit
-those files. Cleanup is user-owned manual cleanup, not a repair write. Upgrade
-does not scan shell startup files.
-
-Only after the installed CLI succeeds, proceed to Step -1 and the routing layers
-below. Do not fall through to a local checkout as a workaround; the npx commands
-above are portable and require no local checkout.
-
-### Step -1: Top-level CLI-first state access
-
-The `agentera` CLI is the authoritative interface to project state. Use
-top-level state commands for routine access. `agentera query` is reserved for
-advanced/custom artifact inspection when no normal command serves the needed
-state.
-
-Before any artifact-backed briefing, route decision, or capability state read,
-run the top-level command that owns the needed state. The app health gate
-above must have already confirmed the installed CLI is usable.
-
-Routine commands are: `prime`, `state plan`, `state progress`, `state health`,
-`state todo`, `state decisions`, `state docs`, `state objective`, and
-`state experiments`. On the npm 3.x CLI, top-level `hej`, `describe`, `gate`, and
-routine-state names are removed; a smaller transitional alias set still forwards
-with stderr deprecation — see [audience-namespace-cli-migration.yaml](references/cli/audience-namespace-cli-migration.yaml). Discovery and custom
-inspection remain available through `agentera schema --format json`,
-`state query --list-artifacts`, and `state query <artifact-name> --format json|yaml`.
-Structured discovery includes an artifact-location contract with mapped paths,
-normal read commands, and raw-access boundaries; use that contract before
-reading `.agentera/docs.yaml` or probing `.agentera/` for path discovery.
-
-Do not silently bypass the CLI and read raw `.agentera/*.yaml` files first. If
-CLI state declares complete startup coverage, do not perform defensive raw
-artifact reads for normal startup. If CLI state is unavailable or incomplete,
-try the CLI-provided fallback commands first; use raw artifact reads only as a
-last-resort fallback after those paths fail or still declare incomplete state.
-When `agentera state plan --format json` returns
-`source_contract.complete_for_plan_artifact=true`, treat its `summary`,
-`entries`, and `source_contract` as complete for normal `PLAN.md` startup and
-evaluation context; do not read `.agentera/plan.yaml` merely to re-check task
-dependencies, acceptance criteria, evidence, overall acceptance, surprises,
-prior-plan archive references, or plan metadata. This no-raw-read rule is for
-normal read-only startup/evaluation. Raw mapped plan artifact access remains valid
-for writes, archives, validation, corruption diagnostics, or unavailable or
-incomplete CLI state after CLI fallbacks.
-
-When artifact paths are the only missing fact, prefer the CLI discovery contract:
-`agentera schema --format json` exposes `artifact_locations`, and
-`agentera state query --list-artifacts --format json` exposes the same compact records
-with a `names` compatibility list. Plain `state query --list-artifacts` remains the
-human names list. These discovery surfaces do not replace routine state commands
-for normal artifact content reads.
-
-For bare `/agentera` or a bare user message exactly `hej`, run `agentera prime`
-first and render the README-style hej dashboard from that single composite
-result. The CLI output is source data, not the user-facing dashboard; do not
-relay raw `agentera prime` lines as the final briefing. Do not run individual `state plan`, `state progress`, `state health`,
-`state todo`, or `state decisions` commands unless `agentera prime` fails or explicitly asks
-for fallback. The final response must
-transform source labels such as `mode:`, `profile:`, `health:`, `issues:`,
-`plan:`, `objective:`, `attention:`, `next_action:`, `app_home:`,
-`v1_migration:`, and `source_contract:` into the dashboard below; never paste
-those labels as the briefing.
-
-Bare `/agentera` returning-project output must include these visible markers:
-
-```text
-┌─┐┌─┐┌─┐┌┐┌┌┬┐┌─┐┬─┐┌─┐
-├─┤│ ┬├┤ │││ │ ├┤ ├┬┘├─┤
-┴ ┴└─┘└─┘┘└┘ ┴ └─┘┴└─┴ ┴
-
-─── status ─────────────────────────────
-  [metric lines: health, issues, plan, objective, profile as available]
-  [1-2 sentence narrative read closing the status section]
-─── attention ──────────────────────────
-─── next ───────────────────────────────
-```
+## Dashboard rendering
 
-Use the README-style layout from hej Step 1b: metrics first, narrative read
-inside `status`, then attention and next. The issues summary line uses
-`critical · degraded · normal · annoying` in the order prime emits them. Omit `attention` only when the source has no attention items. Always include the
-mandatory `⌂ hej · <status>` marker below the dashboard code fence, and ask for
-confirmation before invoking the suggested downstream capability. For
-`/agentera <capability-name>` or `/agentera <alias>`, do not assume the route
-word is a CLI command. The CLI command surface is state-oriented, not
-capability-oriented:
-use the supported routine state command or commands that own the capability's
-needed artifacts, as declared by that capability's artifact schema. For example,
-`resonera` reads decisions through `agentera state decisions`, not through the
-unsupported capability-name command `agentera resonera`. Never run unsupported
-capability-name commands such as `agentera resonera`, `agentera planera`, or
-`agentera realisera` as a bootstrap step. Shared words stay split by interface:
-`/agentera plan` routes to planera, while `agentera state plan` reads plan state from
-the CLI. When capability-specific startup context is needed, request it through
-`agentera prime --context <capability> --format json`. Use returned
-`capability_context.state.included` directly, and for
-`capability_context.state.missing`, run the listed
-`capability_context.state.fallback_commands` before raw file access. Historical
-v2 paths `hej --capability-context` and `--context-profile` are removed in 3.0.
-For normal ≡ planera execution, use
-`capability_context.context.planning_context.startup_contract` from
-`agentera prime --context planera --format json`
-before reading the Planera prose from
-`packages/cli/src/capabilities/planera/instructions.ts` (served via
-`capability_context.prose` from the same prime call). Read the full Planera
-prose only when editing Planera, resolving contradiction or ambiguity,
-validating detailed behavior not covered by the compact contract, or
-investigating benchmark/read-trigger evidence. This preserves Planera prose
-as detailed authority and does not add `agentera planera`; `/agentera plan`
-remains routing while `agentera state plan` remains plan state (top-level
-`agentera plan` is a migration alias).
-For normal DECISIONS.md context, use `agentera state decisions --format json` and its
-source_contract. When `complete_for_normal_deliberation_context=true`, preserve
-returned `missing_fields`, `compacted`, `caveats`, and `satisfaction.review_needed`
-instead of raw-reading `.agentera/decisions.yaml` to reconstruct missing history.
-Raw decision artifact access is reserved for Resonera-owned writes/repairs,
-artifact corruption diagnostics, or CLI defect investigation.
-Reading a capability's instructions module is not itself a capability invocation;
-invocation means routing to the capability, fetching the prose via
-`agentera prime --context <name> --format json`, following that prose, and using
-the CLI state layer first for artifact-backed state.
-
-Capability handoffs use glyph plus canonical capability name, for example
-`⧉ realisera` or `≡ planera`. Reserve `/agentera <alias>` wording for explicit
-slash-route documentation and do not use standalone slash-capability names such
-as `/realisera` or `/planera` as handoff labels. SG priority codes such as `SG2`
-are internal protocol references; do not render them in user-facing handoff
-labels.
-
-Handoff verbs are normative:
-
-- `route`: the user directly invoked a capability by canonical name, primary
-  alias, or slash route. This is consent to invoke that capability; do not ask
-  for extra handoff confirmation.
-- `suggest`: recommend a downstream capability and wait for user confirmation.
-- `handoff prompt`: ask whether to run the suggested capability. Use the native
-  question tool for multi-choice prompts and for a single state-changing
-  Proceed/Cancel handoff. State-changing means the proposed next step may write
-  artifacts, edit code, run optimization or orchestration cycles, apply
-  migrations, refresh app/runtime state, or otherwise mutate project/runtime
-  state. Use the behavior rule first, with common examples such as ⧉ realisera,
-  ≡ planera when creating or updating plans, ▤ dokumentera when writing docs,
-  ⎘ optimera when running or applying optimization cycles, and ⎈ orkestrera
-  when dispatching cycles. A single non-mutating suggestion may use a free-form
-  prompt; clear replies such as `yes`, `start`, `do it`, or `run <capability>`
-  confirm the named suggestion. Ambiguous replies get one clarifying question.
-- `dispatch`: invoke another capability autonomously only when the current
-  capability explicitly owns that orchestration flow.
-- `chain`: dispatch multiple capabilities autonomously only inside an explicitly
-  orchestrated flow; otherwise suggest the next capability and wait.
-
-The first Agentera/hej response in a fresh interaction should deliver the brief
-and a free-form continuation prompt, not a native question menu, unless the user
-explicitly asks for bounded choices or the suggested next step is a
-state-changing Proceed/Cancel handoff. Mid-conversation, use the runtime's
-native question tool only when there are at least two meaningful non-terminal
-next actions or a consequential Proceed/Cancel decision; state-changing
-capability handoffs are consequential Proceed/Cancel decisions even when there
-is only one suggested action. Do not count `Done` or free-form/custom answer
-affordances as alternatives. Current host examples are Claude Code
-`AskUserQuestion`, Copilot `ask_user`, Codex `request_user_input`, and OpenCode
-`question`. Put the recommended choice first with `(Recommended)` in its label
-and include `Done`. Selecting a downstream capability option is confirmation to
-invoke that capability; selecting `Done` stops without routing. This generic
-question-tool gating applies to hej and capability handoff prompts. Once a
-capability is invoked, that capability's own interaction rules control whether
-the runtime-native question tool is required.
-
-### Step 0: V1 migration handling
-
-Do not perform separate v1 Markdown/YAML discovery before a normal prime briefing.
-The top-level CLI owns v1 detection. For bare `/agentera` or bare `hej`, render
-any `v1 artifacts detected` attention item and affected-file list from
-`agentera prime`; do not spend extra tool calls on `.agentera/*.md`,
-`.agentera/*.yaml`, or `VISION.md` globs.
-
-If the CLI reports v1 state, use the `v1_migration.dry_run_command` preview it
-supplies. A no-write preview is mandatory before any apply command. Tell the
-user the preview changes nothing, then ask before applying. Only after
-confirmation, run `v1_migration.apply_command`.
-Never infer consent from the presence of v1 artifacts.
-The preview command shape is
-`npx -y agentera@latest doctor`
-or, from a local checkout, `node packages/cli/dist/bin/agentera.js doctor`
-when supplied by the CLI.
-Do not replace the CLI-owned preview with manual artifact inspection,
-hand-written migration steps, or raw YAML reads. Only the apply step requires confirmation.
-
-The upgrade command is idempotent. It installs or updates Agentera app files,
-migrates legacy Markdown artifacts to YAML when detected, wires runtime config
-to the app home, and removes fixable outdated runtime artifacts after preview
-and confirmation. Package refreshes that run `npx skills remove` for legacy
-standalone skill entries and `npx skills add` for `/agentera` remain explicit
-opt-in via `--update-packages`. `npx skills update` by itself updates only the
-visible skill; if `/agentera` then finds missing or out-of-date app files, run
-the plain-language repair preview above so upgrade updates the app and cleans up
-the old default directory when it is recoverable.
-
-### Layer 1: Bare `/agentera` or bare `hej` — delegate to prime
-
-If the request is `/agentera` with no additional text, or the complete user
-message is exactly `hej`, delegate immediately to hej. Hej performs state-aware
-routing through the `agentera prime` composite result, which condenses project
-artifacts and suggests the most useful next capability. This is deterministic
-and never wrong. Bare `hej` must not be handled as a generic greeting.
-
-### Layer 2: capability name or `/agentera <primary-alias>` — direct route
-
-If the request text exactly matches a capability name (case-insensitive, e.g.,
-"resonera", "planera", "hej"), route directly to that capability without
-evaluating natural-language trigger patterns. Canonical Swedish names remain the
-protocol identity and bypass natural-language matching.
-
-If the request begins with a canonical capability name followed by more text, or
-uses `/agentera <capability-name> <topic>`, route directly to that capability and
-pass the remaining text as the user's topic or instruction. For example,
-`resonera decide whether to keep this API` invokes ❈ resonera; it must not
-receive a generic analysis response and must not try the unsupported CLI command
-`agentera resonera`.
-
-If the request text exactly matches one primary alias from
-`capability_schema_contract.yaml` `ROUTE_ALIASES.primary_aliases`, route directly
-to that alias's capability without evaluating natural-language trigger patterns.
-Each capability has exactly one primary alias. Secondary user wording stays in
-capability trigger schemas below this layer. Examples: `deliberate`,
-`brainstorm`, and `rubber duck` remain resonera trigger wording; `brief` and
-`what's next` remain hej trigger wording. These are not primary aliases.
-
-### Layer 3: Natural language with high-confidence match
-
-If the request is natural language (e.g., "help me think through this"), evaluate capability trigger schemas and route when the schema-owned semantics produce a high-confidence match.
-
-### Layer 4: Borderline match — disambiguation
-
-If the schema-owned routing semantics produce competing borderline matches, present a disambiguation prompt instead of silently choosing. List the matching capabilities with brief descriptions and ask the user to confirm or clarify.
-
-### Layer 5: No match — fallback to hej
-
-If no capability matches with sufficient confidence, route to hej for orientation. Hej handles greetings, status requests, and ambiguous inputs.
-
-### Trigger Pattern Discovery
-
-The trigger-to-capability map for Layers 3-4 is derived from each capability's `schemas/triggers.yaml`, not hardcoded here. Pattern matching, priority, thresholds, fallback, and disambiguation metadata belong to those trigger schemas and the capability schema contract. This keeps the routing layer focused on request-to-capability routing; capability directories and schemas remain the detailed Interface sources.
+The prime dashboard rendering contract — template, field-by-field rules, output
+budget, attention-item ordering, exit marker — is owned by the status capability
+instructions. `npx -y agentera@next prime --context status --format json` returns the full
+`capability_context.instructions` body and the bounded
+`capability_context.context.status_context` state and one
+`capability_context.startup` availability projection in one response. Render
+from that capsule without a separate bare-prime call or raw artifact read. An
+`ok` outcome needs no second call; for deferred detail, use only that family's
+exact `detail_command`.
+Ask for confirmation before invoking a state-changing downstream capability.
+
+The first response in a fresh interaction delivers the brief and a free-form
+continuation prompt, not a native question menu — unless the user explicitly
+asks for bounded choices or the suggested next step is a state-changing
+Proceed/Cancel handoff.
 
 ---
 
@@ -426,62 +179,113 @@ The trigger-to-capability map for Layers 3-4 is derived from each capability's `
 - NEVER push to remote repos without explicit user instruction
 - NEVER modify `.agentera/vision.yaml` or objective state during execution cycles (only the user or the owning capability may change these)
 - NEVER commit secrets or credentials to any artifact or file
-- Respect artifact path resolution: check `.agentera/docs.yaml` for path overrides before accessing any agent-facing artifact
+- For supported mutations, use the state writer; it resolves `.agentera/docs.yaml` path overrides and validates the published bytes
+- For direct access to other agent-facing artifacts, respect `.agentera/docs.yaml` path overrides
 </critical>
 
 ---
 
-## Exit signals
+## Capabilities
 
-All capabilities use the exit vocabulary defined by `protocol.yaml` `EXIT_SIGNALS`. Capability `schemas/exit.yaml` files reference that protocol authority; the routing layer does not maintain a separate exit-signal table.
+| | Capability | Primary route | Purpose |
+|---|---|---|---|
+| ⌂ | status | `/agentera status` | Orientation and routing |
+| ⛥ | vision | `/agentera vision` | Define project direction |
+| ❈ | discuss | `/agentera discuss` | Structured deliberation |
+| ⬚ | research | `/agentera research` | External pattern analysis |
+| ≡ | plan | `/agentera plan` | Planning with acceptance criteria |
+| ⧉ | build | `/agentera build` | Autonomous development |
+| ⎘ | optimize | `/agentera optimize` | Metric-driven optimization |
+| ⛶ | audit | `/agentera audit` | Codebase health audit |
+| ▤ | document | `/agentera document` | Documentation |
+| ♾ | profile | `/agentera profile` | Decision profiling |
+| ◰ | design | `/agentera design` | Visual identity system |
+| ⎈ | orchestrate | `/agentera orchestrate` | Multi-cycle orchestration |
 
 ---
 
-## Cross-skill integration
+## Artifact writes
 
-The twelve-skill suite is collapsed into one Agentera skill. Each capability's schemas define cross-capability artifact references using stable IDs. Cross-capability routing is handled through capability trigger schemas described in the Routing Logic section. Capabilities read from and write to the same artifact store (`.agentera/` for agent-facing, project root for human-facing), so inter-capability data flows through shared artifacts, not direct invocation.
+The CLI state writer is the canonical mutation path for entity-backed state.
+Every public record has `id` and `artifact`, lives in one writer-owned entity
+file, and is retrieved through bounded `list` or exact `get --id` commands. Do
+not edit `.agentera/entities/` directly. The writer assigns bare IDs, validates
+records, publishes atomically, and supports filesystem-safe previews.
 
-### Artifact path resolution
+Discover the live contract before constructing a write:
 
-Before reading or writing any artifact, check if `.agentera/docs.yaml` exists. If it has an Artifact Mapping section, use the path specified for each canonical filename. If `.agentera/docs.yaml` doesn't exist or has no mapping for a given artifact, use the default layout:
+```bash
+npx -y agentera@next state decisions explain --format json
+npx -y agentera@next state decisions explain --verb update --format json
+```
 
-- Human-facing artifacts at the project root: `TODO.md`, `CHANGELOG.md`, `DESIGN.md`
-- Agent-facing artifacts in `.agentera/` as YAML: `progress.yaml`, `decisions.yaml`, `health.yaml`, `plan.yaml`, `docs.yaml`, `vision.yaml`, `objective.yaml`, `experiments.yaml`
+The same pattern applies to every writable artifact:
 
----
+```bash
+npx -y agentera@next state <progress|decisions|plan|health> explain --verb <verb> --format json
+```
 
-## Directory Structure
+Common mutations:
+
+- `npx -y agentera@next state progress append --input <path|-> --format json`
+- `npx -y agentera@next state decisions append --input <path|-> --format json`
+- `npx -y agentera@next state decisions amend --id ID --base-sha256 HASH --input <path|-> --format json`
+- `npx -y agentera@next state decisions update --id ID ... --format json`
+- `npx -y agentera@next state plan create [--force] --input plan.yaml --format json`
+- `npx -y agentera@next state plan append [--plan PLAN_ID] --input task.yaml --format json`
+- `npx -y agentera@next state plan update --id TASK_ID [--plan PLAN_ID] --input task-patch.yaml --format json`
+- `npx -y agentera@next state plan set-status --id TASK_ID --status STATUS --format json`
+- `npx -y agentera@next state plan set-plan-status [--plan PLAN_ID] --status complete --format json`
+- `npx -y agentera@next state plan archive [--plan ID] [--force] --format json`
+- `npx -y agentera@next state plan replace --predecessor PREDECESSOR_ID --successor SUCCESSOR_ID --format json`
+- `npx -y agentera@next state health append --input audit.yaml --format json`
+- `npx -y agentera@next state todo create --input todo.yaml --format json`
+- `npx -y agentera@next state todo update --id ID --input todo-patch.yaml --format json`
+- `npx -y agentera@next state todo set-severity --id ID ... --format json`
+- `npx -y agentera@next state todo supersede --id ID ... --format json`
+- `npx -y agentera@next state todo resolve --id ID ... --format json`
+- `npx -y agentera@next state todo reopen --id ID ... --format json`
+
+TODO create input is a full YAML/JSON typed record. TODO update input is a
+patch: omitted fields remain unchanged and only `target_version`,
+`requirements`, `acceptance`, and `readiness` accept typed clears. Public TODO
+fields remain TODO.md-owned; readiness, dependencies, gates, evidence, and
+lifecycle metadata remain Agentera-owned. Lifecycle verbs are flag-only and do
+not accept record payloads.
+
+Plan create task numbers and dependency values are create-local symbolic
+ordinals inside one atomic input document; the writer removes them before
+publishing bare ten-letter plan and task envelope IDs. A legacy composite
+`header.id` is migration-only and is never a public selector. Post-publication
+task append/update payloads use only mutable task content and bare task IDs.
+Without `--force`, an open plan blocks creation. With exactly one canonical open
+predecessor, forced create archives that plan without changing task, evaluation,
+or completion history, then records its bare ID in the successor's
+writer-owned `previous_plan_archived` field. Forced archive preserves the same
+history. Multiple implicit open candidates reject before effects. When they
+block a reader or implicit writer, use the targeted replacement command only
+after canonical evidence names both roles; list order never assigns predecessor
+or successor roles.
+
+Add `--dry-run` to preview any mutation without publishing it. Artifacts not
+listed above are outside the typed writer contract and remain governed by their
+owning capability's instructions and safety rails.
+`npx -y agentera@next schema --format json` exposes the machine-readable writer operation matrix under
+`state_writer` and on each writable `artifact_schemas[*].write_interface`.
 
-```
-skills/agentera/
-  SKILL.md                          # This file (routing stub + capability table)
-  protocol.yaml                     # Shared primitives
-  capability_schema_contract.yaml   # Self-referential schema contract
-  capabilities/
-    hej/
-      schemas/
-        triggers.yaml
-        artifacts.yaml
-        validation.yaml
-        exit.yaml
-    resonera/
-      schemas/
-        triggers.yaml
-        artifacts.yaml
-        validation.yaml
-        exit.yaml
-    ... (12 capabilities total, each with schemas/ only)
-packages/cli/src/capabilities/<name>/instructions.ts   # Per-capability prose (D65)
-```
+---
 
-Validate any capability against the contract through the canonical CLI:
+## Artifact path resolution
 
-```bash
-npx -y agentera check validate capability <name-or-path>
-```
+The state writer resolves entity storage itself. Before directly reading or
+writing an intentional singleton outside the writer contract, check whether
+`.agentera/docs.yaml` maps it to another path. If no mapping exists, use the
+default singleton layout:
 
-Self-validate the contract:
+- Human-facing artifacts at the project root: `TODO.md`, `CHANGELOG.md`, `DESIGN.md`
+- Agent-facing singletons: `.agentera/docs.yaml` and `.agentera/vision.yaml`
 
-```bash
-npx -y agentera check validate capability-contract --format json
-```
+Do not silently bypass the CLI and read raw entity files first. If
+CLI state declares complete coverage, do not perform defensive raw artifact
+reads. Use raw artifact reads only as a last-resort after the applicable
+availability row's exact detail command fails or state declares corruption.