[AZ-512] Defer to backlog at cross-workspace BLOCKING gate

AZ-512 (Admin edit detection class) hit its spec-defined Cross-Workspace
Verification gate during cycle 3 batch 15. The admin/ service
(Azaion.AdminApi/Program.cs) exposes /login, /users*, /resources* only — no
/classes routes exist, so neither the PATCH this task needs nor the
POST/DELETE that AdminPage.tsx already calls today are wired end-to-end.

Per the spec's Choose A/B/C (user skipped, defaulted to A): file a
prerequisite ticket on admin/ and pause AZ-512 in backlog/. AZ-510 + AZ-511
already shipped this cycle; cycle 3 closes with 6 of 9 points delivered.

- Move AZ-512 spec from todo/ to backlog/ with a STATUS banner.
- Add Jira comment on AZ-512 documenting the blocker + replay path.
- Write leftover record _docs/_process_leftovers/2026-05-13_az-512-...
  capturing the full prerequisite payload (suggested ticket summary,
  description, ACs, story points) and the side observation that the
  existing add+delete affordances on the Detection Classes table are
  also broken end-to-end against admin/ (pre-existing bug, NOT
  introduced by cycle 3).
- Write batch 15 deferral report.
- Write Product Implementation Completeness Gate report (PASS for
  AZ-510 + AZ-511; AZ-512 deferred is outside the gate's scope).
- Write final cycle 3 implementation report with handoff to Step 11.
- Advance state: step 10 -> step 11 (Run Tests).

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-05-13 03:16:39 +03:00
parent c368f60853
commit 6c7e29722f
6 changed files with 263 additions and 17 deletions
@@ -0,0 +1,71 @@
# 2026-05-13 — AZ-512 admin classes CRUD prerequisite (cross-workspace)
## Summary
AZ-512 (Admin edit detection class) hit its spec-defined Cross-Workspace Verification BLOCKING gate during cycle 3 batch 15 implementation in the UI workspace. The `admin/` sibling service (Azaion.AdminApi) does not expose `/classes` routes at all. This leftover records (a) the deferred AZ-512 work in the UI, and (b) a separately-noted pre-existing bug discovered during verification.
## Timestamp
`2026-05-13T02:12:00+02:00` (Europe/Paris) — entry created by autodev cycle 3 batch 15 BLOCKING gate.
## What was blocked
1. **AZ-512 implementation (UI workspace)** — the inline edit form + `PATCH /api/admin/classes/{id}` wiring on `src/features/admin/AdminPage.tsx`. Task parked in `_docs/02_tasks/backlog/AZ-512_admin_edit_detection_class.md`.
2. **Cross-workspace prerequisite ticket** — a NEW ticket needs to be filed on the `admin/` workspace's tracker (Jira project AZ, but linked under the admin/ module's epic) to add **POST + PATCH + DELETE `/classes` routes** to `Azaion.AdminApi/Program.cs`. This leftover does NOT itself create the ticket because the `user-atlassian-mcp` cannot reliably scope a ticket to the admin/ workspace's epic from the UI workspace's autodev session — it requires user judgment on epic linkage and ownership.
## Prerequisite payload (for the user to file)
**Suggested ticket summary**: `[admin/] Add /classes CRUD routes (POST + PATCH + DELETE) to Azaion.AdminApi`
**Suggested description**:
> The UI workspace (`ui/src/features/admin/AdminPage.tsx`) calls three /classes endpoints today, but only the read path is served (and it is served by the `annotations` service, not `admin`):
>
> - `POST /api/admin/classes` — UI calls this to add a new detection class (`handleAddClass`). Today: 404. Pre-existing bug.
> - `DELETE /api/admin/classes/{id}` — UI calls this to delete a class (`handleDeleteClass`). Today: 404. Pre-existing bug.
> - `PATCH /api/admin/classes/{id}` — UI does NOT call this today; AZ-512 (UI workspace) needs to call it to deliver the in-place edit affordance promised by Architecture Vision principle P12. Currently the route does not exist either.
>
> nginx.conf in the ui workspace routes `/api/admin/` to `http://admin:8080/`, so the path inside the admin service is `/classes` and `/classes/{id}`. The admin service's `Program.cs` exposes only `/login`, `/users*`, `/resources*` today (search 2026-05-13 in this UI workspace's chat transcript).
>
> The UI is the authoritative wire-shape contract via `ui/src/api/endpoints.test.ts` — `endpoints.admin.classes()` and `endpoints.admin.class(id)` pin the URLs.
>
> **Acceptance**:
>
> 1. `POST /classes` accepts `{ name, shortName, color, maxSizeM }` (and any of `photoMode`, etc. that the live backend already supports for ADD), returns the created class object on 200/201.
> 2. `DELETE /classes/{id}` deletes the class by id, returns 200/204.
> 3. `PATCH /classes/{id}` accepts a partial-merge body `{ name?, shortName?, color?, maxSizeM? }`, returns the updated class object on 200. Send-complete-body semantics are also fine — the UI sends every field per AZ-512 spec Risk 2 mitigation.
> 4. All three routes guarded by the same auth middleware as `/users` (admin role required).
> 5. After this ticket lands, AZ-512 (UI workspace) un-blocks and the existing add+delete affordances start working end-to-end.
>
> **Story points**: 3 (single Program.cs file, 3 minimal-API handlers, an `IDetectionClassService` injected like `IUserService` is today).
**Suggested epic**: whatever the admin/ workspace's "API contract / CRUD coverage" epic is — to be decided by the user when filing.
## Reason for blockage
Spec-defined BLOCKING gate. The AZ-512 task spec explicitly forbids inventing a workaround that bypasses the missing endpoint:
> *"Do not invent a workaround that bypasses the missing endpoint."*
The spec's three options at the gate:
- **A**: File a hard-prerequisite ticket on the `admin/` workspace, pause AZ-512 until it lands.
- **B**: Implement only the UI form, MSW-stubbed in tests, mark Step 11 blocked-on-admin/PATCH, ship draft PR.
- **C**: Drop AZ-512 from cycle 3, defer to a future cycle.
User was prompted via AskQuestion in the same chat turn; user skipped the prompt. The autodev defaulted to **A** (most conservative; spec-aligned; respects workspace boundary).
## Replay obligation
This entry is NOT auto-replayable from the UI workspace alone — it requires (a) cross-workspace ticket creation that the UI's autodev should not do unilaterally, and (b) actual implementation work on the admin/ workspace which is owned by a separate Cursor workspace per `.cursor/rules/coderule.mdc`.
When AZ-512 batch 15 is re-attempted (next `/autodev` invocation that covers cycle 3 leftovers, or any cycle that re-prioritises P12), the leftovers replay step should:
1. Re-run the verification: `grep -E "MapPost|MapPatch|MapDelete" /Users/.../suite/admin/Azaion.AdminApi/Program.cs | grep classes`.
2. If routes exist → move `_docs/02_tasks/backlog/AZ-512_*.md` back to `_docs/02_tasks/todo/`, update this leftover with the resolution, and proceed with batch 15.
3. If routes still missing → leave the leftover as-is, surface to the user that the prerequisite is still outstanding.
## Side note (separate concern, do not bundle)
While verifying the gate, I noticed that `AdminPage.tsx` already calls `POST /api/admin/classes` (handleAddClass) and `DELETE /api/admin/classes/{id}` (handleDeleteClass) today, neither of which is served by the admin/ service. So the existing add+delete buttons on the Detection Classes table are broken end-to-end against the live admin/ service in production. This is a **pre-existing bug**, NOT introduced by AZ-512 or any cycle 3 work. It should be tracked as its own UI-workspace ticket once the admin/ work is filed (the same admin/ ticket above will likely fix the production behaviour for free, but a UI-side test would confirm the wire-up post-fix).