For AI agents

This wiki is written for two audiences at once: people, and the AI agents that run inside apps/intelligence (or any future agent built on this platform). Nothing here requires a special integration — it's a convention layered on top of plain markdown, so any agent with a fetch/read tool can use it.

Entry point: llms.txt

/llms.txt at the site root is a flat index: one line per module or capability doc, each with a one-sentence summary and a link. Read it first instead of crawling the whole site — it tells you which single page is likely to answer a given question before you fetch anything else.

Every module/capability page has frontmatter

---
title: IAM — Authentication, Organizations, Roles & Permissions
module: iam
routes: [/auth/*, /org/:slug/roles, /org/:slug/members, /platform/organizations]
permissions: [portal:roles:manage, portal:members:manage, ...]
entities: [User, Organization, Membership, Role, Permission, Invitation]
relatedAdrs: [docs/iam/ADR-001-authentication.md, docs/iam/ADR-003-rbac.md]
lastVerified: 2026-08-04
---

• routes — the portal routes this doc covers. Useful when an agent needs to point a user at a specific screen ("go to /org/:slug/roles").
• permissions — the exact permission strings gating the module's actions. This is the same vocabulary used in docs/iam/PERMISSIONS_CATALOG.md and in @RequirePermissions(...) decorators in core-api — an agent reasoning about "can this user do X" should match against these strings, not guess.
• entities — the Prisma models involved, for agents that also have direct data access and need to know what a page actually reads/writes.
• relatedAdrs — where the why lives. This wiki intentionally only covers the what/how; don't infer design rationale from these pages, follow the link.
• lastVerified — the date a human last confirmed this module works end-to-end in a real browser (tied to docs/MANUAL_TESTING.md). A stale date is a signal the page may describe intent rather than current behavior.

What this wiki is not

It is not a source of truth for authorization decisions — always defer to the actual guard/permission check in core-api at request time. Treat this wiki as documentation to reason with and cite, not as a runtime policy source.