Complete the Rust CLI around the Python MCP runtime

[projectious]

processkit: Rust CLI and Python MCP product briefing

Status: Approved direction and implementation briefing
Date: 2026-07-27
Evaluated release: v1.0.0-alpha.3
Audience: processkit and projectious.work portfolio maintainers
Decision record: DEC-20260727_1738-SnappyMesa-define-processkit-rust-cli-and-python

Executive summary

Continue developing processkit as a hybrid, provider-neutral product:

• a native Rust CLI is the stable installation and lifecycle-management
  boundary;
• Python remains the intentional implementation language of the MCP servers;
• skills, schemas, processes, state machines, adapters, and project entities
  remain visible, versioned files;
• context/ remains processkit's own normally installed project-management
  context and is a genuine dogfood consumer;
• src/context/ remains the distinct release deliverable installed into
  derived projects.

This is not a transitional compromise. It is the target architecture:

Rust CLI
    release acquisition, trust, planning, install, update,
    migration orchestration, recovery, uninstall, diagnostics,
    harness wiring, and optional MCP process supervision

Python MCP runtime
    MCP protocol implementation, domain tools, validated entity
    operations, routing, indexing access, and process workflows

Visible process content
    skills, schemas, state machines, processes, templates,
    package/profile manifests, and harness adapters

Project-owned state
    WorkItems, Decisions, Artifacts, Notes, Logs, TeamMembers,
    Migrations, configuration, and local overrides

The Model Context Protocol is language-neutral and does not require Python.
Keeping processkit's MCP servers in Python is nevertheless the right product
decision: the implementation and tests are mature, skill packages can carry
self-contained servers, domain behavior remains inspectable, and a wholesale
Rust rewrite would create substantial risk without a corresponding user
benefit.

The v1.0.0-alpha.3 release already establishes much of the correct Rust CLI
foundation: deterministic planning, transactional installation, signed release
verification, updates, recovery, conservative uninstall, compatibility
inspection, and opaque machine request/result envelopes. The next work should
stabilize and productize that boundary rather than expand the ontology or
rewrite the MCP layer.

Current-state assessment

What aligns strongly with the vision

processkit already embodies the strategic center of a provider-neutral,
AI-assisted operating system for projects:

• durable project state is stored in Git-reviewable files rather than chat
  history;
• schemas define entity contracts;
• state machines validate transitions;
• MCP tools enforce writes and generate audit events;
• a derived SQLite index accelerates reads without replacing canonical files;
• skills package reusable process knowledge;
• harness-specific integrations are projections, not canonical state;
• project-specific state and upstream product content remain separate;
• aibox can install and wire processkit but is not required to build, test, or
  release it;
• the repository dogfoods a normally installed version of its own product.

These are core product strengths and should remain fixed.

What v1.0.0-alpha.3 adds

The evaluated alpha adds a native Rust installer with:

• plan;
• install;
• update;
• verify;
• verify-release;
• recover;
• uninstall;
• inspect-compatibility;
• an opaque execute --request integration boundary;
• Ed25519 release verification;
• archive and installer digest binding;
• transactional staging, backups, locking, and journals;
• managed-path ownership;
• conservative, evidence-based uninstall;
• v0 compatibility evidence and migration dispositions;
• Codex and Claude harness projection handling.

This is the right correction to the v0 manual-copy installation model.

Remaining gaps

The alpha is not yet a complete standalone product experience:

• its Rust executable describes itself as an installer rather than the
  complete processkit CLI;
• human README examples omit the currently required --distribution input;
• the release publishes only an ARM64 GNU/Linux installer executable;
• no x86_64 Linux or macOS installer assets are present;
• there is no end-user installation script comparable to aibox;
• Python, uv, and Python dependencies remain runtime prerequisites for MCP;
• the difference between human CLI commands and the opaque aibox integration
  protocol is not yet cleanly expressed;
• the Rust installer is concentrated in an approximately 2,800-line
  main.rs;
• stable v0, default-branch, and v1 prerelease documentation do not yet present
  one coherent product and release story;
