chore: preserve current staging source on main

AGENTS.md

@@ -8,7 +8,7 @@ Build a secure, evidence-backed STRK20-funded Vickrey auction house for escrowed
 - Behavioral changes follow strict RED -> GREEN -> REFACTOR.
 - Use CodeGraph before investigation/edits and after source path changes. Never commit `.codegraph/`.
 - Preserve the approved privacy language: equal public cap collateral; actual bid sealed until reveal; no claim that a variable note amount remains encrypted after leaving the pool.
-- The app never receives, persists, exports, or logs wallet private keys, viewing keys, bid secrets, claim secrets, or recovery plaintext.
+- Wallet private keys, viewing keys, private notes, and session material never enter the app. For the approved sprint Wallet API demo, bid/claim credentials may exist only in active browser memory and a mandatory password-encrypted downloaded recovery bundle; plaintext is never persisted, exported, logged, or sent to a server.
 - `privacy_invoke` accepts only the configured STRK20 pool and accounts for collateral from observed balance delta.
 - Mainnet writes require fresh human approval with exact budget, addresses, and expected state.
 - `strk20.json` contains only real read-back-verified successful mainnet hashes/addresses.

context/architecture.md

@@ -1,16 +1,14 @@
 # Architecture
 
 ```text
-Browser
-  -> Starknet RPC (read-only auction/event/receipt state)
-
-CipherBid Vault CLI (user-operated; no browser bridge)
-  -> Starknet RPC (independent auction verification)
-  -> Privacy SDK / dedicated account (keys, note discovery, proving)
-  -> STRK20 pool -> CipherBidAuctionHouse.privacy_invoke (private uniform-cap bid ingress only)
-  -> CipherBidAuctionHouse.reveal / claim (direct public lifecycle calls)
+Browser UI
+  -> get-starknet v6 discovery -> privacy-capable wallet -> WalletAccountV6
+  -> Starknet RPC (auction/event/receipt reads and readback)
+  -> CipherBidAuctionHouse.create_auction / reveal_bid / settle_auction (standard wallet calls)
+  -> STRK20 pool -> CipherBidAuctionHouse.privacy_invoke (uniform-cap bid ingress and all monetary claims)
   -> ERC-721 contract (custody and winner delivery)
-  -> local OS-protected credential store
+  -> user-downloaded password-encrypted recovery bundle
+  -> Atomic Delivery Receipt (public RPC-derived verification)
 ```
 
-The Cairo auction house is authoritative for auction lifecycle and accounting. CipherBid Vault is the user-operated custodian of its dedicated execution account, STRK20 viewing key, private notes, bid nonce, and encrypted offline claim bundle. The browser owns only public read-only state and may display a public vault receipt; it never prepares or submits auction actions, or handles recovery plaintext or any credential secret. The user's normal privacy wallet remains separate and may fund the vault profile outside the CipherBid website. There is no CipherBid custodial backend or database.
+The Cairo auction house is authoritative for ERC-721 custody, auction lifecycle, Vickrey settlement, and value accounting. A supported user wallet owns its private key, viewing key, private notes, proof generation, signing, and transaction submission. The CipherBid UI connects through the Wallet API boundary, displays the exact transaction target/cap/commitment, holds bidder and seller claim credentials in memory only, requires password-encrypted recovery export/import verification, and reads back every receipt and expected state transition before showing confirmation. There is no CipherBid custodial backend, database, local-vault daemon, or alternate sprint transaction path. The authoritative product boundary is `docs/evidence/winning-product-scope.md`.

context/decisions/0002-cipherbid-vault-custody.md

@@ -1,32 +1,34 @@
-# Decision 0002: Keep auction credentials in a user-operated local vault
+# Decision 0002: Use a direct Wallet API route for the sprint demo
 
-**Status:** Accepted
+**Status:** Accepted sprint authority; supersedes the local-vault MVP decision
 
 ## Decision
 
-CipherBid adopts `cipherbid-vault`, a user-operated local CLI, as the sole owner of the vault-profile execution-account key, vault viewing key, vault-private notes, auction bid nonce, encrypted credential record, and offline claim private key.
+For the sprint demo, CipherBid uses the selected STRK20 starter-kit Wallet API integration in the browser: get-starknet v6 discovery, `WalletAccountV6.connect`, Wallet API capability detection at `>= 0.10.3`, `strk20PrepareInvoke`, `strk20InvokeTransaction`, bounded receipt polling, and readback-confirmed state transitions.
 
-The web app remains a public-data-only reader. It may display public descriptors and read-back receipts, but it never submits auction actions. It must not receive the sealed bid amount, bid nonce, claim private key, vault master key, execution-account key, viewing key, private notes, or recovery plaintext.
+The privacy-capable wallet remains the sole owner of its wallet private key, viewing key, notes, proving, signing, and transaction submission. The CipherBid UI collects a bid amount, generates app-specific bidder and seller claim credentials in memory, builds the reviewed auction actions, and asks the connected wallet to sign/submit them. Reveal and every monetary claim use the matching in-memory credential or a user-imported encrypted recovery bundle.
 
