Why: the U4 branch is 89 commits behind main, which now carries the shared
document renderer, two-trees project work, the SQLite instance guard and
exec env layers (PR #209 merged as c76d8bd); it conflicted in storage
migrations, host capabilities and the extension surface. The user authorized
syncing U4 after the renderer line on 2026-10-18.
Evidence: content is the agent-exec transport 3b64eb5 (cursor worker, unit
backend-iam-u4-onto-main-c76d8bd-r1, run on a checkout whose tree equals main,
receipt /tmp/cleanup-20261018/render/u4-backend-onto-run.json, SELF). Host
check: main migrations 1-48 unchanged (migrate.go has no deleted lines versus
main), U4 migrations moved from 35-36 to 49-50 with identical SQL,
surface.txt is the sorted union, deps stay at main's pins.
Impact: databases that ran unmerged U4 builds with the old numbering must be
recreated. SurfaceVersion becomes 2.25.0-experimental. Main's admin password
account creation now requires the system.users.create action like the other
U4 account writes.
Refs: Backend main c76d8bd, PR #209
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: Independent review found delegated account actions, stale resource policy, and role migration cutover gaps in the initial U4 implementation.
Evidence: Backend full SQLite suite passed; isolated PostgreSQL role and migration suite passed; independent final review found no remaining findings.
Impact: Enforces transactional system grants, current role snapshots, staged role import with v36 migration, and fail-closed activation.
Refs: feature/iam-u4-role-authority
Why: Non-root managers need the system-management entry and controls to follow their explicit grants.
Evidence: The full Backend test suite passed and /api/me action projection is covered by the grant-isolation test.
Impact: /api/me now returns only the current actor system actions evaluated by the same authorizer.
Refs: Focused role and permission system task 7
Why: Existing RDM role commands must reach the Backend authority during UI and migration cutover without dual-writing RDM role tables.
Evidence: The full Backend suite passed, including actor-bound role administration, owner compatibility, provider, and public-surface tests.
Impact: Adds temporary trusted Host administration methods and completes the project-action catalog used by RDM.
Refs: Focused role and permission system task 5
Why: RDM needs a trusted, non-secret view of Backend-owned role policy without importing Backend internals or accepting a caller-supplied actor.
Evidence: The full Backend test suite passed, including public-surface and provider contract tests.
Impact: Adds optional extension surface 2.14 with actor-bound role snapshots and action decisions.
Refs: Focused role and permission system task 4
Why: System, role, and project entry permissions need explicit actions instead of a single administrator flag or unrestricted project creation.
Evidence: The full Backend test suite passed, including role APIs, action isolation, project.create denial/allow, storage migration coverage, and account write fences.
Impact: Adds versioned role and grant endpoints, maps account actions to explicit permissions, and requires project.create authority.
Refs: Focused role and permission system task 3
Why: Role assignment and permission changes must preserve one active position, version conflicts, idempotency, and the final policy manager.
Evidence: The full Store suite passed on SQLite and focused role/policy tests passed on isolated PostgreSQL.
Impact: Adds transactional role mutations and seeds explicit system grants for existing administrators.
Refs: Focused role and permission system task 2
Why: Backend needs a single trusted catalog and durable role authority before RDM can stop owning position data.
Evidence: Authz catalog tests and the full store suite passed on SQLite; migration rollback and one-active-role constraints are covered.
Impact: Adds schema v35 and stable role/binding types without changing existing authorization callers.
Refs: Focused role and permission system task 1