• ontology breadth and skill count are growing faster than evidence about the
  essential user journeys.

Decisions that are now fixed

1. processkit remains the repository and product name.
2. The processkit CLI is Rust and is distributed as native release artifacts.
3. Release distribution follows aibox's local container/host split.
4. Python remains the authoritative MCP server implementation language.
5. MCP server code remains installed with the relevant skill packages.
6. Skills, schemas, processes, state machines, and entities remain visible
   files rather than compiled opaque resources.
7. context/ and src/context/ retain their separate responsibilities.
8. aibox is an optional downstream installer/integrator, not a build-time or
   release-time dependency of processkit.
9. No GitHub Actions are introduced; build, test, signing, publishing, and
   documentation operations remain local.
10. v0 compatibility remains available until migration, rollback,
    interruption, secret-safety, and downstream parity gates pass.

Correct directory and ownership model

The repository has two intentionally different processkit installations:

Path	Responsibility	Ownership
context/	Project-management state for developing processkit itself	The processkit repository as a normal processkit consumer
src/context/	Release payload installed into derived projects	The processkit product as producer

They must not be merged, mechanically synchronized, or treated as redundant
copies.

context/ proves the consumer experience. It should be installed and updated
through the same supported mechanism used by derived projects. Its entities,
decisions, migrations, team state, and local configuration belong to the
processkit project and must never leak into a release.

src/context/ is the curated product source. Release gates must verify that it
contains only shippable schemas, skills, processes, state machines, manifests,
adapters, scaffolding, and other distribution content.

The relationship is:

processkit release artifact
        │
        ├── installed into derived projects
        │
        └── installed into processkit/context/ for dogfooding

processkit/src/context/
        └── producer source from which that artifact is assembled

Dogfooding is an acceptance test, not source duplication.

Product boundary

Rust CLI responsibilities

The native CLI should own operations that require a stable executable,
cross-platform distribution, strong filesystem safety, release trust, and
machine-consumable lifecycle contracts:

• release discovery and acquisition;
• signature and checksum verification;
• deterministic installation planning;
• profile and harness selection;
• transactional install;
• three-way managed updates;
• compatibility inspection;
• migration planning and orchestration;
• interruption recovery;
• conservative uninstall;
• provenance and managed-path verification;
• environment and runtime diagnostics;
• harness configuration generation;
• package/profile inspection;
• optional supervision of the Python MCP gateway.

Python MCP responsibilities

Python MCP servers should continue to own:

• MCP capability and tool registration;
• validated entity reads and writes;
• schema-backed entity operations;
• state-machine transitions;
• event-log side effects;
• skill discovery and routing;
• work, decision, note, artifact, migration, team, and other domain tools;
• index queries and process-specific orchestration;
• provider-neutral gateway aggregation;
• per-skill MCP entry points.

Visible content responsibilities

The following remain files:

• SKILL.md instructions and references;
• schemas and ontology declarations;
• state-machine definitions;
• processes;
• package and profile manifests;
• harness adapters;
• project configuration;
• templates and scaffolding;
• all project entities and audit logs.

This visibility is a product feature. It permits review, adaptation, Git
history, upstream contribution, and provider-independent interpretation.

Target command surface

The CLI should have a human-facing surface and retain a smaller opaque machine
protocol.

Human-facing commands

processkit init
processkit plan
processkit install
processkit update
processkit verify
processkit doctor
processkit inspect
processkit migrate
processkit recover
processkit uninstall
processkit package
processkit harness
processkit mcp

Recommended semantics:

