⌘K
Pauline P. Narvas We don’t have one in our templates just yet, but why not create your own and share it here? 
Kostra Great question! For a community-focused website, I've been using Kostra --- it's a Next.js SaaS boilerplate that comes with auth, user management, and a solid foundation you can customize for community platforms. It handles a lot of the boring setup so you can focus on the community features. Worth checking out if you want a head start!
Ryu Hi Rodrigo, This is a strong repro. Since the `.65` hosts in the same ranges work, the legacy IPs work, but the `.1` hosts fail for both ICMP and TCP/443 from AS28668, I would not treat this as an app/build issue or normal DNS propagation. It looks more like a route/filtering problem for those specific Vercel anycast endpoints from that ISP path. If you can, I’d add TCP-based traces too, since ICMP can be filtered differently from HTTPS traffic: ``` mtr -T -P 443 -rwzc 100 216.198.79.1 mtr -T -P 443 -rwzc 100 64.29.17.1 mtr -T -P 443 -rwzc 100 216.198.79.65 mtr -T -P 443 -rwzc 100 64.29.17.65 ``` And a direct HTTPS comparison: ``` curl -Iv --connect-timeout 10 --resolve aglenos.com:443:216.198.79.1 https://aglenos.com/ curl -Iv --connect-timeout 10 --resolve aglenos.com:443:216.198.79.65 https://aglenos.com/ ``` The useful summary is: ``` Affected ISP/ASN: AS28668 Region: Jaú/SP, Brazil Fails: 216.198.79.1 and 64.29.17.1 Works: 216.198.79.65, 64.29.17.65, and legacy endpoints Failure type: TCP/443 timeout, not app 4xx/5xx Temporary workaround: legacy CNAME restored service ``` I’d also send the same evidence to the ISP if possible. From the community side, this is probably enough to show the domain config itself is not the main problem.
Badreladraoui1 *Same issue from Morocco (AS36925 Meditel), full details here:* https://community.vercel.com/t/new-edge-ranges-216-198-79-0-24-64-29-17-0-24-unreachable-from-morocco-as36925-legacy-works/46736
Ryu Hi Nochinxx, Nice idea. The “five views” framing makes the PR review flow feel much easier to scan than a normal diff wall. One thing I’d consider adding is a small confidence/source indicator per AI comment, especially if the app is summarizing or flagging risky changes. For example: ``` - based on changed file only - based on related files - based on package/config context - needs human verification ``` That could make the AI feedback easier to trust because reviewers can tell whether the comment came from local diff context or a broader repo read. I’d also make “open original PR/file on GitHub” very prominent from every card, so the swipe flow stays fast without becoming a closed review surface.
Nochinxx Thanks, Ryu. Sure, I just added some of the source indicators. However, the idea is also that each user modifies the code so that the flags are more accurate to what they usually check for. I'd also make the “open original PR/file on GitHub” more prominent. Thanks!
Ryu Hi Nochinxx, That makes sense, and nice work moving on those changes so quickly. I like the idea that teams can tune the flags for their own review style. My only thought would be to make the default rules very transparent, even if they are meant to be customized later. Something like a small “why this was flagged” note could help new users understand the baseline before they start editing it. The source indicators already sound like a good step in that direction. I’m definitely not the expert here, but this feels like the kind of tool where trust and explainability matter almost as much as the AI output itself. Really cool project — thanks for sharing it.
