RBAC permissions on Umami.
A real-app integration fixture proof against umami-software/umami. The live RBAC packet was loaded with agb start, mapped to Umami's existing permission layer, and verified with focused allow, deny, missing-role, and unknown-permission tests.
Bounded RBAC standardization in Umami
What was validated
- Live RBAC package manifest loaded through
agb start. - Pinned host commit:
c0ea3aefbee7a3429ee2f824b06dc4a9dbe0b7e1. .buildprint/host-assessment.mdwas written before implementation..buildprint/capability-plan.mdmapped the Umami-specific policy.- Selected Umami user-admin helpers route through a central AGB RBAC helper.
- Admin access passed; user, view-only, missing-role, unknown-role, and unknown-permission paths denied.
npx vitest run --config vitest.agb-rbac.config.ts Focused Vitest proof against the real Umami permission layer. Final result: 1 file passed, 4/4 tests passed.
Selected depth: real-app integration fixture. No live HTTP server or production authorization behavior is claimed.
Open the proof files
PUBLIC_PROOF_SUMMARY.mdPUBLIC_PROOF_SUMMARY
Public summary, host commit, claim boundary, command, result, and real-app fixture scope.
QA_REPORT.mdQA_REPORT
Install notes, default-test blocker, proof command, exact Vitest result, and checks.
CAPABILITY_RECEIPT.mdCAPABILITY_RECEIPT
Host assessment, plan, changed files, protected surfaces, proof level, risks, and non-claims.
UMAMI_PATCH.diffUMAMI_PATCH
Exact patch applied to the pinned Umami checkout for the integration fixture.
This proves a real-app integration fixture, not production auth.
The proof validates the Capability Buildprint workflow and a bounded server-side Umami authorization path. It does not claim a full Umami permission migration, database migration, live HTTP authorization, or deployed production behavior.