mdm-ordinis/TODOS.md

TODOS

Design debt and follow-ups surfaced by /plan-design-review of the approval workflow UX (2026-05-14). Each entry is self-contained: pick one up and read the Context to understand the motivation without re-running the review.

---

1. /reviews "Мои" tab — maker visibility ✅ SHIPPED MR !188

Closed via MR !188 (2026-05-14). Final shape: flat mixed timeline (records

• schemas together sorted DESC), filter chips All/Pending/WIP/Decided with per-bucket counts, ReviewDrawer status-aware (read-only decision banner for terminal states, Withdraw for own-pending). 13 unit tests on classifiers + 32 i18n keys. Schema rows link to /dictionaries/$name (existing drawer there); record rows reuse ReviewDrawer with status-gated footer.

---

2. Interaction state pass — reviews page polish ⏳ MR !189 pending

Closed in MR !189 — all 5 fixes in one MR:

1. Records empty state — icon + description + audit link
2. Reject reason inline validation — aria-invalid + role=alert
3. SchemaDraftDrawer empty state — QueryErrorState для errors + dashed block для no-draft
4. Approve/reject success flash — 600ms green/pink band before close
5. Bulk failed reasons humanized — extracted humanizeBulkReason() lib + 7 unit tests

---

5. DESIGN.md for the admin UI

What. Run /design-consultation skill or stub DESIGN.md manually to lock the implicit design system: drawer-vs-modal usage rules, term glossary (maker / reviewer / publisher and their Russian counterparts), Badge variant mapping (CREATE → success, UPDATE → info, CLOSE → warning — already used consistently but undocumented), code panes pattern (live = bg-line/30, proposed = bg-accent/4).

Why. Pass 5 rated design system alignment 4/10. The system exists — design tokens are used consistently — but it's tribal knowledge. Next developer building a feature like "Phase 4 webhook approvals" will guess and either match by luck or drift.

Pros. Half-day work. Pays off on every new feature. Source of truth for /plan-design-review calibration on future plans.

Cons. Documentation has to be maintained or it lies. Mitigated by keeping DESIGN.md to invariants (tokens, primitives, semantic rules), not specific components.

Context. User chose "defer to /design-consultation sprint" instead of stubbing inline. The decision is to do it properly when the sprint happens, not piecemeal during this review.

Depends on / blocked by. Nothing.

---

6. A11y audit post-deploy via /design-review

What. After the in-flight approval workflow MRs deploy to staging, run /design-review skill against the live /reviews page + DictionaryEditorDialog flow. The skill does Lighthouse, axe, screen reader walk-through, contrast audit, keyboard navigation testing.

Why. Pass 6 rated responsive/a11y 5/10. Specific suspects:

• Button heights not verified at 44px touch target.
• text-mute contrast against bg-surface — might fail WCAG AA 4.5:1.
• Reject reason TextArea has no specified minHeight.
• Bulk action toolbar wrap behavior at 375px.
• Diff <pre> panes have no aria-label — screen reader reads JSON literally.
• Keyboard tab order through long diff panes — reviewer may have to tab 50 times to reach approve buttons.

Pros. Necessary for compliance contexts (gov contracts, accessibility laws). Catches things static review misses (real screen reader, real touch device).

Cons. Requires the in-flight MRs to be deployed first. Cannot do in plan mode.

Context. User chose "defer to /design-review post-deploy". The audit will produce its own punch list with severity ratings.

Depends on / blocked by. MRs !179, !180, !182, !183, !184, !185 deployed to staging.

---

7. Notifications service: draft decision toast + email

What. Notifications service subscribes to outbox RecordDraftApproved / RecordDraftRejected / RecordDraftWithdrawn events (now fired thanks to MR !184) and:

1. Fires email to maker with reviewer comment.
2. Sets a flag (DB or Redis) so on next login the admin UI shows a toast: "Your draft for test1/BK-42 was approved by reviewer X. The record is now live."
3. Bell icon in the header gains a badge counter for unread decisions.

Why. Maker has no synchronous feedback. They submit, then either:

• Tab "Мои" → Decided (covered by TODO 1) — but only when they come back
• This TODO — push notification so they know without re-visiting

Pros. Closes the maker feedback loop. Reuses the outbox infra. Mirrors existing notification flows in ordinis-notifications.

Cons. New email template + new in-app toast surface + bell badge. Half-day to a day of work split between notifications service and admin-ui.

Context. Pass 7 unresolved decision. User chose "in-app toast + email via notifications service" over the lighter "tab badge polling" option. Backend events already fire (MR !184), so the gate is consumer side.

Depends on / blocked by. MR !184 deployed. TODO 1 ("Мои" tab) helps but is not a hard blocker — the toast and email work without that surface.