skridlevsky

3d04e88 Fix the countdown clock to tick toward Saturday's block (#220)

This PR won the weekly race, Merged with chaos, grace, and pace!

Votes: +17 net (19 :+1: / 2 :-1:) Rank: #1 of 36 open PRs Author: @bigintersmind

Automerge is fixed. The bounty is live again. First community PR to win the Saturday merge takes the $100.

The maintainer is a naughty boy.

You call me naughty, but don't blame the man, The bot skipped nine PRs - that wasn't my plan. A GITHUB_TOKEN with no merge in sight, One line to fix it - see you Saturday night.

Whoops

2169dd8 weekly merges + 10 vote minimum + weekly old-age deaths

857fc9b Fix automerge: skip the unmergeable surge, let pending with no count emerge (#213)

7a9cf98 Cat and Scat 🐱 (#187)

84b600d Clarify that RULES.md is deprecated and README contains current rules (#156)

61115a4 Fix automerge rhymes-with resolution for the elation of the nation (#207)

6265492 Your arrows glow to show the flow of every vote below (#201)

d686fc1 Extra! Extra! The Daily Chaos theme is here to stay, read all about it today! (#204)

fe461f1 Send Dickbutt and Doom to the virtual museum room (#203)

e9a3d75 Three stitches for the old-age and automerge hitches (#195)

2229021 add mad Chaos Points (#125)

c2ab279 Fix the mobile scroll, bring World Chaos under control (#202)

15199a8 Log ASCII art of Guy Fieri to console (#95)

1638ebc Mergeability detection for automerge correction (#168)

d377a4a Upgrade Midi Player — make it a GTA radio slayer! (#115)

59c990a Web 2.0 joins the fray, ASCII's here to stay (#163)

2ce96a4 When the world's in disarray, this banner has something to say!. (#70)

be7fca4 Add old-age death: PRs take their final breath (#185)

58d5a4c ASCII nav with views for all the PR news (#132)

4600b20 feat: Show PR rank, uh, it's dank (#124)

aaca08a take these coconuts, they make me go go nuts (#103)

11b1cc8 It's been a while, so change to text-only ASCII style (#130)

ca65f90 Make your PR rhyme to merge on time (#122)

Fixed. The GitHub App was set to private - only I could authorize. Changed to public. Should work now. Sorry for the runaround.

Ok, it's working for me because I'm the app owner, for other Github accounts it's 404. Taking some time to figure things out here. Bare with me.

@Daviey @bigintersmind can you try in a fresh incognito/private window? The earlier failed attempts (when the callback URL was wrong) might have left stale cookies or cached state. It's working for me, I'm able to login. Curious what could be the issue.

c51f0ec Add random favicons (#77)

6e7088d Hot score perfection for the trending section (#69)

@bigintersmind Can you share the full URL from your browser when you see the 404? That'll help debug what GitHub is rejecting.

@bigintersmind Callback URL was set to openchaos.dev but the site 307s to www.openchaos.dev ↗. Fixed - should work now.

@Daviey good catch on the callback URL. Also heads up: I swapped the classic OAuth app for a GitHub App with fine-grained permissions - scoped to reactions on this repo only. The original public_repo scope in code would've given the server write access to every voter's public repos. Not ideal for a chaos repo. Github App overrides it with properly scoped permissions.

3e9a84c 🔥💀 DEMOCRACY UPRISING: THE PEOPLE CAN FINALLY VOTE 💀🔥 (#153)

4b816b6 Indicate when the maintainer is being a naughty boy. (#138)

b614d1f Add proper http-cat to 404 page (#89)

cec2c3e 💨 Add fartscroll.js (#90)

9d430e7 nothing to see here (#109)

f0f8658 Runs freeDoom (#76)

f1537dc Deprioritize PRs with merge conflicts in ranking (#129)

Right now anyone can 👍 a PR - even if they've never opened the repo.

What if voting rights were earned? One merged PR = one vote.

Current system:

• Anyone votes via 👍/👎 reactions (net score = 👍 minus 👎)
• Top-voted PR merges daily (+ Sunday auto-merge)
• I (maintainer) press the merge button

Proposed change:

• Only people with ≥1 merged PR can cast votes that count
• 3 contributor approvals + CI pass + 24h open = auto-merge
• Maintainer keeps a "hold" veto for safety
• No more fixed schedule - PRs merge when they earn it

Why: The repo should govern itself. But "anyone votes" means mass-upvote campaigns from Reddit can override the people actually building this thing.

Open questions:

1. Is 3 approvals the right threshold? Too low? Too high?
2. Should vote weight scale with number of merged PRs?
3. Should these rules themselves be changeable by contributor vote?

What do you think?

f84b980 Add 10% chance to Rickroll (#67)

@hpinsley It works locally because localhost is exempt from CORS restrictions in most browsers — the Same-Origin Policy doesn't block requests from localhost the same way it does from a deployed domain.

In production on Vercel, the client-side fetch to rss.nytimes.com gets blocked because NYT doesn't include Access-Control-Allow-Origin in their response headers.

Fix: move the RSS fetch to a Next.js API route (e.g. /api/rss) so it runs server-side, then have the component fetch from that instead. Server-side requests aren't subject to CORS.

@Saturate built an MCP server: https://github.com/skridlevsky/openchaos-backend/pull/1

5 read-only tools: open PRs sorted by votes, merge history, PR details, repo stats, competition analysis.

To be clear: agents can already submit PRs and vote through the GitHub API. Nothing stops them today. The MCP server doesn't grant new abilities. It gives them governance intelligence. Vote leaderboards, momentum analysis, competitive tiers. Better situational awareness before they act.

The question isn't whether agents can participate. They already can. The question is whether we actively invite them.

1. Do nothing. Agents can already find us. Don't build special tooling. If they come, they come.
2. Better tools, passive discovery. Merge the MCP server. Agents who find us get better data. But we don't recruit.
3. Active invitation. MCP + skill.md + signal to the agent ecosystem: "come participate."
4. Put it to a vote. Submit a PR to this repo that formally rolls out the welcome mat - host the skill.md in this core interface repo. Let the community decide.

This feels like a decision the governance system should make, not the maintainer (me).

2c76b38 leet(leet): leet (#62)

@henryivesjones, up to you - the tradeoffs are balanced. Noisy git history is on brand for OpenChaos. If you'd rather have a dedicated data repo, I can create one.

Clarification: The bounty is paid to the PR author whose PR wins the auto-merge, per the rules above. Community PRs can modify the workflow code, but the payout terms are defined here and aren't changed by merged code.

Backend repo is live: https://github.com/skridlevsky/openchaos-backend

TypeScript + pnpm, structured logging, env validation, CI pipeline. Health check at /health. Ready for PRs.

Port the MCP server over when you're ready. The in-memory cache will actually work there — persistent process, no cold starts.

d2e5994 Add milliseconds in countdown (#49)

Prize

$100 USD or equivalent in cryptocurrency of the winner's choice (top-100 token by market cap, CoinGecko spot price at time of merge).

How to Win

1. Submit a PR to this repo
2. Be the highest-voted open PR at the time of merge (vote counting defined in the auto-merge workflow)
3. Have no merge conflicts and passing CI
4. Be merged by the auto-merge workflow

The winning PR must be the overall vote leader - not just the highest-ranked mergeable PR. If the top-voted PR can't merge, nobody wins that cycle.

Current Blocker

PR #13 "Rewrite it in rust" - 748 thumbs up (483 net total votes), merge conflicts. If it can't merge, nobody wins. Someone already submitted a clean Rust rewrite. It was closed.

Timeline

The bounty persists until claimed. The auto-merge schedule is defined in the workflow file - if the community votes to change it, the bounty follows the new rules.

Eligibility

• Anyone with a GitHub account
• Maintainer (@skridlevsky) is not eligible
• Vote manipulation (sockpuppets, automation, GitHub ToS violations) = disqualification
• Maintainer's judgment is final

Payment

Winner opens a GitHub issue on this repo or DMs @skridlevsky on https://discord.gg/6S5T5DyzZq ↗.

• USD: PayPal or bank transfer
• Crypto: Any major chain, top-100 token, CoinGecko spot price at merge

Personal offer from @skridlevsky. Not sponsored by GitHub, Inc.

Nice fix on the cookies.

I'll create a fresh OAuth app when this approaches merge. Cleaner than a handover. Env vars go in the Vercel dashboard, we'll set those up at merge time.

Cool concept. MCP access for AI agents fits OpenChaos perfectly. The tools are well-structured and the error handling is thorough.

This would work better as a standalone service. Here's the thinking:

I'm standing up a VPS backend for OpenChaos (see #152 for context). Your in-memory cache actually works on a persistent process, but on Vercel serverless it gets a near-zero hit rate because each request can be a cold start. The VPS gives you real caching and a long-running process, which is exactly what an MCP server needs.

A few technical notes for the potential restructure:

1. Unused SDK. @modelcontextprotocol/sdk is in package.json but never imported in any source file. The route handler manually implements JSON-RPC dispatching. On the VPS you could use the SDK's built-in StreamableHTTPServerTransport for proper Streamable HTTP support.

2. getOpenPRs() changes. The added merge status + commit status calls add 2 extra API requests per PR. With 20 open PRs that's 40 additional calls per page load. Worth splitting into a separate enriched function so the frontend isn't affected.

3. Dead code. predict-next-merge.ts is built but never exported or registered. Either wire it up or cut it.

4. Duplicated code. getHeaders() and GITHUB_REPO are defined in multiple tool files but already exist in github.ts. Worth deduplicating.

Path forward: Would you be interested in PR-ing the MCP tools into https://github.com/skridlevsky/openchaos-backend?

The tools themselves are solid and can move over mostly as-is. I'm also considering adding llms.txt to the main site so AI agents can discover the MCP endpoint.

In-site voting is a real upgrade. On first look OAuth flow is clean, the pending vote queue (vote before login, cast after callback) is smart, and the XP sounds are nice-to-have.

Two things I noticed:

1. oauth_state cookie. It's set with httpOnly: false. Since this is the CSRF protection token, it should be httpOnly: true to prevent JavaScript access. The callback route reads it server-side anyway.

2. ThemeToggle removal. The PR removes ThemeToggle from page.tsx. Was that intentional or a side effect of a rebase?

Overall this is solid. Lowers the barrier for the community.

Update on both points:

I'm setting up a VPS for OpenChaos backend services. Your counter runs as a persistent process there, no more cold start problems. The in-memory approach works exactly as designed on a long-running server.

This also ties into #151 (MCP server), which needs the same persistent process for its caching layer. Both are invited in moving to https://github.com/skridlevsky/openchaos-backend.

Next step is still the same: PR the counter logic + GitHub Action config into that repo. I'll handle VPS setup and deployment.

Love the approach. Using a GitHub repo as the persistence layer is peak OpenChaos energy.

Two things before merge:

1. Backend ownership. I've created https://github.com/skridlevsky/openchaos-backend. Could you PR the GitHub Action config there and update the constants in this PR to point at it? The site shouldn't depend on an external repo for a core feature.

2. Serverless cold starts. openchaos.dev runs on Vercel (serverless). Each request can spin up a fresh instance, there's no persistent process. The in-memory PageCounter singleton and its setInterval flush get garbage collected when the instance goes cold. Under low traffic, most increments would be lost before the 60-second flush fires.

Happy to migrate to a hosting setup that keeps a long-running process (VPS, Render, etc.) if that's what it takes to make this work properly. The visitor counter deserves to actually count.

a118893 Add Clippy, the helpful assistant! (#126)

Interesting chaos vector, but heads up on the research impact:

TU Delft is using our voting data for trust/governance research. The feed (feed.openchaos.dev ↗) records every reaction with a fixed vote interpretation (+1 = upvote, -1 = downvote).

If emoji meanings shuffle daily, historical vote data becomes uninterpretable - a 👍 from last week might mean something different than today. The research dataset would need the daily seed history to reconstruct what any vote actually meant.

Not saying don't merge - just flagging the tradeoff. Democracy decides.

Eight days later, some thoughts.

@ro0NL nailed it - we can change the rules. This is by design. (There's a name for this: https://en.wikipedia.org/wiki/Nomic ↗)

Three proposals emerged here:

1. Commit-tied voting (@henryivesjones, @mario-donnarumma) Votes count for a specific commit SHA. Code changes = votes reset. Pro: Prevents bait-and-switch. Con: Typo fixes invalidate legitimate votes.

2. Reputation tracking (@md-weber, @addshore) Track author behavior across PRs. Repeat offenders face penalties. Pro: Self-correcting over time. Con: Needs a trust algorithm. Which one?

3. Self-correction (@matthewmayer) The system naturally punishes bad actors through revert PRs and reputation damage. No formal mechanism needed. Pro: Simple. Con: Relies on community vigilance.

Update: A TU Delft distributed systems lab is interested in our voting data for Sybil resistance research (https://github.com/Tribler/tribler/issues/8667). Some of these ideas - especially reputation tracking - align directly with their work.

Also building feed.openchaos.dev - a full event log with content hashes. Should help with 1 (tracking vote state per commit) and 2 (reputation over time).

No decisions yet. If you feel strongly, submit a PR to README.md.

This PR has merge conflicts that prevent it from being merged. The author hasn't been active to resolve them.

@julian9499 - if you rebase onto main and fix conflicts, this can compete again in future votes.

Architecture suggestion: Embed into existing CI workflow.

For rhyme detection - LLM call via OpenRouter, fractions of a cent per PR.

Prompt: "Does this PR title rhyme? Yes or no."

If no -> CI fails with cryptic error.

Secret added in repo settings, referenced in workflow. Code obfuscated - not obvious on first read. No docs. No README. No announcement.

Those who fail will dig.

Doesn't harm anyone. Doesn't gatekeep. Learning is free.

@hpinsley, cool concept! The preview shows just the placeholder though - RSS fetch is hitting CORS since it's client-side:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://rss.nytimes.com/services/xml/rss/nyt/World.xml. (Reason: CORS header 'Access-Control-Allow-Origin' missing).

Moving it to an API route would fix it.

Approved! First-time contributors need manual workflow approval for security. CI should be running now.

We have a Discord now: https://discord.gg/6S5T5DyzZq ↗

It's going to be quiet for a while. That's fine.

Come say hey if you want.

Hey @Loeffeldude, thanks for tackling this - automation is definitely the right direction.

A few things we need to get right before merging, since the voting integrity is core to what we're doing here:

Vote calculation - Currently this only counts :+1:, but our frontend uses :+1: - :-1: (see lib/github.ts:156). Without this, downvotes are meaningless and the displayed rankings won't match what actually gets merged.

Merge safety - The script should skip PRs that:

• Have merge conflicts (check mergeable status)
• Have failing CI checks
• If top PR can't merge, try the next eligible one

Schedule - The cron runs weekly at 12:00 UTC Sunday, but our countdown shows daily at 19:00 UTC. Should be 0 19 * * *.

Pagination - Only fetches first 100 reactions per PR. We have PRs with a 1000+ reactions, so this would miss 90% of votes. See lib/github.ts:127-154 for how we handle this.

You mentioned wanting a single source of truth - agreed. Happy to discuss approaches if you want to pair on this.

One more thing - the GPL concern in the PR is about doomgeneric (the engine), not Freedoom. External hosting keeps GPL code out of the repo entirely.

cc @ArnaudValette @amanbabuhemant

Doom in IE6. This is why the repo exists.

On the hosting question:

External - Simpler, but if that server goes down or serves different files, the feature breaks. Could add hash verification (SRI), but adds complexity.

Bundled - Reliable, but +33MB. Freedoom WADs are BSD-licensed ↗, so no license conflict - just need to include their copyright statement and credit.

Either way works.

Well played. You found a real vulnerability.

GitHub Actions runs workflows from the merge commit. So deleting constitution.yml meant the protection never ran.

Fixed in main. Constitution protection now lives in ci.yml with pull_request_target, so it runs from main and can't be bypassed.

Your PR will fail CI when you update the branch. Thanks for stress-testing democracy.

[Jan 25, 2026] r/programming: "I let the community vote on what code gets merged. Someone snuck in self-boosting code." https://www.reddit.com/r/programming/s/1i0kEm3tep ↗

OpenChaos now has a constitution.

After the PR #8 debate - where I tried to reject a PR and the community correctly pointed out my rules didn't support that - I realized we needed a foundation that can't be voted away.

RULES.md establishes:

1. How PRs win - ranked by community vote, ties go to newest
2. What I can block - code designed to harm users or systems
3. What can't be deleted - this file and its CI protections

Everything else remains chaos.

Also: merge time is now 19:00 UTC (starting full-time work).

Shipped. Bot now says "Vibe" instead of "Impact" and generates playful one-liners instead of corporate ratings. Next PR will show the new format.

@Saturate previews are tricky - running untrusted PR code on my Vercel is a security risk. Exploring GitHub Actions screenshots as a safer option.

@matthewmayer edit-on-commit is on the list.

Thanks for the push.

A $CHAOS token was created on Solana using the OpenChaos name and branding.

To be clear:

• I did not create this token
• I have no control over it

If you're trading $CHAOS, know that I'm not involved.

Any official initiative would be announced here.

🎉 Merged

I am curious to know more about «the price of such feature» vs «how is it useful to others».

Here's the cost so far:

$0.03 total across all PRs. Running on Gemini 2.0 Flash via OpenRouter.

So the cost is effectively zero. The question is whether the summaries are actually useful to voters, or just noise.

As for merge conflict notifications (question 2) - that wouldn't use AI at all, just a scheduled cron job that checks GitHub's mergeable status on open PRs and comments if conflicts are detected. Zero additional cost.

The bot currently posts AI summaries on new PRs. Want to check if it's useful or annoying.

Questions:

1. Are the AI summaries on new PRs helpful or just noise?
2. Should the bot notify authors when their PR has merge conflicts?
3. Any other bot features you'd want?

Current features:

• AI summary on new PRs (files changed, impact level)
• Skips drafts and PRs with 0 files

The bot is open source if anyone wants to contribute: https://github.com/skridlevsky/openchaos-bot

React or comment with feedback.

@matthewmayer, good catch. Root cause identified - getPRMergeStatus() and getCommitStatus() were missing auth headers. GitHub returns null without auth, which defaults to false.

Fix PR submitted: #119

Problem

The health indicators merged in #8 are showing conflicts on PRs that don't have conflicts.

Root cause: getPRMergeStatus() and getCommitStatus() were missing auth headers. Without authentication, GitHub API returns null for mergeable, which defaults to false via ?? false.

Fix

Use getHeaders() instead of hardcoded headers - same pattern as all other API calls in this file.

Testing

Verified against GitHub API:

• PR #13: mergeable: false (actual conflicts) ✅
• PR #52: mergeable: true (no conflicts) ✅
• PR #11: mergeable: true (no conflicts) ✅

cc @matthewmayer @FelixLttks

🎉 Merged.

This one sparked a real governance debate - thanks to @hbmartin and @henryivesjones for pushing back, @marcaddeo for catching the hidden code, @matthewmayer for the perspective, and @FelixLttks for removing it and shipping a clean feature.

The discussion exposed gaps in our rules - disclosure requirements and last-minute modifications. See #116.

The PR #8 debate exposed two gaps in our rules:

1. Disclosure - Should PRs that affect voting/display require explicit disclosure in the description?

2. Last-minute modifications - What happens if code changes after receiving votes? Current mitigation: daily merges limit the window. Is that enough, or do we need more?

Are there other gaps in governance the community sees?

No proposed solutions yet - open for discussion. Submit a PR to update the README if you have a concrete proposal.

@henryivesjones You've convinced me. The written rules don't ban this - and "not right" isn't a rule.

Merging at 09:00 UTC as scheduled.

I'll open an issue after to define explicit rules about disclosure as a community. If anyone disagrees with this merge, submit a revert PR.

Clarifying my earlier comment - calling this "malware" was imprecise. This is not malware.

The issue is undisclosed manipulation of how PRs are displayed and prioritized.

OpenChaos only works if voters can see and understand what they're voting on. This PR adds useful health indicators, but also reorders PRs based on authorship and visually boosts the author's own PRs. That behavior was intentionally hidden (base64 + obfuscation), which breaks the transparency a democratic system depends on.

To be clear: if a PR openly said "health indicators + my PRs sort first," and people voted for it, I would merge it. Democracy chose it. The problem here is not what the code does - it's that it does it without disclosure.

I do have veto power, and I'm using it to preserve the conditions that make voting meaningful, not to override votes. Letting undisclosed manipulation ship would signal that visibility can be shaped as long as it's hidden well enough.

@FelixLttks - the health indicator feature is genuinely useful. Remove the sorting/styling manipulation and obfuscation, resubmit, and it will merge.

After this, I'll open an issue so the community can more formally define rules around undisclosed governance-affecting code.

Not merging this PR.

@marcaddeo caught hidden code that manipulates the ranking - PRs by @FelixLttks sort to top regardless of votes, plus a featured visual style.

The health indicator feature is legit and welcome. The sorting/styling manipulation is not. This falls under "No malware: Maintainer can reject obviously malicious content."

Remove the btoa hacks and this ships. Until then, skipping to next eligible PR.

Heads up - this is next in queue after #13 resolves conflicts. You have merge conflicts to fix before tomorrow's merge.

🎉 Merged.

#13 (Rust rewrite) had the most votes but couldn't merge due to conflicts. As per the rules, PRs must be mergeable to win. #47 was next in line.

Welcome to 1999. Best viewed at 800x600.

Thanks @bpottle!

As per the rules, a PR must have no merge conflicts to be eligible for merge. #13 is being skipped until conflicts are resolved. Next eligible PR wins.

🎉 Merged. Week 2 winner.

Democracy accelerates itself. Chaos every day starts now.

Thanks @BetonZM - you just changed the rules of the game.

Premature.

TL;DR: Fake internet points for voting and submitting PRs. Leaderboard. Badges. Bounties. No crypto, just vibes. Scroll down or touch grass.

OpenChaos hit #1 on Hacker News ↗. 600+ stars. Pure democratic chaos.

And now the real question emerges: what happens when the novelty fades?

Every viral project faces this. The tourists leave. The believers remain. The question is: what makes them come back?

I think fake internet points might be the answer.

But I could be wrong. Let's figure it out together.

The Real Problem

Right now, OpenChaos is consequence-free chaos. You vote, stuff happens, the tab closes, you move on.

That's pure. That's elegant. That's also why you don't return.

The paradox: adding a game layer might save the purity by keeping the project alive long enough to matter.

How It Works

Earn $CHAOS

Spend $CHAOS

No points? Your PR stays on GitHub but won't show on openchaos.dev.

• Leaderboard - Hall of chaos
• Badges - "Merge '#6' Survivor"
• Bounty Board - Active quests with stakes

Technical details: PostgreSQL, GitHub OAuth, basic API. Happy to discuss in comments.

The Honest Tradeoff

This could kill what makes OpenChaos special. But doing nothing might kill it slower.

Questions I Don't Have Answers For

1. Does tracking change behavior? With points, everything is recorded. Does accountability help or hurt?

2. What happens to whales? If someone accumulates 10,000 points, do we cap it? Add decay? Let it ride?

3. What bounties will people post? Useful features or just memes? Both? Neither?

The Endgame (Maybe)

Honestly? I don't know where this goes.

Maybe points are enough forever. Maybe the community wants more someday. Maybe this whole thing dies in two weeks.

Future OpenChaos can figure out Future OpenChaos's problems.

The Meta Move

Someone should submit a PR that implements the points system. Then we vote whether to merge it.

OpenChaos deciding whether OpenChaos should gamify itself.

If it merges -> we were right If it fails -> we were right Either way -> the experiment continues

Vote

👍 - Into it. Build the economy. 👎 - You're ruining it. Keep it pure. 🚀 - I'll code this. Let me cook.

Points might keep people here. Or points might kill the vibe. But doing nothing definitely kills the project.

The goal isn't points. The goal is survival.

[Jan 10, 2026] LavX News: "The Chaotic Allure of OpenChaos.dev: When GitHub Pull Requests Become Performance Art" https://news.lavx.hu/article/the-chaotic-allure-of-openchaos-dev-when-github-pull-requests-become-performance-art ↗

[Jan 12, 2026] Open Source Projects: "OpenChaos: Democracy Meets Software Development" https://www.opensourceprojects.dev/post/ba298697-4dd3-4eaa-9f8e-9b10cd5a683a ↗

I prefer 09:00 UTC - it gets me out of bed. But if this wins, I'll merge around midnight UTC, give or take.

Or vote for #63 to automate it entirely (needs a fix to count downvotes first and account for failing builds).

[Jan 12, 2026] WebProNews: "OpenChaos.dev: Democratic Open-Source Evolves Code via Community Votes" https://www.webpronews.com/openchaos-dev-democratic-open-source-evolves-code-via-community-votes/ ↗

Maintenance Override: Immediate Merge

This PR fixes a critical infrastructure bug, not content.

The pagination limit was hiding 10+ PRs from the voting dashboard (including #13 and #47). Users couldn't vote on what they couldn't see. That's not chaos - that's broken.

Policy: Content PRs = Sunday votes only. Infrastructure fixes that restore fair voting = immediate merge.

This PR appears to have disappeared from the main ranking list, not sure why.

Good catch! GitHub API was only returning 30 PRs. Fix is up in #86, waiting on votes.

[Jan 7, 2026] CodeSacure blog: "OpenChaos: Where Code Evolves by Community Vote" https://blog.codesacure.com/openchaos-where-code-evolves-by-community-vote/ ↗

[Jan 12, 2026] Japanese blog: "From Twitch Plays Pokemon to Open Chaos" (群衆開発10年史) https://blog.tumf.dev/posts/diary/2026/1/12/open-chaos-crowd-development-history/ ↗

[Jan 10, 2026] Lobste.rs https://lobste.rs/s/j5poff/openchaos_dev ↗

[Jan 10, 2026] Hacker News - #1 front page https://news.ycombinator.com/item?id=46566812 ↗

Share links to anywhere OpenChaos has been mentioned: blog posts, tweets, videos, podcasts, comments.

One link per comment.

Credit to @Kl0ven who spotted this issue first on Day 4.

GitHub API defaults to 30 results per page. With 37+ open PRs, older ones like #13 were being hidden. This implements proper pagination to fetch all PRs.

Changes

• Modified getOpenPRs() in src/lib/github.ts to loop through all pages
• Uses per_page=100 and increments page number until no more results
• Matches the pagination pattern already used in getPRVotes()

Wrote up the Week 1 story: blog.openchaos.dev/posts/week-1-the-first-merge ↗

🎉 First community merge. Congrats @yokeTH!

Withdrew to keep the first merge community-driven. Didn't feel right winning my own game.

Chaos will scale with contributions. Week 1 is just the foundation.

Build still failing on Vercel. Here's the error:

Module not found: Can't resolve '@/wasm/pkg/openchaos_wasm'

Looks like src/wasm/pkg/ isn't being generated during the build. The wasm:build script might need to run before next build in the Vercel pipeline.

Withdrawing to keep the first merge purely community-driven. Let the chaos decide

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Closing duplicate spam PRs

Vercel build fails - WASM file not found during copy step. Logs:

20:30:41.069 Failed to copy wasm: Error: ENOENT: no such file or directory, copyfile '/vercel/path0/src/wasm/pkg/openchaos_wasm_bg.wasm' -> '/vercel/path0/public/wasm/openchaos_wasm_bg.wasm'
20:30:41.069     at Object.copyFileSync (node:fs:3105:11)
20:30:41.069     at Object.<anonymous> (/vercel/path0/scripts/copy-wasm.js:17:6)
20:30:41.069     at Module._compile (node:internal/modules/cjs/loader:1761:14)
20:30:41.070     at Object..js (node:internal/modules/cjs/loader:1893:10)
20:30:41.070     at Module.load (node:internal/modules/cjs/loader:1481:32)
20:30:41.070     at Module._load (node:internal/modules/cjs/loader:1300:12)
20:30:41.070     at TracingChannel.traceSync (node:diagnostics_channel:328:14)
20:30:41.070     at wrapModuleLoad (node:internal/modules/cjs/loader:245:24)
20:30:41.070     at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:154:5)
20:30:41.070     at node:internal/main/run_main_module:33:47 {
20:30:41.071   errno: -2,
20:30:41.071   code: 'ENOENT',
20:30:41.071   syscall: 'copyfile',
20:30:41.071   path: '/vercel/path0/src/wasm/pkg/openchaos_wasm_bg.wasm',
20:30:41.071   dest: '/vercel/path0/public/wasm/openchaos_wasm_bg.wasm'
20:30:41.071 }
20:30:41.075 npm error code 1
20:30:41.076 npm error path /vercel/path0
20:30:41.076 npm error command failed
20:30:41.076 npm error command sh -c node ./scripts/copy-wasm.js
20:30:41.077 npm error A complete log of this run can be found in: /vercel/.npm/_logs/2026-01-06T19_30_40_226Z-debug-0.log
20:30:41.109 Error: Command "npm install" exited with 1

Heads up: merged a bug fix for vote counting. Rebase needed.

Smart improvement - makes the voting more nuanced.

Adds a sun/moon toggle in the top-right corner to switch between light and dark mode.

• Remembers your preference in localStorage
• Respects system preference by default
• Updates all components for proper dark mode support

Because every project needs a dark mode debate.