# graphs.univerlab.org — the Canopy graph and node catalogue.

canopy-loop-plain	The canopy-loop roles as plain nodes: designer, implementer, full gates, the reviewer, the auditor, the gates again, documenter and one deterministic commit. No ensembles and no repository lock, so every role is a node you can read in one glance. The starting point; canopy-loop is the hardened version.	canopy-loop-plain
canopy-loop	The loop the lab runs on its own branches: a locked repo, a designer that plans into a spec note, an implementer that never commits, deterministic full gates, the reviewer, a deterministic commit with the spec's own message, the auditor that repairs and is committed in turn, the gates again, a documenter, and a clean-tree check before the repo is relocked. Each of the five working roles is a round-robin ensemble, so a quota death rotates to the next member instead of failing the spec.	canopy-loop
auditor	The auditor: it reviews the change strictly against the spec, repairs what it objects to in the working tree, runs the gate script once, and never commits.	auditor
designer	The designer step of a spec loop: it investigates the spec against the code and saves the plan as its spec note. It never writes code and never commits.	designer
documenter	The documenter step of a spec loop: it writes the user docs the change needs and leaves them uncommitted for the commit node.	documenter
full-gates-cargo	The Rust full gate: one check command runs `cargo fmt --all -- --check`, `cargo clippy --all-targets --all-features -- -D warnings` and `cargo test --all-features`. The project should add its dependency audit and coverage floor to the command.	full-gates-cargo
full-gates-web	The TypeScript/web full gate: one check command runs lint, typecheck, unit tests, build and end-to-end tests. The project adds its dependency audit and coverage floor to the command.	full-gates-web
implementer	The implementer step of a spec loop: it follows the designer's plan, writes the code and the tests the plan asks for, runs the gate script once, and leaves the change uncommitted.	implementer
reviewer	The completeness review of a spec loop: it locates every requirement at `file:line` and fails with the list of what is missing or wrong. It asks for changes, never fixes and never commits.	reviewer

## Patterns

Adversarial review	Review the work with models of different families, one told to break it, and back the verdict with deterministic checks.	/patterns/adversarial-review
Deterministic gates	Shell checks decide pass or fail, never an LLM judge, and a failure carries its reason into the next prompt.	/patterns/deterministic-gates
Cross-platform check	The reviewer runs on a different vendor from the implementer, so one family's blind spots and one quota ceiling cannot stall the graph.	/patterns/cross-platform-check
Deterministic commit	A check node commits with the spec's own Conventional Commit subject, and a model never writes the commit.	/patterns/deterministic-commit
Event intake	A graph that fires on a watched file, turning outside events into specs while nobody is watching.	/patterns/event-intake
Parallel proposers	Several cheap models draft the same spec in parallel, then one implementer builds on the best ideas.	/patterns/parallel-proposers
Resilient members	Cascade and round-robin ensembles give one node a fallback ladder or a rotation across providers, so a quota death is not a failed run.	/patterns/resilient-members
Auditor fixes	The auditor repairs what it finds, instead of writing change requests for another model to read.	/patterns/reviewer-fixes
Review panel	An experiment, each reviewer owns one axis, security, performance, maintainability, or project patterns, and every axis must pass.	/patterns/review-panel
Task router	An experiment, a router judges the task by kind or complexity and sends it to a model suited to it.	/patterns/task-router