Learning AI-DLC building a game, part 6: a bugfix intent

This is part 6 of a series on learning AI-DLC by building a game, World Rift Conflict, in Godot with an AWS backend. Part 3 built automated end-to-end tests. A code review of that work then found three small bugs. This post follows them through AI-DLC's bugfix scope, and looks at what six stages cost and what they bought.

Parts so far:

• Part 1: setup
• Part 2: a proof of concept
• Part 3: automated E2E tests
• Part 4: what the reviews caught
• Part 5: inside a stage
• Part 6: a bugfix intent (this post)

TL;DR

1. Even a bugfix runs six stages: Reverse Engineering, Requirements Analysis, Code Generation, Build and Test, Deployment Pipeline and Deployment Execution.
2. The scan found two gaps the code review had missed, one of them a way to commit a secret.
3. A requirements review caught an acceptance check that would have passed on the broken code.
4. Editing a document after its review locks the approval until the change is reviewed.
5. It took a few hours. For three minor bugs that is a lot, but it shipped with tests that prove each fix.

The three bugs

The E2E kit runs the game's sign-up and sign-in on Linux and in three browsers against a separate test backend. The review found:

1. A stale safety value. A guard refuses to run tests against production by comparing user pool IDs. It read production's ID once and kept that copy forever.
2. A swapped config file. To build a test export, the kit swaps the game's amplify_outputs.json for the test backend's, then swaps it back. If the export was interrupted, the test file stayed. If it was interrupted twice, the backup of the real file was overwritten.
3. An impatient mailbox. The test reads the confirmation code from a real email. An email without a code made it fail at once instead of waiting up to two minutes.

Reverse Engineering: the scan saw more

I asked for a full rescan of the codebase rather than a quick look at three functions. The scan located each bug by file and line, and found two things the review had not:

• The backup file from bug 2 was not git-ignored, and the committed-secrets check only knew the exact name amplify_outputs.json. One git add -A after an interruption could have committed it.
• With no Amplify app ID configured, the guard returned silently and kept using whatever copy it had.

Requirements Analysis: four questions, two reviews

The stage asked four questions, each option explained: when to refresh (every run), what to do when the refresh fails (stop, never use the old copy), how far the file fix goes (all the way, including the secrets check), and whether to move my test domain out of the code (no).

The first review flagged a requirement I had written without asking: stop when the app ID is missing. It was right. I hadn't been asked, so I confirmed it at the approval with Request Changes, along with four small fixes.

Then the approval would not reopen:

Requirements Analysis can't go ahead as things stand: which way would you like to go on?

The review on record was of the earlier text. Approving a changed document under an old review is exactly what the guard prevents. Restarting the stage was one way out. A cheaper one was asking for a review of the revision, which AI-DLC records as requested by the person.

That second review found the best bug of the day. The acceptance check for "a failed refresh stops the run" used an unknown AWS profile. But an unknown profile already fails at the credentials check, before the fixed code runs, so the check would pass on the broken code too. The plan replaced it with a well-formed app ID that doesn't exist: credentials pass, and only the refresh fails.

Code Generation and Build and Test

The plan went to me for approval before any code, and a developer agent built it: 18 new unit tests, with the full suite green. The architecture reviewer said READY with five minor findings, which I accepted as open items.

Build and Test ran the acceptance checks against AWS after my go:

Check	Result
Full run on Linux, Chromium, Firefox, WebKit	pass; the refresh adds 6–7 s
Fake app ID, for the run and the cleanup	both stop with exit 2 and remove the old copy
Empty app ID	stops with exit 2 and names the setting
A real export interrupted with Ctrl-C	the next run repairs the file and passes

The interrupted export took four tries. The first sent the signal too late, and to the wrong process. The next two hit an expired AWS SSO token. The aws CLI still answered on cached credentials, but the JavaScript SDK the kit uses did not. After aws sso login, the fourth waited for the marker file the export writes and interrupted at once.

Deploying a fix to test tooling

Nothing players run had changed, so the deployment questions were already answered by the team practices, and AI-DLC filled them in with sources instead of asking. I pushed, Amplify rebuilt the same game, and the production smoke check passed.

Was it worth it?

Six stages and three reviews for three minor bugs is heavy. What it bought:

• Two gaps found that the original review missed, one of them a path to committing a secret.
• An acceptance check that would have proved nothing, caught before it was written.
• A regression test for every bug, and a record of why each choice was made.

What I would change: for a bug this small, the Deployment Pipeline stage mostly repeated the team practices. The scope can be composed without it next time.

What is next

The tooling is done. Next is the game itself: the Ideation stages for World Rift Conflict.