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.
- paircode-0.7.1/.gitignore +37 -0
- paircode-0.7.1/LICENSE +21 -0
- paircode-0.7.1/PKG-INFO +146 -0
- paircode-0.7.1/README.md +119 -0
- paircode-0.7.1/diary/001-step-a-architecture.md +334 -0
- paircode-0.7.1/pyproject.toml +69 -0
- paircode-0.7.1/src/paircode/__init__.py +5 -0
- paircode-0.7.1/src/paircode/__main__.py +4 -0
- paircode-0.7.1/src/paircode/cli.py +419 -0
- paircode-0.7.1/src/paircode/detect.py +52 -0
- paircode-0.7.1/src/paircode/drive.py +385 -0
- paircode-0.7.1/src/paircode/gates.py +62 -0
- paircode-0.7.1/src/paircode/handshake.py +55 -0
- paircode-0.7.1/src/paircode/installer.py +161 -0
- paircode-0.7.1/src/paircode/journey.py +63 -0
- paircode-0.7.1/src/paircode/runner.py +114 -0
- paircode-0.7.1/src/paircode/seal.py +52 -0
- paircode-0.7.1/src/paircode/state.py +162 -0
- paircode-0.7.1/src/paircode/templates/FOCUS.md +35 -0
- paircode-0.7.1/src/paircode/templates/JOURNEY.md +21 -0
- paircode-0.7.1/src/paircode/templates/claude_slash_command.md +23 -0
- paircode-0.7.1/src/paircode/templates/codex_rules.md +13 -0
- paircode-0.7.1/src/paircode/templates/peers.yaml +20 -0
- paircode-0.7.1/tests/__init__.py +0 -0
- paircode-0.7.1/tests/test_drive.py +146 -0
- paircode-0.7.1/tests/test_gates.py +49 -0
- paircode-0.7.1/tests/test_seal.py +37 -0
- paircode-0.7.1/tests/test_smoke.py +84 -0
- paircode-0.7.1/tests/test_state.py +80 -0
|
@@ -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.
|
paircode-0.7.1/PKG-INFO
ADDED
|
@@ -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).
|
paircode-0.7.1/README.md
ADDED
|
@@ -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.*
|