@eir-labs/coltrane 0.9.4 → 0.11.0

package/standards/room-probe-v1.json

@@ -0,0 +1,28 @@
+{
+  "slug": "room-probe-v1",
+  "domain": "venue",
+  "agent_slugs": [
+    "room-prober"
+  ],
+  "phases": [
+    {
+      "name": "probe",
+      "chairs": [
+        {
+          "role": "probe",
+          "agent_slug": "room-prober",
+          "depends_on": [],
+          "input_contract": [],
+          "output_contract": [
+            "Signal"
+          ],
+          "required_skills": []
+        }
+      ]
+    }
+  ],
+  "output_types": [
+    "Signal"
+  ],
+  "description": "One seat, one tool, one question: can a chair reach an MCP server running inside the realized room? Deliberately the thinnest standard that can carry that question — a single SENSE phase whose seat holds only type_browse — because everything interesting lives in the venue, not here. Dispatched WITHOUT a venue it is answered by the host engine; dispatched WITH a containerized venue it must be answered from inside the container or not at all. The difference between those two runs is the whole experiment."
+}

package/standards/software-change-pr-v1.json

@@ -23,10 +23,10 @@
           "output_contract": [
             "change-context"
           ],
+          "optional_outputs": [],
           "required_skills": []
         }
-      ],
-      "intent": "Read the material the change lands in, to the declared boundary and no further: entry points, the files the change plausibly touches, the checks that already cover the region, the conventions it must hold to — and the unknowns, which are part of the reading, not a failure of it. No decision is taken here."
+      ]
     },
     {
       "name": "frame-change",
@@ -43,10 +43,10 @@
           "output_contract": [
             "change-decision"
           ],
+          "optional_outputs": [],
           "required_skills": []
         }
-      ],
-      "intent": "Fix the direction from the reading: scope, non-goals, stop condition, and the alternatives set aside with their reasons. Stated before any structure exists, so the structure is answerable to it. Settled for the run — later phases append observations, never revisions."
+      ]
     },
     {
       "name": "plan-change",
@@ -65,13 +65,13 @@
           "output_contract": [
             "change-plan"
           ],
+          "optional_outputs": [],
           "required_skills": [],
           "preferred_skills": [
             "structure-conformance"
           ]
         }
-      ],
-      "intent": "Settle the structure the change will be built through: ordered steps with explicit dependencies, the checks that land FIRST together with what each reports while the change is absent, the paths the plan commits to touching, and the tradeoff at every step where more than one structure would have served."
+      ]
     },
     {
       "name": "create-change",
@@ -88,10 +88,10 @@
           "output_contract": [
             "change-set"
           ],
+          "optional_outputs": [],
           "required_skills": []
         }
-      ],
-      "intent": "Make the change the plan implies by WRITING it directly into the isolated working tree — every file it requires, created new or edited in place, however many that takes. The change lands as real files and the change-set is the real diff captured from the tree; this seat does not emit a patch for another to apply, and it does not verify its own work. Where the build departs from the plan, the departure is recorded with its reason."
+      ]
     },
     {
       "name": "verify-change",
@@ -110,10 +110,10 @@
           "output_contract": [
             "change-verdict"
           ],
+          "optional_outputs": [],
           "required_skills": []
         }
-      ],
-      "intent": "RUN the checks the plan fixed against the working tree the implementer has already written — build and tests, nothing to apply — then measure the change against its commitments criterion by criterion from the actual run: which acceptance criteria the run confirms green, where scope drifted, and which checks could not be executed. A criterion passes only when a real test asserted it and that test went green in this run; a check that could not run is unverified, never a pass; a red run is reported verbatim. The seat that clears the change is the seat that ran it."
+      ]
     },
     {
       "name": "publish-pr",
@@ -132,20 +132,20 @@
           "output_contract": [
             "pull-request"
           ],
+          "optional_outputs": [],
           "required_skills": []
         }
-      ],
-      "intent": "Turn the verified change into an open pull request the pipeline cannot merge. The change is already on disk and confirmed by the verifier; commit exactly what is in the working tree to a fresh non-main branch, push it, and open exactly one PR whose body carries the rationale and the verifier's verdict. A failed verdict is not published — it is surfaced as a caveat and the seat stops. Landing the PR on main is a human governor's act on green CI, external to this run."
+      ]
     }
   ],
   "input_types": [
-    "change-request"
+    "change-request",
+    "change-context"
   ],
   "output_types": [
     "change-set",
     "change-verdict",
     "pull-request"
   ],
