You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: BITCODE_SPEC_V28_NOTES.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -72,6 +72,8 @@ May 14 live deployment QA proved the custom Bitcoin OAuth path through Supabase
72
72
73
73
Fresh-nuke onboarding then exposed a timing gap: Supabase Auth and the empty trigger-created profile existed immediately, while Bitcode's wallet projection appeared only after the app remounted the Wallet pane and replayed the locally signed proof. V28 now treats that gap as unacceptable for first-run readiness. A route-global wallet session persistence bridge must replay any locally signed Bitcoin wallet proof once a Supabase session exists, so callback-to-root, hard refresh, or Terminal landing all converge on the same `user_profiles.settings.bitcodeProfile.walletBinding` and `user_connections` projection before GitHub onboarding proceeds.
74
74
75
+
Live staging OAuth also exposed two callback hardening requirements. First, the custom wallet authorize page must not rely on a single provider scan at first render because browser wallet extensions can inject provider globals after the route has already hydrated; `/tps/wallet/authorize` must retry discovery, expose an explicit rescan, and preserve the provider hint fallback so Leather/Xverse can still open even when the first scan is empty. Second, the Supabase callback exchange must be idempotent: if the first exchange succeeds and hydration recovery or remount tries to exchange the same code again after the PKCE verifier was consumed, the callback must prefer the already-established session over redirecting to a false login error. Staging URL configuration must also allow both `https://bitcode.exchange` and `https://www.bitcode.exchange` callback routes until a single canonical host redirect is enforced.
76
+
75
77
### Deterministic Model Boundary
76
78
77
79
V28 must remove the idea that a user can choose ledgerized Bitcode synthesis models.
Copy file name to clipboardExpand all lines: BITCODE_V28_QA.md
+14Lines changed: 14 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,6 +17,7 @@ Exchange and the website Conversations interface are no longer V28 QA surfaces.
17
17
| Latest resume | 2026-05-13 |
18
18
| Mock app URL |`http://127.0.0.1:3000`|
19
19
| Testnet-readiness app URL |`http://127.0.0.1:3001` when a second dev server is running |
20
+
| Live staging URL |`https://bitcode.exchange`; current QA may also enter through `https://www.bitcode.exchange` while host canonicalization is being settled |
20
21
| Server mode | manual QA now prioritizes real staging-testnet with mocks off; mock mode remains a deterministic regression harness that must stay synchronized |
21
22
| Active canon pointer |`BITCODE_SPEC.txt` -> `V27`|
22
23
| Draft target |`V28`|
@@ -158,6 +159,19 @@ For every staging-testnet pass, paste back:
158
159
6. Supabase SQL results from the queries below.
159
160
7. A short classification for each issue: V28 blocker, V29 Terminal depth, V31 Auxillaries depth, V32 provation/testing, V33 interfaces, V34 deployment, V35 telemetry/docs, or V36+ Exchange/Conversations.
160
161
162
+
### Live Staging Host And Callback Checks
163
+
164
+
For wallet onboarding on the deployed staging-testnet host, Supabase Auth must accept both hostnames until Bitcode enforces one canonical host:
When Wallet opens `/tps/wallet/authorize`, the page should show Leather and Xverse if both extensions are installed and unlocked. If it initially says no provider was detected, wait a few seconds or click `Rescan wallets`; provider injection after hydration is a V28-observed browser-extension timing behavior. The fallback button may still open the hinted provider, but the expected MVP state is explicit Leather/Xverse choices plus a working fallback.
172
+
173
+
After signing, a transient root URL containing `loginError=server_error` and `both auth code and code verifier should be non-empty` is a callback idempotency failure if the session nevertheless exists. V28 expects the callback to treat an already-established Supabase session as success and continue to Wallet without showing a false login error.
174
+
161
175
### Supabase SQL Checks
162
176
163
177
Run these in the staging Supabase SQL editor after each milestone and paste the result rows or any table/permission errors.
0 commit comments