Otaku Haven

# trail.md
<!-- This file lives at trail/meta/trail.md. It is the persistent identity of
     the product or project — what it is, who it's for, why it exists, and how
     it's shaped. Every intent inherits this context automatically.

     The Manager reads this file before producing run artifacts for every run.
     The Developer does NOT read this file directly — the Manager surfaces
     relevant product context into the run artifacts.

     Changes rarely. Only update when product identity, audience, or permanent
     constraints shift. -->

Owner: James Whitfield
Last Updated: 2026-04-21

---

## Product Identity

Otaku Haven is a fictional brick-and-mortar anime retail store located in
Austin, Texas. It exists as a stress test for the Trail Framework — proving
that Trail's artifact-driven, intent-based approach to human-AI collaboration
works outside of software development.

The project produces a complete, investor-ready business package: formation
documents, a full business plan, pitch deck, financial model, HR policies,
operational SOPs, vendor management documents, and customer-facing policies.
Every document must be internally consistent and referentially correct across
the entire package.

The store concept: a curated anime retail experience at 2847 S Lamar Blvd,
Suite 105, Austin, TX 78704. Products include figures, manga, apparel,
accessories, trading cards, media, and a consignment section for local creators.
Target opening: June 1, 2026.

This is not a real business. It is a controlled test environment where the
complexity of a real business is used to validate Trail's ability to maintain
coherence across dozens of interconnected artifacts produced over multiple
intents.

---

## Users / Audience

**Primary:** The Trail Framework itself — this project validates that Trail
can drive non-software artifact production at scale with full cross-document
coherence.

**Secondary:** Potential investors reviewing the business package. All produced
documents must be credible enough to survive investor scrutiny — realistic
numbers, consistent assumptions, professional formatting, and no contradictions.

**Anti-users:** This is not a template library or a "how to start a business"
guide. The documents are specific to Otaku Haven's fictional scenario and are
not intended for reuse.

---

## Permanent Constraints

- All produced documents must be **referentially correct** with each other. If a number, name, date, policy, role, assumption, or term appears in more than one document, it must match everywhere. Contradictions between documents constitute a test failure.
- The **Store Information & Reference Data** file (`trail/meta/files/Otaku_Haven_Reference_Data.md`) is the canonical fact set. All documents pull shared assumptions from this file. No document may invent facts that contradict it.
- **Acceptable output formats:** Word (.docx), Excel (.xlsx), PowerPoint (.pptx). No other file formats for deliverables.
- **Output location:** All deliverables are written to `Business Plan/` in the repository root, organized into subfolders by intent (e.g., `Business Plan/01-Formation-and-Brand/`, `Business Plan/02-Strategic/`). The Developer creates subfolders as needed.
- Humans remain responsible for approvals and stage transitions. AI does not decide what comes next.
- Entity type is Texas LLC. All legal references, compliance documents, and governance structures must reflect Texas LLC law.
- The fictional timeline is internally consistent. Documents must not reference events before their established dates or after the project timeline.

---

## Technology & Architecture

This is a document production project, not a software project. There is no
runtime, deployment model, or application architecture.

**Document production stack:**
- Word (.docx) — narrative documents, policies, SOPs, handbooks, agreements
- Excel (.xlsx) — financial model, charts of accounts, vendor lists, checklists
- PowerPoint (.pptx) — pitch deck

**Reference systems (fictional):**
- POS / E-commerce: Square for Retail + Square Online
- Accounting: Xero
- Payroll / HRIS: Gusto
- Email & Productivity: Microsoft 365 Business Standard

These systems are referenced in produced documents but are not part of the
Trail project infrastructure.

---

## Product Principles

1. **Coherence over volume.** A smaller set of documents that agree with each other is worth more than a large set with contradictions. If producing a document would introduce an unresolvable inconsistency, stop and document why.
2. **The reference data file is the single source of truth.** When in doubt, the reference data wins. If a document needs a fact that isn't in the reference data, the Architect adds it there first — documents never invent canonical facts.
3. **Investor-grade credibility.** Every document should survive the question "would an investor believe this?" Numbers must be defensible, policies must be realistic for an 8-person retail operation, and the overall narrative must hold together.
4. **Documents are files, not chat.** The produced artifacts are the record. Chat is disposable. If it matters, it's in a file.
5. **Fail visibly.** If a document can't be produced without contradicting another document or the reference data, that's a valid and useful outcome — document the conflict in results.md rather than papering over it.

---

## Non-Goals (Product Level)

- This project will never produce a real, legally binding document. All content is fictional.
- This project will not build software, deploy services, or create application code.
- This project will not produce marketing content for actual distribution (social posts, ad copy, etc.).
- This project does not evaluate or recommend real vendors, landlords, or service providers.

---

## Prior Art / Context

The Trail Framework was born from the TrekCrumbs build process and has been
validated in software development contexts. This project is the first
non-software stress test — deliberately chosen because business document
packages have high interconnection density (financials must match narratives,
policies must match staffing models, SOPs must match technology choices) and
because coherence failures are easy to detect and measure.

The Document Checklist (`trail/meta/files/Otaku_Haven_Document_Checklist.md`)
defines the full scope: 45 documents to produce across 7 intents, plus 28
pre-established reference items.