-  "max_examine_rounds": 3,
-  "description": "The full governed dev-loop: read the material, fix the direction, settle the structure, WRITE the change into an isolated working tree, RUN it to say whether what was built is what was decided, and open it as a pull request the seat that built it cannot merge. The implementer HOLDS the tree — it writes the change directly with the real file-editing interface (any number of files) and seals the change-set as the real captured diff, so the change that gets reviewed is the change that exists; there is no hand-authored patch to apply. The verify seat then EXECUTES against that tree — build and tests — so a change is cleared by a real run, never by argument; and a failing run is not the end: max_examine_rounds budgets the examine⇄amend loop, so a red verdict re-runs the writer (the failing verdict fed back) and re-verifies, iterating to green or stopping honestly at the bound. The publish seat commits exactly what is on disk. The seams hold: the seat that reads does not decide, the seat that decides does not build, the seat that builds does not judge its own work, and the seat that publishes does not merge. The cage is the isolated tree, not a missing tool. Landing on the protected main line is a human governor's act on green CI, not the pipeline's."
+  "description": "The governed dev loop, dispatchable WITH its grounding. Reads context, frames the change, plans it, writes it, verifies by running the checks, and opens a pull request a human lands. `change-context` is declared a seedable input alongside `change-request` (#424 I9): the reading chair's product may arrive from any of four interchangeable producers — a reader, the src/repo_index.ts compiler, a prior standard, or a human — and the runtime's existing seeding seam satisfies a chair's contract from an upstream output OR from the gig payload. A dispatch that already holds a reading need not pay a premium seat to re-derive it; a dispatch that does not, still runs exactly as before."
 }

package/standards/software-change-red-first-v0.json

@@ -0,0 +1,183 @@
+{
+  "slug": "software-change-red-first-v0",
+  "domain": "software-change",
+  "agent_slugs": [
+    "john",
+    "miles",
+    "bill",
+    "red-spec-drafter",
+    "code-implementer",
+    "change-verifier",
+    "pr-publisher"
+  ],
+  "phases": [
+    {
+      "name": "sense-context",
+      "chairs": [
+        {
+          "role": "read-context",
+          "agent_slug": "john",
+          "depends_on": [],
+          "input_contract": [
+            "change-request"
+          ],
+          "output_contract": [
+            "change-context"
+          ],
+          "optional_outputs": [],
+          "required_skills": [],
+          "turn_reserve": 12
+        }
+      ]
+    },
+    {
+      "name": "frame-change",
+      "chairs": [
+        {
+          "role": "frame-change",
+          "agent_slug": "miles",
+          "depends_on": [
+            "read-context"
+          ],
+          "input_contract": [
+            "change-context"
+          ],
+          "output_contract": [
+            "change-decision"
+          ],
+          "optional_outputs": [],
+          "required_skills": []
+        }
+      ]
+    },
+    {
+      "name": "plan-change",
+      "chairs": [
+        {
+          "role": "plan-change",
+          "agent_slug": "bill",
+          "depends_on": [
+            "read-context",
+            "frame-change"
+          ],
+          "input_contract": [
+            "change-context",
+            "change-decision"
+          ],
+          "output_contract": [
+            "change-plan"
+          ],
+          "optional_outputs": [],
+          "required_skills": [],
+          "preferred_skills": [
+            "structure-conformance"
+          ]
+        }
+      ]
+    },
+    {
+      "name": "draft-laws",
+      "chairs": [
+        {
+          "role": "draft-laws",
+          "agent_slug": "red-spec-drafter",
+          "depends_on": [
+            "plan-change",
+            "frame-change"
+          ],
+          "input_contract": [
+            "change-plan",
+            "change-decision"
+          ],
+          "output_contract": [
+            "red-spec"
+          ],
+          "optional_outputs": [],
+          "required_skills": [],
+          "turn_reserve": 14
+        }
+      ]
+    },
+    {
+      "name": "create-change",
+      "chairs": [
+        {
+          "role": "write-change",
+          "agent_slug": "code-implementer",
+          "depends_on": [
+            "draft-laws",
+            "plan-change"
+          ],
+          "input_contract": [
+            "change-plan",
+            "red-spec"
+          ],
+          "output_contract": [
+            "change-set"
+          ],
+          "optional_outputs": [],
+          "required_skills": [],
+          "turn_reserve": 14
+        }
+      ]
+    },
+    {
+      "name": "verify-change",
+      "chairs": [
+        {
+          "role": "verify-change",
+          "agent_slug": "change-verifier",
+          "depends_on": [
+            "write-change",
+            "draft-laws",
+            "plan-change"
+          ],
+          "input_contract": [
+            "change-plan",
+            "change-set",
+            "red-spec"
+          ],
+          "output_contract": [
+            "change-verdict"
+          ],
+          "optional_outputs": [],
+          "required_skills": [],
+          "turn_reserve": 10
+        }
+      ]
+    },
+    {
+      "name": "publish-pr",
+      "chairs": [
+        {
+          "role": "publish-pr",
+          "agent_slug": "pr-publisher",
+          "depends_on": [
+            "write-change",
+            "verify-change",
+            "draft-laws"
+          ],
+          "input_contract": [
+            "change-set",
+            "change-verdict",
+            "red-spec"
+          ],
+          "output_contract": [
+            "pull-request"
+          ],
+          "optional_outputs": [],
+          "required_skills": []
+        }
+      ]
+    }
+  ],
+  "status": "draft",
+  "input_types": [
+    "change-request"
+  ],
+  "output_types": [
+    "pull-request"
+  ],
+  "description": "The governed change loop with the laws made STRUCTURAL. Identical to software-change-pr-v1 through planning, then it splits the single writing chair into two seats with disjoint powers: a law-drafting chair whose grant reaches tests/** and docs/specs/** and CANNOT touch src/, and a building chair that consumes the sealed red-spec as an input. The ordering is not requested in a brief — it is enforced twice over. By GRANT: the drafter cannot write source, so it cannot make its own laws pass. By TYPE: the builder requires a red-spec, so a phase graph seating it before the drafter fails to compose at all. The publishing chair receives the red-spec too, because the laws and the fix are written by DIFFERENT seats and a PR carrying one without the other is the artefact a laws-first pipeline exists to prevent. Carries a reserve pool: a budget-stopped chair may draw turns whose whole purpose is sealing what it already found, so exhaustion costs the tail of a run rather than all of it.",
+  "reserve_pool": 40
+}

