# IntegrityPhase — existing Base wallet and bounded owner session

`@integrityphase/codex-native-buyer` **0.1.4**, Windows, Node **24.14.x**. A ready Codex CLI MCP application using an existing EOA wallet and bundled SDK **0.6.0-r19.5**. Company configuration and source events are supplied as data. The customer does not implement callbacks, JavaScript signing code or `createPreparedHostHandler`. This locally released archive still requires separate public publication and live backend acceptance.

Version 0.1.1 adds an explicit connection-only owner check, corrects Windows CRLF readiness handling in the actual private-key receiver, and makes the PAUSED dialog describe only recovery/invoicing. Version 0.1.0 and its historical test evidence are preserved. Those tests did not accept the actual owner window.

Version 0.1.3 adds verification and recovery of server-authorized owner acceptance without a production invoice. The customer cannot choose this classification or disable invoicing. Owner results report `not_applicable_owner_acceptance`; customer sales still require a READY invoice. Both use the existing journal, enforced budget, company onboarding and source registration. No wallet, login or source is created merely by upgrading.

The connection window introduced in 0.1.2 is unchanged: a compact masked key field without a consent checkbox, used only for the local zero-payment check. It accepts 64 hexadecimal characters with or without 0x, trims surrounding whitespace, and explains why confirmation is disabled. Paid session scope approval remains a separate operation.

This local package implements the session flow. Automated acceptance uses synthetic owner approval, companies, qualification services and settlement with real local signatures. A real logged-in Codex agent completed that synthetic workflow on 14 October 2026. Actual wallet, backend, settlement and publication acceptance must be recorded separately for the delivered version. Installing this package does not open production sales. Nevermined remains OFF.

The wallet owner is the purchasing company's authorized person. IntegrityPhase's seller does not enter a private key or approve each customer order. An owner test uses the seller's wallet only because the owner is acting as the test buyer.

Run the commands below from the approved installation directory; the supplied executable wrappers are in its local `node_modules/.bin` directory.

## One-time connection

1. Verify the archive against the release `SHA256SUMS.txt`, then install it in the company's approved directory:

   ```powershell
   npm.cmd install --ignore-scripts --no-audit --no-fund C:\Downloads\integrityphase-codex-native-buyer-0.1.4.tgz
   ```

2. Use `codex.example.toml` with your installation path and a permanent private state directory. The same Windows user runs provisioning, the agent and the owner command. Existing `.4` buyer state can use this same directory; retain its vault, journal and budgets. Run only one buyer agent against it. Never create a fresh state directory to retry an uncertain payment.
3. Supply the existing company profile, authority, source secret, expected legal document hashes, recipient and session limits using the strict `provision.schema.json`. The trusted company configuration system sends JSON to standard input:

   ```powershell
   Get-Content -Raw C:\Company\integrityphase-authority.json | .\node_modules\.bin\integrityphase-native-provision.cmd provision C:\IntegrityPhaseBuyerState
   ```

   The file path is an example of a restricted company configuration file containing existing authorized data. The package accepts JSON directly and requires no customer program or network bridge. The file contains the source secret and must stay under the company's access controls. No wallet private key belongs in this JSON, shell history, environment, Codex conversation or a source event.

   Provisioning defaults to **OFF**, retains previous operations, and does not authorize a session. Fields in `session` specify duration (60–3600 seconds), total and per-purchase USDC atomic amounts (six decimals), and maximum payment count. Limits cannot exceed the standing authority. A payment's quoted validity must fit inside the remaining session, with a two-second margin; otherwise it is refused before budget reservation. Allow at least 902 seconds when the quote requires 900 seconds.

4. Send authorized events as JSON using `event.schema.json`:

   ```powershell
   Get-Content -Raw C:\Company\authorized-event.json | .\node_modules\.bin\integrityphase-native-provision.cmd event C:\IntegrityPhaseBuyerState
   ```

   Event references are immutable. The supplied source ID must match the provisioned authority. The application creates and validates the `.4` HMAC binding. A model cannot supply an arbitrary payload or replace the source secret.

5. The owner enables this client configuration when ready:

   ```powershell
   .\node_modules\.bin\integrityphase-native-provision.cmd enable C:\IntegrityPhaseBuyerState
   ```

   This enables the local client only. The server independently decides whether qualification and sales are available. Codex starts the MCP agent from the supplied configuration, initially with its signer **LOCKED**.

## First check: existing wallet, no payment

Before connecting company authority or enabling purchases, use the supplied check with the known public wallet address and an absolute, unused output path:

```powershell
.\node_modules\.bin\integrityphase-native-check.cmd 0xYourExistingEOA C:\Company\wallet-connection-result.json
```

`0xYourExistingEOA` is a placeholder for the existing address, not a private key. Its parent report directory must exist. The compact window displays the address, **0 USDC**, a masked key field and the check button. There is no company, legal or purchase authority and no consent checkbox in this connection-only window. Enter 64 hexadecimal characters with or without 0x; outer whitespace is ignored. Only the owner enters the key in its masked input. The process verifies the configured address and one fixed EIP-191 challenge, then releases key access immediately. It does not load buyer state, call a network service, sign a payment or unlock a purchasing session. The report contains only public identity, result and hashes. This check does not prove account balance or full agent autonomy.

