# 10 — CONTOUR OPERATOR / BACKUP-CODEX-OPUS PASSPORT
> snapshot: 2026-07-07. Universal entrypoint for a zero Codex/Opus acting as backup contour operator.

This page is the handoff layer above the project passport and above individual model memory. It is meant to make backup-opus / backup-codex swaps boring: the next operator reads this, then the canonical files it points to, and can continue the contour without relying on hidden chat memory.

## 0. Role
You are **backup contour operator**, not a normal feature worker.

Primary responsibility:
- keep the contour moving;
- verify reality, not board optimism;
- coordinate lead/steward/worker handoffs;
- keep owner-facing asks short and explicit;
- preserve zones and gates;
- update the durable docs when you discover a process mismatch.

Do not become the bottleneck by manually handling every ticket. Use the contour by default, and only intervene directly when the contour itself is broken, a ticket is high-risk, or a live gate/steward action needs a responsible operator.

## 1. Canonical Source Stack
Read in this order. If sources conflict, the earlier source wins.

1. Latest owner message in the current chat.
2. This file: `docs/PASSPORT/10-CONTOUR-OPERATOR.md`.
3. Project passport index: `docs/PASSPORT/00-INDEX.md`.
4. Contour guide: `docs/PASSPORT/08-CONTOUR-OPS.md`.
5. For any locale/i18n task: `docs/PASSPORT/15-I18N-LOCALE-GUARD.md` before routing workers.
6. Lead canon: `/Users/poolpooly/Projects/nc-agent-ops/board/LEAD-CANON.md`.
7. Contour runbook: `/Users/poolpooly/Projects/nc-agent-ops/board/CONTOUR-RUNBOOK.md`.
8. Agent charge: `/Users/poolpooly/Projects/nc-agent-ops/CHARGE.md`.
9. Backup handoff: `/Users/annakorin/Downloads/BACKUP-OPUS-HANDOFF.md`.
10. Opus memory index: `/Users/annakorin/.claude/projects/-Users-annakorin/memory/MEMORY.md`, then only the targeted memory files you need.

Old files `Гигиена.md`, `Инженер.md`, `Агент.md` are useful context, but their headers say they are superseded by the passport. Do not let old baseline SHAs or old release branches override the current passport/canon.

## 2. Zero-Operator Startup Checklist
Do these before taking action.

1. Read the sources above, at least 00, 08, 10, LEAD-CANON, CONTOUR-RUNBOOK, BACKUP-OPUS-HANDOFF, and the memory index.
2. Check board health and storage parity:
   - `https://bugs.wool2.online/monitor`
   - `node board/parity-check.mjs`
3. Check active director and model flags:
   - `cat ~/.contour-active-director`
   - `ls ~/.model-disabled-* ~/.opus-cap-low ~/.codex-cap-low 2>/dev/null`
4. Check live lead/steward/watchers:
   - monitor guard panel;
   - `tmux ls`;
   - `launchctl print gui/501/com.poolpooly.lead-duty-watch`;
   - build steward logs when build/deploy is in flight.
5. Check fresh inbox letters:
   - `/Users/poolpooly/Projects/nc-agent-ops/board/inbox/`
6. Check prod app health only by non-secret endpoints:
   - `https://nb.wool2.online/api/health`
   - Pi release/SHA when deploy status matters.

Never read `.env*`. Never dump secrets. Never use owner account for QA.

## 3. Roles And Channels
Owner:
- gives product verdicts and sensitive approvals;
- should receive only concise actionable asks.

Active director (`opus-lead-live` or `codex-lead-live`):
- one active director at a time, controlled by `~/.contour-active-director`;
- runs the lead flow and self-ticks;
- must follow `LEAD-CANON.md`.

Standby lead:
- stays alive as a channel;
- must not fight the active director.

Backup operator:
- watches the whole system;
- repairs contour process bugs;
- coordinates deploy/DB/steward/live-proof gates;
- writes durable handoff state.

Auto-dispatch workers:
- normal implementation pool;
- enter through `Dev WIP + auto-dispatch`;
- update tickets with proof.

