docs(auth): #85 replace stale Supabase project ref with placeholder by TortoiseWolfe · Pull Request #88 · TortoiseWolfe/ScriptHammer

TortoiseWolfe · 2026-05-13T00:18:03Z

Summary

Replace 32 stale vswxgxbjodpgwfgsjrhq references in 5 docs files with <YOUR-PROJECT-REF> placeholders so fork-onboarding docs work for any forker (not just the original owner's Supabase project).
Matches the existing YOUR_PROJECT_REF convention already used at docs/prp-docs/archive/completed/payment-integration-prp.md:443.

Why

docs/AUTH-SETUP.md was the worst offender (28 stale refs) — it gives step-by-step Supabase setup instructions with dashboard URLs hardcoded to the original project. A fresh forker following it verbatim ends up on someone else's Supabase dashboard (404 / access denied), not their own. Every project rotation in this repo's history would have required a doc-wide ref swap; it didn't happen last time, hence issue #85's "Related" section flagged this.

Re-opened from #87

This PR is a fresh re-target of the closed #87. That PR was originally stacked on the Docker pnpm fix (now merged as #86). When #86 merged with delete_branch_on_merge=true, GitHub auto-deleted the parent branch and auto-closed #87 (the stacked child) rather than retargeting it — a known footgun with stacked PRs. This new PR contains the identical doc-cleanup commit, rebased onto current main.

Scope

This PR is the in-repo half of #85. The other half — repairing the Supabase project's OAuth provider config (external_google_client_id and external_github_client_id are currently literal "placeholder_*" strings, confirmed via Management API) — is external to the repo. It requires Supabase dashboard access and rides on the operator. The full #85 closure depends on both.

Files touched

File	Refs replaced
`docs/AUTH-SETUP.md`	28 (dashboard URLs, OAuth callback URIs, env-var examples, troubleshooting links)
`docs/specs/016-user-authentication/quickstart.md`	1 (env example)
`docs/specs/016-user-authentication/contracts/auth-api.yaml`	1 (OpenAPI server URL)
`docs/specs/016-user-authentication/contracts/profile-api.yaml`	1 (OpenAPI server URL)
`docs/features/payment-integration.md`	1 (example "Project ID" format placeholder — replaced with generic `abcdefghijklmnopqrst` since the surrounding text reads "alphanumeric code like ..." and a literal `<YOUR-PROJECT-REF>` placeholder would have read awkwardly)

Deliberately not touched: docs/specs/023-user-messaging-system/IMPLEMENTATION-STATUS.md:119 contains a stale ref inside a captured error trace from a historical incident. Rewriting it would falsify the historical record.

Test plan

grep -rn "vswxgxbjodpgwfgsjrhq" docs/ → only the one IMPLEMENTATION-STATUS.md hit remains (by design)
Spot-checked docs/AUTH-SETUP.md Prerequisites + OAuth callback table + env example for readability after substitution
Pre-push hooks (lint, type-check, build) all green

Refs: #85
Closes: #87 (re-target after stacked-PR autoclose)

🤖 Generated with Claude Code

The Supabase project the repo currently points at is huvitqubafsrazpjxsax, but docs/AUTH-SETUP.md and three other docs files still referenced an older project ref (vswxgxbjodpgwfgsjrhq, 28 instances in AUTH-SETUP.md alone) across dashboard URLs, OAuth callback URIs, and env-var examples. Stale refs in fork-onboarding docs are worse than just inaccurate: - A fresh forker who follows AUTH-SETUP.md verbatim ends up on someone else's Supabase dashboard URL (404 or "access denied"), not their own. - Every Supabase project rotation in this repo's history would have required a doc-wide ref swap (it didn't happen the last time, hence this issue). Replaced all owner-specific refs with <YOUR-PROJECT-REF> placeholders. Matches the existing YOUR_PROJECT_REF convention already used at docs/prp-docs/archive/completed/payment-integration-prp.md:443. Files touched (32 refs total across 5 files): - docs/AUTH-SETUP.md (28 refs, including 5 OAuth callback URLs that GitHub/Google must accept for the fix in issue #85 to even land) - docs/specs/016-user-authentication/quickstart.md (1 ref, env example) - docs/specs/016-user-authentication/contracts/auth-api.yaml (1 ref, OpenAPI server URL) - docs/specs/016-user-authentication/contracts/profile-api.yaml (1 ref, OpenAPI server URL) - docs/features/payment-integration.md (1 ref, example "Project ID" format placeholder — replaced with generic abcdefghi… since the surrounding text reads "alphanumeric code like ..." and a literal <YOUR-PROJECT-REF> placeholder would have read awkwardly) Deliberately not touched: - docs/specs/023-user-messaging-system/IMPLEMENTATION-STATUS.md:119 contains a stale ref inside a captured error trace. Rewriting it would falsify the historical incident record. Left as-is. Verification: grep -rn "vswxgxbjodpgwfgsjrhq\|huvitqubafsrazpjxsax" docs/ → only the one IMPLEMENTATION-STATUS.md hit remains (by design) Scope: This PR handles only the in-repo doc cleanup half of #85. The other half (repairing the Supabase project's OAuth provider config — Client IDs are currently literal "placeholder_*" strings, confirmed via Management API) is external to the repo and requires Supabase dashboard access. That work is in flight and will close #85 once smoke-tested. Refs: #85 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ging tests The 4 messaging E2E specs that set `el.scrollTop = N` programmatically were relying on the browser to auto-fire a `scroll` event so the React component's handleScroll listener could update state. Chromium and Firefox do this reliably; WebKit does not. Result: tests that depend on the listener firing (jump-to-bottom button visibility, auto-scroll behavior) pass on Chromium / Firefox and fail intermittently on WebKit. This was surfaced by run 25774750382 (PR #89) where `webkit-msg` failed on `messaging-scroll.spec.ts:261` "T007-T008: Jump button appears when scrolled and does not overlap input." The test set scrollTop, the React listener at src/components/molecular/MessageThread/MessageThread.tsx:194-212 never ran, showScrollButton stayed false, and the assert on `[data-testid="jump-to-bottom"]` timed out. All 3 retries failed identically. The same pattern existed in three other test sites that hid the bug behind either flaky-retry (PR #88's webkit-msg passed with "1 flaky" tag on a different test) or the assert not depending on the listener firing immediately. Fixing all 4 to prevent future round-N rediscovery: tests/e2e/messaging/messaging-scroll.spec.ts:237 (test setup scroll-to-top) tests/e2e/messaging/messaging-scroll.spec.ts:276 (THE failing test T007-T008) tests/e2e/messaging/messaging-scroll.spec.ts:322 (test setup scroll-to-top) tests/e2e/messaging/encrypted-messaging.spec.ts:665 (test setup scroll-to-top) The change is additive — same scrollTop assignment, plus an explicit `el.dispatchEvent(new Event('scroll', { bubbles: true }))`. handleScroll is idempotent (just reads current scroll position and sets state), so the event firing twice in browsers that auto-fire is harmless. Rationale for bundling with the concurrency mutex fix in this PR: - Both changes are E2E reliability fixes - The webkit failure surfaced *because* the concurrency mutex removed the 60-min cancellation bottleneck, letting webkit-msg run to completion and reveal pre-existing flake that the prior cancel had been masking - Splitting into two PRs would require coordinating their merge order and re-running CI twice; bundled is one merge cycle Verification: - All 4 sites now dispatch the scroll event - Pre-push hooks (lint, type-check, build) green - CI re-run will confirm webkit-msg passes Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(ci): serialize E2E runs via repo-wide concurrency mutex The E2E suite runs against the project's single Supabase Cloud instance (huvitqubafsrazpjxsax) with shared test users, shared conversation rows, and beforeAll cleanupOldMessages hooks in 11+ messaging spec files. Concurrent runs against the same backend race each other and dogpile shared state, causing the 60-min GitHub Actions job timeout cap to bite. Verified on 2026-05-13: - Run 25769955636 (main, post-#86 merge, started 00:14:46Z) had its `E2E (firefox-msg 1/1)` job cancelled at exactly 60 min during step "Run E2E tests". Last operation in the captured log: a Realtime subscription waitForSelector on `body[data-messages-subscribed]`. - Run 25770068787 (PR #88 docs cleanup, started 00:18:07Z — only 3 minutes later) ran on the same Supabase project. Direct DB queries confirm conversation `4105492f-1047-40ef-bd6e-411788850547` (the one the cancelled main test was using at "Step 8: Conversation ID:") was created by PR #88's run at 00:21:55Z, not by main's run. - The cancelled run's tests detected "Connection already exists / Conversation already exists" and reused PR #88's data, then watched PR #88's beforeAll hooks wipe it on each of 11 spec boundaries. - Progressive per-spec slowdown across the cancel window (35s, 35s, 2m45s, 1m, 6m48s, 5m6s, 8m36s, 12m16s, 10m11s, 10m46s, cancelled at 10m46s) is the cumulative effect of cross-run data races, not Supabase rate limiting (verified zero rate-limit signals in the Supabase health endpoint, zero auth.audit_log_entries during the window — Supabase internal audit is disabled on this project). Three earlier diagnostic theories were wrong because they all assumed single-actor causation: 1. Retry-heavy specific test (complete-user-workflow.spec.ts retry loop) — disproved: that test passed first-attempt at 00:49:26Z. 2. Rate limiting — disproved: ACTIVE_HEALTHY across all Supabase services, no 429s. 3. Cumulative latency from one run's request volume — disproved: two runs were in flight, not one. The fix is structural: GitHub Actions native `concurrency:` group with a repo-wide key. All E2E runs across all refs (main, PRs, schedule) share one mutex; concurrent runs queue rather than race. Changes to .github/workflows/e2e.yml: Before: concurrency: group: e2e-${{ github.ref }} # per-branch cancel-in-progress: true # kill running on new push After: concurrency: group: e2e-supabase-${{ github.repository }} # repo-wide cancel-in-progress: false # queue, don't cancel Why both fields had to change: - Just flipping cancel-in-progress wouldn't fix anything because the race is cross-branch (main vs PR), not within one branch. - Just changing the group key without cancel-in-progress: false would let pushes mid-run abort each other and leave Supabase in a half-cleaned state. - ${{ github.repository }} keeps forks isolated from upstream — each fork gets its own mutex, preserving the template story. Trade-off accepted: PRs land slightly slower when 2+ are pushed close together (queue wait up to ~45 min worst case). On this repo's PR volume (~5/day max), the queue is rarely hit. Slower-by-design beats 60-min cancellation + re-run + human debug time. What this fix does NOT do (and why each is correct): - Does NOT bump `timeout-minutes: 60` — masking the budget is exactly what 9 prior rounds of flake mitigation did and got us here. - Does NOT shard messaging tests N-way — current 1/1 shard works fine when not contended (28 min on chromium-msg when alone). - Does NOT drop retries — the retries weren't the problem. - Does NOT replace the hand-rolled retry loops in complete-user-workflow.spec.ts:437-462 or encrypted-messaging.spec.ts:311,580 — those loops were doing the right thing; they polled while a different CI run was deleting their data. With the mutex in place, they'll succeed on attempt 1. Lessons captured in memory: - ~/.claude/projects/-home-TurtleWolfe-repos-ScriptHammer/memory/lesson_concurrent_ci_shared_backend.md - ~/.claude/projects/-home-TurtleWolfe-repos-ScriptHammer/memory/feedback_branch_hygiene.md This closes round 10 of the E2E flake pattern (STATUS.md:127-129) by addressing the actual underlying invariant: one writer at a time against the shared Supabase backend. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(e2e): dispatch scroll event after programmatic scrollTop in messaging tests The 4 messaging E2E specs that set `el.scrollTop = N` programmatically were relying on the browser to auto-fire a `scroll` event so the React component's handleScroll listener could update state. Chromium and Firefox do this reliably; WebKit does not. Result: tests that depend on the listener firing (jump-to-bottom button visibility, auto-scroll behavior) pass on Chromium / Firefox and fail intermittently on WebKit. This was surfaced by run 25774750382 (PR #89) where `webkit-msg` failed on `messaging-scroll.spec.ts:261` "T007-T008: Jump button appears when scrolled and does not overlap input." The test set scrollTop, the React listener at src/components/molecular/MessageThread/MessageThread.tsx:194-212 never ran, showScrollButton stayed false, and the assert on `[data-testid="jump-to-bottom"]` timed out. All 3 retries failed identically. The same pattern existed in three other test sites that hid the bug behind either flaky-retry (PR #88's webkit-msg passed with "1 flaky" tag on a different test) or the assert not depending on the listener firing immediately. Fixing all 4 to prevent future round-N rediscovery: tests/e2e/messaging/messaging-scroll.spec.ts:237 (test setup scroll-to-top) tests/e2e/messaging/messaging-scroll.spec.ts:276 (THE failing test T007-T008) tests/e2e/messaging/messaging-scroll.spec.ts:322 (test setup scroll-to-top) tests/e2e/messaging/encrypted-messaging.spec.ts:665 (test setup scroll-to-top) The change is additive — same scrollTop assignment, plus an explicit `el.dispatchEvent(new Event('scroll', { bubbles: true }))`. handleScroll is idempotent (just reads current scroll position and sets state), so the event firing twice in browsers that auto-fire is harmless. Rationale for bundling with the concurrency mutex fix in this PR: - Both changes are E2E reliability fixes - The webkit failure surfaced *because* the concurrency mutex removed the 60-min cancellation bottleneck, letting webkit-msg run to completion and reveal pre-existing flake that the prior cancel had been masking - Splitting into two PRs would require coordinating their merge order and re-running CI twice; bundled is one merge cycle Verification: - All 4 sites now dispatch the scroll event - Pre-push hooks (lint, type-check, build) green - CI re-run will confirm webkit-msg passes Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: TurtleWolfe <TurtleWolfe@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(status): #31 close + round 10 E2E flake mitigation resolution Four updates to STATUS.md: 1. Snapshot date 2026-05-06 -> 2026-05-13; subtitle now mentions round 10 closure. 2. Feature 019 (Google Analytics) reclassified from "Mostly Shipped (config gap)" `[~]` to "Shipped" `[x]`. The remaining gap was per-fork GA4 property ID provisioning, which is fork-config not code work. Issue #31 closed. 3. The "E2E flake mitigation" hotspot row, Status column: "Ongoing" -> "Resolved". Evidence column rewritten to explain rounds 1-9 attacked symptoms (stale closures, unstable hook refs, hydration timing, retry budgets, stagger delays, Supabase priming) while round 10 found the underlying cause: two concurrent E2E CI runs racing against one shared Supabase project. Fix landed in #89 / commit 996211e — repo-wide `concurrency:` mutex in .github/workflows/e2e.yml + dispatchEvent('scroll') after each programmatic el.scrollTop = N to work around WebKit's quirk of not auto-firing scroll events. 4. Summary-by-Status counts: Shipped 22 -> 23 (019 added), Mostly Shipped 4 -> 3 (019 removed). Verification: confirmed both PR #89 post-merge run (25801256089) and PR #88 post-merge run (25801281715) on main reached completed/success after merging, with the mutex visibly holding #88 in `pending` for ~80 min while #89 ran exclusively. The previous "9 rounds and counting" cycle pattern is broken. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(status): update 007 inline reference to match resolved hotspot The hotspot table (lines 121-127) was already updated to "Resolved" in the previous commit dfd191f, but the inline reference under feature 007 still said "9 rounds of flake mitigation" without the resolution status. Aligning both references so a future reader doesn't see contradictory framing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: TurtleWolfe <TurtleWolfe@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ry (#93) The PRP-STATUS.md dashboard was last fully refreshed 2026-04-25. Six PRs have landed since then (2026-05-12 to 2026-05-14) closing the long-running E2E flake pattern, the #31 GA4 ticket, and improving fork onboarding. Three targeted updates: 1. Header — bump "Last Updated" to 2026-05-14, "Previous Update" to 2026-04-25. Shipped count 17 -> 18 (019 GA moved from Mostly Shipped to Shipped after #31 close on 2026-05-13). Updated "Current Phase" line to reflect round 10 closure. 2. New "v0.4.x updates since 2026-04-25 audit" section between the header and the full feature table — one-paragraph summary of each merged PR (#86, #88, #89, #90, #91, #92) plus the issue closures (#31 GA4, #85 OAuth) with link to the closure comment for #85's outstanding dashboard work. 3. Stability hotspots note — added a callout indicating the E2E flake row in the hotspot table is resolved at round 10. Rounds 1-9 attacked symptoms; round 10 found the underlying cause (concurrent CI runs racing against a shared Supabase project) and fixed it structurally via the concurrency mutex. Other 9 hotspots remain open. Per-feature audit data in the lower sections is left untouched — the 2026-04-25 sweep is still the canonical detail. This refresh is purely the top-of-document changes needed to reflect 19 days of activity. Verification: - grep "Last Updated" docs/prp-docs/PRP-STATUS.md -> "2026-05-14" - Pre-commit hooks pass (prettier + gitleaks) Co-authored-by: TurtleWolfe <TurtleWolfe@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

This was referenced May 13, 2026

docs(auth): #85 replace stale Supabase project ref with placeholder #87

Closed

fix(ci): serialize E2E runs via repo-wide concurrency mutex #89

Merged

TortoiseWolfe merged commit 79132db into main May 13, 2026
28 checks passed

TortoiseWolfe deleted the docs/85-portable-project-refs branch May 13, 2026 13:11

TortoiseWolfe mentioned this pull request May 13, 2026

docs(status): #31 close + round 10 E2E flake mitigation resolution #90

Merged

This was referenced May 14, 2026

OAuth providers misconfigured: Google + GitHub Client IDs are literal 'placeholder_*' strings #85

Closed

docs(prp-status): #31 close + round 10 E2E closure + PR #86-#92 summary #93

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docs(auth): #85 replace stale Supabase project ref with placeholder#88

docs(auth): #85 replace stale Supabase project ref with placeholder#88
TortoiseWolfe merged 1 commit into
mainfrom
docs/85-portable-project-refs

TortoiseWolfe commented May 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants