# Flow-First Operating Model

audience: AI coding agents first.

status: ACTIVE
worker: main session continuously orchestrating executable lanes under owner goal

## Communication contract

- Detailed recommendations, requirements, owner comments, corrections, rationale, WIP reconciliation, and execution checklists live in this durable plan.
- Every owner comment edits the existing plan with its full long-form meaning before implementation or response.
- Chat response stays short: concepts, decision requested, current status, next steps.
- NEVER leave authoritative plan content only in chat.

## Outcome

Keep customer work flowing through any proven remote executor while infrastructure replacement proceeds independently. NEVER create a global prerequisite from k3s, review, Git ritual, transcript recovery, or architecture cleanup.

## Invariants

- If an item can safely ship through any working remote path, ship it now.
- Heavy execution MUST be remote. Remote unavailable → queue with exact reason; NEVER run locally.
- SSH fleet is current production executor. k3s migrates one proven job class at a time.
- One blocked item NEVER blocks independent items.
- One worker owns one item from claim through installed/deployed proof.
- Keep only trust-boundary safety checks synchronous. Run broad review/reconciliation asynchronously.
- Done means owner-visible and usable now.
- Owner correction 2026-08-10: active goal means continuous execution, not one action followed by a scheduled wakeup. NEVER end a turn or arm only a fallback while any durable plan has an executable action. Background waits trigger immediate work on another independent lane. ScheduleWakeup is fallback only after every open lane is either actively owned by a named worker or genuinely externally blocked.

- Owner correction 2026-08-11: agent/process termination NEVER means owner cancellation, abandoned work, or permission to discard orchestration context. Harness text such as “stopped by the user” is transport metadata, not owner-authored intent, unless a genuine user message explicitly cancels the task. Before any agent can stop or be replaced, persist its complete ownership ledger: every assigned task, active child/process/conversation, WIP path/ref, last receipt, blocker, and next action. Replacement worker MUST reconstruct that ledger from transcript, task registry, plans, artifacts, and prior output before claiming new work. Preserve tasks as IDLE/pending when no worker runs; NEVER mark cancelled or redo from scratch solely because a session died. Main coordinator owns continuity and MUST immediately reassign all orphaned lanes without losing prior work.

- Owner correction 2026-08-11: main session is the ONLY orchestrator. Subagents are bounded workers, NEVER orchestrators. Subagents MUST NOT invoke `cdx`, Codex, ask-gpt, Factory, Workflow, Agent, cursor, or any other model/offload/dispatch mechanism; MUST NOT spawn or supervise child workers; MUST NOT reassign tasks. Main thread alone decomposes, dispatches, reviews receipts, and routes follow-up work. A subagent receives one pinned task, executes it directly with local deterministic tools, reports evidence, then stops/resumes only when main assigns more. Any subagent that discovers broader work reports it to main without dispatching it.

## Work topology

Maximum active lanes:

1. **Delivery:** 2–3 customer-visible items through proven SSH offload.
2. **Infrastructure:** 1 k3s vertical-slice worker.
3. **Coordination:** 1 lightweight controller maintaining receipts and routing; no implementation.

No explorers, panels, duplicate implementers, or phase-wide review batches.

## Per-item pipeline

```text
capture plan → claim WIP → execute remotely → install/deploy → verify → receipt → next item
```

NEVER batch all implementation, review, landing, or deployment into global phases.

## Capability routing

```text
k3s proven for this job class? yes → k3s
otherwise SSH fleet healthy? yes → SSH
otherwise → queue + exact host/step/reason
```

No laptop-heavy fallback.

## Synchronous checks

Block only for:

- local-heavy fallback;
- destructive Git action or WIP loss;
- secret exposure;
- untrusted result application;
- directly relevant focused test failure;
- irreversible external action lacking authorization.

Do not block delivery on broad suites, generalized review, documentation reconciliation, transcript recovery, unrelated pre-existing failures, branch archaeology, or infrastructure convergence.

## k3s migration order

1. Stateless test job.
2. Build job.
3. Browser job.
4. Factory coding job.
5. Privileged/specialized jobs.

Route each class permanently after one real acceptance receipt. Retain SSH for unmigrated classes.

## Acceptance receipt

Every active item records:

```text
Task:
Backend:
Worker:
WIP path/ref:
Installed revision:
Current state:
Last authoritative receipt:
Blocker:
Next executable action:
```

Worker MUST update receipt before stop, compaction, or handoff.

## Launch sequence after approval

1. Keep SSH offload as production plane.
2. Select 2–3 highest-value customer-visible items with preserved WIP.
3. Resume exactly one k3s worker on stateless-job vertical slice.
4. Route heavy payloads remotely; cap local control work.
5. Ship each item immediately after its focused proof.
6. Update plan receipts and `docs/plans/INDEX.md` after every transition.

## Standing authorization

Owner approved this operating model and has an active goal. Keep it ACTIVE while the main session continuously routes work. Individual reversible delivery steps require no repeated approval. Never reinterpret reorganization, compaction, a background wait, or a loop turn as permission to stop.