package/standards/spec-review-and-sequence-v0.json

@@ -0,0 +1,112 @@
+{
+  "slug": "spec-review-and-sequence-v0",
+  "domain": "software-change",
+  "agent_slugs": [
+    "john",
+    "miles",
+    "bill"
+  ],
+  "phases": [
+    {
+      "name": "read-the-red",
+      "intent": "Read the material. THREE SEATS SPLIT THIS PHASE AND EACH READS ONLY THE SLICE ITS OWN ROLE NAMES. This is not a suggestion about tidiness: a chair is killed at a hard wall-clock wall, and a seat that wanders outside its slice dies at that wall having sealed nothing — which costs real money the ledger never records, because a killed chair reports no usage. Read your slice, then seal. Budget most of your window for reading and keep a real margin for writing your change-context.\n\nIF YOUR ROLE IS read-the-argument: read SPEC-worker-contract.md and CHANGELOG.md, and nothing else. Report, gap by gap (there are six), what the document ARGUES: the defect it claims, the contract it proposes, what it explicitly leaves to the deployment, what it names as out of scope, and what its closing 'What this document does NOT specify' section deliberately declines to settle. Quote the document where its wording is load-bearing. You are the only seat that reads the argued half, so the judge sees the reasoning only through you.\n\nIF YOUR ROLE IS read-the-substrate-laws: read tests/spec_venue_realization_substrate.test.ts and nothing else. It is 962 lines and holds 40 of the suite's 88 laws, grouped into ten describe blocks. For each describe block, report: its laws by their own `it` text, the exports each destructures from the module under specification, and — for every law — the exact assertions it makes, distinguishing POSITIVE assertions (something must be present) from NEGATIVE ones (something must be absent), and counting each. That distinction is the most important thing you will record, because a law whose assertions are ALL negative is satisfied by an implementation that produces nothing at all. Be mechanical about it. Also record the type declarations at the top of the file (VenueRealizer, RealizationHandle, RealizedArtifact, RetentionPolicy, VenueGuarantee, RealizationHost), which are the interface being specified, and the shared fixtures and helpers the laws render through.\n\nIF YOUR ROLE IS read-the-other-laws-and-the-grain: read the other five law files — tests/spec_venue_realization.test.ts, tests/spec_worker_environment.test.ts, tests/spec_worker_run_modes.test.ts, tests/spec_venue_targeting.test.ts, tests/spec_venue_credential_mint.test.ts — and report for each the laws by their `it` text, the module and exports each expects, and what it asserts. Then, with whatever budget remains, sense the existing grain the implementation must follow: VenueSchema in src/genome_schema.ts, the realize gauntlet in src/venue_realize.ts, and the candour at src/workspace.ts lines 44-56. Skim these for SHAPE. Do not read them exhaustively; if budget runs short, the five law files matter more than the source.",
+      "chairs": [
+        {
+          "role": "read-the-argument",
+          "agent_slug": "john",
+          "depends_on": [],
+          "input_contract": [
+            "change-request"
+          ],
+          "output_contract": [
+            "change-context"
+          ],
+          "required_skills": []
+        },
+        {
+          "role": "read-the-substrate-laws",
+          "agent_slug": "john",
+          "depends_on": [],
+          "input_contract": [
+            "change-request"
+          ],
+          "output_contract": [
+            "change-context"
+          ],
+          "required_skills": []
+        },
+        {
+          "role": "read-the-other-laws-and-the-grain",
+          "agent_slug": "john",
+          "depends_on": [],
+          "input_contract": [
+            "change-request"
+          ],
+          "output_contract": [
+            "change-context"
+          ],
+          "required_skills": []
+        }
+      ]
+    },
+    {
+      "name": "judge-the-laws",
+      "intent": "Judge the suite as a contract, from the three readings handed to you. DO NOT RE-READ THE SOURCE — the reading is done and your budget is for judgment; you may open a file only to settle a specific question the readings left genuinely ambiguous. For each family of laws answer three questions. SOUND: does it assert the property the document argues for, or something narrower or wider than the argument supports. NON-VACUOUS: could an implementation that keeps none of the guarantees still pass it. Ask this concretely rather than in general — construct the smallest hollow implementation you can (a function returning an empty object, a resolver returning nothing, a filter over an empty family) and then walk EVERY law in the family INDIVIDUALLY saying whether that hollow implementation passes it. Answer at the granularity of the single `it` block, because that is the unit a filtered test run measures: a family may be non-vacuous as a whole while several of its laws pass hollow, and if an acceptance check runs only those laws the hollow implementation ships. Where a family's honesty depends on a positive assertion living in a DIFFERENT describe block, say so plainly — that anchor is one edit away from disappearing. BUILDABLE: can it be satisfied against the existing grain without weakening it. Name every law you believe is wrong by its own describe/it text and say what the document would have to argue instead. Then fix the direction for the build: what ships, what is out of scope, the stop condition, and the alternatives set aside with their reasons. Settled for the run.",
+      "chairs": [
+        {
+          "role": "judge-laws",
+          "agent_slug": "miles",
+          "depends_on": [
+            "read-the-argument",
+            "read-the-substrate-laws",
+            "read-the-other-laws-and-the-grain"
+          ],
+          "input_contract": [
+            "change-context"
+          ],
+          "output_contract": [
+            "change-decision"
+          ],
+          "required_skills": []
+        }
+      ]
+    },
+    {
+      "name": "sequence-the-bands",
+      "intent": "Settle the order the laws are made green in, from the readings and the judgment. Ordered work packages with explicit dependencies, each naming: the laws it closes by their own describe/it text, the modules and exports it creates, the files it touches, and what the closed laws report before the package lands. The security-critical family goes first where the judgment says it must — a permissive implementation is worse than an absent one, because the contract still claims the guarantee. Every package must be independently verifiable, and must be SMALL ENOUGH TO BUILD IN ONE RUN: a package whose laws cannot be run green on their own is not a package, and neither is one that could not be written and verified inside a single chair's wall-clock budget. Size the packages against that bound honestly — a package that creates a whole module with a dozen exports and closes forty laws is two packages wearing one name. Each package states a NON-VACUITY GUARD that is a DEMONSTRATION rather than an argument: name the hollow implementation, say which of that package's laws it would still pass, and require the implementer to run it and report the survivors. Do not inherit the judge's vacuity reasoning as settled — restate it as a check somebody performs. Where the judgment found a law vacuous or unsound, the package that would have closed it must carry the remedy — an amendment to the specification — rather than quietly coding to the weak law. Account for every law: each lands in a package or is listed as deferred with its reason. State the tradeoff wherever more than one ordering would have served.",
+      "chairs": [
+        {
+          "role": "sequence-bands",
+          "agent_slug": "bill",
+          "depends_on": [
+            "read-the-argument",
+            "read-the-substrate-laws",
+            "read-the-other-laws-and-the-grain",
+            "judge-laws"
+          ],
+          "input_contract": [
+            "change-context",
+            "change-decision"
+          ],
+          "output_contract": [
+            "change-plan"
+          ],
+          "required_skills": [],
+          "preferred_skills": [
+            "structure-conformance"
+          ]
+        }
+      ]
+    }
+  ],
+  "status": "active",
+  "input_types": [
+    "change-request"
+  ],
+  "output_types": [
+    "change-context",
+    "change-decision",
+    "change-plan"
+  ],
+  "description": "Review a committed RED specification and turn it into an ordered build sequence. The material is a specification document plus its falsifiable half — test files committed failing on purpose — and the question is not \"is this a good idea\" but \"are these laws sound, non-vacuous, and buildable, and in what order\". The reading is SPLIT ACROSS THREE PARALLEL SEATS because a chair has a hard wall-clock wall and a specification of this size does not fit through one: the argued half, the largest law file, and the remaining laws plus the existing source grain are read by three seats that never wait on each other. Then the seams hold as usual — the seats that READ do not judge, the seat that JUDGES does not sequence, and the seat that SEQUENCES is answerable to a decision it did not make. The output is a change-plan whose steps are work packages, each naming the laws it closes, the modules it creates, and what those laws report while the code is absent, so a later implementation run is measured against a sequence somebody argued for rather than one it invented mid-flight."
+}