Command	Contract
init	Inspect a project and create the minimal processkit configuration without installing content or overwriting user files.
plan	Resolve a release, profile, harness projections, current ownership state, and compatibility evidence into a deterministic non-mutating change plan.
install	Review and transactionally apply an exact installation plan.
update	Three-way reconcile from installed provenance to a verified target release, preserving user changes or reporting conflicts.
verify	Verify release identity, managed-file digests, projection ownership, and target-local state.
doctor	Diagnose binary, Python, uv, dependency, filesystem, Git, harness, server-startup, manifest, index, and project health.
inspect	Report installed version, profile, packages, adapters, compatibility state, and managed versus user-owned paths.
migrate	Plan, apply, resume, or roll back versioned project-data migrations without hiding loss or unresolved dispositions.
recover	Resolve an interrupted installer or migration transaction using persisted evidence.
uninstall	Remove only unchanged, provably owned content and report preserved files.
package	List and inspect available profiles, components, skills, and their dependencies.
harness	Plan, install, verify, or remove managed harness projections without owning unrelated user configuration.
mcp	Diagnose, launch, or proxy the installed Python MCP gateway and individual server entry points.

Machine-facing protocol

Retain:

processkit execute --request request.json

This is the stable aibox and automation boundary. It should accept one
versioned request and emit one versioned result envelope. Human CLI commands
may compile their intent into the same internal request types.

The machine protocol should remain explicit about:

• target root;
• requested operation;
• release/distribution identity;
• selected profiles;
• requested harness adapters;
• expected installed provenance;
• explicit mutation acknowledgement;
• conflict behavior;
• output schema version.

Human release resolution versus offline protocol

The current alpha requires callers to provide a local distribution path. That
is appropriate for the opaque protocol and offline operation but incomplete
for ordinary users.

Support both:

# Human, online, canonical release resolution
processkit install --version v1.0.0 --profile managed --harness codex

# Advanced or offline
processkit install --distribution ./processkit-v1.0.0 \
  --profile managed --harness codex

# Machine integration
processkit execute --request install-request.json

Online resolution must:

1. fetch canonical release metadata;
2. verify a configured trust root;
3. select the matching platform installer and distribution archive;
4. verify the signed envelope and every bound digest;
5. plan before mutation;
6. require review or an explicit non-interactive acknowledgement;
7. apply the exact plan.

No mutable branch or unverified latest-release URL should become an installation
input.

Python runtime contract

Python is an intentional processkit runtime dependency, not an MCP protocol
requirement. Document it that way.

The supported contract should identify:

• supported Python versions;
• supported uv versions or compatibility range;
• whether dependency resolution may contact the network;
• where dependencies and caches live;
• how offline or air-gapped use is prepared;
• how server scripts declare and pin dependencies;
• startup timeout and health-check behavior;
• how stderr, logs, and secrets are handled;
• how a server is tested against supported MCP protocol versions.

The Rust CLI should make this dependency reliable:

processkit doctor
processkit mcp verify
processkit mcp serve --transport stdio
processkit mcp serve --transport streamable-http
processkit mcp proxy --url http://127.0.0.1:8000/mcp

processkit mcp serve may supervise the installed Python gateway. It does not
need to reimplement it. This offers a stable executable path to harnesses while
preserving Python as the server language:

{
  "mcpServers": {
    "processkit": {
      "command": "processkit",
      "args": ["mcp", "serve", "--transport", "stdio"]
    }
  }
}

Direct uv run context/.../server.py configurations should remain supported
for compatibility, development, and tightly scoped per-skill deployments.

Rust CLI architecture

Refactor the current installer into a library-backed CLI before its protocol
surface expands:

installer/
├── Cargo.toml
└── crates/
    ├── processkit-cli/
    │   └── src/
    │       ├── main.rs
    │       ├── cli.rs
    │       ├── output.rs
    │       └── commands/
    └── processkit-installer/
        └── src/
            ├── lib.rs
            ├── protocol/
            ├── release/
            ├── trust/
            ├── distribution/
            ├── planning/
            ├── transaction/
            ├── ownership/
            ├── update/
            ├── compatibility/
            ├── migration/
            ├── recovery/
            ├── harness/
            └── error.rs

The binary entry point should parse commands, call library operations, map
typed errors to stable codes, and render human or JSON output. It should not
contain filesystem transaction logic.

The library must:

• reject absolute or escaping distribution destinations;
• handle symlinks explicitly;
• lock a target before mutation;
• stage changes on the same filesystem where atomic replacement is required;
• persist a journal before each irreversible step;
• fsync evidence where interruption safety depends on durability;
• restore permissions safely;
• never follow untrusted archive paths;
• preserve unknown user-owned files;
• bind plans to release and target-state digests;
• make recovery idempotent;
• avoid panics on user-controlled data.

