> ## Documentation Index
> Fetch the complete documentation index at: https://docs.briksync.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AGENTS

# AGENTS.md — Mintlify (CUSTOMER-FACING DOCS ONLY)

> **Read before touching ANYTHING under `mintlify/`.**
> Everything in this folder is **published to customers** at the public docs site.
> Mintlify also auto-discovers/auto-adds `.mdx` pages. Treat this directory as a
> **public website**, not internal notes. When in doubt, leave it out.

## The one rule

**Never reveal internal information to customers — not the data, not the names, not the *intent*.**

This is a hard boundary. A leak here is a security and trust incident.

## NEVER put in `mintlify/**`

* **Internal role names:** never expose internal/system role identifiers (snake\_case keys) or
  the Errsol-internal cross-org administrative role that no customer ever holds. The full
  forbidden list is enforced by `scripts/check-docs-leaks.sh` + the pre-commit pattern guard —
  that script is the single source of truth, don't duplicate the raw tokens here. Customer-facing
  role vocabulary is only: **Super Admin, Admin, Property Manager, Landlord, Broker, Tenant** —
  the exact labels the product UI shows (team-settings role chips + the app header). **"Super
  Admin"** (the org owner) IS a customer-facing label and is allowed. There is no "Owner" or
  "Accountant" role in the product — do not invent them.
* **Database internals:** raw table/column names, RLS policy details, migration names,
  "row-level security" implementation specifics, counts ("48 tables", "% of tables secured").
* **Secrets & config:** env var names, key names, connection strings, ports, project refs,
  `SUPABASE_SERVICE_ROLE_KEY`, internal URLs, `localhost:55321`, etc.
* **Internal paths:** `src/...`, `docs/...`, `supabase/...`, internal file or action names
  (e.g. `listPropertiesAction`), repo structure.
* **Credentials of any kind:** seed logins, shared/demo passwords (`BrikSync2026!`), test
  accounts, sandbox creds. (These belong in `docs/ops/`, never here, never as `.mdx`.)
* **Unshipped or aspirational features stated as live.** Payments are "coming soon," AI is
  "private beta." Never imply self-serve sign-up (it's invitation-only).
* **Fabricated proof:** customer counts, unit counts, testimonials, metrics we can't back.
* **Internal links:** never link to a page that lives outside `mintlify/` (it 404s publicly
  or, worse, leaks if globbed in). Cross-link only to other `mintlify/` pages or
  `https://briksync.com/*` marketing routes.

## ALWAYS

* Write in **customer language**: outcomes and how-to, not implementation.
* Use the canonical contact **`hello@errsol.com`** — never invent `support@`, `security@`, etc.
* Keep the honest **private-beta** posture; primary CTA is **Request access** (`/contact`).
* Match the public OpenAPI spec to the real `/api/v1` contract (see the API audit) — do not
  document endpoints that don't exist.
* Run the leak guard before committing: `bash scripts/check-docs-leaks.sh`.

## Leak self-check (run mentally on every edit)

1. Could a competitor or attacker learn our internal structure from this page? → cut it.
2. Does this name a role/table/env/path a customer would never see? → reword to customer terms.
3. Is this a claim we can prove today? → if not, remove or label beta/coming-soon.
4. Does any link leave `mintlify/` or `briksync.com`? → fix it.

## Dispatching a docs sub-agent

Any agent told to work in `mintlify/` MUST be handed this file and told:
"You are editing a **public customer website**. Apply `mintlify/AGENTS.md` strictly. Do NOT
touch `src/`, `supabase/`, or `docs/internal/`. Customer-facing language only. Run
`scripts/check-docs-leaks.sh` before reporting done."