package/standards/studio-session-v0.json

@@ -0,0 +1,101 @@
+{
+  "slug": "studio-session-v0",
+  "domain": "introspection",
+  "agent_slugs": [
+    "john",
+    "miles",
+    "bill"
+  ],
+  "phases": [
+    {
+      "name": "listen",
+      "chairs": [
+        {
+          "role": "listen",
+          "agent_slug": "john",
+          "depends_on": [],
+          "input_contract": [
+            "parsed-conversation-trace"
+          ],
+          "output_contract": [
+            "pattern-extraction"
+          ],
+          "optional_outputs": [],
+          "required_skills": []
+        }
+      ]
+    },
+    {
+      "name": "direct",
+      "chairs": [
+        {
+          "role": "direct",
+          "agent_slug": "miles",
+          "depends_on": [
+            "listen"
+          ],
+          "input_contract": [
+            "pattern-extraction"
+          ],
+          "output_contract": [
+            "design-definition"
+          ],
+          "optional_outputs": [],
+          "required_skills": []
+        }
+      ]
+    },
+    {
+      "name": "name-the-seat",
+      "chairs": [
+        {
+          "role": "name-the-seat",
+          "agent_slug": "bill",
+          "depends_on": [
+            "direct",
+            "listen"
+          ],
+          "input_contract": [
+            "design-definition",
+            "pattern-extraction"
+          ],
+          "output_contract": [
+            "draft-agent-profile"
+          ],
+          "optional_outputs": [],
+          "required_skills": [],
+          "preferred_skills": [
+            "structure-conformance"
+          ]
+        }
+      ]
+    },
+    {
+      "name": "accept",
+      "chairs": [
+        {
+          "role": "accept",
+          "agent_slug": "",
+          "human": true,
+          "depends_on": [
+            "name-the-seat"
+          ],
+          "input_contract": [],
+          "output_contract": [
+            "Judgment"
+          ],
+          "optional_outputs": [],
+          "required_skills": []
+        }
+      ]
+    }
+  ],
+  "status": "draft",
+  "input_types": [
+    "parsed-conversation-trace"
+  ],
+  "output_types": [
+    "draft-agent-profile"
+  ],
+  "description": "A STUDIO SESSION plays back a take and names what the leading was. It reads one session transcript as material — what was asked, what tune was called, what the band was handed, where the leader stopped the band and why — extracts the recurrent moves and the roles that keep reappearing, judges which of them are method and which are merely habit, and renders the seat that emerges as a draft agent for a human to accept or reject. The corpus is conduct, not code: a transcript records what a run DID as against what it REPORTED doing, and the gap between those two is the most instructive thing in it. Draft only — the profile is a proposal, never a promotion."
+}