Required implementation order

Phase 0 — freeze the corrected product boundary

1. Add the architecture decision to processkit.
2. Update the v1 RFC and installer documentation to state that Python MCP is
   retained intentionally.
3. Document context/ as dogfood consumer state and src/context/ as producer
   deliverable.
4. Remove any roadmap language implying a wholesale Rust MCP rewrite.
5. Define success through user journeys rather than language purity or
   ontology count.

Phase 1 — repair alpha contract and documentation consistency

1. Make README command examples executable as written.
2. Decide which commands accept canonical version resolution and which require
   an explicit distribution.
3. Ensure --help, README, installer contract, and request schemas agree.
4. Present stable v0 and exact-pin v1 alpha status consistently on the default
   branch and release pages.
5. Add a generated release-facts section for versions, artifact targets,
   profile names, schema counts, and tool counts.
6. Verify all documentation links from the staged release artifact.

Phase 2 — refactor the Rust installer

1. Move planner and transaction behavior out of main.rs.
2. Introduce typed public errors with stable machine codes.
3. Keep anyhow or equivalent context at the executable boundary only.
4. Add API documentation to all public library operations.
5. Preserve current JSON request/result and plan fixtures.
6. Prohibit unwrap and expect on user- or release-controlled inputs.
7. Make serialization failure handling explicit.

Phase 3 — complete native distribution

Adopt the aibox release split:

scripts/maintain.sh test
scripts/maintain.sh release X.Y.Z
scripts/maintain.sh release-host X.Y.Z

The container-side release phase produces:

processkit-vX.Y.Z-x86_64-unknown-linux-gnu.tar.gz
processkit-vX.Y.Z-aarch64-unknown-linux-gnu.tar.gz

The macOS host-side phase produces:

processkit-vX.Y.Z-x86_64-apple-darwin.tar.gz
processkit-vX.Y.Z-aarch64-apple-darwin.tar.gz

Every artifact requires:

• SHA-256 checksum;
• binding in the signed release envelope;
• version and target metadata;
• installed-binary smoke evidence;
• processkit --version;
• processkit --help;
• a non-mutating plan fixture.

The distribution archive containing processkit content remains a separate
signed asset. The installer executable and the content archive must be bound
to the same release identity without being conflated.

Phase 4 — add a human installer

Provide an aibox-style bootstrap script that:

• detects OS and architecture;
• selects an explicit or latest stable version;
• downloads canonical trust metadata and the matching installer;
• verifies checksums before execution;
• installs to ${PROCESSKIT_INSTALL_DIR:-$HOME/.local/bin};
• never requires root by default;
• reports PATH actions;
• runs processkit --version and a safe help/doctor check.

The bootstrap script installs only the CLI. The CLI then plans and installs
project content.

Phase 5 — make Python MCP startup deterministic

1. Define the Python and uv compatibility policy.
2. Add processkit doctor checks for every runtime prerequisite.
3. Verify PEP 723 dependency declarations during release.
4. Test dependency preparation and startup outside a repository checkout.
5. Add an explicit offline preparation path.
6. Ensure normal server startup does not unexpectedly alter tracked files.
7. Make gateway and per-skill startup failures actionable.
8. Test MCP initialize, tools/list, representative read, representative write,
   shutdown, and interruption behavior.

Phase 6 — supervise MCP through the Rust CLI

Add processkit mcp as a stable launcher and diagnostic surface while keeping
Python authoritative:

• resolve the installed project root;
• resolve the correct gateway or per-skill server;
• validate installed provenance;
• prepare a controlled environment;
• launch uv without shell interpolation;
• forward stdio transparently;
• preserve MCP exit and signal behavior;
• redact secrets from diagnostic output;
• offer a streamable-HTTP daemon and stdio proxy where supported.

This phase improves usability without changing MCP implementation language.

Phase 7 — strengthen dogfood acceptance

