# AlphaBot V2 1.0.0-rc3 — native dual-factor startup correction

The reported durable_account_or_config_binding_mismatch is a comparison of a
saved **local configuration/key fingerprint**. It was raised by Journal creation
before rc2 called the login gate. It was not a Cloudflare edge-state query.

## Corrected order

For a syntactically valid --live invocation:

1. Hidden prompt: `Enter App-Level Secret Password: `
2. Hidden prompt: `Enter 6-Digit Google Authenticator MFA Token: `
3. Read local project/security configuration and verify both factors against the
   encrypted local vault, including persistent TOTP replay prevention.
4. POST the SHA-256 password challenge through the administrator-configured HTTPS
   LIVE_AUTH_GATEWAY_URL; require the original AUTHENTICATED / integer 3600 /
   Secure+HttpOnly session-cookie contract.
5. Look up broker credentials, open the journal and review local binding metadata.
6. Start the read-only portal. A metadata mismatch becomes
   LOCAL_BINDING_REVIEW_REQUIRED, preserving the existing hash and all risk state.
   The portal stays available; no broker worker starts against an unreviewed scope.
7. Explicit authenticated rebind can approve same-account configuration/key
   changes only when the account/book are flat and reconciled. It records the
   transition without clearing a halt, lesson, peak, floor or pending intent.

Python imports/argument parsing have normal startup latency. No exact millisecond
latency guarantee is made. Real pseudo-terminal tests verify prompt order and
hidden input on this Linux POSIX host. Actual Mac host acceptance remains open.

## Real local MFA, not a cosmetic second prompt

The implementation now lives in gauntlet_v2.py and includes the complete local
vault reader and administrator gate. The old auth_gate.py module is a compatibility
export. The provided v1 vault format uses AES-256-GCM with a fixed-cost scrypt key,
random salt/nonce, six-digit SHA1 TOTP/30-second steps and a one-step clock window.
A private FULL-sync SQLite counter rejects replay across restarts and simultaneous
attempts. RFC 6238 SHA1 vectors are tested. Neither the seed nor entered tokens
are logged, sent to the remote password-hash endpoint or included in reports.

rc2 did not contain an existing local TOTP vault implementation, and no verified
legacy vault schema was available. This is an explicit, documented vault adapter;
compatibility with an unseen prior vault file is not claimed. Enroll the existing
Google Authenticator Base32 seed locally through the hidden enrollment command.
No credentials or seeds should be supplied in chat.

```bash
python3 -m pip install -r requirements.txt
python3 gauntlet_v2.py enroll-vault --project /absolute/project
python3 gauntlet_v2.py auth-check --project /absolute/project
python3 gauntlet_v2.py --live --serve --project /absolute/project --port 8080
```

Each accepted enrollment/auth-check/login consumes its TOTP counter; use the next
unused Authenticator code for the next command. Auth-check validates locally
without keys or network and never fabricates gateway authorization. A real live
session still needs the configured gateway to issue its genuine session cookie.
The remote hash-only contract cannot independently attest local MFA; gateway-side
MFA enforcement would require a separately implemented server protocol.

## --serve and dynamic snapshots

--serve alone observes the exact native database without reading trading config,
prompting for login or requiring broker keys. --live infers run. --live --serve
runs the engine and its connected observer together. --project defaults to the
current directory rather than a demo. The portal retains committed-frame replay,
balanced Decimal journal rows, historical selection, equity/floor graphs and
lesson memory. A live binding review does not block the read-only portal.

## Explicit metadata rebind

```bash
python3 gauntlet_v2.py rebind --project /absolute/project --acknowledge-binding-change --reason "Verified same-account local configuration or key rotation"
```

The command requires the same verified broker/account, no pending outcomes,
flat holdings, matching cash/holdings and no unresolved accounting. A conservative
saved starting-capital baseline protects the previously recorded flat-account
floor. Existing durable halts remain halted; rearm is separate. An initialized
legacy Kraken project without a verifiable stored account scope cannot be
silently migrated. No reset/delete-state workaround is introduced.

## Acceptance scope

The bundled tests use synthetic credentials and localhost HTTP/HTTPS/WebSockets.
No real account, production gateway, Authenticator phone or live order was used.
Full live gateway/venue acceptance, actual Alpaca fee/individual-fill completion,
strict guaranteed market-order debit caps, external protection and actual browser
responsive rendering remain open as detailed in AUDIT_FINDINGS.md. The build is
an implementation candidate, not a production certification.