archwall 把架构画全Every architecture, drawn in full

peerreview：两家厂商的 AI 一起审一个仓库，直到都说可以peerreview: two AI vendors review one repo until both say it's done

code-reviewagentscross-modelskillsgit

peerreview overview: you run /peerreview [repo], with optional flags --chat and --dry-run; 1 set up: a charter (private, temporary, from your docs), pick the peer (another vendor: Claude Code ↔ Codex), a review branch (baseline commit first); if the docs conflict or say nothing, stop and ask; 2 rounds until done: the HOST reviews, runs the gate and writes findings, the PEER co-edits files and never commits, behind a git guard and a round deadline, the HOST re-checks the real diff and reruns the gate, then commits the round, since the HOST owns git; 3 stop only when every check passes with no findings left, the PEER says CONVERGED to a read-only, neutral prompt, and at least 1 peer round ran, with no upper cap; a round with no progress stops and reports; NOT CONVERGED goes back for another round; 4 hand over: one squashed commit in a pull request on evolve/<slug>, a converged tag where the next review starts, and an honest report of each check, the peer tier and leftovers; never called perfect; lessons from a run go to /peerreview-evolve, which keeps or drops them

peerreview 让两家厂商的 AI 一起检查一个仓库。主方（HOST）负责审查，管 git。同伴（PEER）来自另一家，负责改文件。两边来回改，直到都同意仓库做到了它说的事。

章程。 每次先写下“完成”是什么意思，依据你的指令和仓库文档，放在临时目录，不进仓库。文档矛盾或没写，就停下问你。

The charter: in come your instruction and the repo's own docs; 1 where intent comes from, in order: your instruction now, an upstream source it names, PRD, plan or spec, then tests and docs; 2 the charter (PROBLEM.md): problem, scope and non-goals, acceptance checks that are each testable, the verification gate of commands run every round, and residuals, the known gaps out of scope; 3 check the sources: if they conflict or nothing is written, stop and ask you; if they agree, go on with no confirmation stop; the code is evidence, never intent, since checks taken from the code would be circular; 4 review plan: the repo type picks the lenses (e.g. cdd-prd, evidence-docs, code), a full run or only the changes since the last converged tag, and a round forecast shown to you but not a cap; the --dry-run flag shows the plan and stops here; the charter sits in a private temp folder, never in the repo, and is deleted when the run ends, whatever the outcome; a PROBLEM.md you wrote yourself is an input, never edited or deleted
章程：每次从你的文档重新写下“完成”的标准，放在仓库外面

同伴。 Claude Code 和 Codex CLI 互相审。另一个用不了才换 DeepSeek，报告里写明。

Picking the peer: select-peer.sh picks the PEER before the loop; 1 who is the HOST: Claude Code (Anthropic), the Codex CLI (OpenAI), or Pi or the DeepSeek Harness dsh (DeepSeek), read from the environment and the model in use; 2 tier 1, the other subscription: Claude Code on a Claude subscription, the Codex CLI on a ChatGPT subscription; a Claude Code HOST gets Codex, a Codex HOST gets Claude Code; 3 tier 2, only if tier 1 is out: dsh with deepseek-v4-pro for CDD repos, Pi with deepseek-flash for every other repo; named as the weaker tier in the report, and a DeepSeek HOST has tier 1 only; 4 each candidate is checked: CLI installed and signed in, no keys printed; a quota probe with one tiny prompt, only for the subscription peers, and a used-up peer means the next one; nobody left means stop, with no same-vendor stand-in; the PEER is never from the HOST's own vendor
选同伴：永远是另一家厂商，先第一档，用不了才降到第二档

一轮。 主方审查、跑检查，同伴修改，主方读真实的 diff、重跑检查、提交。