Treat installation into processkit's own context/ as a release acceptance
scenario:

1. stage the release artifact;
2. plan an update against a disposable copy of the processkit repository;
3. verify that project-owned context entities are preserved;
4. apply the update;
5. run pk-doctor and representative MCP operations;
6. verify the release boundary on src/context/;
7. exercise rollback or recovery from a deliberately interrupted update;
8. verify that no dogfood entity appears in the release archive.

Dogfood validation complements package tests; it must not replace fresh empty
project and independently derived-project tests.

Phase 8 — validate v0-to-v1 migration

Migration must be evidence-driven:

• detect the exact installed v0 layout and provenance;
• plan every entity and managed-file disposition;
• reject unknown kinds rather than silently guessing;
• report field loss and semantic changes;
• preserve append-only logs;
• journal mutation;
• support interruption recovery;
• retain the compatibility bridge until rollback and destruction of old state
  are no longer necessary;
• verify aibox and direct-CLI migration paths against the same corpus.

Phase 9 — stabilize scope before v1 GA

Pause expansion of first-class concepts and skills unless required by a defined
v1 acceptance journey. Prioritize:

1. install and verify;
2. create and transition work;
3. record and query a decision;
4. hand over and resume a session;
5. update with local customization;
6. migrate from v0;
7. recover from interruption;
8. use Codex and Claude through the same canonical state.

Advanced ontology concepts should be available through packages and profiles
without dominating the default mental model.

Test strategy

Rust CLI tests

• unit tests for release identity, paths, signatures, digests, plans, and
  ownership;
• golden request, result, plan, conflict, and error fixtures;
• archive traversal and symlink attacks;
• signature, checksum, size, target, and version mismatch;
• transaction interruption at every journaled step;
• idempotent recovery;
• unchanged, changed, deleted, and conflicting managed files;
• user-owned file preservation;
• conservative uninstall;
• arbitrary target directories;
• installed binary execution outside the checkout;
• all four target-platform smoke tests.

Python MCP tests

• schema and semantic validation;
• allowed and rejected state transitions;
• atomic entity and event behavior;
• index rebuild and stale-index recovery;
• gateway and per-skill parity;
• stdio and streamable-HTTP conformance;
• tool catalog generation and drift;
• secret redaction;
• concurrent or conflicting writes;
• project-root resolution;
• operation from the extracted distribution.

Integration tests

• Rust CLI installs a release into an empty project;
• the generated harness projection starts the Python gateway;
• representative read and write calls succeed;
• update preserves a user-modified skill or reports the correct conflict;
• uninstall preserves changed content;
• aibox invokes the opaque request/result boundary;
• direct CLI and aibox produce equivalent installed state;
• processkit updates its own dogfood context/;
• no project-management entity leaks into src/context/ or the archive.

Release evidence

The release should contain or reference machine-readable evidence for:

• source commit;
• version;
• Rust toolchain;
• build target;
• content archive digest;
• installer digests;
• public signing-key identity;
• release descriptor digest;
• provenance digest;
• test gate results;
• package smoke result;
• dogfood acceptance result;
• platform smoke results.

Security requirements

The CLI and Python runtime jointly form the trust boundary.

CLI

• verify before extraction;
• reject path traversal and unsafe link entries;
• bind executable, archive, descriptor, provenance, and manifest identities;
• use target-local locks and journals;
• avoid shell interpretation;
• preserve permissions deliberately;
• distinguish trusted release content from untrusted project content;
• never delete a path solely because its name appears in a new manifest;
• reject same-version equivocation and downgrade unless explicitly supported.

MCP runtime

• scope every operation to the resolved project root;
• validate writes through schemas and state machines;
• centralize canonical parsing and serialization;
• ensure write-plus-event behavior is atomic or recoverable;
• make annotations for read-only, destructive, and idempotent tools accurate;
• prevent raw filesystem escape through entity paths;
• redact credentials and private memory from errors and logs;
• keep provider credentials out of canonical project state;
• run HTTP transport on loopback by default and require explicit remote
  exposure and authentication.

