- Shipped
- August 14, 2026 at 5:00 PM UTC
- Author
- kamo
- Commit
- 82252a1
Signing was inline on the member's profile tab, so the document sat under the settings tab strip AND the compliance sub-tab strip AND that tab's help panel — three bands of unrelated chrome over the instrument the member is being asked to read, and two headers. It is now **************** The page inherits NavTop and NavPri like every other screen and the wizard's hero band is the only header. Finishing or leaving returns to **************** — the list it came from, on the bucket the package was in. The list navigates with `push`, not `replace`: it is a move to a different screen, so browser Back has to come back to the list. THE ALLOWLIST HAD TO MOVE WITH IT. `RESTRICTED_ROUTE_PREFIXES` is prefix-matched and denies by default, and it is what a member whose employment has ended is confined to. Without `/settings/sign` on it, a former employee could open their package list and be bounced straight back to it by RestrictedMembershipGuard the moment they clicked into one — a redirect loop on the exact surface that tier exists to keep reachable, since compliance acknowledgements are one of the two things it protects. `restrictedRoutes.test.ts` now pins that, including that the match is not a bare startsWith: `/settings/signage` is not `/settings/sign`. No gate on the page itself, deliberately. A member executing their own employment agreement holds no HR right and never will — the package was issued TO them — and every endpoint behind it is self-scoped in DocsService (LegalAssignmentOwnership, not LegalPackageAccess), so the session decides whose assignment it is and someone else's uid answers 404. A bare /settings/sign with no assignment returns to the list rather than reporting an error: there is nothing on the page without one and no way for the member to supply it there. A malformed uid does show the error, because bouncing would hide a bad link somebody is about to send again.