Skip to main content
Prerequisite: You should have Docker and Bun installed, and the Tuturuuu Monorepo cloned locally.
Step 1. Start the docs site from the repo root:
This uses the repo-managed Docker docs stack, which runs Mintlify inside a Node.js 24 container instead of relying on a globally installed CLI. The documentation website is now available at http://localhost:3000. To stop the stack:

​
Custom Ports

The docs stack exposes port 3000 by default through ${DOCS_PORT:-3000} in docker-compose.docs.yml. You can use the --port flag to customize the host-side port binding. For example:
If the chosen port is already taken, Docker will fail to bind the host port.

​
Runtime Details

  • The docs image is defined in apps/docs/Dockerfile.
  • The development stack is defined in docker-compose.docs.yml.
  • The root command wrapper lives in scripts/docker-docs.js.
  • The container pins the runtime to Node.js 24 and installs Mintlify inside the image.

​
Writing Documentation

​
File Structure

Each documentation file should follow this structure:

​
Content Guidelines

  1. Use clear headings to structure your content
  2. Include code examples with proper syntax highlighting
  3. Add cross-references to related documentation
  4. Keep content up-to-date by updating the updatedAt field
  5. Use consistent formatting throughout

​
Product Decisions and Regression Evidence

Record intentional customer behavior in the owning feature page alongside the change: scope, defaults, affected web/mobile surfaces, persistence and permission rules, and intentional exceptions. Distinguish implemented behavior from pending stages and installed or deployed behavior. Link the owning regression tests and exact validation evidence; do not convert a user preference into a repo-wide rule. Exercise the real boundary that previously failed. Examples include server-to-client date serialization, cache provenance before membership-based cancellation, and route-to-provider payload propagation. A helper-only mock can pass while those contracts remain broken. Use synthetic fixtures; keep private calendars, mail, credentials and live notifications out of shared test evidence.

​
Long-session learning maintenance

Finish sustained agent work by updating reusable guidance, not by copying the conversation into documentation. Use the existing feature page for customer behavior, the operational runbook for debugging/delivery, and the source skill reference for a fragile agent procedure. Keep AGENTS.md for rules that apply across tasks; managed plugin caches are not editable source. Record the observed cause, the evidence that distinguishes it from alternatives, the safe repair procedure, relevant regression tests and outstanding runtime proof. Separate source implementation, focused local validation, exact-commit CI, deployment markers, production migrations and authenticated runtime behavior. A merge alone proves none of the later stages. Avoid promoting an unverified inference or a one-off workaround into a permanent rule. For parallel work, assign one owner per overlapping path and Git publication lane. A child agent being listed is not proof that it is active: check its current state and request a concrete path/check/commit handoff. If a PR branch has another agent’s dirty packet, integrate main in a fresh isolated worktree rather than staging or overwriting that packet. After the parent merges, transplant the owned follow-up patch onto current main; do not replay the whole old branch. Keep temporary receipts, exact SHAs, pending gates and scheduler IDs in an unstaged coordination note. Register every worked-on PR with T3 Code, including follow-ups. Use native PR watches for PR news; use an explicitly authorized scheduled task for broader delivery follow-through. Record its cadence and next run, and disable it when delivery is complete. Recheck live refs after each wake. The latest explicit user instruction determines merge/review timing; a speed exception for merging does not silently authorize production promotion or expand the release range.

​
Code Examples

When including code examples:
  • Use proper syntax highlighting
  • Include TypeScript types
  • Show both server and client examples
  • Include error handling
  • Test examples before committing

​
Images and Assets

  • Store images in the images/ directory
  • Use descriptive filenames
  • Optimize images for web
  • Include alt text for accessibility

​
Contributing

​
Before You Start

  1. Check if documentation already exists
  2. Look for similar patterns in existing docs
  3. Follow the established structure
  4. Read the Organization Guide for structure

​
Making Changes

  1. Create a branch for your documentation changes
  2. Write clear, concise content that’s easy to understand
  3. Include practical examples that developers can use
  4. Update related documentation if needed
  5. Test your changes locally with bun dev:docs

​
Review Process

  1. Self-review your changes for clarity and accuracy
  2. Check links to ensure they work correctly
  3. Verify code examples are correct and complete
  4. Update the table of contents if adding new sections
  5. Submit a pull request with a clear description

​
Best Practices

​
Writing Style

  • Be concise but comprehensive
  • Use active voice when possible
  • Write for your audience (developers)
  • Include context for complex topics
  • Use consistent terminology throughout

​
Organization

  • Group related content together
  • Use clear section headings
  • Include a table of contents for long pages
  • Cross-reference related documentation
  • Keep examples practical and realistic

​
Maintenance

  • Update documentation when APIs change
  • Remove outdated information promptly
  • Keep examples current with latest versions
  • Review documentation regularly for accuracy
  • Ask for feedback from other developers