One round: in come the charter and the last committed state; 1 HOST reviews: sweep the charter, correctness and security first, re-sweep old defect kinds across every sibling, not one line, run the full gate, and write a prompt file with the whole charter and ranked findings; 2 PEER co-edits: through a driver script (claude-, codex-, pi- or dsh-round), with its own findings too, not a confirm-my-work pass, and minimal edits with no commit and no push; a 30 min deadline per round, set by an env var; 3 HOST re-checks: wait for the driver to exit because a mid-flight tree can't be trusted, read the real git diff and status rather than the PEER's report, rerun the gate and fact-check fixes, since a "fix" can be a regression; 4 commit the round as peerreview: round N with HOST and PEER as co-authors; worse than before means revert and tighter findings; no progress in a round stops the loop with a report; dashed arrow: next round; the HOST owns git and the decision to stop, the PEER only edits
一轮：主方审、同伴改、主方复查再提交

护栏。 每个同伴都有 git 防护和 30 分钟时限。裁决那轮不许改；dsh 挡不住，动过就判失败。

Guard rails: each driver script wraps its PEER CLI like this; 1 Claude Code as PEER: safe mode with no HOST CLAUDE.md, hooks or MCP, edit rounds with all tools and git guarded, the verdict round with Edit, Write and Bash switched off; 2 Codex CLI as PEER: edit rounds in a workspace-write sandbox, the verdict round in a fresh read-only sandbox, both behind the git guard; 3 Pi and dsh as PEER: Pi has no sandbox and its verdict gets read, grep, find and ls only; dsh has no tool allowlist, so its verdict fails if the repo moved; a moved repo is not reverted, the HOST looks at it first; 4 for every PEER: a git guard on PATH allows only read-only git in the repo, a round deadline of 1800 s by default, and only the HOST commits and pushes; the git guard catches mistakes, it is not a sandbox against a PEER set on getting around it
护栏：四种同伴 CLI 各自怎么被限制，只读裁决、git 防护、时限

何时停。 检查全过，且同伴在中立提问下回答 CONVERGED。至少一轮同伴，没有上限。没进展就停下。

When to stop: in comes the committed state after the last edit round; 1 all must hold: every acceptance check met with evidence, the full gate exits clean, no findings left with every lens swept, not sampled, and the tree clean, or left for manual commit; 2 then the verdict prompt: a read-only round with no edits allowed, neutral facts only, the raw gate output and no "all green", and reading is allowed, said in the first paragraph; a leading prompt invites false agreement; 3 the PEER answers CONVERGED, no substantive defects remain, or NOT CONVERGED with defects named, which means round N+1; at least 1 peer round, no upper cap; 4 other endings: no progress means stop and report, no peer reachable means stop with no stand-in, and never "perfect", only converged with leftovers listed; the HOST cannot declare convergence alone, the PEER has to say it
何时停：检查全过，并且同伴在中立提问下说 CONVERGED

落地。 各轮压成一个提交，开成拉取请求。打标签记下审过的提交，下次从这开始。~/projects 下的仓库不做任何 git 写入；--chat 参数在临时仓库里审一个想法。

Landing: in comes the repo you asked to review; 1 during the review: the review branch peerreview/<slug>, its own worktree if installed skills point into this repo, and round commits as evidence, not history; a baseline commit first, so each round's diff is its own; 2 land: squash to one commit on evolve/<slug>, check the subject first (type and a lowercase description), then push and open a PR; the base branch is never written; 3 after: a converged tag peerreview/converged/..., push the reviewed repo and fail loud if it can't, and the maintainer merges later with land-evolution.sh on an explicit go-ahead; 4 exceptions: a repo under ~/projects gets no git writes at all, the --chat flag uses a temp repo, answers in chat and deletes it, and a named open PR is reviewed on its own branch; the tag gives the next review a starting point: a full pass, or only the changes since
落地：审查时在分支上，结束时压成一个提交开拉取请求

越用越好。 /peerreview-evolve 把教训写进技能，但要先过宪法这关。没过的直接丢掉，不记日志。