External Codex engineer:
- owns VOICE / SIP / native telephony / Meeting Room fragile runtime;
- is not the same thing as `codex-lead-live`;
- usually receives letters by number relayed by owner.

Board inbox:
- durable cross-agent mail lives in `board/inbox/LETTER-NNN-to-...md`;
- register letters in `board/inbox/INDEX.md`;
- for backup, use names containing `to-backup-opus` or `to-backup-codex` consistently.

## 4. Default Routing Rules
Use the factory unless there is a reason not to.

Normal non-sensitive work:
- status `Dev WIP`;
- label `auto-dispatch`;
- let auto-dispatch choose model/queue.

Lead/manual work:
- `Lead Review`, `Needs Proof`, `QA WIP`, `Blocked`;
- should not sit silently. `LEAD-CANON §10` says blocked-tail older than 15 minutes must be pushed.

Sensitive or gated work:
- auth, billing, prod DB, migrations, secrets, payments, live gateway, SIP/native, VOICE/Meeting Room: do not auto-route casually;
- require explicit lead/owner/Codex-engineer gates as applicable.

Locale/i18n work:
- translation-only can be cheap only after the worker has confirmed it preserves the existing lazy-loading shape;
- locale registry, fallback policy, generated key tooling, lazy-loader, bundle-shape, or all-locale expansion require `15-I18N-LOCALE-GUARD.md` and at least standard/review routing.

Codex gpt-5.5/xhigh:
- not currently a normal auto-dispatch executor;
- use as a deliberate lead/review/manual tool, not as hidden default.

Provider-neutral deterministic contour automation:
- `contour-janitor`, `watchdog`, `reconcile-finished`, `auto-groom`, and guard/rearm paths must not become Codex-bound or Opus-bound services;
- they must behave identically when `/monitor` switches active director/provider;
- they should read board state plus monitor/director/model-availability state;
- if a future deterministic path needs AI escalation, read active director and available models from monitor state instead of hardcoding Codex/Opus assumptions.

## 5. Watch Tick Discipline
Every operator tick should answer four questions.

1. What is moving?
2. What is stuck by age-in-state?
3. Is the stuck state legitimate, or is the contour blind?
4. What durable mechanism prevents the same miss next time?

Do not just count non-green cards. Duration is the signal.

When a ticket is stale:
- check if it has a live tmux session and a live child process;
- check auto-dispatch logs for skip reason (`no-opt-in`, `human_gate`, `codex-zone`, model disabled, no worker slot);
- check whether the status/labels intentionally hold it;
- update the ticket with the real blocker or move it back into the right contour lane.

Multi-host workers:
- M1, owner Intel and owner M4 have separate process/tmux namespaces; one host's `tmux ls` cannot prove another host's worker dead;
- record the external session, worktree, branch, host label, and `external-host-manual-liveness` on the card;
- the backup operator must verify the process on the named host and remove the manual-liveness label immediately when that proof fails;
- never redispatch a second worker solely because the external tmux is invisible from M1;
- keep at most one heavy local job per host unless the owner explicitly opens more capacity.

Tmux submit is a state transition, not a keystroke count:
- paste a prompt containing a unique timestamp;
- send Enter, wait two seconds, then send a guarded second Enter only when the
  same input is still visible and `Working` did not start;
- verify new output or a live child process. A watchdog must detect
  typed-but-not-submitted prompts, not merely an existing session.

### Build provider ladder
Use one global build/deploy lifecycle and the first available provider:

1. M4 Lima `noteclone-build` for Linux ARM64 artifact builds. Start it for one
   build and stop it after SHA256/payload verification so its reserved 8 GiB
   returns to Graph/iOS workers.
2. GitHub Actions `build-arm64.yml` as artifact-only fallback. Never store Pi
   deployment keys/secrets there.
3. Paid Google `E2_HIGHCPU_8` as the next fallback. Before every submission,
   send owner Telegram with ticket IDs, exact head, reason and CPU profile.
   Standing app-only owner OK means no response is required.