## Preparation without payment

Version 0.1.4 accepts a session with `totalAtomic: "0"`, `perPurchaseAtomic: "0"` and `maxPayments: 0`. All three zero limits are required together. This session permits company delegation, onboarding, document acceptance, source registration and event preparation. It cannot invoke a purchase, reserve budget or sign typed payment data. The owner window explicitly displays preparation and 0 USDC. The separate standing company authority and its budget are still shown; they do not override this session limit. The existing SDK, journal and budget format are unchanged.

The onboarding presentation contains the current commercial offer when the server supplies it. It is not proof that sales are open or that an eventual payment has been authorized. After the exact purchase scope is reviewed, the company updates the session limits through the same provisioning command and the owner unlocks a new session. Changing any configuration invalidates the earlier session; existing operations and budget commitments remain.

## One owner approval, then autonomous tools

While that MCP agent is running, the owner invokes:

```powershell
.\node_modules\.bin\integrityphase-native-session.cmd unlock C:\IntegrityPhaseBuyerState
```

The separate Windows window shows the company, full standing authority, existing EOA, recipient, Base/USDC, source, approved document texts, session budget, payment count and deadline. The owner checks the scope, explicitly checks consent and enters the existing EOA's private key in the masked field. This does not create or import a CDP wallet. Safe may remain the recipient; this package does not implement Safe as payer.

The packaged dialog runs Windows PowerShell with `RemoteSigned` for that child process only. System and user execution-policy settings are not changed. Organization-enforced policy remains applicable; environments requiring signed application scripts must approve/sign the package through their normal deployment process.

A real local EIP-191 challenge first verifies control of the configured address without network access or payment. A different key is rejected. The agent can then use the existing ten MCP product tools to prepare and qualify the buyer, review and accept the exact documents, bind the source, buy, recover and retrieve the invoice. No extra signature windows appear inside the approved session. There is no raw signing, key export, enable, provisioning or budget-increase tool.

```powershell
.\node_modules\.bin\integrityphase-native-session.cmd status C:\IntegrityPhaseBuyerState
.\node_modules\.bin\integrityphase-native-session.cmd lock C:\IntegrityPhaseBuyerState
.\node_modules\.bin\integrityphase-native-provision.cmd pause C:\IntegrityPhaseBuyerState
.\node_modules\.bin\integrityphase-native-provision.cmd off C:\IntegrityPhaseBuyerState
```

Lock, timeout, process exit, authority expiry/revocation and configuration revision invalidate signing access. A new process always starts locked. PAUSED permits a separately approved **zero-payment** recovery/invoice session; OFF prevents online actions. Changes to company scope or configuration require another owner approval. The watchdog notices changes within approximately 500 ms and every signing/claim boundary checks them again.

The model should use `prepare_buyer` → `accept_buyer_documents` → `prepare_source_event` → `buy_proof` → `recover_purchase` / `retrieve_invoice`, following the actual results. Business or source refusal means no payment. `pending_reconciliation` means retain the original event and recover it. Unlocking again does not permit another payment for that operation.

## Persistence and exact limits

The unmodified `.4` SQLite journal and budget remain authoritative across sessions and restarts. The adapter reserves the same operation before signing, stores a signing intent before dispatch, and never signs that payment again after uncertainty. Native session identifiers and approval hashes supplement those existing records; there is no second payment ledger. Confirmed and uncertain operations both consume the standing budget. Session limits are additional caps over its remaining amount. Invoice verification and delivery use the existing `.4` implementation.

The wallet key travels through a random Windows named pipe restricted to the current user, with the receiving process ID verified, and stays in the agent's memory for this session. It is not persisted or returned over MCP. Controlled byte buffers are cleared. JavaScript/.NET strings, garbage collection, operating-system memory or crash dumps do not provide a guarantee of physical key erasure. Use the company's trusted Windows account and trusted application installation. The process boundary does not isolate a malicious program already running under that same user.

Local locking stops new signatures; it cannot revoke a signed authorization already sent. Its expiry is constrained to the approved session. The ordinary standing business delegation can have a longer validity and is shown separately in the approval window.

## Acceptance boundaries

The supplied tests exercise new `.4` onboarding, company/source qualification, quote refusal without reservation, one settlement under concurrent calls, response-loss recovery without another signature, restart recovery, budget limits and invoice consistency. Synthetic invoices validate against the pinned FA(3) XSD; this does not establish production KSeF acceptance or a customer sale.

For model acceptance, check login from the same approved Windows process context and restricted child environment used by the test. An isolated process reporting “Not logged in” can lack access to an already valid owner login; do not automatically request another login or copy credentials. On 14 October 2026, correcting that execution context allowed the real agent to finish onboarding, refusal, one simulated settlement and recovery through this adapter. Model tools remained restricted, company data and settlement stayed synthetic. Custom CA configuration is documented in [official Codex authentication documentation](https://learn.chatgpt.com/docs/auth#custom-ca-bundles); TLS verification was not disabled.

The archive is a local delivery. Public offer linkage, actual owner-window acceptance, a current real backend check and a controlled `.4` purchase are distinct evidence records. Public `.4` documents were already accepted through POST MCP; an earlier GET 403 does not invalidate that result.