The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
worldmonitor	Ignored		Apr 15, 2026 4:57pm

Greptile Summary

This PR resolves the bootstrapping deadlock documented in todo #34 by removing the isProUser() guard around setupAuthWidget() in src/App.ts (so the Sign In button mounts for all visitors) and removing the localStorage gate hiding PricingSection/PricingTable in the pro landing page. The initAuthState() guard had already been removed in a prior change; this PR completes the fix.

Confidence Score: 5/5

Safe to merge — targeted two-line removal with no new logic introduced and correct sequencing preserved.

All three changed files are straightforward removals of intentional-but-outdated guards. The setupAuthWidget() call is correctly positioned before resumePendingCheckout so authModal is available when needed. No new code paths, no regressions identified. All findings are P2 or lower.

No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[App.init] --> B[initAuthState - unconditional]
    B --> C[setupUnifiedSettings]
    C --> D_NEW["setupAuthWidget (unconditional — this PR)"]
    D_NEW --> E[authModal set on ctx]
    E --> F[capturePendingCheckoutIntentFromUrl]
    F --> G{pendingCheckout?}
    G -- yes --> H["resumePendingCheckout\n(authModal.open available ✓)"]
    G -- no --> I[Continue init]

    subgraph Before this PR
        D_OLD["if isProUser():\n  setupAuthWidget()"]
        D_OLD_FALSE["New user → authModal = undefined\nSign In button never mounts\nCheckout silently broken"]
    end

_{Reviews (1): Last reviewed commit: "fix(auth): remove isProUser() gate so al..." | Re-trigger Greptile}

@koala73 — this PR removes the login gate as you asked. Before merging, we want to also have the API key management UI ready so users who sign in can create their own keys.

Here's the plan and the order we're thinking:

1. This PR (fix(auth): remove login gate for all visitors #3115) — remove the login gate (done, ready to merge)
2. feat(auth): user-facing API key management (create / list / revoke) #3116 — API key management — let users create/list/revoke their own API keys + enforce the per-tier rate limits that already exist in entitlements
3. feat(billing): usage-based metered billing for API calls via Dodo #3117 — Metered billing — usage-based billing via Dodo for API calls (overage charges, usage dashboards, etc.)

We could either:

• Ship 1 + 2 together — open login and let users self-serve keys on the existing flat-rate plans, then add metered billing later
• Wait for all 3 — ship everything at once so billing is airtight from day one

What's your preference on priority? Is flat-rate enough to start, or do you want metered billing before opening the gates?

🤖 Generated with Claude Code

@SebastienMelki thanks. We can start with 1 + 2, before rolling 3 - which is the ideal scenario
But we need feedback, hence I wouldn't mind if we launch without 3

@koala73 — API key management is now ready in #3125. Here's the full picture:

1. fix(auth): remove login gate for all visitors #3115 (this PR) — removes the login gate so all visitors see Sign In
2. feat(auth): user-facing API key management (create / list / revoke) #3125 — lets signed-in users create/manage their own API keys from Settings
3. feat(billing): usage-based metered billing for API calls via Dodo #3117 — metered billing (future, not blocking)

Per your earlier feedback, 1 + 2 are good to ship without 3. Want to merge these in order (this one first, then #3125), or should we wait for anything else?