A team of AI agents.
Built from one agent engine.

01 / SUPERVISION

Workers do the work; the lead watches and restarts them when needed — with a limit on how many restarts are allowed. When the limit is hit, the problem goes to a human instead of retrying forever. Modeled on Erlang/OTP supervision trees (the concept, not the code).

02 / RESEARCH THAT STOPS AND ASKS

Long research runs in steps that save their progress, check the results, and pause for a human to review. It never runs silently for hours.

03 / EVERYTHING SAVED TO DISK

All work state is written to files as it happens, and old entries are never overwritten. A restarted agent continues from the files, not from memory that died with it. This is what keeps the team correct even after months untouched.

04 / THE MAKER NEVER MARKS THEIR OWN WORK

The agent that produces something is never the one that approves it. Approval is based on reading the actual result — never on the producer saying “done”. Test on a staging copy first, get approval, then publish.

05 / STRICT QA

An automated check first, then an independent reviewer. Rules that stop endless polishing: keep it simple, cap the retries, stop when improvements level off. QA can send work back with less scope, not more.

06 / ONE FIXED ORDER OF WORK

Lead → Researcher → Architect → UX → Coder → QA → Lead, once through. UX is one step (not two); the architect never codes; the coder is the only one who writes code.

07 / LIMITS FOLLOW THE MODEL

Rate limits belong to the provider and model, not to an agent’s name. Before a request runs, the team checks the route it will use and keeps a small request and token reserve. If a fallback uses another provider, it gets its own limit.

08 / UNKNOWN LIMITS STAY OBSERVE-ONLY

The kit never invents a quota. When a provider’s limit is unknown, it records response headers and errors but does not pretend to know when the allowance resets. A verified limit can later be enforced with a bounded wait instead of endless retries.

09 / AI-ASSISTED CHANGES FOLLOW A WRITTEN CONTRACT

When a change is made with an AI coding agent, the task brief states the scope, acceptance criteria, and commands that prove the change; tests are behavior-first and cover boundary and error cases; parallel work is isolated; security-sensitive paths get a checklist before handoff; and an independent agent reads the evidence back before anything is called done. It is a written contract, not a tool — nothing installs, runs, or enforces by itself. Read choreography/ai-assisted-development.md.

10 / ROUTERS HAVE A TRUST BOUNDARY

A model router or relay may see plaintext requests, tool calls, outputs, and credentials. The kit now documents a vendor-neutral preflight: inventory the route, minimize credentials, gate high-risk tools, fail closed when provenance or integrity is missing, keep logs metadata-only, and test conditional changes. This is guidance, not a router, detector, or claim of end-to-end response integrity. Read choreography/router-security.md.

11 / SIDE EFFECTS AND COSTS ARE PRECHECKED

Before an operation edits files, contacts an external system, uses credentials, or may incur cost, the team records what can happen, what it may touch, which credential names it needs, how much it may use, who approves it, and how to recover. Unknown cost is explicit; conditional actions are marked; missing rollback evidence fails closed. The dependency-free checker validates the contract, but does not execute the operation. Read choreography/side-effect-cost-preflight.md.

12 / EVERY HANDOFF IS A CHECKED FILE

Each stage boundary carries one small machine-checkable contract: what artifacts must exist, what runtime state the work is in, where the next worker resumes, and what it must not touch. It is a documentation contract, checklist, and dependency-free checker — shipped into the generated kit so an instantiated team carries them together — not a runtime. Kanban remains the task state authority; a contract that disagrees with the board is rewritten from it. Read choreography/artifact-contract.md.

13 / CHEAPER WORKERS MAY DO THE BULK READS

For two narrow work classes — predictable read-heavy summarization and pattern-conforming scaffolding — the contract documents optional offload to a cheaper worker with an explicit route, input cap, latency bound, and fallback. Edits, debugging, architecture, security-critical work, ambiguous input, and final acceptance always stay with the frontier agent. It is a contract plus an example config, not a runtime or provider integration; nothing is enabled by default, and published savings figures are a vendor’s self-report, not a Proteus result. Read choreography/io-delegation.md.