package/tours/coltrane.json

@@ -0,0 +1,72 @@
+{
+  "_comment": "Coltrane's OWN roadmap as the worked-example Tour. This repo does committed work, so its roadmap IS a tour. Every commitment here carries NO amount — Coltrane's tour genuinely has none ('ship the evaluator' is a real commitment with a real acceptance condition and no price). This is NOT hedging: the money path is fully public and exercised with synthetic values in tests/committed_work fixtures, so a fork runs a funded tour on day one. What is absent from THIS example is fake numbers, not the mechanism. Slugs resolve against institutions/coltrane.json (org eir-labs; chairs coltrane.chair.human-governor and coltrane.chair.change-author).",
+  "tour": {
+    "slug": "coltrane-roadmap",
+    "institution_slug": "coltrane",
+    "org_slug": "eir-labs",
+    "responsible_chair": "coltrane.chair.human-governor",
+    "period": "2026-H2",
+    "northstar_slugs": [
+      "model-the-domain-before-the-work",
+      "treat-inference-as-scarce"
+    ],
+    "bookings": [
+      {
+        "slug": "ship-the-binding-middle-place",
+        "aim": "land the Tour/Booking/Resource objects and the tour-admissibility checker on main behind a green pull request",
+        "period": "2026-H2",
+        "accountable_office": "coltrane.chair.change-author",
+        "acceptance": {
+          "predicate": "(=> (= ci_result \"green\") allow)",
+          "inputs": { "ci_result": "ci-status" }
+        },
+        "tier": "enforced",
+        "draws": [
+          { "resource_slug": "engine-dev-seat", "unit": "max-seat-hours", "quantity": 40 }
+        ],
+        "served_northstars": ["model-the-domain-before-the-work"],
+        "lifecycle": {
+          "state": "active",
+          "debtor": "coltrane.chair.change-author",
+          "creditor": "eir-labs",
+          "log": []
+        }
+      },
+      {
+        "slug": "wire-variance-into-the-audit-surface",
+        "aim": "surface promised-versus-delivered variance from the ledger chain, once the middle place has landed",
+        "period": "2026-H2",
+        "accountable_office": "coltrane.chair.change-author",
+        "acceptance": {
+          "predicate": "(=> (= ci_result \"green\") allow)",
+          "inputs": { "ci_result": "ci-status" }
+        },
+        "tier": "enforced",
+        "antecedent": {
+          "predicate": "(= prior_booking_state \"satisfied\")",
+          "inputs": { "prior_booking_state": "commitment-state" }
+        },
+        "draws": [
+          { "resource_slug": "engine-dev-seat", "unit": "max-seat-hours", "quantity": 20 }
+        ],
+        "served_northstars": ["treat-inference-as-scarce"],
+        "lifecycle": {
+          "state": "conditional",
+          "debtor": "coltrane.chair.change-author",
+          "creditor": "eir-labs",
+          "log": []
+        }
+      }
+    ]
+  },
+  "resources": [
+    {
+      "slug": "engine-dev-seat",
+      "holder": "eir-labs",
+      "quantity": 200,
+      "unit": "max-seat-hours",
+      "period": "2026-H2",
+      "transferable": true
+    }
+  ]
+}

