Rejected under reject-vibecoded: I've fixed the pitfalls I found, what else have I missed?

[gdsolver]

Hi — my mod gdsolver.solver was rejected under reject-vibecoded. I'm not
contesting the rejection or arguing about the rule. I'd like to ask a narrower
question: what specifically was wrong with the code, and what would have to
change before it could be accepted?

Two things up front.

First, English isn't my first language and isn't good enough for me to write a
message like this unaided, so I use AI for translation and drafting. That
includes this one —
I check it by having it put back into Japanese, and as far as I can tell it says
what I mean, but the English isn't mine, and I'll read your replies the same way.

Second, the project was built with heavy AI assistance. I directed it, made the
design and physics decisions, tested against the game and worked through the
failures, but I did not hand-write most of the code. CLAUDE.md and AGENTS.md are
still in the repository; I'm not trying to hide it.

https://github.com/gdsolver/gdsolver

The more embarrassing part is that I submitted without properly reading the
guidelines and the common pitfalls page. That was careless. Going through them
afterwards I found several concrete problems, and they're fixed:

• std::stoi and std::stof, which the pitfalls page names specifically, are
  gone in favour of numFromString. A malformed number in a config file could
  take the game down at launch, and one in a command file mid-frame.
• A std::filesystem::create_directories call was missing its error_code
  overload.
• Hotkeys were polling GetAsyncKeyState with hardcoded virtual key codes,
  which skips both cocos' keyboard dispatcher and Geode's keybind settings.
  They're Geode keybinds now.
• A node was kept across scenes by a ticker of my own, under a comment claiming
  this version of Geode had no equivalent. OverlayManager exists. The comment
  was simply wrong.
• Releases were built on my machine. They come from CI now, so the published
  binary is built from the public source.

Those are all things I should have caught before submitting.

There are still three try blocks — four catch clauses, since the terminate
handler has both a typed one and a catch-all. They're only at boundaries: the
std::terminate handler, which rethrows the current exception to recover its
type and what() for the crash log, and two thread entry points where an
escaping exception would take the process down. There's also a new_handler
that logs an allocation failure and then throws bad_alloc, which is what the
standard requires of one — returning would loop — and that's what those two
catches exist for: running out of memory ends the round instead of the process.
My reading is that the page is about not relying on throwing APIs in normal code
paths rather than about catching at boundaries, but if the index wants these
gone as well, say so and they'll go.

My guess is that the list above is also why it looked like code I didn't
understand, which is a fair conclusion from the version I submitted. It's all
Geode-specific — I didn't know this SDK well enough.

What I'd like to know is whether there are more problems I've missed: API
misuse, compatibility issues, unsafe patterns, anything that would block
acceptance. The repository is larger than a typical mod — about 2 MB of C++ —
but only 890 KB of that is the mod. The rest is a standalone solver it links,
which builds with no Geode installed at all (-DGDSOLVER_BUILD_MOD=OFF) and
never touches the SDK. I'm not asking anyone to review the whole thing; I'm
asking about the mod-facing code.

And if the answer is that the amount of AI-generated code makes this ineligible
regardless of whether I understand and maintain it, that's a clear answer too,
and I'll leave it there.

Thanks for reading.

[miskkaaa]

we dont accept ai generated mods on the index
and since you wrote this fully with ai then yeah

[miskkaaa]

the mod itself looks very vibecoded

[dankmeme01]

the rejection reason is pretty clear: The mod’s codebase entirely or mostly consists of AI-generated code. If it appears the programmer does not understand the code that has been generated and is trying to get vibecoded mods on the index, this will result in a rejection. Using AI tools to boost productivity is fine, but fully vibecoding mods will inevitably lead to instability and crashes.

[gdsolver]

Thanks, both of you. That's the clear answer I asked for, and I'll leave it there.

One thing for the record rather than as an argument. This wasn't thrown together. Every physics constant in it was measured against the running game rather than guessed at, and no change is accepted unless a cold run reproduces the same repair count on all 22 official levels. That doesn't change the rule, and I'm not asking anyone to revisit it. I'd just rather that part were on the record.

Thanks for taking the time to reply.