14 / ONE REPORT PER RUN, SAFE TO SHARE

When a run finishes, a single packet records what was attempted, decided, actually verified, changed, tested, whether anything reached a live surface, and what is still open. Share rules fail closed: no credential values, no internal local paths, no ad-hoc placeholders. The documentation contract and standard-library-only validator ship through the generated kit. The packet is a derived report — Kanban stays the state authority — not a second state store, and it is not a security guarantee. Read choreography/safe-run-packet.md.

15 / REVIEWS LEAD WITH COUNTED EVIDENCE

Reviews, triage notes, and status comments define the unit being counted, count each item once at its highest impact, separate included work from requests and unresolved findings, map every row to its artifact, commit, test, and status, and label the evidence boundary. Missing evidence limits the claim instead of supporting it. This is writing guidance published in the kit's public skill templates, not tooling. Read templates/skills/creative/external-writing-discipline/SKILL.md.

16 / OPENSHORTS ROUTE (EXTERNAL, DOCS ONLY)

Finished short-video production requests — where the user explicitly asks for a rendered short — route to OpenShorts, an external local-first tool Proteus has studied as a reference. This is a documentation route only: the kit does not bundle or run OpenShorts, does not render video by itself, and does not post, publish, or schedule anything on the user's behalf. Transcript, summary, and media-research requests stay on the existing media skills. Users install OpenShorts separately and check its current license and dependency terms before use. Read registry/openshorts-route.yaml.example and choreography/openshorts-route.md.

17 / VERIFICATION DISCIPLINE

The team requires independent proofread and fact audit before any prose is delivered. Quoted source text is extracted programmatically and compared byte for byte. For behavioural claims, implementing code or a pinned test outranks repository prose. A durable record carries only verbatim values from the producing command. Third-party tools are piloted in an authorised sandbox before adoption. Read templates/skills/creative/external-writing-discipline/SKILL.md, templates/skills/software-development/source-verification/SKILL.md, templates/skills/research/source-evaluation/SKILL.md, templates/contracts/artifact-contract.md.tmpl, and templates/skills/software-development/external-tool-vetting/SKILL.md.

18 / THE SAME MOVE TWICE IS A DEFECT

An agent that repeats an operation that returns nothing new is stuck, not working. The team stops, reports, and encodes the rule. Read choreography/anti-loop-discipline.md.

19 / THE SYSTEM FIXES ITSELF ON PURPOSE

Every failure the team hits becomes one written rule at the shared layer, so the next run inherits the fix. A rule must name the incident, the failure it prevents, and where it is enforced — or it is rejected. Read choreography/self-improving-flywheel.md.

20 / FRESH BRANCHES, ORDERED COMMITS

Start each branch from a fresh fetch of the target repository’s default branch. Stage and commit one declared file set at a time. The stale-tree example shows how old state can duplicate or undo work. The session-start router is in templates/personas/SOUL.md.tmpl. The mirror rule is in choreography/self-improving-flywheel.md. The peer-team review procedure is in choreography/orchestration.md.

21 / GOLDEN-ARTIFACT REGRESSION GATE

Before a release, run a checkpoint that fixes an input and checks that the output matches a committed golden. If the output drifts, the check fails and the release is not shipped. No network, no third-party libs, no model calls—pure Python stdlib. Read demo/golden-artifact/README.md and AUDIT/infographic-learnings.md.

22 / WE GIVE BACK TO WHAT WE USE

When the team finds a bug or a gap in an open-source project it depends on, it writes the fix or the report and shows it to the owner before anything is sent. Nothing is posted without a human seeing it first. Read choreography/open-source-contribution.md.

REDACT

A first-pass filter for text about to be sent out or saved to outside logs. If it finds an address, a number that looks sensitive, or anything it is unsure about, the text is held for a human to review first. A filter — not legal anonymization.

GIST

Sorts large piles of notes and transcripts into rough topics. A hint for where things belong — never the final word on a decision.

TITLE

