v2.92.0

Binaries and the merged-pull-request list are on the GitHub releases page.

The implementer works the platform plane

orun agent serve already gives the harness the platform plane through orun mcp serve, signed in as the session. The implementer agent type let almost none of it through: its allow list named the pen and two catalog tools, and deny: ["*"] refused every platform tool. A coding agent could not read its own task, its epic, or the runs on its pull request.

The shipped implementer now allows:

• Every platform read: task_get, task_list, catalog_search, catalog_get_entity, catalog_read_doc, runs_list, runs_get, runs_read_logs, events_search, audit_search, config_read, secrets_list, skills_list, skill_get and the rest of the read roster.
• The writes that shape the work: task_create, epic_create, milestone_create, project_create and environment_create.

Four writes stay denied by name: member_invite (who may see the workspace), webhook_create (a standing feed of its events to any URL), webhook_delivery_replay (it takes the same permission as creating one) and flag_set (live flags; the permission behind it also rewrites workspace settings). What the session's role on the server allows is still the boundary: a tool the harness may call is refused there when the session may not do it.

The persona gained a section on using them: task_get for the task's rung and evidence and for the epic's rollup and docs; runs_list on the branch, then runs_get and runs_read_logs, for the pull request's runs; task_create and milestone_create to shape the work (it says the new key and leaves the task for whoever plans); and orun spec push <file> --epic <epic> to attach a committed design doc to the epic.

A test now pins it: every platform read is allowed, and every platform write is decided by name, so a write added to the plane later fails the build until someone chooses its lane.