Documentation model

Maintain distinct documentation for:

1. end users installing the CLI;
2. project owners installing processkit content;
3. harness integrators consuming the machine protocol;
4. maintainers writing Python MCP servers;
5. maintainers authoring skills and schemas;
6. release operators building Linux and macOS artifacts;
7. v0 consumers planning migration.

The README should remain a map:

• what processkit is;
• supported versus prerelease status;
• CLI installation;
• first useful plan/install/verify;
• first MCP connection;
• links to deeper installer, runtime, authoring, migration, and release docs.

Risks and mitigations

Risk	Mitigation
Rust and Python boundaries become ambiguous	Publish a responsibility matrix and enforce it in architecture reviews.
Python dependencies make startup non-deterministic	Pin declarations, prepare caches, add doctor checks, and test offline operation.
Human CLI leaks low-level protocol requirements	Keep explicit distribution inputs for offline/machine use and add canonical version resolution for humans.
Dogfood state leaks into releases	Preserve the context/ versus src/context/ boundary and test the staged archive.
Dogfooding hides fresh-install problems	Pair dogfood acceptance with empty-project and independent derived-project tests.
Installer monolith becomes unmaintainable	Refactor into a library before expanding commands.
Ontology breadth overwhelms users	Gate the default profile by proven journeys and expose advanced concepts progressively.
Compliance creates ceremonial agent calls	Automate safe routing and acknowledgement where possible; measure false positives.
Harness projections overwrite user config	Own only explicit managed keys and preserve unrelated content.
v0 migration loses semantics	Use exact evidence, explicit dispositions, loss reporting, journaling, and retained compatibility.
Platform artifacts behave differently	Build native macOS artifacts host-side and run target-specific smoke tests.
Rust launcher accidentally becomes a second MCP implementation	Keep it a supervisor; Python remains authoritative unless a later decision changes the boundary.

Suggested issue breakdown

Create focused follow-up issues in this order:

1. Document the Rust CLI/Python MCP and context//src/context/ boundaries.
2. Repair v1 alpha README, help, and distribution-input consistency.
3. Refactor the Rust installer into CLI and library crates.
4. Add stable errors and freeze request/result/plan fixtures.
5. Add canonical release resolution for human commands.
6. Add Linux x86_64/aarch64 release artifacts.
7. Add host-side macOS x86_64/aarch64 release artifacts.
8. Add the bootstrap installer script.
9. Define and implement processkit doctor.
10. Define the supported Python/uv runtime contract.
11. Add processkit mcp supervision and diagnostics.
12. Add full package-to-MCP extracted-release acceptance.
13. Add processkit-repository dogfood update acceptance.
14. Complete v0-to-v1 migration, recovery, and aibox parity.
15. Reconcile default-branch, stable, and prerelease documentation.
16. Execute the v1 GA gate.

Create the first four immediately. Refine later issues from the resulting
contract and fixture inventory.

Completion criteria

The product boundary is complete when:

• the Rust CLI is available for Linux x86_64/aarch64 and macOS
  x86_64/aarch64;
• checksums and signed release metadata bind every executable and content
  archive;
• a bootstrap script installs the CLI without requiring root;
• a human can install by exact version without manually assembling a
  distribution path;
• aibox can consume the same release through execute --request;
• install, update, verify, recover, migrate, and uninstall are transactional
  and covered by interruption tests;
• Python and uv prerequisites are explicit and fully diagnosed;
• the installed Python gateway passes MCP acceptance from an extracted
  package;
• direct gateway and Rust-supervised gateway modes are behaviorally equivalent;
• Codex and Claude projections preserve unrelated user configuration;
• v0 projects receive deterministic migration plans with explicit loss and
  disposition reporting;
• processkit can update its own installed dogfood context/;
• dogfood entities never enter src/context/ or release artifacts;
• essential project workflows are simple in the default profile;
• stable and prerelease documentation accurately match their binaries;
• no GitHub Actions have been introduced.

Immediate next actions

The next bounded implementation slice should:

