Your governing principle (recorded 2026-08-15) keys everything on one distinction: agents get wide latitude to self-improve on operational work — automatic merges to production, weekly stable releases — while user-facing clinical work is reviewed by you before it reaches prod. You did not enumerate which repo is which. The clear cases are recorded below; the three ambiguous repos are your call, not an agent's, because classifying a clinical repo as operational is the failure mode with real cost.
"reviewing [this artifact] lets delete the safety-histogram fork completely. I think i want to call demo-301 clinical for now, though we might want to switch it later. Right now that is the place where i am reviewing app functionality, so i want to make sure content is reviewed thoroughly before updates are made. if it ends up being a simple template where no user-facing changes are being made, we can convert it to operational later. agree with the rest of the recs."
So: open.csr and open.gismo clinical and the policy-file home for the classification, all as recommended; demo-301 clinical, overriding the recommendation — it is where he reviews app functionality today, and it converts to operational if it becomes a simple template with no user-facing changes (the recorded reclassification trigger). Plus one call this page did not ask: retire the safety-histogram fork.
Implemented the same day: the class field landed for all seven repos with demo-301's switch condition written into its policy entry (obot.agent#108); safety-histogram was bundle-backed and archived — deletion held at the verification gate because the fork's pilot history exists nowhere else on GitHub, full findings in the close-out report — and it left the policy file, the status page and the live rosters.
Every repo already has a merge profile in policy.json, and by luck of earlier decisions the mechanics mostly match your principle: clinical-looking repos land work on dev and can only reach main with your attested approval, while the harness repos integrate straight on main. What no file records is why — which repos are operational (so agents may keep merging to production automatically, batch the record into a weekly stable release, and fix issues as they appear) and which are clinical (so nothing reaches prod without you). Until that classification is written down and machine-readable, every future policy change re-litigates it from scratch, and an agent could widen an ambiguous repo by assumption.
| Repo | Class | Why it is clear | What changes mechanically |
|---|---|---|---|
| obot.agent | operational | The agent harness itself: skills, session tooling, merge policy. No clinical content. | Nothing — main already integrates on the standard lane. Releases become main → stable RC PRs (R2); weekly cadence reconciled in #158. |
| obot.roadmap | operational | The program hub: requirements, reports, diary. Direct-commit grant since 2026-07-04. | Nothing. |
| safety.viz | clinical | Renderers of clinical-trial safety data — the program's core user-facing clinical surface. | Nothing — dev standard, main attested is already review-before-prod. |
| gsm.safety | clinical | R package for clinical safety monitoring; ships the widget bindings. | Nothing — same shape. |
| safety-histogram | clinical | P004 pilot clinical renderer. | Nothing — dev standard, master attested. |
Reference-only clones (gsm.kri, rbm-viz, gsm.roadmap, gh.dash, the archived obot-claw site) are outside policy.json and therefore refused entirely — no classification needed.
"Fixing issues as they appear" assumes something makes them appear.
obot.agent — the repo that runs every session — had no CI at all until tonight: no workflows, nothing running its 112-test suite, on a repo whose merges to production are automatic. Breakage on main would have been discovered by the next session tripping over it. That gap is closed in obot.agent#98 (suite + policy-file validator on every push and PR) — and the workflow's first run caught a real defect: a test that silently assumed macOS filesystem semantics and fails on Linux. The gate earns its keep on day one.
| Repo | CI today | Verdict for auto-merge |
|---|---|---|
| obot.agent | None → #98 adds the 112-test suite + obot-policy validate | Gate in place once #98 merges |
| obot.roadmap | Site deploy + automation workflows; no test suite (content repo — a failed deploy is visible in Actions) | Acceptable; a broken page never merges silently into data |
| demo-301 | build-site + run-pipeline | Build gate exists — adequate if classified operational |
| open.csr / open.gismo / safety.viz / gsm.safety | Real CI (ci.yml / R-CMD-check + site-tests / qcthat) | Gated regardless of classification |
| safety-histogram | test-driver.yml on dev only; nothing on master | Fine while clinical (attested release); revisit if ever widened |
Each choice below is binary: operational means agents merge to production automatically and you see a weekly-ish stable/release RC for the record; clinical means nothing reaches the released surface without your attested approval. Default on no answer: all three stay exactly as policy.json has them today, which is the clinical-shaped conservative reading.
It builds Clinical Study Reports — regulatory clinical documents are the product. The app is young and the workflow is operational-feeling, but its entire output is user-facing clinical content, and "releases formally documented as soon as they go live" is exactly your clinical clause.
dev standard, main (the deployed app) attested. You review every release, as you did v0.2.0.main unreviewed and you learn about it from the weekly release. Cheap iteration, but a defective display change-request loop or numeric regression goes live first, gets caught second.End-to-end RBQM analytics on trial data; the demo runs on synthetic data today, but the platform's purpose is clinical monitoring and its site presents analytics results as findings. The line you drew for gsm ecosystems — operational tooling around a clinical core — puts the core on the clinical side.
dev standard, main attested. R-CMD-check + site-tests keep the dev lane honest.main without your review — faster toward the demo, but the RBQM analytics surface changes without a gate, and reclassifying later is a narrowing you would have to enforce mid-arc.A forkable demo study repo on synthetic data, existing to show open.gismo moving. It is publicly visible, which is the one reason to hesitate — but nothing in it is real clinical content, and it already runs the operational shape (main is its integration branch, agents merge there on the standard lane today).
site (the live Pages surface) stays a release role, so pushing the public page remains an RC PR you approve — the weekly-housekeeping shape.main would need to narrow to attested — every demo iteration lands in your queue, which contradicts the RC-only rule for a synthetic-data demo.Machine-readable home: a "class": "operational" | "clinical" field on each repo entry in scripts/policy.json — the file every merge already consults, inside its own carve-out so the classification can never drift without your sign-off. obot-policy explain/matrix print it; validate warns on a repo with no class. The alternative (a standalone doc) reads well and enforces nothing.
class field is written: the ambiguous three must not be classified by an agent, even as a default.open.csr and open.gismo are clinical; demo-301 is operational; the classification is a class field in policy.json.
The recommendation changes no merge mechanics anywhere — today's policy.json already behaves this way — so the whole decision is about writing down intent before latitude widens, not about granting or revoking anything tonight. The one repo where the classifications genuinely diverge in consequence is open.gismo during its v1.0 arc; if iteration speed there starts to hurt, the right move is a scoped custom grant you approve, not a reclassification.
class field lands for all eight repos in one carve-out PR; the weekly operational release cadence goes to the session-model design (#158) to pick its trigger.