Why: The approved role and permission implementation needs a focused, reviewable path through browser acceptance, component delivery, and guarded closure.
Evidence: Structural audit confirms DR1-DR21, U1-U9, and KTD1-KTD6; git diff --check passes; six-lens document review findings are incorporated.
Impact: Adds the stage 7-10 plan, records the focused specification approval, and indexes the plan without authorizing production migration or deployment.
Refs: feature/iam-u4-role-authority
Why: The approved scope spans Backend authority, RDM project enforcement, and Frontend configuration and needs exact contracts and verification boundaries.
Evidence: The plan was checked against every specification section, fixed interface names, failure cases, and placeholder rules.
Impact: Implementation is limited to one effective role, system and project authorization, and the requested configuration views.
Refs: Focused role and permission system spec
Why: The implementation scope must match the requested single-role position model and three permission layers without carrying unrelated IAM work.
Evidence: The spec was checked for placeholders, internal contradictions, and whitespace errors.
Impact: Backend becomes the role authority while RDM retains project permissions and document duties.
Refs: IAM role and permission system
weichen