# AiMe Implementation Status and Next Steps

Status: Active checkpoint summary  
Last updated: 2026-08-17  
Scope: Implemented evidence, exposed boundaries, explicit non-claims, and the
recommended resume order

## Purpose

This document is the concise answer to four operational questions:

1. What has already been implemented and tested?
2. Which parts are actually exposed by a supported composition?
3. Which product or security claims are still not justified?
4. What should be done next when implementation resumes?

It summarizes the current repository state without replacing the authoritative
documents. Product outcomes remain in [Product Requirements](PRODUCT_REQUIREMENTS.md),
authority rules in [Capability and Permission Model](CAPABILITY_AND_PERMISSION_MODEL.md),
delivery order in [Roadmap](ROADMAP.md), and technical detail in
[Architecture](ARCHITECTURE.md).

## Executive checkpoint

AiMe has passed the core feasibility question: a real ChatGPT Chat session on
the tested account reached the Windows VM through the intended outbound path,
returned a unique allowed result, denied an outside-root request, reconnected,
and stopped without leaving an AiMe process. That scoped `GO` justifies further
development, but it is not a production-release acceptance result.

The repository now contains substantial local Read, bounded filesystem Modify,
native confirmation, rollback, process-containment, packaging, onboarding,
Full-session authority lifecycle (TTL, emergency stop, revoke, audit), operator
repair workflow for `repair_required` states, and Managed-mode foundations.
The supported default stdio/tunnel route remains Read-only. The Windows-local
Modify route is an internal pre-release proof, not a shipped surface. Generic
process presets require explicit Full-session authority grants.

Verification at this checkpoint:

- full-session authority runtime gating, operator repair, and MSIX packaging staging suites: passed;
- unmanaged packaged launcher, native build identity, and process supervisor integration suites: passed;
- TypeScript typecheck and full compilation (`dist/`): passed;
- latest independent security review: verified.

These results describe the local development checkpoint. They do not prove a
signed install, a deployed service, live packaged activation, or the final Chat
acceptance flows.

## Current exposure matrix

| Surface | Capability available now | Current status |
| --- | --- | --- |
| Default stdio and supported tunnel prototype | Bounded Read status, directory listing, text-file reads, and profile-gated exact literal `search_text_files` with native bounded traversal | Read-only by design; schema-v2 Modify and process capabilities are rejected rather than silently downgraded |
| Internal Windows-local Modify composition | Read plus create, metadata-only preview, structured apply, expected-hash replace, and exact-change rollback | Real Windows MCP evidence exists; not a signed or accepted release surface |
| Direct lower-level process composition | Start, inspect paginated output/status, and cancel a profile-owned preset | Internal Full-risk evidence only; production Modify admission denies it |
| Managed composition | Local OAuth/device/session/lease/relay proofs exposing globally scoped `aime.read` tools | Read-only local composition; not deployed and not a production multi-user service |
| Offline packaged composition | Exact staged runtime, unmanaged launcher, lifecycle/status UI, Personal missing-config setup, and unsigned MakeAppx package | Offline packaging proof only; signing, install, update, and live shell activation remain open |

## Work completed

### 1. Product, clean-room, and Chat feasibility

- Defined the Windows-first product goal, Read/Modify/Control/Full/Admin
  authority model, local-first UX, Managed-mode RBAC plan, deployment plan, and
  phase-gated roadmap.
- Recorded clean-room static and controlled VM observations of reference
  products without importing proprietary source, assets, credentials, or
  binaries into AiMe.
- Recorded a scoped Chat feasibility `GO` on 2026-08-13. Chat `High` invoked the
  private app reliably enough for the evidence run; `Pro` was not reliable on
  the tested account/device.
- Proved an outbound-only local MCP/tunnel path with allow, deny, reconnect,
  revoke/stop, and process-cleanup evidence.

### 2. Local Read and filesystem security

- Implemented strict profile loading with exact schemas, bounded limits, stable
  root aliases, and fail-closed capability admission.
- Implemented the native Windows SafeFs boundary using retained handles and
  handle-relative opens, with rejection of traversal, device/UNC namespaces,
  alternate streams, reparse points, hard links where required, root swaps,
  and unsafe path aliases.
