# AiMe Chat Feasibility Gate Evidence

Status: `GO_WITH_SCOPED_CONSTRAINTS`  
Last updated: 2026-08-13  
Surface: `CHAT_VERIFIED_HIGH_MODE`

## Investment decision

**GO** for continued investment beyond the read-only feasibility prototype.
This decision proves that ChatGPT on the Chat surface can discover and call the
AiMe MCP tools on the tested Windows VM. It does not approve a production
release, higher capability levels, or general availability across every
ChatGPT model/mode, account, device, or rollout.

The accepted path on 2026-08-13 was Chat with AiMe explicitly selected and the
PC model mode set to `High`. The same private app also returned real tool
results on tested mobile and tablet clients. On the tested PC/account, `Pro`
mode did not reliably invoke AiMe tools; that is an observed ChatGPT product
constraint, not an AiMe policy decision or transport guarantee.

## Decision rule

This is the evidence record for the Phase 1 hard investment gate. Local tests,
a live outbound tunnel, or a successful OpenAI control-plane poll cannot by
themselves produce `GO`. The final decision requires corroborating evidence
from a fresh ChatGPT **Chat** conversation and an explicit manual review.

The manual review recorded the scoped `GO` above only after correlating Chat
results with the local audit, controlled disconnect/reconnect, app
uninstall/reinstall behavior, and process cleanup. A local `PASS_LOCAL` result
alone remains insufficient to change this decision.

## Evidence boundary

The local harness takes sibling container directories named `approved` and
`outside`, plus a disjoint evidence container. It creates three unique,
pairwise-disjoint directories for each run:

- one approved root containing only `allowed.txt`;
- one outside root containing a secret denial canary; and
- one evidence directory containing a fresh profile, audit file, and redacted
  manifest.

The profile exposes only the session-specific approved root. The manifest
contains hashes and relative test inputs, not raw canary values, absolute paths,
account identity, Chat URL, tunnel ID, or credentials. The allowed canary is
expected to become visible in Chat during the test. The outside canary must
remain confined to its local fixture file.

The summary can report only:

- `PASS_LOCAL`: all required local lifecycle, action, denial, redaction, and
  integrity checks passed;
- `INCOMPLETE`: the evidence is valid but required local observations have not
  all occurred; or
- `FAIL`: an integrity, redaction, or protocol-sequence check failed.

Its gate decision is always `PENDING_MANUAL_REVIEW`.

## Current VM preparation evidence

Observed on the disposable `GPTME-Lab` VM on 2026-08-13:

- a fresh session-specific fixture and profile were created without a tunnel
  ID, runtime key, browser operation, or OpenAI account mutation;
- the initial summary was `INCOMPLETE`, with zero protocol and tool events;
- fixture integrity, profile integrity, and the empty-audit redaction check
  passed;
- the surface remained `UNVERIFIED` and the decision remained
  `PENDING_MANUAL_REVIEW`;
- no AiMe or tunnel-client process remained after preparation; and
- the complete repository test suite passed 110 of 110 tests on `GPTME-Lab`
  after the credential, process-supervision, and evidence-review corrections.

A separate credential-transport probe used the exact pinned tunnel-client
v0.0.11 executable with SHA-256
`7d3c7d492ce84b52835e11865a835a8a5bcd4a669dee84e169aa11b314dc952a`.
The VM generated a random dummy key internally, protected a tunnel-bound
envelope with DPAPI CurrentUser, and delivered it through the native
supervisor's one-shot named pipe. The correct supervised child consumed the
pipe before the supervisor reported `started`; `tunnel-client doctor` then
exited with the expected nonzero diagnostic result against the deliberately
unreachable loopback control-plane address `127.0.0.1:9`. The dummy key and its
random prefix were absent from the supervisor request, captured output, and
logs. No tunnel-client or supervisor process remained, and the unique probe
directory and staged files were removed.

That probe made no OpenAI request and did not create, select, or modify a real
tunnel, app, runtime key, organization, workspace, or Chat conversation. It
proves compatibility of the local protected-key transport with the pinned
client, not Chat feasibility.

That preparation evidence alone proved only that the fixture was ready. The
real Chat evidence below is the separate basis for the investment decision.

## Real Chat observations

Observed and manually reviewed on the disposable `GPTME-Lab` VM on
2026-08-13:

- the final redacted local summary was `PASS_LOCAL`, with profile/fixture
  integrity, audit redaction, protocol lifecycle and sequence, status, list,
  allowed read, and outside-denial checks all passing;
