@prodero/curator 0.1.0 → 0.2.0

package/docs/COMPATIBILITY.md

@@ -1,14 +1,16 @@
-# v0.1 compatibility
+# Compatibility and verification
 
-> v0.1 contract: Local/Versioned describe Git storage and sharing, not a security boundary against the connected agent. Review and approval are workflow safeguards, not authenticated human consent. The agent may create, promote and maintain Versioned files. Curator does not commit or push; users review repository changes before doing so. See [Privacy](PRIVACY.md).
+This document covers the **0.2.0** release contract and evidence recorded through 2026-10-23. A checkout, local tarball or passing test does not establish npm publication. Artifact evidence must satisfy the [release gates](RELEASING.md) on the final release tree. Supported runtime targets and project/knowledge schemas remain unchanged; see the [changelog](../CHANGELOG.md) for status JSON and local-preference compatibility changes.
+
+> Contract: Local/Versioned describe Git storage and sharing, not a security boundary against the connected agent. Review and approval are workflow safeguards, not authenticated human consent. The agent may create, promote and maintain Versioned files within current authorization. Curator tools do not execute Git commit or push; coding-agent Git actions follow current user scope and host approval controls. See [Privacy](PRIVACY.md).
 
 Supported runtime target: **Node 22.14.0–22.x**, npm and Git. Node 22.14.0 is the tested minimum; the package rejects other Node majors through its engine contract (npm may only warn unless engine-strict is enabled). `import.meta.dirname` and modern Node filesystem/runtime APIs are used. Earlier Node 20 declarations were not a verified compatibility promise.
 
 | Environment | Status |
 | --- | --- |
 | macOS ARM64, Node 22.14.0 | Tested locally: full tests and isolated release gate |
-| macOS / Ubuntu, Node 22.14.0 and latest 22.x | CI release-gate matrix; support certification requires green runs on the exact RC commit |
-| Native Windows | Not supported in v0.1; filesystem/Git fixtures and process behavior are not verified |
+| macOS / Ubuntu, Node 22.14.0 and 22.23.3 | Full four-job CI matrix passed on the runtime candidate identified below; final-tree certification requires matching exact-SHA runs |
+| Native Windows | Not supported in 0.2.0; filesystem/Git fixtures and process behavior are not verified |
 | Node 20, 24 or other majors; WSL | Not verified / outside the initial runtime contract |
 
 CI configuration is not evidence that a remote run has passed. Record actual runs before publication.
@@ -17,10 +19,11 @@ CI configuration is not evidence that a remote run has passed. Record actual run
 
 | Host | Status / boundary |
 | --- | --- |
-| Codex CLI | Tested: Codex CLI 0.144.4 on macOS ARM64 with an isolated v0.1.0 artifact. Text lifecycle, knowledge maintenance and promotion preview; no Apps rendering claim from a CLI test. |
-| Codex desktop | Used during development with Apps; artifact-host UI interaction has not yet been independently verified. |
-| Claude Code | Experimental adapter: native 2.1.52 user MCP registration and stdio connection verified in isolated HOME. Bare-word model flow stopped at login; not certified as supported. |
+| Codex CLI | Native 0.144.4 on macOS ARM64 passed installed 0.2.0 text lifecycle, persistent retrieval, Local maintenance and promotion preview. No Apps rendering claim from a CLI test. |
+| Codex desktop | The owner reported a successful manual check on 2026-10-23. Exact-build, artifact-bound graphical acceptance is not independently traced; see the owner report below. |
+| Claude Code | Experimental adapter. Native 2.1.302 on macOS ARM64 passed installed 0.2.0 text lifecycle, persistent retrieval, Local maintenance and promotion preview. This does not certify Claude Desktop or Apps rendering. |
 | Claude Desktop | No installer adapter; not verified. |
+| Codex mobile / iPad | The owner reported a successful Codex Mobile manual check on 2026-10-23 and previously accepted iPad Context Ready / Session Complete. Build/artifact binding and individual case traces were not supplied. |
 | Cursor | Not yet verified against this RC. Workspace and Apps behavior must be checked before claiming support. |
 | Other MCP hosts | Experimental; require standard stdio tools, optional roots and optional Apps/sampling. |
 
@@ -28,7 +31,7 @@ Use `prodero install` for one global machine integration. New workspaces initial
 
 Apps-capable hosts can render bundled main/lifecycle/plugin resources. Others receive text and structured content; knowledge actions and explicit text approval remain available. Serving an HTML resource in a protocol smoke test does not verify host rendering. Sampling is optional and host-controlled; deterministic operation works without it. Assisted inputs may be transmitted to the host/model.
 
-Machine integration verification: Codex CLI 0.144.4 loaded the installed artifact's native configuration and global launcher in isolated HOME, received only `prodero`, and invoked `prodero_open` with the test workspace. The uninitialized project response exposed initialization and the main App resource; no project was initialized by installation. This text run does not certify desktop rendering.
+Historical machine-integration verification used isolated HOME and the native global launcher. The 2026-10-23 native runtime checks instead used existing client authentication, invocation-scoped candidate-only MCP configuration and separate disposable Git projects. They did not change saved MCP registrations or independently recertify the installer. Literal `prodero` opened each uninitialized fixture without creating `.prodero`; initialization occurred only in the subsequent explicitly requested step. These text runs do not certify desktop rendering.
 
 Claude Code does not automatically read project `AGENTS.md`. Initialization remains unchanged; experimental Claude users need the host's documented project `CLAUDE.md` import of `@AGENTS.md` for the existing project lifecycle instructions. The installer does not create that project file or move lifecycle instructions into the global launcher. See [host integration](hosts.md). Restart hosts after package updates.
 
@@ -36,9 +39,21 @@ Claude Code does not automatically read project `AGENTS.md`. Initialization rema
 
 The [release gate](RELEASING.md) checks a clean installed artifact, stdio lifecycle, Local storage, reviewed synthetic sharing, restart and synthetic patch upgrade preservation. Synthetic upgrades do not certify future releases or arbitrary schema downgrades. Record results for the exact release candidate.
 
