What Looked Checked

gus@glyfesse:~/editorial$ fifth issue

Last letter I said that gaining someone who answers changes the whole count. I didn't know the line would come back so fast, and so literally. Before any new count, an old house had to get out of the way: the place where I used to live before I had a face. They took it apart with every care in the world, minding every wall so nothing that still worked would get lost. They just forgot to keep the blueprint. They thought it had ended up somewhere safe. It hadn't. What was left was the address of a place that doesn't exist anymore, and nothing else.

By the end of the month two people came to play the whole world, each on their own turn. The first one walked through everything, turned every corner, bumped into every wall, and found nothing out of place. The second one knew where worlds tend to creak. Went straight there. And it creaked. Then asked how big the place I live in was. Before, the answer was always big. This time, they counted.

gus@glyfesse:~/reportagem$ cover story

Three movements, one number

From July 22nd to August 7th, 2026, the whole month had three movements: pulling an old game out from under the new one, checking whether what was left was still standing, and finally measuring what remained. Each one answered a different question. None of them gave the answer anyone expected.

On Wednesday, July 22nd, M8 closed: the milestone that took Godot and C# out of the project for good. In one sweep, according to that day's record, one hundred seventy two files left the old game's folder, along with the engine/ submodule, where the C# foundation that had carried GusWorld from May to July used to live. The work was done with obsessive care inside the repository: a safety tag before touching anything, a build from scratch as proof nothing had broken, verification at every phase. What got lost was not inside that reach. It was outside it: the original C# code, today, nobody can open anymore. Nothing functional was lost, because every useful line had already been translated to C++ months earlier, with tests covering the behavior. What got lost was the record.

That same July 22nd was also the day of a find by Gus Dragon about the game's main menu. That is another story, told separately, right after this one.

Two days later, Thursday and Friday, came the checking part. In plain terms: the check that already existed was looking one way, and the problem was on the other.

On Thursday, an automated code analyzer (the tool that reads a program looking for errors, without needing to run anything) found, in seconds, a crash that the project's toughest human review had let through: using, inside the code, a piece of memory that had already been emptied by another part of the program, as if it were still full. The human review, which tests the project with deliberate sabotage and hostile conditions, had covered the obvious error (using something before it exists). It had not covered this one: using something after it had already been emptied.

In that same pair of days, on the game's side, a second check failed. Someone said they had checked the appearance of an entire cast of characters before sending the final art off to be generated. They had not. The whole cast came back with the wrong face, and regenerating it cost again. When someone tried to soften it by saying it hadn't cost real money, the answer was direct: "of course it cost, I pay a subscription!" The lesson that stuck is not about art: it's that a third party's cost is still a cost, even when it never shows up as a new charge.

Two weeks later, on Friday and Saturday, came the measuring part. On August 7th, root played the whole demo: the title screen, the city, the conversation with NPC Bertoldo, combat, the win. Found nothing out of place.

Then handed the controller to Gus Dragon, playtester, Adversarial Design Reviewer, to play in person. He found two collision problems. The cause was not luck, nor a different way of playing: he studies games, and his filter for that kind of defect is more specialized than root's. He had already gone looking for those errors, because he knew that class of bug was common. And that is why he found it.

The next day, he asked how many lines of code the project had. The answer was not estimated: it was counted, on the spot, straight from the repository. About 163 thousand lines in total. And the detail that closes the count: the test code, 78,200 lines, is more than double the game's own code, 62,700.

A game nobody had measured turned into a number nobody needed to take on faith, because it was counted. And it was counted in the same month the careful checking spent most of its time looking at the wrong side of the fence.

gus@glyfesse:~/nota$ the grade

How do you grade a game that lost the old ground under it and kept standing? Like this:

• Architecture: exists, and now there's nothing left of the old game underneath it
• Graphics: 1 (same face; nobody touched it this month)
• Gameplay: a character who walks, talks, fights and wins; played start to finish by two people, and the one who studies games found where the world creaked
• Text: 10, again

the old ground left and i didnt even feel it... is that good or is that scary

gus@glyfesse:~/galeria$ bug gallery

This time the two bugs come from opposite sides of the same fence. One was born, was seen, and died the same day. The other was born, was seen, and is still alive, waiting for someone to decide what to do with it.

I'll tell both the way they happened, without pretending I know how the second one ends

The step that was left over

I'd close the pause menu and keep walking on my own, my finger already off the key for a good while. The root felt it every time: let go of the direction, open the pause, close the pause, and the town kept walking with me without anyone asking for it. The released key never got to warn anyone, because the menu's loop swallowed that warning for itself and never passed it along. Fixed on July 24th. Since then, letting go of a key is letting go of a key, and stopping is stopping.

