Why: Frontend main d562d6a is the PR #106 merge commit of df7818f, which this
branch already contains; recording it keeps the branch current for the
outdated-branch merge check.
Evidence: d562d6a and df7818f have identical trees; the merge changes no
content.
Impact: none.
Refs: Frontend PR #106
Why: the U4 Frontend branch is 100 commits behind main, which now carries the
shared document renderer delivery UI, two-trees project work and regulations
citations (PR #106 merged as d562d6a); it conflicted in the API client and
the admin sections. The user authorized syncing U4 after the renderer line on
2026-10-18.
Evidence: content is the agent-exec transport cf07aef (cursor worker, unit
frontend-iam-u4-onto-main-d562d6a-r1, run on a checkout whose tree equals
main, receipt /tmp/cleanup-20261018/render/u4-frontend-onto-run.json, SELF),
integrated with agent-exec apply onto df7818f; this merge (strategy ours)
only records U4 commit 05609ff as an ancestor and changes no content.
Host review: U4's removal of the superseded RDM roles panel and main's move
of RdmDutiesSection to duties/ are both kept; root administrators keep main's
account creation and password reset panel under the U4 users section.
Impact: the Python environment admin section becomes root-only like the other
U4 system sections; AccountRecord gains a ManagedAccountRecord view type.
Refs: Frontend main d562d6a, PR #106
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: the real catalog leads with protected system actions whose checkboxes are disabled; the live flow must advance permission groups to reach an editable action.
Evidence: deterministic 16/16 unchanged.
Impact: live test navigation only.
Refs: feature/iam-u4-role-permission-ui
Why: the live composition starts with zero roles; the real permission catalog table renders only after a role is selected, so the catalog assertion must follow role creation.
Evidence: deterministic 16/16 unchanged; live layer reruns via iam-u4-role-acceptance.sh.
Impact: live test order only; no behavior change.
Refs: feature/iam-u4-role-permission-ui
Why: stage 7 (DR6-DR10) requires repeatable browser evidence; the reviewed flows lacked a disable confirmation, role-scoped draft lifetime with an explicit leave decision, and status announcements.
Evidence: 16/16 deterministic Playwright scenarios pass on an isolated preview (route-driven, no live services); 283 unit tests and build/knip stay green; live-layer cases ride the same file under IAM_E2E_LIVE.
Impact: RolePermissionsPanel keeps per-roleId drafts, guards zone leave/refresh, adds a disable confirm strip (name + binding count + impact + cancel) and restores save focus; AdminZone consults the leave guard; AccountUsersPanel notice becomes role=status; new e2e/iam-role-authority.playwright.ts.
Refs: feature/iam-u4-role-permission-ui
Why: Fine-grained viewers and managers need independent data loading, safe conflict recovery, and complete paged role access.
Evidence: Frontend 281 tests, production build, and knip baseline passed; independent final review found no remaining findings.
Impact: Adds action-specific controls, server-side role filters and paging, matrix cap editing, and sequence-safe draft rebasing.
Refs: feature/iam-u4-role-authority
Why: The Backend-authoritative role and account views replace the legacy local role and user panels.
Evidence: npm test; npm run build; node scripts/check-knip.mjs; UI npm test.
Impact: Keeps one role administration surface and restores the unused-export baseline.
Refs: feature/iam-u4-role-authority
Why: Administrators and delegated system managers need focused role, user, and permission controls with search, filters, single-role editing, and a matrix view.
Evidence: Frontend 280 tests, production build, paired UI 163 tests, and design guards passed.
Impact: Replaces the RDM role panel with Backend role authority and adds optional user profiles, unique role assignment, and explicit system-grant editing.
Refs: Focused role and permission system task 7
Why: Single-role and matrix views need one typed Backend contract and one draft model so filtering cannot mutate authorization scope.
Evidence: Focused draft-model tests passed and the Frontend production build completed.
Impact: Adds role, binding, catalog, and system-grant APIs without changing visible UI yet.
Refs: Focused role and permission system task 6
weichen