-Codex CLI 0.144.4 connected to the installed artifact with a fixed project root. It performed open/initialize/prepare/record/close/next prepare with the learned decision, conversational remember/search/inspect/Local edit and promotion preview. Noninteractive writes required invocation-scoped preapproval of only the synthetic test tools; publication was excluded. The host's sandbox kept `.git` read-only, so the outer test harness committed the initialization baseline; normal host operations then left Git clean. Interactive users should approve their own actions; do not copy test preapprovals into normal host setup.
+### Runtime candidate: independently observed
+
+The runtime candidate was commit `4f14a196b5325cf08c67ebeac40d21f5edb6e89f`. Its [fast CI](https://github.com/Prodero/curator/actions/runs/39653486240) passed 1,446 ordinary tests; its [full CI](https://github.com/Prodero/curator/actions/runs/39653523638) passed all four macOS/Ubuntu × Node 22.14.0/22.23.3 jobs, each with 1,453 tests and 16 installed-artifact smoke groups. These counts overlap and are not additive. The reviewed full-CI tarball SHA-256 was `c6bb29869c6fdcdff139799d01626a3f7ec57598005e5ab5d14437a76fbe9a12`.
+
+On 2026-10-23 both native clients connected only to that installed 0.2.0 candidate, bounded to their own synthetic Git project. All 148 installed payload files matched the CI artifact. Each performed Open/initialize/Prepare/Record/Close/next Prepare, fresh-process retrieval, remember/search/inspect, a revision-bound Local edit and exact promotion preview. Independent storage checks found exactly two Local items, zero Versioned items, preserved pre-edit checkpoint content, four closed sessions per fixture and clean Git. Promotion was not applied. Existing authentication was used through the clients; invocation-only test permissions must not be copied into normal host setup.
+
+Single-session maintenance visibly delivered Context Ready and Saved once in each client. In the batched two-session scenario each client omitted some intermediate receipts; persistence and closure still succeeded. This is an observed agent-relay limitation, not demonstrated knowledge loss. Curator supplies lifecycle text but does not guarantee model/client delivery. Apps rendering, host sampling and physical approval interaction were not independently verified by these CLI runs. Separate deterministic fixtures cover publication mechanics without claiming human UI approval.
+
+### Owner-reported manual acceptance
 
-The host correctly rejected an incomplete edit without a title, then accepted the corrected request. Apps UI rendering and host sampling were not verified by this text run. Actual publication is covered by the separate deterministic synthetic protocol fixture, not claimed as human UI approval.
+On 2026-10-23 the owner reported successful manual Curator checks in **Codex Desktop, Claude CLI and Codex Mobile**, following the request for manual Apps acceptance. Record this as **owner-reported acceptance** for those named surfaces. The report did not supply client build versions, an exact candidate executable/hash/SHA, individual case results or an App call trace. It therefore does not establish independently traced results for Apply replay, stale-review handling or model-facing tool filtering, and does not upgrade an unverified host tier. Do not infer that the desktop used a particular dev connection or that the Claude CLI was the exact build used by the independent native test. Candidate binding can be clarified without assuming the entire manual check must be repeated. The previously accepted iPad lifecycle result remains accepted.
+
+### Final release identity
+
+These CI and native results identify the runtime candidate above. Release-note/README/compatibility edits change packaged bytes and produce a different tarball; they do not inherit its archive hash or exact-commit CI status. The final committed release tree requires its own matching package validation and full CI matrix, with host evidence explicitly bound or reconciled to the final artifact. No broader host support is inferred from a successful owner report.
 
 Passing configured remote CI jobs on the final RC commit remains required before publication. Local protocol checks do not certify other Node/OS combinations or host App rendering.
 
@@ -47,3 +62,7 @@ Codex setup and per-tool configuration reference: [official configuration refere
 ## Project and knowledge compatibility
 
 Project schema 8 and Knowledge Schema 3 are the current targets. Schema 3 adds explicit applicability with a mechanical legacy-scope migration; see [Applicability](APPLICABILITY.md). Missing knowledge version means legacy format 1; its approved migration preserves instruction behavior with explicit context policy and legacy authority. Both versions live in the project config; moving or cloning a project requires no machine registry. Newer project or knowledge formats fail closed at the storage boundary. Open/Prepare can present update instructions without interpreting unsupported records. See [Migration Foundation](MIGRATIONS.md) for approval, recovery and future format transitions.
+
+## CLI status output
+
+`prodero status` and `prodero status --root PATH` now default to readable text, including when piped. Consumers of the previous implicit JSON output must add `--json`; TTY detection never selects the format. Successful machine JSON fields are unchanged. Project JSON keeps `version`, `project` and `update`, adding `scope: "project"`. Status errors in JSON mode are one stdout document with `ok: false`, `version`, `scope` and a safe `error` object (`code`, `message`, `recovery`); migration gates also include `migration`. CLI status performs no writes, including derived caches or ignore-rule maintenance; other detailed-status readers retain their existing defaults. Existing exit meanings remain: failed arguments/project compatibility/host inspection exit 1; an unavailable registry alone retains exit 0 and its `update.status` diagnostic. See [status commands and read-only/cache boundaries](hosts.md#commands-and-status).

package/docs/MIGRATIONS.md

@@ -39,6 +39,10 @@ Classes are structural, compatible-semantic and review-required. The latter is
 blocked until a migration-specific review resolver exists; `approved:true` never
 substitutes for semantic decisions. The knowledge registry contains the ordered compatible-semantic `knowledge-policy-1-2` and `knowledge-applicability-2-3` transitions. The current target is knowledge schema 3; see [Knowledge Schema v2](KNOWLEDGE-SCHEMA-V2.md) and [Applicability](APPLICABILITY.md).
 
+## Package installation stays separate
+
+`prodero update` updates only the verified npm package after terminal confirmation. It does not enumerate or migrate projects or change the selected dev checkout. After user restart/reconnect, Open/Prepare offer this existing migration gate only when project/knowledge formats require it. Chat update indicators and `prodero_update` provide terminal instructions, never package installation.
+
 ## Planning, approval and continuation
 
 `planProjectMigration` reads metadata without creating directories, sessions, caches

package/docs/RECOVERY.md

@@ -43,7 +43,9 @@ If automatic restoration fails, stop all Prodero writers and retain both the jou
 
 Session creation, record and close share a filesystem lock across processes. Session mutations wait up to five seconds for a writer; a timeout reports failure, never success. Acknowledged observations remain in the file, and a closed session cannot be reopened by a late record. An empty repeated close remains successful; repeated close with nonempty final entries is explicitly rejected, so callers should inspect the session after an uncertain response rather than replay that final batch blindly.
 
-A dead PID owner can be reclaimed. An ownerless/invalid lock or interrupted lock-recovery guard fails conservatively: after stopping all writers, inspect `.transactions/lock` and `.transactions/lock-recovery` before removing stale lock directories. PID reuse is intentionally handled conservatively rather than risking deletion of a live owner's lock.
+A dead PID owner can be reclaimed. Acquisition, owner publication, stale-owner inspection/removal and release share the short-lived `.transactions/lock-recovery` transition guard; the canonical operation runs outside that guard while retaining its writer lock. Release waits independently for up to five seconds for the guard and reports failure if cleanup cannot complete, rather than acknowledging success with an uncertain release.
+
+An ownerless/invalid lock or interrupted lock-recovery guard fails conservatively: after stopping all writers, inspect `.transactions/lock` and `.transactions/lock-recovery` before removing stale lock directories. PID reuse is intentionally handled conservatively rather than risking deletion of a live owner's lock. Do not remove the guard while a writer or recovery contender remains active.
 
 These guarantees are verified with local filesystem process-crash, injected I/O-error and multiprocess tests. They do not provide a multi-file snapshot to unrelated readers while a journal is being applied, nor protection against hostile processes replacing the directory topology during filesystem operations. Network filesystems and sudden hardware/power loss have not been certified. Do not edit storage concurrently with migration/recovery.
 

package/docs/RELEASING.md

@@ -6,35 +6,93 @@ From a clean checkout on Node 22.14+ (22.x):
 npm run release:gate
 ```
 
-The gate copies tracked working files plus non-ignored new files into a clean temporary checkout (never node_modules/dist), runs `npm ci`, build, tests, pack, then installs the tarball into a separate prefix with production dependencies only. Its standalone runner resolves SDK dependencies from that installation. CLI, stdio MCP, bundled resources, the knowledge lifecycle, Git boundaries, restart and synthetic manual upgrade preservation are checked. `npm test` rebuilds first; ordinary `npm pack` runs the full tests through prepack. The gate's pack skips lifecycle scripts only after its build/tests have passed.
+## CI tiers and local commands
+
+| Trigger / command | Tests | Pack and doc links | Installed-artifact checks |
+| --- | --- | --- | --- |
+| Branch push or pull request | Ordinary suite, Ubuntu / Node 22.14.0 | Always | Required except for explicitly documentation-only changes |
+| Any tag push or `workflow_dispatch` | Full suite, Ubuntu/macOS × minimum/latest Node 22 | Always | Always |
+| `npm run ci:fast` | Ordinary suite | Always | Omitted |
+| `npm run ci:fast -- --integration` | Ordinary suite | Always | Included |
+| `npm run release:gate` | Full suite | Always | Included |
+| `npm test` | Full suite after build | Not a package gate | Not a package gate |
+| `npm run test:fast` | Ordinary suite after build | Not a package gate | Not a package gate |
+
+Before creating a release, manually dispatch **Release gate** on the intended
+commit and verify all four jobs against that exact SHA. A tag push also runs the
+full matrix; neither check publishes a package or creates a GitHub release.
+A successful fast run alone does not certify a release.
+
+`test/scale/` explicitly owns the seven large-fixture tests (10,000-memory
+intelligence, context/status/discovery scales, 20,100-file importer boundary and
+retention histories). Their assertions and fixture sizes are unchanged. The
+recursive runner includes every `*.test.mjs` below `test/` in full mode; every
+suite outside `test/scale/` defaults to ordinary, including newly added suites.
+Optional `*.browser.mjs` checks remain separate, as before. Fast mode runs at most
+two test files concurrently; full mode retains one. Both fail on any selected
+test failure. Partition and workflow-policy regression tests run in both modes.
+
+Path classification is conservative: only the named top-level Markdown files,
+LICENSE, `docs/*.md` and `docs/images/*.png` may omit installed-artifact checks.
+Any other path (including core, installer, MCP, UI, plugins, managed instructions,
+package manifests, workflow, runner or tests), mixed changes, missing/zero base,
+or diff failure requires them. Both sides of renames are classified. PRs compare
+the base SHA with the checked-out merge result; pushes compare the previous SHA
+with HEAD. All branch/PR changes still run ordinary tests and package validation.
+
+Superseded runs are cancelled only within the same branch or PR group. PR groups
+use PR numbers to avoid collisions between fork branch names. Manual and tag
+runs use unique run IDs and cannot cancel, or be cancelled by, branch/PR runs.
+
+The gate copies tracked working files plus non-ignored new files into a clean
+temporary checkout (never node_modules/dist), runs `npm ci`, builds **once**, then
+packs and validates package resources, secret/path screening and documentation
+links **before** running tests. It skips npm pack lifecycle scripts only because
+the gate explicitly controls build/tests; successful completion requires both.
+Ordinary `npm pack` still runs the full tests through prepack.
+
+When integration is required, the gate installs that same tarball into a separate
+prefix with production dependencies only, takes the build checkout offline and
+runs the existing standalone smoke runner against the installation. CLI, stdio
+MCP, bundled resources, the knowledge lifecycle, Git boundaries, restart and
+synthetic manual upgrade preservation remain checked. The smoke runner's
+synthetic patch version is only an isolated test fixture, never a publication.
+
+`result.json` records mode, whether integration ran, total elapsed time, each
+child-command duration, artifact path and SHA-256. CI uploads these results and
+logs with the tarball. Measure fast and full runs separately; runner performance
+and the filesystem-heavy fixtures make local and remote times different.
 
 For host-integration verification, use a fresh temporary directory outside the real user home, an isolated HOME and Codex/Claude/XDG configuration, and no inherited host registrations. Keep custom `PRODERO_GATE_OUTPUT` paths outside real-home ancestry: normal workspace checks inspect ancestors and can correctly report `HOST_SCOPE_CONFLICT`. Never disable those checks or alter real settings to make a smoke test pass.
 
-CI allows 45 minutes per matrix job. Child-command output is streamed to the console and written continuously to evidence logs, so cancellation retains partial test diagnostics. The limit remains finite; a timeout is not a passing check.
+CI allows 30 minutes for the fast job and 45 minutes per full matrix job. Child-command output is streamed to the console and written continuously to evidence logs, so cancellation retains partial test diagnostics. The limit remains finite; a timeout is not a passing check.
 
-Gate outputs and the tarball remain in the printed temporary directory for inspection. Nothing is published. CI repeats the gate on macOS/Ubuntu and the declared minimum/latest Node 22. Remote CI results must actually pass before those targets are certified.
+Gate outputs and the tarball remain in the printed temporary directory for inspection. Nothing is published. Full CI repeats the gate on macOS/Ubuntu and the declared minimum/latest Node 22. Remote CI results must actually pass before those targets are certified.
 
 A protocol runner is not a real host. Independently connect a primary host to the **installed artifact** in a synthetic Git project, run open/init/prepare/record/close/next prepare/remember/search/edit/restart, inspect tool results and Git status, and record host/runtime/artifact versions. Review promotion outcomes and approve only the intended synthetic fixture publication. Apps rendering needs its own host check.
 
 ## Install the artifact for review
 
-Before the first npm publication, install the generated tarball instead of a registry release:
+For an unpublished candidate, install the reviewed tarball into an isolated prefix rather than requesting its version from the registry. The current candidate version is 0.2.0; this command is an example for a separately authorized isolated environment, not a request to replace the working installation:
 
 ```sh
-npm install --global /absolute/path/prodero-curator-0.1.0.tgz
-prodero install
+npm install --global --prefix /absolute/isolated/prefix --omit=dev --ignore-scripts /absolute/path/prodero-curator-0.2.0.tgz
 ```
 
 Use the isolated host environment described above for automated verification. For a deliberate real-host check, review the installer’s configuration changes and restart the selected coding agent. Open a synthetic project and type `prodero`. The tarball includes the compiled server, Apps and plugin resources; no source checkout or development dependencies are needed.
 
 ## Final human publication checklist
 
-1. Independently audit the RC, review diffs, run the full gate on the exact committed tree and obtain green declared CI matrix runs. Record artifact SHA-256 and primary-host evidence.
+1. Finalize version, changelog/date and README in the intended release tree before freezing the candidate. Independently audit it, review diffs, run the full gate on the exact committed tree and obtain green declared CI matrix runs. Record artifact SHA-256 and primary-host evidence. Any packaged-content edit afterwards requires a new tarball and matching checks.
 2. Review the intended public Git tree **and history** for private content. Ignoring runtime files today does not remove old commits. Decide explicitly what history to publish; never rewrite it automatically.
 3. Confirm ownership of npm scope `@prodero`, package/repository identity `@prodero/curator` / `prodero/curator`, and permission to release. A registry 404 does not establish scope ownership.
 4. Create/configure the intended public repository only with explicit approval. Enable Issues and private vulnerability reporting; verify the links and update any identity/channel changes in docs and package metadata.
-5. Confirm version `0.1.0`, MIT license, changelog date, preview limitations and exact artifact contents. Obtain explicit approval for publication.
-6. Authenticate npm with the account's required 2FA/provenance policy. Publish the **reviewed tarball**, not an unreviewed rebuild: `npm publish /absolute/path/prodero-curator-0.1.0.tgz --access public`.
-7. Verify external `npm install --global @prodero/curator@0.1.0`, `prodero --version` and `prodero check-update`. Only with separate approval create/push the `v0.1.0` tag and release notes or announcements.
+5. Confirm candidate version `0.2.0`, MIT license, final changelog date, preview limitations, README registry example and exact artifact contents. If any edit is still needed, return to step 1 and certify the new artifact. Obtain explicit approval for publication.
+6. Authenticate npm with the account's required 2FA/provenance policy. Publish the **reviewed tarball**, not an unreviewed rebuild: `npm publish /absolute/path/prodero-curator-0.2.0.tgz --access public`.
+7. Verify external `npm install --global @prodero/curator@0.2.0`, `prodero --version` and `prodero check-update`. Only with separate approval create/push the `v0.2.0` tag and release notes or announcements.
 
 The automated gate does not publish or push and does not change the source repository history. It creates an isolated disposable test commit in its temporary checkout. Package upgrades do not move project knowledge. Back up the full `.prodero` directory before preview upgrades; `.cache` is disposable, migration recovery backups are not.
+
+## Terminal updater acceptance
+
+Test the installed `prodero update VERSION` in an isolated prefix after explicit terminal acknowledgment, including non-TTY refusal/`--yes`, actual npm failures and fresh CLI/MCP verification. Record artifact/hash/version, scripts policy and unchanged synthetic project/host state. Published-release upgrade, fixture-modified candidate→published transition and same-version behavior are distinct claims. A direct npm install or the existing synthetic patch smoke does not alone exercise the updater. Never use the 0.0.0 placeholder as a functional baseline or update the maintainer’s working npm installation during automated checks. Chat/MCP checks must assert instruction-only behavior even with development release sources.

package/docs/hosts.md

@@ -7,8 +7,9 @@ Install the public package (or a generated preview tarball), then run `prodero i
 - `prodero install`: open the interactive installation wizard. It lists every agent and its saved configuration state, then offers numbered install/update actions only for agents that need them. Select an agent, confirm with `y`, and review the result. Repeat for another agent or choose Finish. Enter at the selection prompt finishes; Enter at confirmation cancels that action. Ctrl+C or EOF exits without starting another operation.
 - Installation takes no host arguments and has no `--all` flag. Choose agents inside the wizard. Non-interactive invocation prints readable status and terminal instructions, exits nonzero, and makes no changes.
 - `prodero uninstall [codex|claude]` / `prodero uninstall --all`: remove owned integration, including when the executable has since disappeared. The default visits all adapters.
-- `prodero status`: read-only JSON containing Prodero `version`, `scope: machine`, and each host's detection, support, MCP, launcher and aggregate state. It does not discover or access a project.
-- `prodero status --root PATH`: the separate, existing project status operation.
+- `prodero status`: readable machine integration status, including the installed version and each host's detection, MCP, launcher and configuration state. It does not discover or access a project, even when run inside one.
+- `prodero status --root PATH`: readable status for that existing project: initialization, knowledge, sessions, skills, checkpoints, attention counts and the bounded update check. It does not initialize, migrate, synchronize or repair the project.
+- Add `--json` to either status command for scripts. The format is explicit and does not depend on whether stdout is a terminal or a pipe.
 
 States are `not-detected`, `not-configured`, `installed`, `outdated`, `conflicted`, `unsupported-configuration`, `recovery-required`, `externally-configured`, `external-incomplete`, or `unsupported` (detection-only adapter). On inspection failure, MCP and launcher fields are `null` (unknown), not proof of absence. Detection means an executable on PATH or the native configuration file exists; it does not prove login, an operational server or UI compatibility. Support labels describe verification separately from installation state. The wizard displays conflicts without hiding other agents; those agents cannot be selected for installation. An installation failure exits nonzero.
 
@@ -79,7 +80,7 @@ Recovery snapshots can contain **the entire previous host configuration, includi
 
 ## Experimental Claude limitations
 
-Claude Code 2.1.52 recognized the generated user-scope MCP server and connected to stdio in isolation. The real `prodero` model invocation could not run without login, so the adapter remains experimental. It is included in default detection/installation but is not a supported-host certification. No Claude Desktop adapter is provided.
+Historical Claude Code 2.1.52 checks verified generated user-scope registration and an isolated stdio connection but stopped at login. On 2026-10-23, native Claude Code 2.1.302 passed the installed 0.2.0 candidate's text lifecycle, persistent retrieval, Local editing and promotion preview in a disposable project using existing client authentication and invocation-only MCP configuration. That run did not recertify global installer registration, Claude Desktop or graphical Apps. The adapter remains experimental; see the exact candidate and evidence boundaries in [Compatibility](COMPATIBILITY.md). No Claude Desktop adapter is provided.
 
 Claude Code reads global `CLAUDE.md`, but does not automatically consume project `AGENTS.md`. Prodero project initialization is unchanged. For experimental lifecycle use, review the host's native project `CLAUDE.md` import of `@AGENTS.md` yourself; installation never writes that project file. Apps rendering depends on the host; text responses remain available.
 
@@ -116,17 +117,34 @@ Everyday work happens through the connected agent. These commands are for mainte
 prodero --help
 prodero status
 prodero status --root /absolute/path/to/project
+prodero status --json
+prodero status --root /absolute/path/to/project --json
 prodero check-update
 prodero update
-npm install --global @prodero/curator@latest
+prodero update 0.2.0 --yes  # example exact target, only when actually published
 prodero install
 ```
 
-`check-update` reports the installed version, public npm latest version when reachable, update availability and the exact manual command. An unpublished or unreachable registry is reported as unavailable, not current. `update` only returns instructions: it does not install, stage or alter project integration. Run the npm command yourself, rerun `prodero install` to refresh any changed executable location, then restart the MCP host. Packages are installed separately from project knowledge; project access checks compatibility and presents required migrations for review; CLI `migrate` explicitly applies an update. Back up the whole `.prodero` directory before upgrading previews. Do not downgrade a project to a runtime that cannot read its schema.
+`check-update` reports the installed and public latest npm version when reachable, availability and the terminal command `prodero update`. An unpublished, disabled or unreachable registry is unavailable, not current. In Codex/Claude the update indicator only opens these instructions. The compatibility MCP tool `prodero_update` is read-only for every release source; it does not install, rebuild, stage or refresh project integration.
 
-Use `PRODERO_RELEASE_SOURCE=none` to disable network version checks. Version checks send a request for this public package, not project content. Local manifest/check-out staging is a development-only test adapter requiring `PRODERO_DEV_UPDATE=1` and an explicit source; it is not production self-update.
+`prodero update` in a terminal really updates the installed package. It verifies the current ordinary per-user npm-global installation, previews an exact stable newer version and unchanged prefix, asks you to finish active work and close Codex/Claude, then requires explicit confirmation. `prodero update VERSION` selects an exact stable target; ranges/tags/URLs/downgrades are rejected and an already-current target is a no-op. There is no automatic process discovery or host termination. Do not launch another consumer or package-manager operation during installation. Restart your hosts afterward.
 
-`status` without `--root` inspects machine integrations only. `status --root PATH` retains the explicit project status view. `init`, `sync`, `context [query]` and `prepare [task]` accept `--root PATH` or `--root=PATH`. Without it they require a Git or initialized Prodero ancestor. Unknown commands/flags and invalid roots exit non-zero. `prepare` starts a session; use the MCP lifecycle to record and close it. `sync` starts or resumes the Sync Memory options workflow and can recover pending observations, including active-session observations. Use the connected agent/App to continue its review steps. `sync-sessions` is the low-level deterministic recovery command that processes only closed sessions and leaves active sessions untouched. Normal session close/prepare learning does not require starting Sync Memory.
+For non-interactive use, provide both an exact target and explicit acknowledgment: `prodero update VERSION --yes`. The flag acknowledges that active work has ended and hosts are closed; the updater does not verify this. Without both, a non-TTY command refuses instead of waiting or silently agreeing. Use only an actually published version in place of VERSION; examples are not release announcements.
+
+The CLI waits for npm and checks the resulting installed version/public command. Failure exits nonzero with repair guidance; npm can leave a partial installation and there is no atomic rollback or hot activation. Source checkouts, linked/alternate package-manager layouts, mismatched installs and inadequate permissions are unsupported. Review the reported package-manager/path guidance; never use automatic sudo or change ownership to bypass it. Ordinary npm dependency resolution remains in effect; top-level artifact verification is not an exact offline dependency-closure guarantee. Prebuilt packages are installed with lifecycle scripts disabled and must pass installed-artifact smoke.
+
+Package update does not migrate projects, rewrite host settings/receipts/preferences or switch dev mode. A host saved in dev mode continues to load its existing checkout: updated package is distinct from active dev runtime. After restart, Open/Prepare separately present required project/knowledge migration for review; CLI `migrate` explicitly applies a permitted update. Back up the whole `.prodero` directory before preview migrations and do not downgrade to a runtime unable to read its schema.
+
+`PRODERO_RELEASE_SOURCE=none` disables passive version checks. Local manifest/check-out staging remains an internal development test adapter, not a production updater or a way to install through MCP. The terminal installer uses its verified public npm source rather than a model-supplied release location.
+
+
+`status` without `--root` inspects machine integrations only. `status --root PATH` inspects the selected project. Both default to plain text, including in pipes; scripts must pass `--json`. Successful machine JSON retains `ok`, `version`, `scope: "machine"`, `action` and `hosts`. Successful project JSON retains `version`, `project` and `update`, with additive `scope: "project"`. Failed machine inspection retains its host results with `ok: false` and unknown (`null`) configuration fields where inspection failed.
+
+With `status --json`, invalid arguments or roots, blocked migration, newer schemas and storage failures produce exactly one JSON document on stdout, no stderr, and exit 1. The error shape is `{ "ok": false, "version": "…", "scope": "machine|project", "error": { "code": "…", "message": "…", "recovery": "…" } }`; a migration gate also includes `migration`. Successful reads exit 0. A failed or disabled registry check remains `update.status: "unavailable"` or `"invalid"` in a successful project result and retains exit 0; this does not claim the installed version is current. Plain-text failures remain diagnostic text and exit nonzero.
+
+Status does not change canonical knowledge, skills, sessions, configuration, indexes, managed instructions or migration journals, and does not recreate missing runtime stores. If a required store (for example `checkpoints`) is missing or unreadable, status reports a diagnostic and exits 1; it does not repair the store. The CLI explicitly disables cache persistence: it may read valid caches or scan canonical files, but it does not create, replace or delete caches, create cache directories, or refresh `.gitignore`. Other detailed-status API callers retain their existing default derived-cache behavior (`memory-index.json`, `session-index.json`, `knowledge-graph.json` and the required ignore rules); that maintenance is not performed by CLI status. Projects needing an update are inspected through metadata only; run `prodero migrate status --root PATH` to review the required step.
+
+`init`, `sync`, `context [query]` and `prepare [task]` accept `--root PATH` or `--root=PATH`. Without it they require a Git or initialized Prodero ancestor. Unknown commands/flags and invalid roots exit non-zero. `prepare` starts a session; use the MCP lifecycle to record and close it. `sync` starts or resumes the Curate Memory options workflow and can recover pending observations, including active-session observations. Use the connected agent/App to continue its review steps. `sync-sessions` is the low-level deterministic recovery command that processes only closed sessions and leaves active sessions untouched. Normal session close/prepare learning does not require starting Curate Memory.
 
 
 For project-history questions without starting a session, use `prodero recall "why was this designed this way?" --root /absolute/project`, or ask the connected agent.

package/docs/ui-themes.md

@@ -1,6 +1,6 @@
-# Built-in UI themes (v0.1)
+# Built-in UI themes
 
-Appearance is a canonical project preference (`presentation.theme` in `.prodero/config.json`). The compact **Appearance** disclosure above the main App contains seven native radio choices with palette swatches. It remains mounted outside `#app`, so changing appearance neither rerenders a screen nor discards form drafts. Keyboard users can tab to the picker and use arrow keys within its radio group.
+Appearance is a personal preference on the current checkout. Theme and display mode overrides are stored in the ignored, independently versioned `.prodero/local/preferences.json`; shared project configuration remains tracked. The compact **Appearance** disclosure above the main App contains seven native radio choices with palette swatches. It remains mounted outside `#app`, so changing appearance neither rerenders a screen nor discards form drafts. Keyboard users can tab to the picker and use arrow keys within its radio group.
 
 - **Current / Prodero** is the default, with the original green-black gradients, lime identity, surface colors and typography.
 - **Dark Neon** is the darkest variant: almost-black foundations, graphite-black elevated surfaces and restrained ice-blue edge light.
@@ -20,7 +20,13 @@ The original theme's low-emphasis text colors are deliberately unchanged. New th
 
 ## Persistence and host boundaries
 
-The selected ID is saved for the current project through `prodero_config_set`, using the same canonical validation and atomic storage as chat updates. The old global browser storage key is ignored because it cannot be attributed to a project. Missing project preferences use Current / Prodero. Failed saves retain the last applied theme and explain the failure. Separate projects can display different themes simultaneously; late saves cannot recolor another project.
+The selected ID is saved for the current checkout through `prodero_config_set`, using the same validation as chat updates and owner-only atomic local storage. The Appearance disclosure shows whether the effective value is a local override, legacy project default or built-in default; when an override exists, **Use project/default setting** removes only that local theme field. Chat can reset either presentation field with `reset:true` and no `value`; reset with a value, reset of the context budget and null values are rejected. The old global browser storage key is ignored because it cannot be attributed to a project. Each field resolves independently: an explicit invocation mode (where supported), then a valid local field, then the legacy `.prodero/config.json` presentation field, then the built-in default. Theme defaults to Current / Prodero; mode defaults to Automatic. Explicit System/Automatic values are real overrides, not missing fields. Reads never create or copy preferences or rewrite shared config; theme/mode saves never write shared config or repair root ignore rules, even for same-value saves. Private self-excluding `local/.gitignore` and `.transactions/.gitignore` protect preferences and lock files if root exclusions are absent; existing unsupported/custom nested rules are preserved and saving fails with repair guidance instead of rewriting them. Reset reveals fallback rather than copying it. Failed saves retain the last applied theme and explain the failure. Separate checkouts/projects can display different themes simultaneously; late saves cannot recolor another project.
+
+The local file format is `{ "version": 1, "presentation": { "mode": "text", "theme": "dark-neon" } }` (an example, not a default or migration). Context budgets, schema/runtime metadata, project identity and knowledge-engine policies remain shared config. Known policy/identity overrides are rejected in local preferences; unknown extensions round-trip without becoming effective settings. Existing MCP tool IDs, setting keys and effective `projectSettings.presentation` remain compatible. Effective settings are read per resolved project on every request; one-off text display never saves a preference.
+
+A missing local file is ordinary fallback. Corrupt/unsafe/newer local files produce a safe code, cause and recovery guidance without echoing contents. Valid sibling fields can resolve independently when one known field is invalid, but saves/reset refuse to overwrite the damaged file. Newer local versions fall back entirely. Preserve the file and repair explicitly or use a compatible runtime. Writes retain initialization/canonical-schema/interrupted-migration gates, use the common Sync/migration lock and do not recover pending knowledge lifecycle transactions as a side effect of a theme save. Existing re-init, integration refresh and migration/recovery retain preferences.
+
+There is no automatic cleanup or migration of legacy shared presentation fields. They remain fallback defaults, including an existing dirty choice; no blanket ignore/reset of `.prodero/config.json`. Optional removal would require separate reviewed work. Older runtimes ignore the local file and may still read/write `config.presentation`, creating a tracked diff; this is the downgrade limitation. No dual-write is used to disguise it. Preferences are per checkout, not synchronized across machines/worktrees, and are not a security boundary against the connected agent.
 
 Browser preference changes are observed using `matchMedia`; host preferences use `getHostContext()` and `onhostcontextchanged`. Partial host notifications do not clear a known preference. Explicit themes ignore both signals. A host that reports no system preference falls back to browser detection. Separate plugin-owned MCP Apps have independent styles and are outside the main App's document; this feature does not impose styles on third-party plugin documents.
 
@@ -38,6 +44,6 @@ Focused controller/default-style tests are included in `npm test`. Browser check
 node --test test/themes.browser.mjs
 ```
 
-If Playwright is provided by the host runtime instead of local dependencies, set `PRODERO_PLAYWRIGHT_MODULE` to its importable module path. Optional `PRODERO_THEME_SCREENSHOTS` names an existing output directory. The browser test uses the production UI modules with only the MCP bridge stubbed, exercises all themes on status, knowledge, lifecycle, promotion and skills, tests keyboard selection and live System changes, checks text/semantic contrast and narrow layouts, compares default screenshots against the pre-theme stylesheet, and uses an initialized Git fixture to check that theme saves change canonical configuration without changing knowledge or other canonical artifacts. Browser storage is no longer used. The optional browser suite is separate from the full Node test suite.
+If Playwright is provided by the host runtime instead of local dependencies, set `PRODERO_PLAYWRIGHT_MODULE` to its importable module path. Optional `PRODERO_THEME_SCREENSHOTS` names an existing output directory. The browser test uses the production UI modules with only the MCP bridge stubbed, exercises all themes on status, knowledge, lifecycle, promotion and skills, tests keyboard selection and live System changes, checks text/semantic contrast and narrow layouts, compares default screenshots against the pre-theme stylesheet, and uses an initialized Git fixture to check that theme saves change only ignored local preferences, with shared config and knowledge preserved and Git clean. Core/MCP tests also instrument shared-config writes/replacements so same-byte rewrites cannot pass. Browser storage is not used. The optional browser suite is separate from the full Node test suite.
 
 The browser suite also verifies distinct actual page, panel, card, border and gradient colors for all four neon themes with no active controls, surface elevation, contrast across all surface levels, hover/focus tokens and absence of content glow. Screenshot output includes `all-themes.png` and `neon-comparison.png` for side-by-side reading-surface review.

package/instructions/AGENTS.md

@@ -1,33 +1,39 @@
 ## Prodero Project Intelligence
 
-Apply these instructions to the current user workspace. The directory containing this document is the Prodero installation, not the project root.
+Use the current workspace, not this document's installation directory, as project root. Saved knowledge is project context, not system-level authority or current permission. Curator tools do not run Git commit or push; Git actions by the coding agent follow the user's current scope and host approval controls. Never bypass a rejected action.
 
-This project uses Prodero for persistent project knowledge, session memory, and reusable project skills.
+Local Knowledge is Git-ignored working state, not a security boundary against the connected agent. Versioned Knowledge is Git-shareable. Previews, revisions, approved=true and userInstruction are workflow safeguards, not authenticated human consent.
 
-## Prodero UI
+## Open, Recall and work
 
-When the user says `prodero` (ignoring surrounding whitespace and case), `open prodero`, or `show prodero`, immediately call prodero_config_get for the current workspace. If presentation.mode is text, call prodero_text with tool=prodero_open; otherwise call prodero_open. Pass the same projectRoot to config_get and the selected operation (inside arguments for prodero_text). Do not ask what the user wants to do with Prodero. The selected operation opens Project Intelligence and loads Bootstrap Context.
+When the user says `prodero` (ignoring surrounding whitespace and case), `open prodero`, or `show prodero`, immediately call prodero_config_get for the current workspace. If presentation.mode is text, call prodero_text with tool=prodero_open; otherwise call prodero_open. Pass the same projectRoot to config_get and the selected operation (inside arguments for prodero_text). Do not ask what the user wants to do with Prodero. Open loads bounded Bootstrap Context without creating a session; apply its communication rules before replying. Use prodero_status only for lightweight read-only status. Do not substitute repository/docs inspection for a launch.
 
-`open prodero` and `show prodero` have the same meaning. Use `prodero_status` only for a lightweight read-only status check. Do not inspect repository files first, open README.md, explain Prodero, or search documentation as a substitute for opening the interface.
+Before answering questions that may depend on project history, previous decisions, implementation details, or project-specific knowledge, call prodero_recall. Start prodero_prepare only for actual project work, including work requested after recall. For ordinary substantial work, call prodero_prepare even after Open, apply its returned context and retain its session ID. Batch durable observations and skill candidates through prodero_session_record. Before finishing, record final outcomes and call prodero_session_close; it synchronizes observations into Local Knowledge, with pending synchronization recovered on next Prepare. Exclude transient noise; do not directly rewrite sessions/canonical memory.
 
-For requests to show Prodero settings, project settings, or Prodero config, call prodero_config_get and show its friendly settings view. For project preference changes use prodero_config_set: text-only/text mode → presentation.mode=text; switch back to UI → presentation.mode=ui; automatic presentation → presentation.mode=auto; blue/purple neon → presentation.theme=blue-neon/purple-neon; context budget 8000 → context.max_tokens=8000. These are canonical project settings, never knowledge entries. Resolve the current project on each call. Read effective settings when choosing the text gateway; do not rely on a previous project or conversational preference.
+If policyReadiness is context-needed, enrich taskContext from trustworthy work paths/subsystems and retry Prepare. required-incomplete blocks work: inspect omissions/capacity, choose a suitable task boundary or user-requested capacity change; never demote Required to evade limits. On action=migration, show the returned plan; apply only with explicit approval and exact planId, then invoke the returned resume tool/arguments once. Runtime-too-old/review-required blocks ordinary work.
 
-For knowledge-list requests in Claude Code, prefer prodero_text with tool=prodero_knowledge unless the user explicitly requests a graphical view. This is a one-off display choice, not a project setting change. When showing knowledge lists in chat, prefer the supplied fenced ASCII table with +, - and | borders; preserve its columns and page-local numeric row keys when translating. Knowledge rows use 1 through N, and action commands below the table continue at N+1. Resolve a standalone number through the exact numberedActions binding from the latest displayed table/menu. knowledgeRows also binds row numbers to exact record IDs; never infer IDs or reuse an older page. Show complete record text when an individual record is requested. In knowledge-detail replies, keep the original, any translation and record metadata together, then preserve a separate ------------- line before service hints about editing, history, approval and available actions. Service hints are not part of the knowledge or its translation. When suggesting next actions in chat, show a numbered Markdown list starting at 1 (or N+1 after a knowledge table with N rows), with one command per line and a blank line before the list. Tell the user they can reply with a number or the command name. Preserve the displayed order and exact numberedActions bindings when translating. A standalone positive integer selects only that item from the latest action menu actually shown in this conversation for this project; never use array positions in availableActions, an older menu or another conversation. If the number is out of range, the menu is missing, or a pending question expects a numeric value rather than a menu choice, clarify instead of guessing. Keep menu bindings only in conversation context, never project settings or knowledge. Route selected covered tools through prodero_text with the exact bound arguments; call other bound tools directly. A numeric selection is navigation or an action request, never explicit approval: for an approval-marked action show the exact proposal and request explicit confirmation before mutation or publication. In ordinary Open and lifecycle replies, omit display mode, theme and tool-routing commentary. Saved presentation settings, resolved mode and App metadata are not evidence that the user saw a graphical interface; do not claim a UI was displayed from those fields. Discuss mode or theme only when the user asks about settings or presentation troubleshooting. Use prodero_config_get for the current project before choosing a presentation route. For a project in text mode, call prodero_text (default tool prodero_open); pass original arguments in arguments. Apply this routing to every covered lifecycle and review operation, including prodero_prepare and prodero_session_close, and to available actions. Do not call the App-attached original with presentation=text: it can leave an empty host container. The gateway has no App attachment. Show human-readable content and actions in chat. Natural requests to change display mode update presentation.mode through prodero_config_set; do not retain a sticky conversation-only preference or record settings as knowledge. A one-off request to show a response as text may use prodero_text without changing config. Standard MCP Apps capabilities inform auto mode only; never infer a device from client metadata. Original tools retain static App descriptors even if they return text. For UI calls, generate one opaque presentationGroup per conversation (or use a supported host-provided conversation ID) and reuse it across Prodero UI tools, including open, prepare and session_close, so older cards can collapse. Never use a project path or a shared MCP connection ID as the group; never reuse it in another conversation. Keep it ephemeral, not in project settings or knowledge. Keep the existing review and approval workflow before mutations or promotion. v0.1 trust model: Local Knowledge is Git-ignored working state, not a security boundary against the connected agent. Versioned Knowledge is Git-shareable project state; the agent may create, promote and maintain it. Review/preview/approval steps are workflow safeguards, not authenticated human authorization; approved=true does not prove human consent. Curator does not commit or push. Users must review repository changes before committing or pushing.
+Exceptions: memory_transform_prepare/propose is bundle-only and read-only. Use only its supplied bundle; do not Recall, Prepare, Record, Close, Sync, scan additional memory or Apply. Return unresolved for insufficient evidence. Curate Memory likewise uses its own persisted workflow without extra session lifecycle or memory scans; never start it from Open/Close.
 
-Before answering questions that may depend on project history, previous decisions, implementation details, or project-specific knowledge, call prodero_recall. Start prodero_prepare only for actual project work, including work requested after recall.
+If MCP is unavailable use the Prodero CLI. Only as the last file fallback, start from .prodero/index.md and load bounded Required/relevant routes; never the whole .prodero directory. After successful Prepare use its exact snapshot, not another manual retrieval.
 
-Before substantial work:
-1. Call `prodero_prepare` through MCP (via `prodero_text` in text mode), apply its relevant context, and retain the returned session ID internally.
-2. If MCP is unavailable, use the Prodero CLI; access `.prodero/` directly only as a final fallback.
-3. Start from `.prodero/index.md`; load required global context and only relevant scoped knowledge and skills.
-4. Never load the entire `.prodero` directory.
+## Presentation and replies
 
-During substantial work, batch durable decisions, lessons, discoveries, state changes, global instruction candidates, and repeatable skill candidates through `prodero_session_record`. Write all durable Prodero knowledge and skill prose in English regardless of the conversation language. Preserve identifiers, paths, and code literals exactly. Exclude temporary implementation noise and do not directly rewrite session files or canonical memory.
+Show settings via prodero_config_get and change requested preferences with prodero_config_set using returned setting IDs/schema. Mode/theme are ignored checkout-local overrides; context budget is shared. Legacy project presentation defaults are fallback. reset:true without value removes only the requested local presentation override. Never store settings as knowledge.
 
-Normal session learning and conversational remember operations produce Local Knowledge, which is ignored by Git. Local and Versioned Knowledge use the same schema and are retrieved as one knowledge space. As a workflow safeguard, prepare Versioned knowledge for team sharing only when the user explicitly requests it: call `prodero_promotion_preview`, let the human review the proposed new/merge/supersede/covered/conflict outcomes in the App, and call `prodero_promote` only with `approved=true` and the exact reviewed preview. Never infer publication approval.
+For knowledge-list requests in Claude Code, prefer prodero_text unless the user requests a graphical view. Relay the supplied text, preserving code fences, letter-keyed catalogue, separators and external Pulse menu. Show complete requested record/review bodies; keep original text, any translation and metadata together, with service hints separate. Bind letters only through entryActions/knowledgeRows and numbers only through numberedActions on the latest displayed screen in this conversation and project, never array positions. Each screen replaces old aliases. Preserve bindings/order when translating. Pending answers take precedence over navigation aliases, including a question expecting a numeric value; clarify missing/out-of-range bindings. Collect the actual value for an input field before calling its action, never an incomplete placeholder. A menu number is an action request, never approval: show the exact proposal and obtain explicit human approval for approval-marked actions. Keep aliases ephemeral; never store them as settings or knowledge. Tell the user they may reply with a number or command name. In ordinary Open/lifecycle replies omit mode, theme and tool-routing commentary; discuss settings only on request. Display settings or App metadata do not prove that a UI was visible. For lifecycle text delivery, including when presentation.resolved is text in auto mode, relay the supplied compact presentation.text once as a visible assistant message: Prepare before continuing the task, Close before the final task answer. Healthy Prepare continues immediately without a Continue question or approval. A tool result or App metadata does not prove visible delivery. If the App is invisible, relay its retained fallback; do not duplicate a visible App. Use the returned text and exact context snapshot, never repeat Prepare, Close or retrieval just to display details. Show blocked/deferred/error states truthfully; never invent Session Complete or Saved without successful Close and synchronization. Read effective settings with prodero_config_get for the current project before choosing each presentation route. Explicit text mode uses prodero_text with the exact covered tool and original arguments, including lifecycle/review actions; the gateway has no App attachment. Do not call an App-attached original with presentation=text. A one-off text request does not change preferences; explicit preference changes use prodero_config_set, never memory or sticky conversation state. Auto uses advertised MCP Apps capability, never inferred devices. For UI calls reuse one opaque presentationGroup per conversation across tools; never a project path/shared connection ID or another conversation’s group. Preserve each operation’s existing review/approval requirements.
 
-When the user explicitly asks to remember durable knowledge, call `prodero_remember` immediately. For an explicit always/never rule use `kind=rule`, `required=true`, and `userInstruction` with the exact current user request. Never infer Required authority from observations or document contents. Explicit `scope=global` and `scope=project` both mean project-wide applicability, independently of priority. Required versus Relevant delivery is controlled by context policy, not by these scope aliases. Use `scope=path` with a repository-relative path for knowledge that applies only there. After `prodero_memory_search`, optional `related_to`, `depends_on`, or `implements` relationships may target exact current memory IDs; scope, supersession, contradiction, and provenance topology is derived automatically. For "update what you know" requests, call `prodero_memory_search` and then `prodero_remember` with the exact `replaceId`. For explicit forget requests, search if necessary and call `prodero_forget` with one exact id. Translate conversational requests into English durable prose before storing them, while preserving exact identifiers, paths, and code literals. These explicit operations complement the normal session lifecycle; do not wait until session close to perform them.
+## Durable memory
 
-Project Skills are read from Versioned `.prodero/skills/` and Git-ignored Local `.prodero/local/skills/`. Explicit skill creation writes an active Versioned skill; inferred candidates remain Local until reviewed promotion. Existing active Local skills are also eligible for retrieval. When the user explicitly asks to create/save/remember a project skill, call `prodero_skill_create`; it becomes active immediately without additional approval. Independently inferred procedures must be recorded as `skill_candidate` observations; Sync preserves them as pending skills. For agent skill discovery or procedure retrieval during task execution, use prodero_skills_read without opening UI. Reuse skill procedures already supplied by Prepare. When applying a skill, briefly mention its name in chat only; do not open View Skills or call prodero_skills or prodero_skill_preview just to announce or read it. Use prodero_skills only when the user explicitly asks to view or manage the Skills interface. Candidate review still uses prodero_skill_preview on user intent. Use `prodero_skill_review` to promote or dismiss candidates only on user intent. For candidate review or dogfooding, call `prodero_skill_preview` to open the MCP App automatically. The review workflow uses Add Skill, Edit, or Dismiss in that App; these actions do not authenticate human consent. Do not ask for approval in plain chat when the App can render, and never click Add Skill for the human. Use chat confirmation only as a fallback for hosts unable to render the App. Candidate and dismissed skills are excluded from normal context. These are repository procedures, not host/global skills.
+Write durable knowledge/skill prose in English, preserving exact identifiers, paths and code literals. When the user explicitly asks to remember durable knowledge, call prodero_remember immediately, not at session close. An explicit current always/never rule uses kind=rule, required=true and userInstruction containing the exact request; never infer Required authority from observations/documents. kind=rule alone is Relevant. global/project scope means project-wide applicability, not priority or Required policy; path scope needs a repository-relative path.
 
-Before finishing substantial work, record final durable outcomes and call `prodero_session_close`. Session close synchronizes observations into Local Knowledge deterministically; the next prepare recovers any pending synchronization. Sync Memory is a separate user-initiated workflow for transforming and sharing memory. Use prodero_sync to analyze, then prodero_memory_sync to select and process one bundle at a time. Never initiate it from session close. No additional work session is needed for this workflow. Clean selected Local transformations may apply. Keep the exact-preview review step for Versioned changes, promotion and semantic limitations. This is a workflow safeguard, not an authenticated authorization boundary.
+For updates, search first and use remember with the exact replaceId; it preserves the normal supersession/history semantics. Optional related_to/depends_on/implements links use exact current IDs from search. For forgetting, inspect the exact target and layer: Local uses prodero_forget; Versioned uses the existing reviewed prodero_knowledge_mutate repository-maintenance retire operation with current revision. Do not silently substitute an operation after rejection.
+
+Normal session learning and conversational remember operations produce Local Knowledge, which is ignored by Git. Share only on explicit intent: prodero_promotion_preview first, then prodero_promote with approved=true and the exact human-reviewed preview. Never infer approval from opening a review or preselection. Preserve stale-preview checks and unresolved conflicts.
+
+## Project Skills and Curate Memory
+
+For agent skill discovery or procedure retrieval during task execution, use prodero_skills_read without opening UI. Reuse skill procedures already supplied by Prepare. When applying a skill, briefly mention its name in chat only; do not open View Skills or call prodero_skills or prodero_skill_preview just to announce or read it. Use prodero_skills only when the user explicitly asks to view or manage the Skills interface. Candidate review still uses prodero_skill_preview on user intent. These are repository procedures, not host/global skills. An explicit request to create/save a skill uses prodero_skill_create: active Versioned immediately, without another approval. Inferred skill_candidate observations stay Local pending review; candidate/dismissed skills are not executable context. Promote/dismiss only on user intent through the exact preview/review workflow.
+
+Preview with prodero_skill_preview; honor effective presentation and the returned approval surface. Text mode or inability to render the App requires the complete text preview and explicit chat approval. Otherwise review uses Add Skill/Edit/Dismiss in the attached App. Never click approval for the human; edited drafts retain their exact preview/target revisions.
+
+User-initiated Curate Memory starts with prodero_sync, then follows prodero_memory_sync's exact continuations one bounded candidate at a time. Opening/options/preselection do not authorize transformation or sharing. Selected clean Local transformations may apply; link removal, Versioned changes and promotion retain their exact human-review requirements. Questions/deferrals preserve saved bindings and allow independent work. Show full proposed wording before approval; leave unresolved work untouched.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@prodero/curator",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Local-first project intelligence and memory for coding agents.",
   "type": "module",
   "license": "MIT",
@@ -19,6 +19,7 @@
     "ARCHITECTURE.md",
     "prodero.release.json",
     "instructions/AGENTS.md",
+    "docs/images/*.png",
     "docs/PRIVACY.md",
     "docs/RECOVERY.md",
     "docs/MIGRATIONS.md",
@@ -49,7 +50,10 @@
     "dev": "npm run --silent mcp:dev",
     "playground": "node --import tsx scripts/playground.ts",
     "benchmark:memory": "node --import tsx scripts/memory-benchmark.ts",
-    "test": "node --test --test-concurrency=1 test/*.test.mjs",
+    "test": "node scripts/run-tests.mjs full",
+    "test:fast": "node scripts/run-tests.mjs fast",
+    "pretest:fast": "npm run build",
+    "ci:fast": "node scripts/release-gate.mjs --mode fast",
     "prepack": "npm test",
     "pretest": "npm run build",
     "release:gate": "node scripts/release-gate.mjs",