Fairway In Practice designed
This page is the practical reading path for how GPUaaS actually uses Fairway. The core rule is simple:
Fairway task = durable work unit.
Provider session = replaceable execution attachment.
Execution Surfaces
| Surface | Use it for | Do not depend on it for |
|---|---|---|
| Desktop thread | review, screenshots, browser checks, architecture decisions, control-room coordination | unattended deploy, repeated CI polling, long kubectl loops, git commit boundaries |
| tmux / SSH / Codex CLI | trusted execution attachment for tests, deploy, CI watch, branch closeout, repeated smoke loops | changing task authority outside Fairway |
| Fairway | source of truth for task state, evidence, review, handoff, and session lifecycle | implementation itself |
Standard Loop
What Must Be Recorded In Fairway
- current task owner and role;
- active provider session;
- evidence for commands that decide pass/fail;
- required review-domain outcomes;
- blocked reason plus exact follow-up when work stops;
- deploy/UAT handbacks when runtime state changes.
When To Use tmux Instead Of Desktop
Use a tmux or SSH execution lane when the task is already approved and the only remaining work is trusted execution:
- git staging/commit/push closeout;
- CI monitoring;
- deploy and rollout observation;
- repeated smoke/UAT reruns;
- Fairway reconciliation after long waits.
This is the normal workaround for Desktop sandbox boundaries such as
.git/index.lock write failures.
Why This Model Exists
The goal is to reduce coordination drift and token burn:
- chats are not the system of record;
- repetitive waits should move into utilities and monitors;
- review should happen at real risk boundaries, not every tiny slice;
- the team should step back when a loop is not producing new understanding.