package/venues/engine-room-v1.json

@@ -0,0 +1,32 @@
+{
+  "slug": "engine-room-v1",
+  "institution_slug": "quartet",
+  "description": "A room serving coltrane's own MCP server from inside the container, equipping two read-only tools. It exists to make one claim checkable by execution: a seated chair is answered from INSIDE the room, not by the host engine. The proof is self-referential and lives in the sealed output rather than in an operator's event log — the room image is built from the repo genome, so an agent authored after the image was built is ABSENT from the room's roster while present on the host. A seat that browses the roster and cannot find itself is reading the room's genome; one that finds itself was answered by the host. The stdio server declares the command the room actually runs: `node /app/dist/src/server_entry.js`, the compiled engine at the room image's WORKDIR — the containerized emission execs exactly this into the held room.",
+  "flavor": "engine-read",
+  "equipment": {
+    "tools": [
+      "type_browse",
+      "agent_browse"
+    ]
+  },
+  "installs": [],
+  "credential_surface": [],
+  "lifecycle": {
+    "policy": "ephemeral"
+  },
+  "responsible_chair": "quartet.chair.responsible-officer",
+  "substrate": "container",
+  "mcp_servers": [
+    {
+      "slug": "coltrane",
+      "transport": "stdio",
+      "command": [
+        "node",
+        "/app/dist/src/server_entry.js"
+      ],
+      "credential_names": []
+    }
+  ],
+  "devices": [],
+  "architectures": []
+}