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.

Searching it from inside the platform

An agent running on P4P does not need to fetch pages at all. core-api builds this whole wiki into a searchable index and exposes it three ways, on both the internal and the external MCP server:

• search-help — a question in, the sections most likely to answer it out, each with a short passage and an absolute link. Start here.
• read-help-section — one section in full, by the module and anchor a search returned. Read only what answers; cite its link.
• list-help-modules — the map: every area, its routes, the permissions that govern it, its section titles.

Each takes an optional locale (en, ru, hy). Many terms stay in English on the Russian and Armenian pages — permission keys, "Impersonation" — so if a search in one language finds little, try the English term. The same answers are available over HTTP at /help/search, /help/sections/:module/:anchor and /help/modules.

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.