Skip to main content

​
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.”
Last modified on June 21, 2026