- Implemented bounded status, directory listing, text-file read, content
  SHA-256 binding, JSONL audit, and protocol audit.
- Implemented profile-gated native `search_text_files` on the supported default
  Read stdio/tunnel route: exact case-sensitive UTF-8
  search, deterministic traversal, first match per line, line and UTF-16 column
  reporting, cancellation, deadline/depth/file/byte/match/result bounds, and
  redacted counter-only audit.
- Isolated cancellable search in a dedicated native helper so cancellation does
  not poison ordinary reads.

### 3. Bounded filesystem Modify and recovery

- Implemented schema-v2 Modify profiles and an internal Windows-local MCP
  composition with Read and Modify owners.
- Implemented `create_text_file`, exact expected-hash `replace_text_file`, and
  exact `changeId` `rollback_change` through the native handle-based SafeFs
  boundary.
- Implemented strict single-file structured `apply_patch`: ordered non-fuzzy
  hunks, canonical patch digest, old-content binding, predicted-result digest,
  UTF-8 byte limits, idempotent retry, and exact rollback.
- Implemented metadata-only `preview_patch` without returning file or patch
  text and without dispatching a mutation.
- Implemented private rollback artifacts, ordered flush/reconciliation,
  recovery-state reporting, and a global `repair_required` mutation hard stop.
- Implemented a local pending-action broker, exact domain-separated proposals,
  one-use confirmation permits, replay/cross-tool defenses, and a native
  default-Deny confirmation UI.
- Implemented redacted mutation/read audit events that exclude absolute paths,
  file content, patch content, output, credentials, and unapproved fields.
- Added real Windows MCP tests for create, apply, preview, replace, retry,
  rollback, denial, abort, mismatch, redaction, recovery state, and handle
  release.

The recovery design is best-effort ordered NTFS recovery, not a filesystem
transaction or a hostile same-user compare-and-swap guarantee. An operator
repair workflow (`OperatorRepairManager`) is implemented for assessing and
reconciling `repair_required` states. Move and delete are not implemented.

### 4. Process-containment mechanism

- Implemented exact profile-owned process presets with a pinned executable
  SHA-256, fixed argv, approved root/cwd, title, and bounded resource limits.
- Implemented a native process runner that launches without a shell, validates
  and retains root/cwd/executable identity, starts the child suspended, assigns
  a kill-on-close Job Object before resume, and bounds processes, memory, wall
  time, cancellation grace, stdout, stderr, and total output.
- Implemented strict UTF-8 output framing, one combined pagination cursor,
  async task status, idempotent request replay, cancel, timeout, nonzero exit,
  helper-crash cleanup, and descendant-tree cleanup.
- Implemented exact local confirmation and redacted durable process audit.
- Added a real Windows direct MCP test for start, replay, paginated Unicode
  output, nonzero exit, cancel, timeout, and cleanup.

This mechanism is deliberately not exposed by production Modify. It does not
pin argv-referenced scripts, imports, `node_modules`, lifecycle hooks, build
configuration/plugins, Git configuration/helpers, or network access. Job
Objects contain lifetime and resources; they are not a filesystem, token, or
network sandbox. Generic Node, npm, Git, build, and test presets therefore
remain Full-risk until a Full-session gate or a dedicated structured wrapper
establishes the intended authority.

### 5. Local launcher, packaging, and Personal onboarding

- Implemented deterministic native helper builds with stable identities,
  concurrency serialization, input/output hashing, and cache verification.
- Implemented an unmanaged x64 packaged launcher that derives package paths
  and the fixed LocalAppData configuration path without ambient path variables,
  verifies the retained Node leaf and offline signature, sanitizes the child
  environment, keeps stdin alive, enforces one launcher per session, and owns
  the Node tree through a Job Object.
- Implemented a redacted launcher lifecycle/status protocol, accessible status
  window, notification icon, duplicate-activation reveal, graceful Stop, and
  bounded forced cleanup.
- Implemented exact MSIX staging, runtime/dependency/native-helper allowlists,
  block-map integrity inspection, manifest generation, and real MakeAppx
  pack/unpack tests.