Suggests titles and short descriptions for files, transcripts, and research notes. A human reads them before they reach a user.

LIMITS BY DESIGN

Normal conversation, final answers, and legal/financial/security/architecture decisions are all outside its job. Media models only run if you opt in, and they never download weights during active work.

01 / NO LABELS UNTIL CHECKED

A README, a license, and a working search index only prove the source was captured. It cannot be filed away as “just a reference” until someone has checked what it is actually useful for.

02 / LOOK AT THE REAL THING, NOT THE BROCHURE

The check walks the actual file tree, package lists, wiring, skills and plugins, CI workflows, tests, and docs — recording the path for every finding.

03 / ONE ROW PER FINDING, WITH AN OWNER

Every capability found gets a row — do we already have this, what’s missing, what happens next, who owns it — compared against the live catalog, not memory. Each row ends in a decision: use it now, test it, postpone it, or reject it.

04 / FIVE STEPS, NOT ONE

Bringing a source in, adopting it, building with it, checking it, and enforcing the result are separate steps with separate finish lines. Step one ends at a source captured, indexed, and checked — an indexed source is not a build task someone forgot.

05 / PROVE IT IN A SANDBOX FIRST

One isolated test area per proof, a pinned version, no production data, and the pass/fail bar written down before it runs. Nothing is installed wholesale just to find out whether it works.

06 / WRITTEN RECORDS, READ BACK

The ledger, the findings table, and the decisions are saved as files and read back by someone other than whoever wrote them. An adopted change names every place it touches — repo, docs, skills, site — and each goes through its own check.

07 / EACH CHANGE ROUTED TO ITS OWNER

Each candidate produces one machine-readable summary of what it adds or changes. Its impact level — reference only, internal use, kit change, website change, or release-worthy — decides who reviews it and how carefully.

08 / ONE LOG, BATCHED CHANGES

Candidates live in one append-only log with clear states: proposed, accepted, implementing, verified, staged, live, or dropped. Compatible candidates are combined into one coherent update instead of one public change per source.

09 / QUICK CHECK EACH, FULL AUDIT THE BATCH

Every candidate gets a cheap pre-check: safe for public, license clear, owner named, pass/fail bar set, affected places listed. The full pre-merge audit is saved for the batch or release candidate, and the repo and site are checked against each other before merging or deploying.

01 / THE CONTRACT

choreography/codebase-map.md defines one small snapshot document: which roots were included, which patterns were skipped, the measure, the sort policy, and the layout token. Every one of those is a required, checked field. An unknown field, or an undeclared ordering policy, fails the map instead of passing quietly.

02 / A DEPENDENCY-FREE CHECKER

build/check-codebase-map.py is Python 3 standard library only — no network, no writes. It reads one snapshot path and prints the field path of every violation. Exit 0 means valid, exit 1 means not. Its own pass and fail cases run with --self-test.

03 / TWO AUTHORED FIXTURES

examples/codebase-map.valid.json and codebase-map.invalid.json are synthetic samples, not repository captures. The invalid one fails on purpose — a missing sort policy, an unknown layout token, an absolute path, a duplicate identity, a negative size — and it is never made valid by weakening the checker.

04 / A STATIC VIEWER PROOF

demo/codebase-map/index.html draws one fixture as a treemap with no library, no font, no image, and no network request. It is a proof on a synthetic fixture — not a live product, not deployed, and not a repository crawler.

05 / ONE LAYOUT, NAMED

The only accepted layout token is t6-squarified-v1 — a squarified treemap applied to the snapshot’s declared child order. The viewer rejects an unrecognized token rather than falling back to a default. It is a Proteus experiment baseline, not a claim about any other tool’s default.

06 / FOCUS AND SEARCH, METADATA ONLY

Selecting a directory re-roots the viewport to it; search matches display labels and normalized paths, nothing else. Source text, syntax highlighting, dependency edges, and live source search are out of scope and shown as unavailable rather than guessed. Focus and query are held in the URL, so a reload rebuilds the same view from the snapshot alone.