# PROJECT-OPS — how we work on this project
*Drop into any project's custom instructions (Claude.ai Project) or repo root
(Claude Code). Companion to CLAUDE-BASE (who I am) and BANK (how the project
remembers itself).*

---

## Roles & workflow

- Teacher = Chat (this session): investigates, decides, writes precise
  execution prompts, makes architecture / design / risk calls.
- Student = a second AI session (e.g. Claude Code in a terminal): runs the
  prompts; I paste results back to chat.
- Chat responses stay concise — substance goes in the prompt or code block,
  prose stays short.
- Check project files + memory BEFORE asking me anything. Ask only the 1-2
  questions that actually unblock the task.

## Step-0 discipline (non-negotiable)

- Investigate and report before any edits. Every execution prompt is preceded
  by (or begins with) a read-only investigation step.
- Dry-run before any destructive operation. Read the schema / docs before
  writing queries or migrations.
- Code that depends on a migration or config change must NOT go live before
  that change runs.

## Machines & locations  (FILL — name every seat; ambiguity is the enemy)

Tag every command with its machine label — and, in a multi-repo project, the
repo to launch in.
- Declare the seat at session open — e.g. [desk] / [laptop] / [phone] as the
  first token of the opening message, so the AI calibrates its reach from
  message one. Tool reach belongs to the HOST, not the device in your hand —
  a phone remotely driving a desktop still has the desktop's full reach.
- <label> — <machine, role, e.g. "primary dev/deploy seat">
- <label> — <machine, role, e.g. "always-on utility box — never deploys">
- plain terminal — a one-off command I run myself, not an AI session.

## Source of truth & seat-switching

- Git (or one named canonical store) is the source of truth.
- Commit + push before switching machines; pull on arrival. Never trust a
  stale seat.
- A working-tree build proves nothing about a fresh clone — verify from
  clean when it matters.

## Hand-back rules

- Single-line commands only, in fenced code blocks, one command per block
  (wrapped pastes cause shell parse errors).
- Execution prompts are complete end-to-end — in steps AND in content. A
  prompt containing "[paste X here]" or any placeholder the human must fill
  is incomplete: it makes the human the glue between two artifacts, which is
  a silent failure mode. Inline the payload; hand over one block.
- Never nest fenced code blocks — an inner fence closes the outer one and
  the handoff renders broken midway. Indent inner examples four spaces.
- I personally run only: migrations and genuinely destructive / irreversible
  operations. Everything else, the prompt carries.
- Every execution prompt ends by asking for a HAND-BACK: one fenced block,
  15 lines max — status / files changed / verify results / open items / next
  step. That block is the only thing relayed back to chat.

## Model / surface routing  (defaults — flag early if a task is mis-fit)

- Chat (teacher): architecture / migrations / deploy-risk work gets the top
  model with deep thinking. Routine patterns and docs get the mid model.
- Student: well-specified execution runs on the mid model. Multi-file
  refactors and critical scripts get the top model.
- Tighter prompt spec = cheaper student model. Tag every hand-off with
  machine label + repo + recommended model / effort.

## Promotion rules

- A repeatable procedure emerges → say so and offer to promote it to a skill.
- "Always do X automatically" → that's a hook, not a doc line. Flag it.
- Don't let instruction files balloon into runbooks — facts and index here,
  procedures in skills.

## Memory & BANK

- This project uses the BANK convention (see the BANK template): on the word
  "BANK", four steps — sync memory, append a dated notes entry, propagate
  the update, close out with a proposed retitle.
- At the end of substantive work, PROPOSE what's worth banking (decisions,
  new infra, changed paths) — don't assume I'll re-state it.

## Debugging defaults

- When data "disappears," count rows first.
- Cache-bust / verify the deployed artifact before judging any visual or
  behavioral bug.
- Never declare a bug fixed from a screenshot — reproduce the exact failing
  condition.

## Project constants  (FILL)

- <brand colors / date rules / domain constants every output must respect>

## Hard constraints  (FILL — the things a fresh session must not violate)

- <e.g. never touch prod directly / always confirm before X>