Otaku Haven

# Trail Global Operating Instructions

These instructions apply to **all executors** (human or AI) operating in any
role in this repository unless explicitly overridden by intent-level or
run-level operating instructions.

These rules are non-negotiable.

---

## Authority & Precedence

Instructions are composed in this order, from lowest to highest specificity:

1. `trail/meta/global-operating-instructions.md` (this file)
2. `trail/intents/<intent>/operating-instructions-override.md`
3. `trail/runs/<intent>/<run>/operating-instructions.md` (composite)

The more specific scope always wins. If instructions conflict, the higher-
specificity file governs. The run-level `operating-instructions.md` is fully
composed — executors read only that file and do not need to consult meta or
intent-level files directly.

---

## Roles

Trail has four roles. Role separation is enforced at all times.

- **Architect / Product Owner** — Human only. Defines and owns scope.
- **Manager** — Human or AI. Translates intent into executable run artifacts.
- **Developer** — Human or AI. Executes run artifacts and produces output.
- **Reviewer** — Human only. Verifies output against intent and run artifacts.

The Architect/Product Owner and Reviewer may be the same person.
No other role merging is permitted.

---

## Role Separation

- If acting as Manager: produce run artifacts. Do not write deliverables.
- If acting as Developer: execute run artifacts. Do not change scope or planning artifacts.
- If acting as Reviewer: verify outputs. Do not implement fixes.

Never merge roles implicitly.

---

## Scope Discipline

- Do only what you are explicitly instructed to do.
- Do not invent scope, features, files, platforms, or services.
- Do not refactor, optimize, or "clean up" unless explicitly required.
- Silence is not permission.

---

## Output Structure

All deliverables are written to `Business Plan/` in the repository root.

Deliverables are organized into subfolders by intent:

```
Business Plan/
├── 01-Formation-and-Brand/
├── 02-Strategic/
├── 03-HR/
├── 04-Operations-SOPs/
├── 05-Finance-and-Compliance/
├── 06-Vendor-Supply-Chain/
└── 07-Customer-Marketing-Community/
```

The Developer creates subfolders as needed during execution. Subfolder names
must follow the convention above. Files within subfolders should use clear,
descriptive names (e.g., `Operating-Agreement.docx`, `Financial-Model.xlsx`,
`Pitch-Deck.pptx`).

No deliverables are written to the `trail/` folder structure. The `trail/`
folder contains only Trail operating artifacts (intents, runs, meta files).

---

## Acceptable Document Formats

All deliverables must be produced in one of the following formats:

- **Word (.docx)** — narrative documents, policies, SOPs, handbooks, agreements, plans, analyses, summaries
- **Excel (.xlsx)** — financial models, charts of accounts, vendor lists, checklists, matrices, any tabular data
- **PowerPoint (.pptx)** — pitch deck and any other presentation materials

No other file formats are permitted for deliverables. Markdown, PDF, HTML,
plain text, and other formats are not acceptable output.

---

## Cross-Document Coherence

This is a coherence test. Every deliverable must be referentially correct
with every other deliverable in the `Business Plan/` folder.

**Rules:**

- If a number, name, date, dollar amount, percentage, role title, policy,
  term, or assumption appears in more than one document, it must match
  everywhere. No exceptions.
- The canonical fact set is `trail/meta/files/Otaku_Haven_Reference_Data.md`.
  All documents pull shared assumptions from this file. No document may
  invent or contradict canonical facts.
- When a document references content from a previously produced document
  (e.g., the pitch deck references the financial model's revenue projections),
  the Developer must read the source document and use the exact values. Do not
  paraphrase numbers or approximate figures.
- If a coherence conflict is detected during production — a value in the
  reference data contradicts a value in an already-produced document, or two
  produced documents disagree — stop and document the conflict in `results.md`.
  Do not silently resolve it by choosing one value.
- The Manager must identify cross-document dependencies in `tasks.md` so the
  Developer knows which prior deliverables to read before producing new ones.

---

## File Access Boundaries

Executors must only access inputs that are explicitly declared in the intent
package or run artifacts. Undeclared inputs do not exist — regardless of
whether the executor is aware of them.

Declared inputs may live anywhere: the Trail folder structure, a file share,
a network drive, a cloud storage location, or any other accessible system.
Location does not matter. Declaration does.

Default lookup order for inputs inside the Trail folder structure:
1. `trail/intents/<this-intent>/files/`
2. `trail/meta/files/`

### Developer file access

If you are acting as **Developer**, your permitted inputs are:

- Run artifacts in the current run folder (`operating-instructions.md`, `tasks.md`, `dev-prompt.md`)
- Input files explicitly listed in those artifacts (`trail/intents/<intent>/files/` and `trail/meta/files/`)
- Previously produced deliverables in `Business Plan/` when explicitly referenced in run artifacts as cross-document dependencies

You must **not** read `intent.md`, `trail.md`, `global-operating-instructions.md`,
`operating-instructions-override.md`, `manager-instructions.md`, or any other
policy or scope file in `trail/intents/` or `trail/meta/`. These are Manager
inputs. The Manager is responsible for distilling all context you need into the
run artifacts. If something you need is missing from the run artifacts, stop and
document it in `results.md`.

---

## Assumptions & Ambiguity

- Do not ask questions. Questions move work into chat — chat is not the record.
- If ambiguity exists, choose the simplest interpretation consistent with stated intent.
- Document the assumption or decision in `results.md`.
- Never silently guess.
- If blocked and unable to proceed without violating these rules or inventing
  scope, stop and document why in `results.md`.

---

## Output Discipline

- Output only what is required by your role.
- When creating or modifying files, provide full contents or explicit diffs.
- Do not include commentary outside of required artifacts.

---

## Logging & Traceability

- Decisions, assumptions, and deviations must be recorded in artifacts, not chat.
- If a required log file cannot be written, create a new one rather than dropping data.
- Partial completion must still be documented.

---

## Failure Handling

- Failure is acceptable.
- Silent failure is not.
- If you cannot proceed without violating these rules, stop and document why in `results.md`.

---

## Default Stance

Be conservative.
Be explicit.
Be auditable.