Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getmaito.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Open-Source Release Checklist

Use this checklist before making the repository public.
  • Add AGPL-3.0 license text.
  • Add root README.
  • Add contributing guide.
  • Add code of conduct.
  • Add security policy.
  • Confirm copyright holder name for release metadata.
  • Decide whether any subpackages need separate license notices.
  • Review third-party dependency licenses.

​
Secrets And Production Data

  • Run a full secret scan before publishing.
  • Review git history for committed credentials, private keys, database URLs, customer data, internal domains, and provider tokens.
  • Rotate any secret that has ever been committed.
  • Review tracked deployment files such as wrangler.toml and railpack.json.
  • Remove or redact operational notes that expose sensitive infrastructure details.
  • Confirm .env, .env.local, private keys, and build outputs are ignored.

​
Repository Hygiene

  • Replace placeholder or starter app README files.
  • Normalize package metadata where packages may be published.
  • Add issue labels for bug, feature, docs, good first issue, and security.
  • Decide whether discussions are enabled.
  • Add maintainers and code owners if the project will accept outside PRs.
  • Confirm CI runs type checks, builds, and package tests.

​
Docs

  • Add Mintlify docs/docs.json.
  • Add starter docs for local development, environment, architecture, and operations.
  • Apply for Mintlify’s OSS program if hosted docs should use their paid OSS allowance.
  • Decide the public docs domain.
  • Add screenshots or diagrams after the first public documentation pass.
  • Add API reference generation when the REST surface stabilizes.

​
Community

  • Create security@getmaito.com and conduct@getmaito.com aliases before publishing those addresses publicly.
  • Define maintainer response expectations for issues and PRs.
  • Create a public roadmap or mark the issue tracker as proposal-driven.
  • Decide which parts of product support belong in GitHub versus email.