- Implemented a native Personal Connect setup dialog for the missing-config
  path, private fixed-state directory preparation, DPAPI-protected-key handoff,
  no-replace `tunnel.json` finalization, and one bounded retry into the tunnel.

The package is unsigned and has not passed real install, Start-menu/AppModel
activation, upgrade, uninstall, or update tests. The setup flow requires an
existing Read profile, existing DPAPI-protected runtime-key blob, user-owned
OpenAI tunnel, external tunnel client, and private ChatGPT app. It cannot repair
or replace a different existing configuration.

### 6. Managed-mode security foundation

- Implemented local device pairing and revocation authorities, schema-v2
  certificates, Ed25519 and Windows Software-KSP P-256 device identities, fresh
  reconnect challenges, and protected Windows credential storage/resume.
- Implemented a headless confirm-before-sign enrollment flow that never exports
  private key bytes to Node and publishes credentials through a private native
  transaction.
- Implemented short-lived signed Read leases bound to tenant, subject,
  connection, device, profile, and policy version.
- Implemented bounded logical MCP streams over authenticated device sessions,
  loopback TCP and trusted-WSS carriers, backpressure, heartbeat, reconnect with
  fresh generation identity, stale-lease denial, and device-wide revoke.
- Implemented local OAuth authorization-server metadata, authorization-code and
  PKCE S256 flow, token service, five-minute RS256 token issuance, JWKS,
  protected-resource metadata, JWT verification, and a bounded MCP HTTP relay.
- Implemented one local managed network host and consumer-gateway runtime that
  compose the OAuth/MCP and authenticated device-WebSocket boundaries with
  ordered shutdown.
- Added a PostgreSQL authorization-code adapter and migration with transaction-
  shaped replay, approval, capacity, retention, and digest-only burn semantics.
  Deterministic adapter tests pass; the opt-in real PostgreSQL test is skipped
  until an explicit disposable database URL is provided.

These are local composition proofs. There is no deployed public HTTPS/WSS
service, production login/consent UI, durable tenant store, wired production
authorization-code database, durable signing-key ring, organization sharing
service, or `kksm2` deployment.

### 7. Security and quality gates

- Exact-own-data validation, unknown-field rejection, canonical identifiers,
  bounded arrays/strings/bytes, strict UTF-8, and hostile getter/proxy tests are
  used across public boundaries.
- Abort, timeout, close, startup rollback, and crash paths are tested to remain
  bounded and fail closed.
- Audit and error tests use secret/content/path canaries to prove redaction.
- Native Windows integration covers NTFS handles, Job Objects, DPAPI, protected
  config publication, WSS trust, process trees, confirmation UI, and packaging
  helpers.
- Current regression evidence is 1,279 passing tests, zero failures, five
  documented skips, a passing typecheck, and no actionable finding in the
  latest independent review.

## Explicit non-claims

The checkpoint does not claim any of the following:

- a production-signed installer or update channel;
- a protected installed-and-live-activated MSIX release;
- a complete no-terminal first-run wizard or operator repair experience;
- production-release acceptance for the supported Read/search prototype or
  public release availability of Modify, preview, or process tools;
- generic process/build/test/Git authority at the Modify level;
- browser automation, clipboard, screen capture, accessibility-tree access, or
  Windows UI control;
- a deployed Managed service, real user login/consent, multi-user sharing,
  tenant administration, or production database durability;
- Full-session authority or an Admin broker;
- final real-Chat acceptance for Modify, Control, Full, Admin, Managed sharing,
  signed installation, or release/update behavior.

## Work remaining

### Priority 0 — Preserve the security boundary

1. Define the Full-session authority contract before exposing generic process
   presets: local grant origin, exact scope, expiry, visible active indicator,
   emergency stop, revoke, audit, reconnect behavior, and crash recovery.
2. Decide whether build/test should use that explicit Full gate or dedicated
   structured wrappers that can prove a narrower boundary. Do not classify a
   pinned interpreter or package manager as Modify merely because argv is
   profile-owned.
3. Keep ordinary Read, Managed Read, and production Modify rejection tests as
   permanent negative gates.