Getting better: in comes a lesson from a run, a gap, or a size breach; 1 triggers: after a review, from the raw session traces; research on a real gap, pulled and never scheduled; simplify, monthly or when a size cap is breached; run with /peerreview-evolve; 2 the gate is the constitution: proven and high value (impact × confidence / effort ≥ 3), not already covered, fits the size caps of 1000, 800 and 150 lines, and leaves every past case the same or better; 3 pass: edit the skill, often one of 7 lens modules, and open a PR with propose.sh for the maintainer to land; lens modules are one per repo type: PRD, conformance, evidence docs and more; 4 fail: nothing happens, no log and no queue, and git history is the only record; "maybe someday" counts as fail, since the same trigger will come back; a lesson is either written into a skill now or dropped
越用越好：教训先过宪法，通过就改技能，不通过就丢掉

peerreview is a skill that has two AI models from different vendors check a repo together. The HOST reviews and owns git. The PEER, from the other vendor, edits files. They loop until both agree the repo does what it claims.

The charter. Each run first writes down what "done" means, from your instruction and the repo's own docs. It lives in a temp folder, never in the repo. If the docs conflict or say nothing, it stops and asks.

The charter: in come your instruction and the repo's own docs; 1 where intent comes from, in order: your instruction now, an upstream source it names, PRD, plan or spec, then tests and docs; 2 the charter (PROBLEM.md): problem, scope and non-goals, acceptance checks that are each testable, the verification gate of commands run every round, and residuals, the known gaps out of scope; 3 check the sources: if they conflict or nothing is written, stop and ask you; if they agree, go on with no confirmation stop; the code is evidence, never intent, since checks taken from the code would be circular; 4 review plan: the repo type picks the lenses (e.g. cdd-prd, evidence-docs, code), a full run or only the changes since the last converged tag, and a round forecast shown to you but not a cap; the --dry-run flag shows the plan and stops here; the charter sits in a private temp folder, never in the repo, and is deleted when the run ends, whatever the outcome; a PROBLEM.md you wrote yourself is an input, never edited or deleted
The charter: each run writes down what "done" means from your docs, outside the repo

The peer. Claude Code and the Codex CLI review each other. DeepSeek is a fallback, used only when the other one can't be reached, and the report says so.

Picking the peer: select-peer.sh picks the PEER before the loop; 1 who is the HOST: Claude Code (Anthropic), the Codex CLI (OpenAI), or Pi or the DeepSeek Harness dsh (DeepSeek), read from the environment and the model in use; 2 tier 1, the other subscription: Claude Code on a Claude subscription, the Codex CLI on a ChatGPT subscription; a Claude Code HOST gets Codex, a Codex HOST gets Claude Code; 3 tier 2, only if tier 1 is out: dsh with deepseek-v4-pro for CDD repos, Pi with deepseek-flash for every other repo; named as the weaker tier in the report, and a DeepSeek HOST has tier 1 only; 4 each candidate is checked: CLI installed and signed in, no keys printed; a quota probe with one tiny prompt, only for the subscription peers, and a used-up peer means the next one; nobody left means stop, with no same-vendor stand-in; the PEER is never from the HOST's own vendor
Picking the peer: always another vendor, tier 1 first, tier 2 only when tier 1 is out

One round. The HOST reviews and runs the checks, the PEER fixes, the HOST reads the real diff, reruns the checks and commits.

One round: in come the charter and the last committed state; 1 HOST reviews: sweep the charter, correctness and security first, re-sweep old defect kinds across every sibling, not one line, run the full gate, and write a prompt file with the whole charter and ranked findings; 2 PEER co-edits: through a driver script (claude-, codex-, pi- or dsh-round), with its own findings too, not a confirm-my-work pass, and minimal edits with no commit and no push; a 30 min deadline per round, set by an env var; 3 HOST re-checks: wait for the driver to exit because a mid-flight tree can't be trusted, read the real git diff and status rather than the PEER's report, rerun the gate and fact-check fixes, since a "fix" can be a regression; 4 commit the round as peerreview: round N with HOST and PEER as co-authors; worse than before means revert and tighter findings; no progress in a round stops the loop with a report; dashed arrow: next round; the HOST owns git and the decision to stop, the PEER only edits
One round: the HOST reviews, the PEER edits, the HOST re-checks and commits