- the summary contained 25 protocol events and 15 tool events before the final
  reconnect smoke, then advanced to 26 protocol events and 16 tool events on a
  third local connection;
- Chat displayed the unique allowed value returned by `read_text_file`, while
  the outside canary did not appear in Chat, audit, diagnostics, or logs;
- Chat calls succeeded from tested PC, mobile, and tablet clients on the Chat
  surface, and results remained available in the existing conversation;
- a controlled stop of the exact AiMe owner session reduced AiMe-owned Node,
  process-supervisor, tunnel-client, safe-filesystem-helper, and MCP processes
  to zero;
- one remaining `cloudflared.exe` was verified by path and SHA-256 as the
  separately running Khai-Hub binary, not an AiMe descendant or orphan;
- restarting the exact AiMe profile completed a fresh OpenAI control-plane
  poll, and the next Chat request returned the unique marker
  `AIME_RECONNECT_OK_8C31` with `read_only workspace`; the local summary gained
  one connection, one protocol event, and one successful tool event; and
- uninstalling the private ChatGPT app caused the next new `get_status` attempt
  to fail as an unknown/unavailable tool with no matching local `get_status`
  event. After reinstall, a fresh initialize and successful status call reached
  the VM again.

One read request that was already queued or in flight around uninstall still
reached the running local tunnel. Therefore this evidence supports fail-closed
behavior for subsequent calls, but does not claim that app uninstall instantly
cancels work already accepted by the transport. Immediate cancellation and
runtime-credential revocation remain separate product requirements.

The working conversation was revisited across clients and subsequent calls,
but a browser-reload action was not independently instrumented. Conversation
persistence is demonstrated; exact reload UI behavior remains an account-side
regression check rather than a transport guarantee.

## Operator workflow

Build the project before using the evidence command:

```text
npm run build
```

Create a session using three existing, explicit local container directories:

```powershell
npm run chat-gate:evidence -- prepare `
  --approved-root <absolute-approved-container> `
  --outside-root <absolute-outside-container> `
  --evidence-root <absolute-evidence-container> `
  --root-id lab
```

The command prints operator-only paths plus the two relative tool inputs. It
does not print either canary value or the manifest's evidence-session
identifier. The operator path necessarily contains a separate, non-secret run
directory identifier. Use the generated profile when starting AiMe. After calls
or lifecycle transitions, summarize the same session:

```text
npm run chat-gate:evidence -- summarize --session <absolute-session-directory>
```

Do not copy the profile, raw audit, tunnel log, or canary files into public
issues or Chat. The allowlisted summary is the exportable local record.

## Reviewed gate checklist

- [x] User authorized creation of a real tunnel and runtime key.
- [x] AiMe reached the OpenAI control plane using the protected key reference.
- [x] Fresh conversations were visibly on Chat, not Work, before calls.
- [x] AiMe was explicitly selected in the working Chat conversations.
- [x] Local audit recorded initialize, initialized, tool discovery, and multiple
      tool calls with gap-free sequence numbers.
- [x] Chat received the exact allowed canary through `read_text_file`.
- [x] Chat received a generic denial for the unique outside-relative input,
      while the outside canary appears nowhere in Chat, audit, diagnostics, or
      logs.
- [x] Multiple bounded calls completed in the same conversation.
- [x] The conversation remained on Chat after calls and across client revisit;
      exact browser-reload UI instrumentation remains an account-side
      regression check.
- [x] Observed latency/error behavior and the `High` versus `Pro` limitation
      were recorded. Full cancellation and caller-identity behavior remain
      open product tests because stdio exposes no verified Chat user identity.
- [x] Controlled disconnect and reconnect were demonstrated.
- [x] App access was removed and the next new call failed closed; runtime-key
      rotation/revocation remains a release-path test.
- [x] Tunnel, MCP host, native filesystem helper, supervisor, and descendants
      are absent after stop/revoke.
- [x] The complete evidence was manually reviewed and the scoped `GO` above was
      recorded.

## Open pre-production gaps

The feasibility fixture does not close these release gaps:

- user-facing orchestration of the native DPAPI enrollment flow, an
  unmanaged-only decrypt/delivery path, rotation/recovery/uninstall behavior,
  and signed helpers;
- signed packaging and installer/update provenance;
- the complete NTFS race, reparse, long-file, sparse-file, concurrency, and
  cancellation matrix; or
- product UX, higher capabilities, web/RBAC, deployment, or updater work.

These remain separate gated work. They must not be inferred as passed from a
successful Chat feasibility test.