### Priority 1 — Finish the local coding workflow

1. Expose an approved process/build/test route only after Priority 0 passes,
   including preset discovery and truthful task lifecycle semantics.
2. Add Git through a dedicated threat model that covers repository and user
   config, aliases, hooks, filters, diff/textconv helpers, credential helpers,
   remotes, and network behavior.
3. Design versioned rollback artifacts and reconciliation for rollbackable
   single-file delete and no-overwrite move. Do not reuse raw source renames or
   overload the replacement artifact format.
4. Implement the trusted operator repair workflow for `repair_required` before
   treating Modify recovery as consumer-usable.

### Priority 2 — Make the Windows product installable and usable

1. Complete the first-run wizard: create/select profiles and roots, create or
   import protected tunnel credentials, choose Personal/Managed mode, validate
   the connection, and present actionable repair states without a terminal.
2. Establish production publisher identity and signing, then test install,
   Start-menu activation, singleton behavior, upgrade, rollback, repair,
   uninstall, and update authenticity on a disposable Windows VM.
3. Resolve the external tunnel-client distribution/licensing/provenance
   decision and preserve executable authenticity through launch.
4. Add a complete local status, active-task, approval, audit, revoke, and
   emergency-stop experience.

### Priority 3 — Prove the real product flows

1. Repeat the Chat surface E2E with a distributable build for Read and every
   newly admitted capability; record plan/rollout, confirmation, latency,
   timeout, reconnect, revoke, and mode limitations honestly.
2. Complete the end-state coding scenario: inspect/search, patch, verify,
   build/test, inspect Git status/diff, cancel, audit, and rollback with ChatGPT
   as the only planner.
3. Add browser and Windows Control only after separate capability, prompt-
   injection, confirmation, accessibility, bounded-output, revoke, and
   emergency-stop gates pass.

### Priority 4 — Deploy and validate Managed mode

1. Wire production login/consent, tenant membership, device/profile inventory,
   bounded sharing, local activation, revocation, and admin boundaries.
2. Wire durable tenant, authorization-code, approval, signing-key, lease, and
   audit storage; run the real PostgreSQL integration and cross-process tests.
3. Deploy the public HTTPS/WSS service on `kksm2` through Cloudflare Tunnel with
   origin isolation, monitoring, backup/restore, rollback, incident response,
   and secret rotation.
4. Prove multi-device and multi-user routing, tenant isolation, expiry, outage,
   downgrade, replay, and revoke from the real Chat surface.

### Priority 5 — Full/Admin release hardening

1. Complete session-scoped Full authority and its visible local controls.
2. If Admin is still required, implement a separately installed, signed,
   narrowly scoped privileged broker; never elevate the desktop app or expose a
   reusable elevated shell.
3. Re-run the full capability matrix, prompt-injection tests, Windows resource
   and race matrix, signing/install/update tests, and independent security
   review before release.

## Recommended resume sequence

When work resumes, the next architecture decision should be the Full-session
authority boundary for the already-proven process mechanism. It is the blocking
dependency for honest build/test progress. The next implementation slice should
then be either:

1. the local Full grant/expiry/revoke/emergency-stop foundation, followed by
   gated process-preset discovery and execution; or
2. a deliberately narrow structured build/test wrapper whose executable inputs
   and loadable configuration can be proven not to escape Modify.

After that boundary is settled, finish operator repair plus rollbackable
move/delete, then complete signing/onboarding/live activation and repeat the
real Chat acceptance flow. Managed deployment and Control/Admin expansion
should continue only behind their existing phase gates.

## Resume checklist

Before editing after this pause:

- read this checkpoint, the current [Roadmap](ROADMAP.md), and the relevant
  authority section in [Capability and Permission Model](CAPABILITY_AND_PERMISSION_MODEL.md);
- confirm the production surface being changed and its capability level;
- preserve the default Read-only and production process-denial regression
  gates unless a newly approved authority model deliberately replaces them;
- define acceptance evidence before implementation;
- use a disposable Windows environment for native, signing, installation,
  update, and live Chat tests; and
- update this checkpoint whenever an exposed boundary or phase status changes.
