Front-End-Checklist

Hi — I maintain FrontendAtlas, an independent frontend interview-prep project. I’m preparing a public, no-sign-up benchmark that compares unbounded DOM append, , and windowed virtualization at 1,000, 10,000, and 50,000 variable-height rows. The planned package includes raw samples, JSON/CSV downloads, an accessible chart, a fixed-seed fixture and runner, and separate data/code licenses. The “Virtualize long lists and tables” rule already asks readers to compare mounted nodes, memory, scrolling, and interaction cost. Before proposing any source change, would this kind of reproducible evidence fit the rule’s Sources or Resources section once the public URL and final measurements are live and independently verifiable? I maintain the proposed resource. It is not published yet, so I’m not asking you to review or add a link now. No paid, affiliate, sponsored, or particular placement is being requested. If this is not the right use of issues, please close it and I won’t follow up here. Disclosure: this note was drafted with AI assistance and reviewed before posting.

Fixes Fixes #722 Summary Fix GitHub sign-in flow when the application is configured to use a GitHub App ( starting with ). Root Cause Better Auth adds default GitHub OAuth scopes ( and ) when generating the authorization URL. GitHub Apps use predefined permissions and do not support dynamic OAuth scope parameters. When these default scopes are included in the authorization URL, GitHub rejects the request and users are redirected to the error/404 page described in #722. Changes Detect GitHub App client IDs (). Enable for GitHub App authentication. Preserve existing behavior for traditional GitHub OAuth Apps. Testing Investigated the generated GitHub authorization URL. Verified that Better Auth includes default scopes by default. Verified that enabling suppresses those scopes. Confirmed the generated URL no longer includes unsupported scope parameters for GitHub Apps. Notes The change is limited to the GitHub provider configuration in and does not affect other authentication providers.

Hi @thedaviddias, Love the work on ! As you transition from open-source into commercializing your AI agent, you'll likely run into a major scaling problem: power users running infinite loops and bankrupting your LLM budget. Currently, most frameworks require you to pay the Anthropic/OpenAI bill out of pocket or build a complex Stripe billing backend from scratch. We built NeuForge Pay, a 5-line Python SDK that acts as a proactive Spend Firewall and Hybrid Merchant of Record. It blocks transactions before inference runs if the user exceeds their session budget, and lets them instantly top-up via Stripe (Credit Card) or Coinbase Commerce (USDC on Base for M2M Agent payments). You can test how fast unmetered agents destroy margins using our interactive calculator here: NeuForge AI Margin Leak Calculator Example Integration: If you are looking to monetize this project without getting burned by unpredictable LLM usage, we'd love for you to try it out!