Александр Зимин
118 lines
5.1 KiB
Markdown
118 lines
5.1 KiB
Markdown
# 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](https://git.nstart.cloud/2-6/2-6-4/terravault/ordinis/-/merge_requests/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.
|