paircode 0.7.1__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,37 @@
1
+ # Python
2
+ __pycache__/
3
+ *.py[cod]
4
+ *$py.class
5
+ *.egg-info/
6
+ *.egg
7
+ .pytest_cache/
8
+ .tox/
9
+ .coverage
10
+ .coverage.*
11
+ htmlcov/
12
+
13
+ # Build artifacts
14
+ build/
15
+ dist/
16
+ wheels/
17
+ *.whl
18
+
19
+ # Virtualenvs
20
+ .venv/
21
+ venv/
22
+ env/
23
+ ENV/
24
+
25
+ # IDE
26
+ .idea/
27
+ .vscode/
28
+ *.swp
29
+ *.swo
30
+
31
+ # macOS
32
+ .DS_Store
33
+
34
+ # Local test scratch
35
+ /tmp/
36
+ scratch/
37
+ dist/
paircode-0.7.1/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 Travis Somerville
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
@@ -0,0 +1,146 @@
1
+ Metadata-Version: 2.4
2
+ Name: paircode
3
+ Version: 0.7.1
4
+ Summary: Adversarial journey framework — orchestrate multiple LLM peers through research, plan, and execute stages with file-trace peer review.
5
+ Project-URL: Homepage, https://github.com/tsomerville2/paircode
6
+ Project-URL: Repository, https://github.com/tsomerville2/paircode
7
+ Project-URL: Issues, https://github.com/tsomerville2/paircode/issues
8
+ Author-email: Travis Somerville <travis.somerville@gmail.com>
9
+ License: MIT
10
+ License-File: LICENSE
11
+ Keywords: agents,claude,codex,gemini,llm,multi-agent,ollama,orchestration,peer-review
12
+ Classifier: Development Status :: 2 - Pre-Alpha
13
+ Classifier: Intended Audience :: Developers
14
+ Classifier: License :: OSI Approved :: MIT License
15
+ Classifier: Operating System :: OS Independent
16
+ Classifier: Programming Language :: Python :: 3
17
+ Classifier: Programming Language :: Python :: 3.10
18
+ Classifier: Programming Language :: Python :: 3.11
19
+ Classifier: Programming Language :: Python :: 3.12
20
+ Classifier: Programming Language :: Python :: 3.13
21
+ Classifier: Topic :: Software Development
22
+ Requires-Python: >=3.10
23
+ Requires-Dist: click>=8.1
24
+ Requires-Dist: pyyaml>=6.0
25
+ Requires-Dist: rich>=13.0
26
+ Description-Content-Type: text/markdown
27
+
28
+ # paircode
29
+
30
+ **Multi-LLM peer review for your code, with file-traces on disk.** One primary LLM (alpha) + any number of peer LLMs (Codex, Gemini, Ollama, …) running independent research, plans, and code, with structured cross-review rounds stored entirely as Markdown on disk.
31
+
32
+ > Born from 31 iterations of dual-LLM silent-agreement hunting on a real ML project. See `diary/001-step-a-architecture.md` for the full design rationale.
33
+
34
+ ## Install
35
+
36
+ ```bash
37
+ pipx install paircode # or: pip install --user paircode
38
+ paircode install # registers /paircode in Claude / Codex / Gemini
39
+ ```
40
+
41
+ Then open Claude Code, Codex, or Gemini and you'll see `/paircode` available globally.
42
+
43
+ ## Use it — three entry points
44
+
45
+ ### 1. From Claude Code (or any supported LLM) as a slash command
46
+
47
+ Inside a Claude Code session:
48
+
49
+ ```
50
+ /paircode drive "build a KISS PHQ-9 depression risk engine"
51
+ ```
52
+
53
+ Claude relays that to the CLI. paircode opens a focus, runs research → plan → execute with peer-reviewed rounds, writes everything to `.paircode/` as Markdown.
54
+
55
+ ### 2. From the shell directly
56
+
57
+ ```bash
58
+ paircode init # bootstrap .paircode/ in cwd
59
+ paircode handshake --write # detect CLIs + write peer roster
60
+ paircode drive "refactor the auth middleware" # full loop
61
+ paircode status # see where you are
62
+ ```
63
+
64
+ ### 3. Piece by piece
65
+
66
+ ```bash
67
+ paircode focus "try GitHub Actions migration"
68
+ paircode stage research --rounds 2 # cold v1 + one review/revise round
69
+ paircode seal research # mark research FINAL
70
+ paircode stage plan --rounds 3
71
+ paircode seal plan
72
+ paircode stage execute
73
+ paircode seal execute
74
+ ```
75
+
76
+ ## What ends up on disk
77
+
78
+ ```
79
+ your-project/
80
+ .paircode/
81
+ JOURNEY.md # fleet log (auto-updated)
82
+ peers.yaml # who's on the team
83
+ peers/
84
+ peer-a-codex/ # peer's profile (and code if full-fork mode)
85
+ focus-01-<slug>/
86
+ FOCUS.md # this focus's goal, roster override, gate config
87
+ research/
88
+ alpha-v1.md ... alpha-vN.md
89
+ peer-a-codex-v1.md ...
90
+ reviews/round-01-peer-a-codex-critiques-alpha.md
91
+ alpha-FINAL.md # sealed exit artifact
92
+ peer-a-codex-FINAL.md
93
+ plan/
94
+ (same shape)
95
+ execute/
96
+ (same shape)
97
+ focus-02-<slug>/
98
+ ...
99
+ ```
100
+
101
+ Every LLM's every thought lands as a Markdown file. That's how heterogeneous LLM tools communicate reliably across vendors, sessions, and days.
102
+
103
+ ## Three peer modes
104
+
105
+ | Mode | What the peer does | When to use |
106
+ |---|---|---|
107
+ | **full-fork** | Writes its own cold codebase + markdown artifacts | Silent-agreement hunting, safety-critical code |
108
+ | **pair-code** | Contributes directly to alpha's codebase via patches + reviews | Feature work, regular dev |
109
+ | **opinion-only** | Reads alpha's work, writes reviews, never touches code | Budget peers, quick sanity checks |
110
+
111
+ Configured per peer in `.paircode/peers.yaml`.
112
+
113
+ ## Model compatibility
114
+
115
+ | CLI | Slash command | Subprocess driver | Status |
116
+ |---|---|---|---|
117
+ | Claude Code (`claude`) | ✓ `/paircode` via `~/.claude/commands/paircode.md` | ✓ `claude -p <prompt>` | stable |
118
+ | Codex (`codex`) | ✓ context rule via `~/.codex/rules/paircode.rules` | ✓ `codex exec <prompt>` | stable |
119
+ | Gemini CLI (`gemini`) | ✓ reference file at `~/.gemini/paircode.md` | ✓ `gemini -p <prompt>` | stable |
120
+ | Ollama (`ollama`) | — (local models, no slash-cmd primitive) | ✓ `ollama run <model> <prompt>` | stable |
121
+ | Aider / others | — | best-effort, PRs welcome | planned |
122
+
123
+ ## Commands
124
+
125
+ ```
126
+ paircode --help full command list
127
+ paircode install register /paircode in all detected LLM CLIs
128
+ paircode uninstall remove /paircode from LLM CLIs (idempotent)
129
+ paircode handshake detect CLIs, propose peer roster
130
+ paircode handshake --write save roster to .paircode/peers.yaml
131
+ paircode init bootstrap .paircode/ in cwd
132
+ paircode status summarize current state
133
+ paircode focus <name> open a new focus
134
+ paircode focus list existing focuses
135
+ paircode stage <name> run one stage N rounds on active focus
136
+ paircode seal <stage> seal stage — copy each peer's latest vN to {peer}-FINAL.md
137
+ paircode drive <topic> full loop: research → plan → execute
138
+ ```
139
+
140
+ ## Why this exists
141
+
142
+ See [`diary/001-step-a-architecture.md`](diary/001-step-a-architecture.md) for the full backstory. The short version: running two LLMs adversarially surfaces silent-agreement bug classes that neither engine alone can catch, because cross-engine agreement is not the same as correctness when both share the same blind spot.
143
+
144
+ ## License
145
+
146
+ MIT. See [LICENSE](LICENSE).
@@ -0,0 +1,119 @@
1
+ # paircode
2
+
3
+ **Multi-LLM peer review for your code, with file-traces on disk.** One primary LLM (alpha) + any number of peer LLMs (Codex, Gemini, Ollama, …) running independent research, plans, and code, with structured cross-review rounds stored entirely as Markdown on disk.
4
+
5
+ > Born from 31 iterations of dual-LLM silent-agreement hunting on a real ML project. See `diary/001-step-a-architecture.md` for the full design rationale.
6
+
7
+ ## Install
8
+
9
+ ```bash
10
+ pipx install paircode # or: pip install --user paircode
11
+ paircode install # registers /paircode in Claude / Codex / Gemini
12
+ ```
13
+
14
+ Then open Claude Code, Codex, or Gemini and you'll see `/paircode` available globally.
15
+
16
+ ## Use it — three entry points
17
+
18
+ ### 1. From Claude Code (or any supported LLM) as a slash command
19
+
20
+ Inside a Claude Code session:
21
+
22
+ ```
23
+ /paircode drive "build a KISS PHQ-9 depression risk engine"
24
+ ```
25
+
26
+ Claude relays that to the CLI. paircode opens a focus, runs research → plan → execute with peer-reviewed rounds, writes everything to `.paircode/` as Markdown.
27
+
28
+ ### 2. From the shell directly
29
+
30
+ ```bash
31
+ paircode init # bootstrap .paircode/ in cwd
32
+ paircode handshake --write # detect CLIs + write peer roster
33
+ paircode drive "refactor the auth middleware" # full loop
34
+ paircode status # see where you are
35
+ ```
36
+
37
+ ### 3. Piece by piece
38
+
39
+ ```bash
40
+ paircode focus "try GitHub Actions migration"
41
+ paircode stage research --rounds 2 # cold v1 + one review/revise round
42
+ paircode seal research # mark research FINAL
43
+ paircode stage plan --rounds 3
44
+ paircode seal plan
45
+ paircode stage execute
46
+ paircode seal execute
47
+ ```
48
+
49
+ ## What ends up on disk
50
+
51
+ ```
52
+ your-project/
53
+ .paircode/
54
+ JOURNEY.md # fleet log (auto-updated)
55
+ peers.yaml # who's on the team
56
+ peers/
57
+ peer-a-codex/ # peer's profile (and code if full-fork mode)
58
+ focus-01-<slug>/
59
+ FOCUS.md # this focus's goal, roster override, gate config
60
+ research/
61
+ alpha-v1.md ... alpha-vN.md
62
+ peer-a-codex-v1.md ...
63
+ reviews/round-01-peer-a-codex-critiques-alpha.md
64
+ alpha-FINAL.md # sealed exit artifact
65
+ peer-a-codex-FINAL.md
66
+ plan/
67
+ (same shape)
68
+ execute/
69
+ (same shape)
70
+ focus-02-<slug>/
71
+ ...
72
+ ```
73
+
74
+ Every LLM's every thought lands as a Markdown file. That's how heterogeneous LLM tools communicate reliably across vendors, sessions, and days.
75
+
76
+ ## Three peer modes
77
+
78
+ | Mode | What the peer does | When to use |
79
+ |---|---|---|
80
+ | **full-fork** | Writes its own cold codebase + markdown artifacts | Silent-agreement hunting, safety-critical code |
81
+ | **pair-code** | Contributes directly to alpha's codebase via patches + reviews | Feature work, regular dev |
82
+ | **opinion-only** | Reads alpha's work, writes reviews, never touches code | Budget peers, quick sanity checks |
83
+
84
+ Configured per peer in `.paircode/peers.yaml`.
85
+
86
+ ## Model compatibility
87
+
88
+ | CLI | Slash command | Subprocess driver | Status |
89
+ |---|---|---|---|
90
+ | Claude Code (`claude`) | ✓ `/paircode` via `~/.claude/commands/paircode.md` | ✓ `claude -p <prompt>` | stable |
91
+ | Codex (`codex`) | ✓ context rule via `~/.codex/rules/paircode.rules` | ✓ `codex exec <prompt>` | stable |
92
+ | Gemini CLI (`gemini`) | ✓ reference file at `~/.gemini/paircode.md` | ✓ `gemini -p <prompt>` | stable |
93
+ | Ollama (`ollama`) | — (local models, no slash-cmd primitive) | ✓ `ollama run <model> <prompt>` | stable |
94
+ | Aider / others | — | best-effort, PRs welcome | planned |
95
+
96
+ ## Commands
97
+
98
+ ```
99
+ paircode --help full command list
100
+ paircode install register /paircode in all detected LLM CLIs
101
+ paircode uninstall remove /paircode from LLM CLIs (idempotent)
102
+ paircode handshake detect CLIs, propose peer roster
103
+ paircode handshake --write save roster to .paircode/peers.yaml
104
+ paircode init bootstrap .paircode/ in cwd
105
+ paircode status summarize current state
106
+ paircode focus <name> open a new focus
107
+ paircode focus list existing focuses
108
+ paircode stage <name> run one stage N rounds on active focus
109
+ paircode seal <stage> seal stage — copy each peer's latest vN to {peer}-FINAL.md
110
+ paircode drive <topic> full loop: research → plan → execute
111
+ ```
112
+
113
+ ## Why this exists
114
+
115
+ See [`diary/001-step-a-architecture.md`](diary/001-step-a-architecture.md) for the full backstory. The short version: running two LLMs adversarially surfaces silent-agreement bug classes that neither engine alone can catch, because cross-engine agreement is not the same as correctness when both share the same blind spot.
116
+
117
+ ## License
118
+
119
+ MIT. See [LICENSE](LICENSE).
@@ -0,0 +1,334 @@
1
+ # Diary 001 — Step-A architecture, complete and locked
2
+
3
+ **Stardate:** 2026-04-18
4
+ **Milestone:** step-A (understand) complete. Step-B (plan schemas + command lifecycle) next. Step-C (ship to pypi + as slash command) after.
5
+ **Sibling project that birthed this:** `~/clients/syra/mlmodel/` at tag `milestone-0.1` — 31 iterations of `/peerkickoff` between Claude and Codex on a KISS mental-health ML pipeline surfaced the meta-pattern this project generalizes.
6
+
7
+ ---
8
+
9
+ ## TL;DR — what paircode is
10
+
11
+ A framework for steering a software project through any number of **focuses** (goals), where each focus runs a **research → plan → execute** cycle, and every stage of every cycle is **peer-reviewed** by one "alpha" codebase plus N peer LLMs producing file-traces on disk. The captain (human architect) sets scope and taste; the LLMs author content.
12
+
13
+ Three layers, three peer modes, one hidden folder, files on disk always.
14
+
15
+ ---
16
+
17
+ ## Provenance — why this exists
18
+
19
+ Between 2026-04-17 and 2026-04-18, two LLMs (Claude Opus 4.7 and Codex) were run adversarially on a shared ML project:
20
+
21
+ - Each produced **independent cold research** on mental-health risk stratification.
22
+ - Each produced **5 iterated versions of a plan** (`plan1 → plan1.5`), cross-reviewing via human-mediated copy-paste.
23
+ - Human called bullshit, forced a **KISS reduction** (scope-cut gate).
24
+ - Each executed a **full-fork cold implementation** (`LABS/claude-kiss/` + `LABS/codex-kiss/`).
25
+ - `/peerkickoff` command orchestrated **31 rounds of cross-review**, surfacing ~30 silent-data-corruption defect classes that neither engine alone could catch (because cross-engine *agreement* is not the same as correctness when both share the same blind spot).
26
+
27
+ Final state at `milestone-0.1`:
28
+ - claude-kiss pytest: 74 green
29
+ - codex-kiss pytest: 66 green
30
+ - Cross-engine tier-agreement on 258/258 rows (silent-agreement-on-valid-data baseline)
31
+ - Real NHANES 2011-2018 ML baseline: AUC 0.67 SDOH-only, bit-identical MD5 reproducibility (11+ consecutive matches)
32
+ - ~30 input-contract guards landed (Excel serials, NaN/bytes/bidi/zero-width patient IDs, Arrow/Period/timedelta/tz-aware dates, fractional scores, empty-post-strip IDs, ...)
33
+
34
+ Two conclusions from that run:
35
+ 1. **The *pattern* is generalizable.** Research, plan, and execute are three instances of the same peer-review engine — only the artifact type differs.
36
+ 2. **The *specific implementation* (hardcoded paths, ML-specific prompts, manual copy-paste at early stages) was scaffolding**, not the thing itself. paircode is the extracted framework.
37
+
38
+ ---
39
+
40
+ ## The meta-pattern — named
41
+
42
+ **Adversarial journey architecture**, a.k.a. **dual-lane stage-gate with file-trace peer review and human taste-gates.**
43
+
44
+ It's a variant of the Phase-Gate model from 1980s product development, run at LLM speed with N parallel LLM lanes, each stage producing file-traces that the next stage consumes.
45
+
46
+ ### Three layers
47
+
48
+ ```
49
+ ┌────────────────────────────────────────────────────────┐
50
+ │ JOURNEY (captain's layer) │
51
+ │ FOCUS-1 → FOCUS-2 → FOCUS-3 → ... │
52
+ │ (ML engine → claims expansion → demo site → app) │
53
+ └──────────┬─────────────────────────────────────────────┘
54
+ │ each FOCUS contains ↓
55
+ ┌──────────▼─────────────────────────────────────────────┐
56
+ │ WORKFLOW (per-focus lifecycle) │
57
+ │ Research → Plan → Execute │
58
+ │ (each stage peer-reviewed, each stage optional) │
59
+ └──────────┬─────────────────────────────────────────────┘
60
+ │ each STAGE uses ↓
61
+ ┌──────────▼─────────────────────────────────────────────┐
62
+ │ PEER-REVIEW ENGINE (universal primitive) │
63
+ │ Alpha cold → peers cold → │
64
+ │ N rounds of cross-review with file traces → │
65
+ │ optional human gate → FINAL per-peer │
66
+ └────────────────────────────────────────────────────────┘
67
+ ```
68
+
69
+ The inner engine is one thing. Stage + focus + journey are all just different scales of invoking it.
70
+
71
+ ---
72
+
73
+ ## The universal peer-review engine
74
+
75
+ Same shape at every stage. Only the prompt and the artifact type differ:
76
+
77
+ | Stage | Alpha writes | Peers write | Exit artifact |
78
+ |---|---|---|---|
79
+ | Research | `alpha-v{N}.md` | `peer-a-v{N}.md` ... | `alpha-FINAL.md` + `peer-a-FINAL.md` ... |
80
+ | Plan | `alpha-v{N}.md` | `peer-a-v{N}.md` ... | Same naming |
81
+ | Execute | Code in project root | Code in `.paircode/peers/peer-a-codex/` (if full-fork) + review `.md` files | `iter-NNN.md` orchestration logs + `alpha-FINAL.md` summary per peer |
82
+
83
+ ### Peer-review mechanics (identical at every stage)
84
+
85
+ 1. **Round 0** — Alpha and all peers produce **cold, independent** versions. No one sees anyone else's output. This independence is sacred — it's what prevents anchoring.
86
+ 2. **Round N (N ≥ 1)** — Each peer reads alpha's latest, writes a review file (`reviews/round-N-peer-X-critiques-alpha.md`). Alpha reads ALL peer reviews, incorporates, publishes `alpha-v{N+1}.md`. Peers optionally revise their own cold version to `peer-X-v{N+1}.md` based on what they now know.
87
+ 3. **Gate check** — did human intervene (`HUMAN-GATE-*.md` file appeared)? Did we hit `MAX_ROUNDS`? Did we hit a convergence criterion (e.g., 3 consecutive rounds of no new findings)?
88
+ 4. **Exit** — each peer writes their FINAL; alpha writes its FINAL *after* reading peers' FINALs (so alpha's final says "having seen everyone, here's my sealed position"); stage is closed.
89
+
90
+ ---
91
+
92
+ ## N-team star topology
93
+
94
+ ```
95
+ Alpha (the project itself)
96
+ / | \ \
97
+ / | \ \
98
+ peer-a peer-b peer-c peer-d ...
99
+ (Codex) (Gemini) (Ollama) (N teams)
100
+ ```
101
+
102
+ **Key rule:** Peers review *alpha only*. Peers do NOT peer-review each other. This keeps review edges at O(N), not O(N²).
103
+
104
+ **Knowledge seepage:** Ideas from peer-c reach peer-a not via direct peer-c↔peer-a edge, but via alpha absorbing peer-c's review in round N, which peer-a then sees when it reads alpha-v{N+1}. Alpha is the gossip hub.
105
+
106
+ **Why Alpha is the project, not a peer:** alpha is implicit — it's the project directory itself, the captain's primary working codebase. No `team-a/` or `lane-a/` subfolder. When you `cd ~/myproject`, you are in alpha's workspace.
107
+
108
+ ---
109
+
110
+ ## Three peer modes
111
+
112
+ | Mode | Peer writes | Peer code location | Cost | Use case |
113
+ |---|---|---|---|---|
114
+ | **full-fork** | Own cold codebase + `.md` artifacts | `.paircode/peers/peer-N-{cli}/src/` etc. | High — peer does full implementation work | Silent-agreement hunting, safety-critical code |
115
+ | **pair-code** | Patches / proposed diffs / reviews as `.md` | No code dir — peer contributes to alpha's codebase directly | Medium | Feature work, frontend, general dev |
116
+ | **opinion-only** | Review / opinion `.md` files only | No code at all, just `.md` under focus folders | Low — cheapest mode | Budget peers, free-tier models, quick sanity checks |
117
+
118
+ **Every peer gets a folder regardless of mode.** Opinion-only peers have a mostly-empty `.paircode/peers/peer-b-gemini/` with just a `profile.md` from the handshake. Full-fork peers have a complete working codebase there. The principle is: **every LLM's every thought gets written to disk**, because that's how heterogeneous LLM tools communicate reliably across vendors, sessions, days.
119
+
120
+ ---
121
+
122
+ ## File-trace schema
123
+
124
+ ```
125
+ ~/clients/syra/mlproject/ ← project root = alpha's code
126
+ src/, tests/, README.md, etc. ← alpha's actual codebase (untouched by paircode)
127
+
128
+ .paircode/ ← EVERYTHING paircode-related, hidden
129
+ JOURNEY.md ← fleet log: active focus, roster, focus transitions
130
+ peers.yaml ← single registry file declaring all peers + their configs
131
+
132
+ peers/
133
+ peer-a-codex/ ← peer-a's working dir
134
+ profile.md ← handshake result, capabilities, quota
135
+ src/, tests/, ... ← peer-a's cold code (full-fork mode only)
136
+ peer-b-gemini/ ← opinion-only peer
137
+ profile.md ← handshake result
138
+ peer-c-ollama/
139
+ profile.md
140
+ src/, tests/, ... ← peer-c's cold code (full-fork)
141
+
142
+ focus-01-ml-engine/
143
+ FOCUS.md ← this focus's prompt, roster override, gate config
144
+ research/
145
+ alpha-v1.md ... alpha-vN.md
146
+ peer-a-v1.md ... peer-a-vN.md
147
+ peer-b-v1.md ... peer-b-vN.md
148
+ reviews/
149
+ round-01-peer-a-critiques-alpha.md
150
+ round-01-peer-b-critiques-alpha.md
151
+ round-02-...
152
+ alpha-FINAL.md ← flat, not in a FINAL/ subfolder
153
+ peer-a-FINAL.md
154
+ peer-b-FINAL.md
155
+ plan/
156
+ (same shape: vN + reviews + FINAL per peer)
157
+ execute/
158
+ iter-001.md ← what happened round 1 (review summaries, fixes landed)
159
+ iter-002.md
160
+ ...
161
+ iter-031.md
162
+ HUMAN-GATE-resting-spot.md ← gate marker when captain paused
163
+ alpha-FINAL.md ← executive summary of this focus's execute stage
164
+ peer-a-FINAL.md
165
+
166
+ focus-02-clinical-data/
167
+ FOCUS.md
168
+ research/ ... ← new `.md` artifacts; alpha's src/ and peer-a's .paircode/peers/peer-a-codex/src/ keep evolving in-place
169
+ plan/ ...
170
+ execute/
171
+ iter-001.md ← counter resets per focus
172
+ ...
173
+ ```
174
+
175
+ ### Key structural principles
176
+
177
+ 1. **Alpha's code NEVER moves into `.paircode/`.** Alpha = the project, project root is sacred.
178
+ 2. **Full-fork peers' code lives inside `.paircode/peers/peer-N-{cli}/`** (visible ONLY when you `cd .paircode/`).
179
+ 3. **Codebases persist across focuses.** Focus-02 doesn't clone focus-01's code — it continues from where focus-01 left alpha's src/ and peer-a's fork.
180
+ 4. **Each focus contains only `.md` orchestration artifacts** — research/plan/execute stages produce text files, not code.
181
+ 5. **FINAL files are flat**, suffixed `-FINAL.md`, not in a subfolder.
182
+ 6. **Iteration counter resets per focus.** `focus-01/execute/iter-031.md` then `focus-02/execute/iter-001.md`. JOURNEY.md aggregates cumulative stats.
183
+ 7. **No bubble-up to project root.** FINAL `.md` files stay inside `.paircode/`. The captain is notified verbally by the team-lead agent (the orchestrating Claude), e.g., *"FINAL for focus-02/plan completed at `.paircode/focus-02-*/plan/alpha-FINAL.md`, it says: …"* If later we want FINALs at project root, that's an additive choice, not a default.
184
+
185
+ ---
186
+
187
+ ## Naming — locked
188
+
189
+ | Concept | Name | Why |
190
+ |---|---|---|
191
+ | Framework / pypi package | `paircode` | Available on pypi; captures collaboration framing; works for all three peer modes |
192
+ | Slash command / CLI | `paircode` (and `/paircode` as Claude Code slash command) | Matches pypi name |
193
+ | Hidden orchestration folder | `.paircode/` | Dotted/hidden, matches `.git/`, `.venv/`, `.claude/` precedent |
194
+ | Primary developer's identity | **alpha** (implicit — is the project itself) | No subfolder; alpha = project root |
195
+ | Additional LLMs | **peer-a, peer-b, peer-c, ...** | Star topology spokes; named by order, suffixed with CLI identity (e.g., `peer-a-codex`) |
196
+ | Goal / chapter | **focus** (numbered `focus-01-*`) | Captain's steerable unit; each has its own research/plan/execute cycle |
197
+ | Work phase inside a focus | **stage** (research / plan / execute) | Universal peer-review engine invoked at each |
198
+ | Overall project timeline | **journey** | "Software journey" — captain's language; JOURNEY.md is the top-level log |
199
+
200
+ ---
201
+
202
+ ## Human gate semantics
203
+
204
+ Gates are **optional per stage**. Two declaration mechanisms:
205
+
206
+ ### In `FOCUS.md` (durable)
207
+ ```yaml
208
+ human_gate:
209
+ mode: auto # or: manual_between_stages, manual_every_N_rounds, manual_always
210
+ max_rounds: 20
211
+ convergence: 3_rounds_no_new_findings
212
+ ```
213
+
214
+ ### In the invoking prompt (transient)
215
+ > `paircode stage research --autopilot "I'm heading to bed, iterate until convergence or 20 rounds, then stop and wait"`
216
+
217
+ **File beats prompt** on conflict (file is durable truth; prompt is a one-off override).
218
+
219
+ ### Auto mode
220
+
221
+ When `mode: auto` is set, the engine runs until one of:
222
+ - `max_rounds` reached
223
+ - Convergence criterion met
224
+ - A peer goes persistently offline (quota exhausted multiple rounds)
225
+ - Human writes a `HUMAN-GATE-*.md` file into the stage dir (takes effect next round)
226
+
227
+ **The captain is the final steering wheel.** Auto mode is a *convenience* for overnight / away runs, not a replacement for captain judgment.
228
+
229
+ ---
230
+
231
+ ## Quota / rate-limit graceful degradation
232
+
233
+ Each peer in `peers.yaml` has:
234
+ ```yaml
235
+ peers:
236
+ - id: peer-a-codex
237
+ cli: codex
238
+ model: gpt-5-codex
239
+ mode: full-fork
240
+ priority: high
241
+ daily_budget_usd: 20
242
+ - id: peer-b-gemini
243
+ cli: gemini
244
+ model: gemini-2.5-flash
245
+ mode: opinion-only
246
+ priority: low
247
+ daily_budget_requests: 1500 # free-tier daily cap
248
+ ```
249
+
250
+ ### Policy
251
+
252
+ - Peer hits quota → that peer **sits out the rest of today's rounds**, rejoins at next daily reset.
253
+ - Round proceeds without them — **never halt the fleet for one peer's budget**.
254
+ - The iter-NNN.md log records "peer-b-gemini unavailable this round (quota exhausted)".
255
+ - Captain can override per-focus via `peers.yaml`: downgrade a paid peer to opinion-only when saving budget, or upgrade free-tier peer to pair-code when captain pays up.
256
+
257
+ ---
258
+
259
+ ## Auto-detection handshake (first-run behavior)
260
+
261
+ `paircode handshake` (also invoked implicitly on first `paircode` in a fresh project):
262
+
263
+ 1. Scan PATH: `claude`, `codex`, `gemini`, `ollama`, `aider`, etc.
264
+ 2. Scan env vars: `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `GEMINI_API_KEY`, `OLLAMA_HOST`, ...
265
+ 3. Ping each with a cheap "say hi, what model are you?" probe. Write `profile.md` per peer.
266
+ 4. Propose roster:
267
+ > "Detected: Claude Opus 4.7 (primary, paid), Codex CLI ($20 tier), Gemini-flash (free, rate-limited), Ollama kimi-2.5 (local unlimited). Suggest: alpha = Claude Opus (you), peer-a = Codex (full-fork), peer-b = Ollama (full-fork, unlimited), peer-c = Gemini (opinion-only, free-tier). Edit `peers.yaml` or accept?"
268
+ 5. Write `peers.yaml`, `JOURNEY.md`.
269
+
270
+ ---
271
+
272
+ ## Reporting back to captain — the no-bubble-up principle
273
+
274
+ When a stage or focus completes, **the team-lead agent (the orchestrating Claude) reports textually**, not by moving files to project root. Example:
275
+
276
+ > "focus-02 (claims-data expansion) plan stage complete after 7 rounds. FINALs written:
277
+ > - `.paircode/focus-02-claims-data/plan/alpha-FINAL.md` — alpha's synthesis, says: '...'
278
+ > - `.paircode/focus-02-claims-data/plan/peer-a-FINAL.md` — codex's position, flags tension on ...
279
+ > - `.paircode/focus-02-claims-data/plan/peer-b-FINAL.md` — gemini's opinion, concurs on ...
280
+ >
281
+ > Ready to advance to execute stage. Shall I proceed, or do you want to review FINALs first?"
282
+
283
+ The captain reads the text summary, opens any FINAL they want to inspect, and says go/pause/revise. The conversation is the notification channel.
284
+
285
+ ---
286
+
287
+ ## What's in step A (this diary) vs. what's in step B and C
288
+
289
+ ### Step A — understand (complete as of this diary) ✓
290
+ - Meta-pattern recognized and named
291
+ - Three layers (Journey / Focus / Stage) defined
292
+ - Universal peer-review engine shape locked
293
+ - N-peer star topology with alpha = project
294
+ - Three peer modes specified (full-fork / pair-code / opinion-only)
295
+ - File-trace schema finalized
296
+ - Naming locked (`paircode`, `.paircode/`, `peer-a/b/c`, `alpha = project`)
297
+ - Human gate semantics defined
298
+ - Quota degradation policy defined
299
+ - Reporting-back via conversation, not file bubble-up
300
+
301
+ ### Step B — plan (next)
302
+ - Schemas for: `JOURNEY.md`, `FOCUS.md`, `peers.yaml`, `profile.md`, review round `.md` files, iteration `.md` files, FINAL `.md` files
303
+ - Command lifecycle for: first-run bootstrap, handshake, focus open, stage run, status, install-claude, install-codex
304
+ - Convergence detection algorithm
305
+ - MCP / toolnudger self-registration design (maybe — undecided)
306
+ - Test strategy: what's integration-tested vs. unit-tested
307
+
308
+ ### Step C — ship
309
+ - Implementation of the step-B plan
310
+ - Pypi release (paircode 0.1.0 → public pypi)
311
+ - Claude Code slash-command installer (`paircode install-claude`)
312
+ - Codex CLI peer-invocation adapter (`paircode install-codex`)
313
+ - Real end-to-end test: run paircode on a fresh project, go through research → plan → execute for one focus, verify file-traces land correctly
314
+
315
+ ---
316
+
317
+ ## Things deliberately out of scope for step A
318
+
319
+ - **Exact prompt templates** for research / plan / execute stages — these will be customizable per project via `FOCUS.md`, not baked into paircode.
320
+ - **How peer code gets git-tracked** — could be nested repo, subdir under main repo, or gitignored entirely; captain's call.
321
+ - **Ops concerns** — telemetry, error reporting, update mechanism, backward compatibility — all deferred.
322
+ - **Bubble-up of FINALs to project root** — explicitly deferred. Captain will tell us if they ever want it.
323
+ - **Visual/TUI interface** — CLI + file-traces is enough for v0; maybe `paircode status --rich` later.
324
+ - **Multi-project / workspace mode** — focus on single-project case first.
325
+
326
+ ---
327
+
328
+ ## One principle above all
329
+
330
+ **Files on disk, always.** Every LLM output, every review, every version, every iteration log — written to `.md` or `.yaml`, readable by any tool, survivable across sessions and LLM vendor outages. If an idea didn't land on disk, it didn't happen. This is the spine of the whole framework.
331
+
332
+ ---
333
+
334
+ *End of diary 001. Step-A architecture complete and locked. Step-B planning begins on captain's command.*