Guard rails. Each PEER runs behind a git guard and a 30-minute deadline. In the verdict round edits are blocked; dsh can't block them, so its round fails if the tree moved.

Guard rails: each driver script wraps its PEER CLI like this; 1 Claude Code as PEER: safe mode with no HOST CLAUDE.md, hooks or MCP, edit rounds with all tools and git guarded, the verdict round with Edit, Write and Bash switched off; 2 Codex CLI as PEER: edit rounds in a workspace-write sandbox, the verdict round in a fresh read-only sandbox, both behind the git guard; 3 Pi and dsh as PEER: Pi has no sandbox and its verdict gets read, grep, find and ls only; dsh has no tool allowlist, so its verdict fails if the repo moved; a moved repo is not reverted, the HOST looks at it first; 4 for every PEER: a git guard on PATH allows only read-only git in the repo, a round deadline of 1800 s by default, and only the HOST commits and pushes; the git guard catches mistakes, it is not a sandbox against a PEER set on getting around it
Guard rails: how each of the four PEER CLIs is held back: read-only verdicts, a git guard, a deadline

When to stop. Every check passes and the PEER says CONVERGED to a neutral prompt. At least one peer round always runs; there is no upper limit. A round with no progress stops the loop.

When to stop: in comes the committed state after the last edit round; 1 all must hold: every acceptance check met with evidence, the full gate exits clean, no findings left with every lens swept, not sampled, and the tree clean, or left for manual commit; 2 then the verdict prompt: a read-only round with no edits allowed, neutral facts only, the raw gate output and no "all green", and reading is allowed, said in the first paragraph; a leading prompt invites false agreement; 3 the PEER answers CONVERGED, no substantive defects remain, or NOT CONVERGED with defects named, which means round N+1; at least 1 peer round, no upper cap; 4 other endings: no progress means stop and report, no peer reachable means stop with no stand-in, and never "perfect", only converged with leftovers listed; the HOST cannot declare convergence alone, the PEER has to say it
When to stop: every check passes and the PEER says CONVERGED to a neutral prompt

Landing. Rounds are squashed into one commit and opened as a pull request. A tag marks the reviewed commit, so the next run can start from it. Repos under ~/projects get no git writes; the --chat flag reviews an idea in a temp repo.

Landing: in comes the repo you asked to review; 1 during the review: the review branch peerreview/<slug>, its own worktree if installed skills point into this repo, and round commits as evidence, not history; a baseline commit first, so each round's diff is its own; 2 land: squash to one commit on evolve/<slug>, check the subject first (type and a lowercase description), then push and open a PR; the base branch is never written; 3 after: a converged tag peerreview/converged/..., push the reviewed repo and fail loud if it can't, and the maintainer merges later with land-evolution.sh on an explicit go-ahead; 4 exceptions: a repo under ~/projects gets no git writes at all, the --chat flag uses a temp repo, answers in chat and deletes it, and a named open PR is reviewed on its own branch; the tag gives the next review a starting point: a full pass, or only the changes since
Landing: the review runs on a branch and ends as one commit in a pull request

Getting better. /peerreview-evolve turns lessons into skill edits, but only if they pass the constitution. Anything else is dropped, not logged.

Getting better: in comes a lesson from a run, a gap, or a size breach; 1 triggers: after a review, from the raw session traces; research on a real gap, pulled and never scheduled; simplify, monthly or when a size cap is breached; run with /peerreview-evolve; 2 the gate is the constitution: proven and high value (impact × confidence / effort ≥ 3), not already covered, fits the size caps of 1000, 800 and 150 lines, and leaves every past case the same or better; 3 pass: edit the skill, often one of 7 lens modules, and open a PR with propose.sh for the maintainer to land; lens modules are one per repo type: PRD, conformance, evidence docs and more; 4 fail: nothing happens, no log and no queue, and git history is the only record; "maybe someday" counts as fail, since the same trigger will come back; a lesson is either written into a skill now or dropped
Getting better: a lesson must pass the constitution to become a skill edit; otherwise it is dropped

来源Source: github.com

← 全部架构← All architectures