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

What. One MR covering five small fixes:

• Records empty state: add description + primary action ("Queue is clear, see /audit for past decisions"). Current <EmptyState title={t('reviews.empty')} /> is just a heading.
• Reject reason inline validation: today handleReject does if (!comment.trim()) return silently. Button click → nothing happens. Show inline error or set the TextArea into error state.
• Drawer empty state (workflow.schemaDraft.empty): distinguish "not loaded", "not found" (deleted), "no permission". Today the same blank message covers all three.
• Approve action: drawer closes immediately on success. Add a 500ms success state (or toast) so the reviewer gets visual confirmation. Currently feels like the click might not have registered.
• Post-bulk-result polish: the bulkResult Alert lists business keys but the failed list shows raw reason codes (self_approve_forbidden, draft_not_pending). Map through extractReviewError already in the file.

Why. Pass 2 rated state coverage 5/10. These are the visible gaps. Each is 10-30 LOC; the value is interaction confidence.

Pros. All in one place — reviews.tsx, SchemaDraftDrawer.tsx. Low risk.

Cons. Five different surfaces in one MR means review surface is wider than a single-purpose change. Still worth grouping because they're all "state polish" semantically.

Context. Pass 2 finding. None of these block functionality; they're trust builders. Reject silent fail is the most user-visible — a reviewer clicks the button and nothing happens, then notices the TextArea is empty after a beat.

Depends on / blocked by. Nothing.

---

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.