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

# Repository Boundary Policy

> Rules and mechanisms defining the public application projection vs. private workspace boundaries in toorow.

## Decision

Toorow maintains a private working repository while exporting a strictly allow-listed projection to public repositories. This approach separates core shareable application code from private marketing, design, and product planning workspace assets.

***

## Public Application Projection

The shareable application projection includes only paths explicitly allowed in `distribution/public-app.toml`:

| Surface          | Included | Purpose                                                                             |
| ---------------- | -------: | ----------------------------------------------------------------------------------- |
| `server/`        |      Yes | FastMCP kernel, source-specific module connectors, and test suites.                 |
| `ui/`            |      Yes | React Admin Console, shared shells, design tokens, and single-file MCP App widgets. |
| `dbt/`           |      Yes | Canonical dbt models (`fact_daily_kpi`), seeds, and data-quality tests.             |
| `infra/`         |      Yes | Local services (Docker Compose for Nango/Postgres) and GCP Terraform IaC.           |
| `.github/`       |      Yes | Application CI matrix and human-gated Cloud Run deployment workflow.                |
| Root build files |      Yes | `pyproject.toml`, `uv.lock`, `pnpm-workspace.yaml`, Makefile, `README.md`.          |
| `scripts/`       |      Yes | Export utility (`export_public_app.py`) and audit scripts.                          |
| `distribution/`  |      Yes | Boundary policy file (`public-app.toml`).                                           |

***

## Private Workspace Projection

The following surfaces remain strictly private and are excluded from public application exports:

| Surface                                  | Purpose                                                   |
| ---------------------------------------- | --------------------------------------------------------- |
| `web/`                                   | Marketing showcase site (Astro).                          |
| `studio/`                                | Sanity CMS content administration workspace.              |
| `docs/`, `doc/`                          | Technical documentation and research notes.               |
| `_bmad/`, `_bmad-output/`, `reviews/`    | Planning artifacts, story specs, and cynic review output. |
| `_screenshots/`, `logo/`                 | Brand assets, screenshots, and visual design assets.      |
| Dot-directories (`.agents/`, `.claude/`) | Local assistant and workflow agent configurations.        |
| `info.md`                                | Original product requirements document.                   |

***

## Why an Allow-List Policy?

Deny-list policies risk exposing private files when new directories or temporary local databases are introduced. The allow-list model enforces a **default-private** security stance: any new path is private unless explicitly reviewed and added to `distribution/public-app.toml`.

Defense-in-depth deny rules further scrub environment files (`.env`), credentials, local SQLite/DuckDB databases, and scratch data from allowed directories before export.

***

## Export & Release Workflow

1. Execute `python scripts/export_public_app.py --list` to inspect allowed export targets.
2. Export snapshot to an isolated build directory outside the repository.
3. Run automated secret scanner (`ruff`, secret-grep) over the exported tree.
4. Verify license inclusion prior to describing the repository as open-source.
5. Human approval (**Human Gate**) is required before pushing public releases.

***

## Next Steps & Cross-References

<CardGroup cols={2}>
  <Card title="Security Constraints" icon="shield-check" href="/constraints">
    Review pre-live security checklists and architectural invariants.
  </Card>

  <Card title="Self-Hosting Guide" icon="server" href="/self-hosting">
    Deploy your own instance of toorow.
  </Card>
</CardGroup>