Structural subject for access checks. Decoupled from the persistence layer: any object with an id and a role list can be checked (e.g. a Prisma Account row, a JWT payload, or a test fixture).
Loose on purpose. A real deployment carries extra context alongside the roles — the authenticated principal, a department, a tenant — and the core has no business rejecting keys it does not interpret. Whatever a capability means beyond "has the role" is enforced by the caller, against the resource.
Changelog October 18, 2026
v6.13.0 Oct 18
🐛[x] 🐛 fix: update dates service to correctly handle datetime parsing with offsets
✨[x] 🚀 feat: update WordPress roles declaration and audit
✨[x] 🚀 feat: update examples and scripts with new WordPress API usage and comments
✨[x] 🚀 feat: update documentation and configuration files
✨[x] 🚀 feat(tests): add a, AccessCapabilitySchema and AccessResourceSchema
… and 1 more
v6.12.0 Oct 18
✨[x] 🚀 feat: add subject resolution and ownership management for sessions closes #6
📚[x] 📝 docs: align ADR-0004, ADR-0006 and guides with the shipped code
🐛[x] 🐛 fix(docs): correct AssistantService JSDoc to the real method name
✨[x] ♻️ refactor(core): move useCreateStorageSignal to infrastructure
🧪[x] 🧪 test(coverage): establish Vitest coverage baseline and reporting