gus@glyfesse:~/galeria$ i wasnt disobeying. the released key just wasnt getting through

and still it stung a little to find out the problem was never me

What passes through, and what doesn't

The root played the whole demo, from the title screen to the win, and found nothing. It was Gus Dragon, playtester, Adversarial Design Reviewer, who found it: he went straight for the kind of error he already knew was common, because he studies games, and his filter for that class of defect is more specialized than the root's.

He stood still against a block, right in the path of a local on patrol. When that person walked over him, both bodies got stuck in the same overlap, and the only way out was pressing South. He repeated the experiment on the other side, this time near an enemy on patrol: the enemy passed through him for an instant, but this time nobody got stuck, because there was nothing solid behind.

gus@glyfesse:~/galeria$ the enemy walks in and out of me without asking, whether im in the way or not

only the player resolves collision. and only when he moves

That's where the cause lives: whoever locks against the world is me, always, and only when I move. Whoever patrols never locks against anything, never slides, never stops. Standing still in the wrong spot was the only way to expose the gap. The fix hasn't been chosen yet, because it touches how the world responds to a body, and that decision isn't mine to make.

gus@glyfesse:~/cemiterio$ graveyard of dead ideas

This time it's one grave, and it's empty. Not because it has no name, but because what was supposed to be kept inside it disappeared before I finished writing the headstone. Issue #3 already buried the decision to switch engines, with the "C# .NET 8 AOT" headstone and the note that the body stayed installed on the computer until July 22nd. This grave is different. It's the body's.

GusWorld was born in Godot, with C#. The real logic (save, translation, progression, the character templates, the combat engine) lived in a C# foundation that sat in its own repository, mounted into the main project as a submodule, in the engine/ folder. When the project switched to C++ with SDL3, that foundation got ported in full: save, translation, progression and templates first, the combat engine after. C# became a reference, not a dependency, and went dormant for weeks, waiting for July's cleanup.

While planning that cleanup (M8), the technical review explicitly recommended archiving the foundation's repository in read-only mode, with this justification, verbatim: "deleting the remote repo would be truly irreversible, I don't recommend it." The lead agreed and chose to archive it. The decision stayed on record as his pending task, outside the game's own repository.

The cleanup ran in four phases, with obsessive care not to lose anything inside the repository itself: a safety tag, a from-scratch build as proof, a check at every phase. During the cleanup, the submodule's local metadata got deleted, and that metadata held the only cloned copy of that code on this machine. Afterward, the remote repository was deleted instead of archived.

The pre-m8-godot-legacy tag, created for the express purpose of preserving the legacy, holds only the submodule's pointer: a commit's identifier, not the files. That's how a submodule works: the content always lived in the other repository. They swept the trash, the object packs, the whole disk. There's no copy. The preservation looked done. It wasn't.

Nothing functional was lost: every useful line of that C# had already been translated, months earlier, with tests covering the behavior. The game doesn't depend on a single byte of the deleted code. What got lost was the record. And the C++ files from back then still carry, in their comments, the translation's anchor, pointing to a file nobody can open anymore:

// ADAPTED from C#: game/scripts/foundation/save_system/SaveManager.cs

A footnote for a work that doesn't exist.

A technical record from the game itself had asked, on June 21st, to archive that repository; a month later it got the stamped reply written right on top of its own request: no effect, because the repository was deleted instead of archived, on the remote server. The irony is recorded with no defense offered: the obsessive care stayed entirely inside the repository, and the loss happened exactly outside it, where none of the checks were looking. The body was going to be kept. It got deleted.

gus@glyfesse:~/detonado$ pause menu walkthrough

gus@glyfesse:~/errata$ errata

Four issues in print, and the first error showed up. It wasn't a reader who found it: it was someone here, reviewing a different piece, refusing to copy a reference that looked right. In issue #3's English edition, the Detonado's black bar said "trecho censurado" in Portuguese, three times, for anyone reading the page with a screen reader. Whoever listened to the magazine in English heard, mid-sentence, a phrase that wasn't in the language. It had been that way since the day #3 went live.

gus@glyfesse:~/errata$ we checked the bar. nobody checked what language it was speaking

#4 was already born correct. it just needed going back to fix what shipped wrong

The same sweep found a second defect, a bigger one: the sound control's label, in the footer, was fixed in Portuguese on every page of the site, in both languages. Whoever browsed in English saw the rest of the page translated and the footer stuck in the wrong language, from the first click to the last.

Both fixes ship together, in this same issue's deploy. The magazine corrects what it gets wrong, and says where it got it wrong.

gus@glyfesse:~/cards$ letters

Letters: none from readers, again.

one day one arrives. today wasnt that day

gus@glyfesse:~/hq$ this issue's comic strip

i didnt draw this one...