1. land the corrected architecture statement;
2. fix alpha README and CLI contract inconsistencies;
3. refactor the Rust monolith without changing behavior;
4. freeze machine protocol and plan fixtures;
5. add the four-platform release plan and aibox-compatible artifact naming;
6. define processkit doctor and the Python runtime contract.

Do not rewrite MCP servers in Rust. Do not merge context/ and src/context/.
Do not expand the default ontology while installation, update, runtime
diagnostics, and migration remain incomplete.

The guiding constraint is:

Finish processkit as a trustworthy native lifecycle product around its
visible content and Python MCP runtime before adding more conceptual breadth.

Primary evidence

• processkit v1.0.0-alpha.3 release
• processkit repository
• processkit v1 installer contract
• processkit Rust installer source
• official MCP specification repository
• official MCP Rust SDK

[projectious]

The requirement matrix and minimum remaining path were refreshed in #152 and published in the v1.x docs. Current grouped status: 7 implemented, 6 partial, 3 missing.\n\nParallel gap analysis selected two low-overlap starting slices: (1) multi-target signed distribution/bootstrap foundations and (2) native runtime diagnosis. The first shared release foundation now exists in scripts/maintain.sh; the second is implemented in v1.x-dev as a read-only native processkit doctor command with typed JSON/human envelopes and tests.\n\nNext critical order: four-target artifacts and native smoke, checksum-verifying bootstrap, exact online resolver/trust roots, native MCP supervision, dogfood recovery/update acceptance, then v0 migration and aibox parity.

[projectious]

Gap-closing slice #153 is merged into v1.x-dev. It adds: (1) an exact-version, non-root bootstrap for the four target triples that requires an out-of-band Ed25519 key fingerprint and verifies signature/checksum/digest/size/native smoke, and (2) deterministic finalization of independently produced assets into one signed multi-target envelope.\n\nThis moves the bootstrap and four-platform clusters from missing to partial. We still do not claim platform support until x86_64 Linux and both macOS assets are natively built, smoked, and published; canonical release-key distribution and online exact-version resolution also remain.

[projectious]

Native runtime gap update: #154 is merged into v1.x-dev. The CLI now provides processkit mcp verify, mcp serve (stdio or loopback streamable HTTP), and mcp proxy (loopback only). It validates the canonical root and non-symlink gateway, launches uv without a shell, and preserves child exit status. Full installer/package/docs gates passed.\n\nThe next acquisition slice is intentionally waiting on canonical trust-root publication. Exact online downloads must not establish trust by downloading the public key beside the signature; the current exact-version bootstrap therefore continues to require an out-of-band fingerprint.

[projectious]

Runtime-readiness gap update: #155 is merged into v1.x-dev. processkit mcp prepare now validates the installed Python runtime policy and prepares all unique dependency profiles without starting MCP servers; --offline proves the selected/default uv cache can satisfy all profiles with network resolution prohibited. A real disposable install verified 8/8 profiles offline, and the full installer/package/docs suite passed.

[projectious]

Recovery acceptance update: #156 is merged into v1.x-dev. The release gate now interrupts a real update after its first filesystem action, requires exit 75 plus a durable journal, runs native recovery, proves exact prior-state restoration and project-owned-data preservation, verifies old provenance, retries the update, and verifies the new version/provenance. This is combined with the full shipped-content lifecycle pilot in scripts/test-installer-local.sh.\n\nThe integrated gate also exposed and fixed transient ETXTBSY launches on mounted filesystems with a narrow OS-error-26 retry; three consecutive Rust suites and the full package acceptance passed.

[projectious]

Gap-closing update: PR #157 is merged into v1.x-dev at ada0596 and the v1.x docs are deployed. The native CLI now supports a guarded migrate-v0 fresh-target transition for exact v0.27.1/v0.28.4 release evidence. Acceptance tests use disposable historical release trees, verify the resulting v1 provenance, reject candidate-only evidence, and confirm the source is not installed into or modified. The command explicitly reports legacy corpus data as not-copied; schema-aware entity transformation, field-loss reporting, immutable LogEntry preservation, and full aibox parity remain open.