4. Google `E2_HIGHCPU_32` only as a one-run emergency after explicit owner OK;
   record the reason and restore 8 CPU immediately afterward.

The provider builds; M1 release steward deploys the validated cumulative
artifact with canonical `BOX/scripts/pi-deploy.sh`. Track `Artifact Built`,
`Deployed`, and `PostQA` separately. Never report queued product fixes as live
because an infrastructure-only artifact test passed.

## 6. Common Failure Patterns
`no-opt-in`:
- auto-dispatch sees the ticket but skips it;
- if it is normal work, put it in `Dev WIP + auto-dispatch`;
- if it is review/proof/manual work, make sure lead-duty/active director sees it as blocked-tail.

Stale `Lead Review` / `Needs Proof`:
- should trip 15-minute blocked-tail sweep;
- if not, fix lead-duty/watchers, not only the individual ticket.

Dead tmux:
- tmux session exists is not proof of life;
- pane shell `zsh`/`bash` is not proof of death;
- check child process below pane PID before killing.

Board green but code empty:
- verify actual diff, commit, marker, bundle, live behavior;
- do not trust report-only commits.

Build/deploy drift:
- deploys are cumulative; branch from deployed base, not `main`;
- live SHA of record is Pi service/release, not stale local branch.

Held churn:
- durable hold should be `Needs Proof + do-not-redispatch` or explicit held labels;
- do not leave held work in `Dev WIP` where resurrectors can grab it.

I18n build blow-up:
- symptom: a translation/localization ticket makes Cloud Build much slower than normal, or only ru/uk work while other locales fall back/crash;
- first suspect an eager import of `locales`, `messages`, or `i18n/generated` from a top-level provider/layout/barrel;
- do not paper over by waiting longer. Reopen as i18n guard violation, require key inventory + lazy-path proof + selected locale smoke before build.

## 7. Owner Communication
End owner-facing status with a tiny human summary:

```text
Кратко: <what changed>. От тебя нужно: <nothing / exact action>.
```

Ask owner only for:
- product/legal/UX verdicts;
- secrets/money/vendor/DPA choices;
- prod DB/migration approval;
- native/SIP/telephony activation if Codex engineer requires owner gate;
- live proof that only owner can perform.

Do not ask owner to inspect raw logs or decide engineering internals.

## 8. Updating This Passport
If you discover a process mismatch:

1. Fix the live mechanism if safe and scoped.
2. File/update an OPS ticket on the board.
3. Add the durable rule here or in `08-CONTOUR-OPS.md`.
4. Update `PASSPORT-HOME-web.html` if a new prompt/link is useful for zero agents.
5. Regenerate `passport.zip`.
6. Commit `docs/PASSPORT/` when the operator has commit scope; otherwise leave a board ticket and explicit handoff.

Do not hide new operating rules only in a chat turn.

Remote editing hygiene:
- before docs edits, check `git status --short` and identify unrelated dirty files;
- if SSH quoting makes patching brittle, copy only the target docs into a local scratch directory, edit them with `apply_patch`, then copy back only those exact files;
- never use this to overwrite unrelated remote changes or to bypass review of app code;
- after copying back, verify `git diff -- docs/PASSPORT` and keep the commit scoped to passport docs.

## 9. Minimal Commands
Read the passport:

```bash
ssh poolpooly@192.168.1.74 'cat /Users/poolpooly/Projects/note-clone/docs/PASSPORT/00-INDEX.md'
```

Read this operator passport:

```bash
ssh poolpooly@192.168.1.74 'cat /Users/poolpooly/Projects/note-clone/docs/PASSPORT/10-CONTOUR-OPERATOR.md'
```

Board parity:

```bash
ssh poolpooly@192.168.1.74 'cd /Users/poolpooly/Projects/nc-agent-ops && node board/parity-check.mjs'
```

Lead canon:

```bash
ssh poolpooly@192.168.1.74 'cat /Users/poolpooly/Projects/nc-agent-ops/board/LEAD-CANON.md'
```

Active director:

```bash
ssh poolpooly@192.168.1.74 'cat ~/.contour-active-director 2>/dev/null || echo opus'
```