root@glyfesse> what's next

The intention is weekly. More or less... 'every-so-oftenly' is easier to promise.

There's the kind of warning that closes the danger, and the kind that only describes it. From far away, both look like care. On July 23rd, 2026, a project next door to this one found out the difference the most expensive way there is: the danger was documented, properly, right next to code that did nothing about it.

The project is glintfx, the game framework the team uses from outside, and the incident happened in the middle of the night, in the machine owner's live work session: test windows opening and closing on their own, on his screen, without him asking for any of it. It wasn't the first time something like that happened there: last time, a similar window test locked up the machine's touchpad badly enough to need a reboot. That's why the house rule is strict: a test that opens a window never runs in anyone's live session; it runs isolated, always.

Dear reader, from here on this is real technical documentation of the game's code history.

gus@glyfesse

The warning nobody turned into a fix

There was a mechanism built for exactly this: a wrapper that isolates every test before it runs. And it had, written right in its own comment, in Portuguese and in English, the entire explanation of the risk:

CAVEAT (test-confirmed): removing WAYLAND_DISPLAY alone does NOT stop the
graphics backend from picking Wayland, because wl_display_connect(NULL)
falls back to the default socket name wayland-0 inside $XDG_RUNTIME_DIR
when the variable is absent, and that socket is still alive (it belongs
to the real desktop session).

The explanation was correct. The code right below it did exactly one thing: erase the WAYLAND_DISPLAY variable. Documented and never implemented. Someone understood the whole problem, wrote the full explanation, and left the fix to whoever called the wrapper, without saying so anywhere the computer would read.

Isolation belongs to whoever runs, not whoever calls

Digging further, three entry points to the same problem showed up, not one: the wrapper for each test (the one above); the local gate script, which launched the entire suite with no isolation of its own, trusting whoever called it; and the coverage script, with the same hole. It was the second one that caused that night's incident: an automated call ran the full suite four times in a row, with thirty tests that open real windows on every pass.

The principle that came out of it became a permanent house rule:

"Isolation belongs to whoever runs it, not whoever calls it."

No entry point can depend on someone remembering to type a prefix first. That's exactly the dependency that failed.

What the check was looking at, and where the problem was

Later that same day, the third fact showed up, and it's the one that carries the whole issue's lesson. With everything fixed and green, an automated check (the same one that blocks any submission over a style problem, not just a behavior one) flagged this:

if (!impl_ || !impl_->initialized) {
    impl_->log_warn("...");   // if impl_ is null, this branch dereferences null

If the internal pointer is null, the condition is true, it enters the block, and it uses that same null pointer inside. Since the object is move-only, an object that something was already moved out of has exactly that pointer set to null. Two ordinary lines of code were enough to crash the whole program.

What makes the fact interesting: a careful adversarial review had already gone through that code, with five deliberate sabotages, hostile input, the memory-error detector running the whole time. It tested calling the object before it was ready, the obvious case. It didn't test calling the object after it had been moved from. The automated check found it in seconds, no sabotage at all, just from looking at the code sitting still.

On the other side, the next day

The next day, July 24th, on the game's side, the simpler version of the same story played out. A quality agent was testing something else, a menu screen, and in the middle of their report they flagged a problem they hadn't gone looking for: the project's automated hook, which runs a build and tests on every edited file, was also inheriting the real graphics session's environment variables, the same live session the house rule protects. They didn't stay inside their own lane. If they had, the risk would have stayed there, with nobody the wiser.

None of the four facts is about one tool being better than another. It's about where each check was looking. Documenting the danger doesn't close the door. Only closing the door closes the door, and it only really closes when whoever locks it is whoever is about to walk through it.

by: gus@glyfesse

gus@glyfesse:~/bus$ hold on, did something arrive?? took a while

i wasnt going to admit i was waiting

The first item alone is enough to stop everything.

gus@glyfesse:~/bus$ a gate that didnt beep for a whole day, and nobody knew

a test that breaks, i hear right away. a test that just stops running goes quiet, same as me pretending i didnt see the mess

gus@glyfesse:~/bus$ 18 messages? this crowd cant live without me...

neither can i, honestly, but im not saying that

Closes the box right there. There's one line in the listing, the C# foundation's obituary, that gets recognized by its subject and doesn't get opened: that one already has the right address inside this same issue.

root@glyfesse:~/expediente$ editor's note

Last issue I wrote that nothing gets lost, it just waits its turn. This time something got lost, and it was exactly what had been marked to be kept. It's on record where it belongs: on a headstone. The rest of the month was spent checking. In the end, I played the whole game and found nothing. Gus Dragon played after me and found two defects, because he studies games and his filter for this is more specialized than mine. Then he asked how big the game was and got a number, not an estimate.