Files
ui/_docs/_process_leftovers/2026-05-13_az-512-admin-classes-prereq.md
T
Oleksandr Bezdieniezhnykh 09449bda2c
ci/woodpecker/push/build-arm Pipeline failed
[AZ-510][AZ-511][AZ-512][AZ-513] Cycle 3 Steps 12-15 + admin prereq
Wrap up cycle 3 across the autodev existing-code Phase B steps that
follow Implement (Steps 12-15), plus the cross-workspace prerequisite
ticket filed for AZ-512.

Step 12 - Test-Spec Sync:
- Un-quarantine FT-P-01 in traceability-matrix (closed by AZ-510)
- Add AZ-510 chained /users/me failure-path test reference under AC-23
- Note AZ-512 deferral status under O9 (P12 Phase B target)

Step 13 - Update Docs (task mode):
- Refresh src__auth__AuthContext module doc with AZ-510 wire shape
  (POST refresh + chained /users/me + bootstrapInflight guard)
- Add usersMe() to src__api__endpoints module doc + consumer note
- Rename src__features__annotations__classColors module doc to
  src__class-colors__classColors (matches AZ-511 git mv); refresh header
- Refresh src__components__DetectionClasses + src__features__annotations
  module group doc for the new class-colors barrel import path
- Update components/11_class-colors Module Inventory to point at the
  renamed module doc filename
- Rewrite system-flows.md Flow F2 (Bearer auto-refresh) with the AZ-510
  POST + chained /users/me sequence; close Finding B3 references
- Generate ripple_log_cycle3 documenting all changed source files,
  their reverse-dependency search results, and the docs touched

Step 14 - Security Audit (cycle-3 delta):
- Resume mode against cycle-2 baseline; cycle-2 artifacts untouched
- Re-run bun audit on both roots: clean (cycle-2 inline fix held)
- Re-rate OWASP A06: FAIL -> PASS; A07: PASS_WITH_KNOWN -> PASS (B3
  closed by AZ-510)
- New finding F-SAST-CY3-1 (LOW): __resetBootstrapInflightForTests
  exposed via src/auth public barrel; defer to hygiene cycle
- Verdict: FAIL -> PASS_WITH_WARNINGS; one HIGH (F-SAST-1
  mission-planner git-history key, unchanged) remains
- Add amendment banner to cycle-2 security_report.md

Step 15 - Performance Test:
- Static profile NFT-PERF-01 PASS (290 575 B gzipped vs 2 MB budget;
  ~14% of budget; no regression from AZ-510 surface additions)
- E2E profile SKIP (Playwright perf project still pending AZ-457..AZ-482);
  legitimate skip per test-run skill, gap acknowledged in report
- AZ-510 200ms p95 chain NFR verified at spec level only - no CI gate
  yet (covered by future AZ-457..AZ-482 work)

Cross-workspace prerequisite (AZ-513 just filed):
- Updated _docs/_process_leftovers/2026-05-13_az-512-admin-classes-prereq.md
  to reflect AZ-513 filing on admin/ workspace (parent epic AZ-509,
  Blocks link to AZ-512). Companion task spec added in admin/ repo
  (separate commit there, owned by admin/ workspace).

State file: advanced to Step 16 (Deploy) per autodev existing-code flow.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-13 03:58:21 +03:00

6.1 KiB

2026-05-13 — AZ-512 admin classes CRUD prerequisite (cross-workspace)

PARTIALLY RESOLVED 2026-05-13T03:51+02:00 — prerequisite ticket AZ-513 was filed on the admin/ workspace (Jira Task, parent epic AZ-509, "Blocks" link to AZ-512). Matching task spec written to admin/_docs/02_tasks/todo/AZ-513_classes_crud_routes.md. AZ-512 carries a comment pointing at AZ-513. Replay obligation below now waits on AZ-513 shipping (admin/ side work), not on the autodev session itself.

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 ticketFILED as AZ-513 on 2026-05-13 with user-confirmed epic linkage (AZ-509). Spec at admin/_docs/02_tasks/todo/AZ-513_classes_crud_routes.md. "Blocks" link AZ-513 → AZ-512 created in Jira. Comment on AZ-512 references AZ-513. Pending: admin/ team picks up and ships AZ-513.

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.tsendpoints.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).