-The vault uses the maintained Privacy SDK for its own dedicated account to submit STRK20 equal-cap ingress, and that account also sends direct public reveal/claim calls. It never imports the user's normal wallet key or viewing key. Users fund the vault profile independently of the CipherBid website.
+The UI must require a password-protected encrypted recovery download and successful local import verification before bidder submission and before seller auction creation. It may hold bid amount, bid nonce, bidder claim secret, or seller claim secret only for the active interaction; it must never persist plaintext to browser storage, cookies, URLs, logs, analytics, crash reports, clipboard, Git, or any server.
 
-## Rationale
+## Rationale and accepted tradeoff
 
-The installed Wallet API 0.10.3 supports STRK20 action preparation and invocation, but no reviewed capability owns a dapp-specific bid/recovery credential end to end. Browser-side generation or encrypted storage would violate CipherBid's hard browser boundary, and browser-built actions can be modified before a wallet prompt. The Privacy SDK route would place a viewing key and a signing key into a browser runtime, which is unsuitable; it is acceptable only in the separately distributed, user-operated vault.
+Demo-day requirements require a bidder to connect a supported wallet and place the bid from the CipherBid UI. The Wallet API keeps wallet keys, viewing keys, notes, proving, and submission in the wallet while providing the STRK20 integration route already extracted from the starter kit.
 
-A user-operated companion makes the new trust assumption explicit, local, and auditable without introducing a CipherBid cloud custodian or backend.
+The browser must necessarily receive the user-entered bid amount and app-specific bid/claim credentials long enough to construct the commitment and recovery bundle. This is a deliberate, documented relaxation of the former hard browser boundary. A compromised browser can alter a dapp-built action before the wallet prompt; CipherBid mitigates but cannot eliminate that risk with independent UI summaries, exact target/cap/commitment checks, explicit wallet confirmation, no plaintext persistence, required recovery export, and contract-side validation.
 
 ## Consequences
 
-- Bid creation remains disabled until the vault and an authenticated onchain claim path exist.
-- The auction protocol will replace `claimSecret` with an offline claim key and onchain public-key claim authorization.
-- The vault is Windows-first in the MVP and must use maintained OS-protection and encrypted-backup libraries rather than custom cryptography.
-- No localhost daemon, native browser bridge, cloud backup, telemetry, or automatic clipboard export is allowed.
-- Public reveal/claim submissions from the dedicated execution account may be linkable to each other. Product copy must disclose this limitation.
-- The vault profile is local user custody with account-key compromise, offline-claim-bundle recovery, funding, and rotation responsibilities; it is not a lightweight browser helper.
+- Bid creation and seller auction creation are enabled only after successful wallet/network checks and the required encrypted recovery export/import round trip.
+- The auction protocol uses `claim_handle = Poseidon("CIPHERBID_CLAIM_V1", claim_secret)` and requires the matching one-time secret for bidder and seller monetary claims.
+- The app never asks for, receives, persists, or exports a wallet private key, seed phrase, viewing key, private note, or wallet session material.
+- No localhost daemon, browser extension bridge, native-messaging integration, cloud backup, server credential storage, telemetry of private payloads, or automatic clipboard export is allowed.
+- Seller creation and direct reveal activity link to the connected wallet account and must be disclosed. Bid ingress and monetary claims rely on STRK20 relayed submission, while timing and public amounts remain observable.
+- A separate local-vault route remains a post-sprint hardening option; it is not a second sensitive transaction path in this sprint.
 
-## Reference
+## Required proof before mainnet
 
-The detailed protocol, storage boundary, user flows, contract revision, threats, and acceptance criteria are in:
-
-`docs/superpowers/specs/2026-08-24-cipherbid-vault-custody-design.md`
+1. Supported-wallet discovery and `WalletAccountV6` connection work in a clean browser.
+2. Capability detection uses `supportedWalletApi()` and never probes private balances merely to feature-detect.
+3. Every STRK20 path constructs the exact reviewed action sequence, preserves literal protocol placeholders, prepares before submit, and distinguishes rejected/submitted/confirmed/reverted/timeout states.
+4. Tests prove no plaintext bid/claim credential enters persistent browser storage, logs, analytics, URLs, errors, or public receipts.
+5. A real Sepolia then mainnet two-bidder lifecycle—including NFT custody and all monetary claims—is read back from chain before public claims are made.

docs/superpowers/specs/2026-08-24-auction-bid-page-design.md

@@ -2,9 +2,11 @@
 
 **Date:** 2026-08-24
 
+**Status:** Superseded for interactive behavior by the 2026-08-25 direct Wallet API submission plan; its original visual/accessibility constraints remain reusable.
+
 **Route:** `/auctions/[auctionId]`
 
-**Scope:** Presentational design only; no auction reads, wallet actions, bid secrets, transaction preparation, or submission
+**Scope:** Historical presentational baseline. The current submission plan adds verified chain reads, Starter-Kit wallet connection, and real bid/reveal/claim controls through a separately tested implementation slice.
 
 ## Objective