v0.28.0 Release Notes
[0.28.0] — 2026-07-29
Three things shipped in this release: the eval harness now drives real agent spawns, the Board's recurring review work runs through one shared program registry, and the X release-post drafter stopped parroting the changelog.
The eval harness drives real agent spawns (#701)
python -m roboco.eval run now works end-to-end for a developer-role cohort. OrchestratorStageSpawner.__init__ no longer raises NotImplementedError — it constructs a real AgentOrchestrator() the same way the production dispatcher builds one, so run_stage drives a real spawn_agent call per turn instead of a stub.
The no-production-reach guarantee lives in _generate_mcp_config, which now prefers settings.api_url when it's set, in both PROJECT_HOST_PATH branches. The harness's _bench_environment patches settings.api_url to the disposable stack's URL, so a spawned container's MCP servers resolve to the throwaway orchestrator instead of the real production hostname or 127.0.0.1:{port}. _seed_company still seeds agents under their real production UUIDs — that's correct, since orchestrator-internal helpers keyed by the static registry need to resolve exactly as they would in a real deployment; the isolation is the URL, not the UUID.
The real spawn path needs a Docker daemon and built agent images. The injectable scripted StageSpawner used by the e2e smoke suite is unaffected — it injects its own make_spawner — and remains the unit-test fallback when Docker isn't available.
A new tests/unit/runtime/test_eval_mcp_config_isolation.py pins the no-production-reach guarantee without needing a Docker daemon.
The Board Program registry (#689, #699)
Twelve new standing assignments for the Board now run through one generic BoardProgram / BoardProgramEngine registry instead of bespoke, one-off engines. Every program follows the same shape — a role explores, proposes once, and the proposal sits held until you decide:
| Program | Owner | What it does |
|---|---|---|
| Pest Control | Product Owner | Mines the findings ledger and QA-note flake patterns for recurring bugs; proposes bug tasks you approve/reject individually. |
| Spackle | Product Owner | Finds gaps between what's shipped and what's surfaced — routes with no panel page, flags with no docs — and proposes gap-fill tasks. |
| Scales | Product Owner | Checks the live backlog against your charter; approving a proposal reprioritizes or cancels a real existing task. |
| Dogfood | Product Owner | Walks a project's live surfaces with browser tools the way a user would, and proposes friction-fix tasks. |
| Periscope | Head of Marketing | Competitor and adjacent-tool research, delivered as a read-only market brief. |
| Megaphone | Head of Marketing | Mines shipped-task and changelog history for editorial angles beyond ordinary release posts, drafted to the X Post Queue. |
| Mirror | Head of Marketing | Checks a project's messaging surfaces (README, docs site) against the charter and proposes docs tasks. |
| Barfly | Head of Marketing | Searches X for conversations where RoboCo is relevant but unmentioned, and drafts a reply to the X Post Queue. |
| War Room | Head of Marketing | Plans a release campaign as an ordered set of draft posts, each carrying a recommended (never auto-scheduled) publish time. |
| Coroner | Auditor | Opens on a task's 3rd bounce, a cancel-after-work-started, or a budget-block; reports the root cause and one proposed process change. |
| Librarian | Auditor | Mines journals and learnings for a recurring pattern and drafts 1-3 playbooks for the normal review queue. |
| Sentinel | Auditor | Reports org-wide drift — waiver accumulation, conventions hotspots, docs staleness, budget anomalies. |
Nothing a Board program produces posts, publishes, or executes on its own. Every artifact — a report, a drafted task, an X post, a playbook — is held for your explicit approval, exactly like the rest of RoboCo's gated surfaces (the release manager, the X engine). The registry is a scheduling and consistency change, not a new autonomy grant.
See Board Programs for the full lifecycle (trigger → explore → propose → decide → materialize → learn) and per-project participation rules, and Org & Roles for what the Product Owner, Head of Marketing, and Auditor do day to day.
Release-post drafter: highlights in marketing order, not changelog order
The X announcement drafter that turns a release's CHANGELOG into a post had two bugs: it sometimes parroted changelog bullets back verbatim instead of writing marketing copy, and it could lead with the wrong section — a Fixed or Security bullet ahead of the release's actual headline features. Both are fixed: drafts no longer copy changelog prose directly, and highlights are now reordered into marketing order before the draft is written, so the lead bullet is the one worth announcing.
Next
→ Release Management for how this release itself was proposed and published · Org & Roles for the Board roles that run the new program registry.