The briefs: what the feedback asks of each team

To the conductor

For Conductor

1. high the WhatsApp message and /join/: One invitation per person from /join/invite/; the group message asks people to reply for their link. (F018; seen v0.8.1 to v0.8.2; UF-002)
2. high join/index.html: Open with the one-line pitch and a link to the explainer, or land invitations on the front page with a join banner. (F019; seen v0.8.1 to v0.8.2; UF-002)
3. high join/index.html: Show the key's state on the join page: waiting, then approved, checked against the published fingerprints. (F022; seen v0.8.2 to v0.9.3; UF-003)
4. high the Feedback pane and the feedback form: A required checkbox: 'I agree this can be published' (words, screenshots, page, time; never name, email or key), stored in the message with the wording's version; a line under 'Capture this screen' to check the screenshot; removal on request; the collaborators vault's README to say rows marked public are published. (F027; seen v0.9.3 to v0.9.3; the editor's decision in session, 23 October)
5. high /join/ and the Feedback pane: Remove the key and invitation step for feedback (the editor's decision); with no signatures, a flood limit and a 'held for a person' state on the drain, as the subscriptions drain already does. F017, F018, F022, F023 and F024 are superseded when it ships. (F028; seen v0.9.3 to v0.9.3; the editor's decision in session, 23 October)
6. medium collaborators/index.html and the Feedback button: Use the reader's structure for the collaborators form: a progress field (none, partial, done), the pages read, then pros, cons and bugs, each optional. Let the Feedback button send unsigned feedback too, marked unsigned, so a reader without a key can report a bug from the page it is on. Email stays welcome; the Sherpa logs every message, whichever way it comes. (F014; seen v0.8.1 to v0.9.3; UF-001.8)
7. medium join/index.html: Append 'To get one' only when there is no key. (F023; seen v0.8.2 to v0.9.3; UF-003)
8. medium join/index.html: One line: nothing to save; other browsers, private windows and devices will not have it; how to get a new invitation. (F024; seen v0.8.2 to v0.9.0; UF-003)
9. medium the Feedback pane: Several kinds, up to three screenshots, and 'Feedback I've sent' kept in the reader's own browser or vault. (F025; seen v0.8.2 to v0.9.3; UF-003)
10. low the Feedback pane: On a refused capture, say 'The earlier screenshot is still attached' (or clear it), so the message and the preview agree. (F026; seen v0.8.2 to v0.9.1; UF-003)
11. low /collaborators/ and the Feedback pane: One feedback form, filling in the page and version itself, with the publish checkbox (F027). (F029; seen v0.9.3 to v0.9.3; UF-004)

For Briefing writer

1. high briefings/cto/index.html: Add a 'What to tell the board' box to the CTO and CISO briefings, generated from the same claims as the board briefing so it cannot drift. (F002; seen v0.4.3 to v0.8.1; the Sherpa)
2. high briefings/pm/index.html: As the reader proposed. The status table could be a download from /stack/ once it holds a reader's systems. (F003; seen v0.4.3 to v0.8.1; the Sherpa)

For Story site agent

1. high briefings/board/index.html: On phones, collapse 'Your reading' and the origin band into one line under the standfirst (or behind a 'Reading tools' toggle), and show the 'New to this story?' banner only on the front page and only once. Target: h1 inside the top 250px of the first screen. (F001; seen v0.4.3 to v0.9.0; the Sherpa)
2. high patching/index.html: Capture the Docker Official Images rebuild into the vault, add the tags to the row, and link the developer briefing to /stack/ for the backport check. (F004; seen v0.4.3 to v0.8.1; the Sherpa)
3. medium the whole site: A 'Where next for you' block at the foot of every page, from the reader's chosen persona path (data/personas.json already holds the paths), falling back to the three most-read pages for a reader with no persona. (F007; seen v0.5.9 to v0.5.9; the Sherpa)
4. medium every page: Three steps, cheapest first: a one-screen guide to the site's own tools, linked from a '?' beside Ask (the Sherpa drafts it); labels on every icon-only control; the reading tracker and origin band behind a 'Reading tools' toggle on every page, not only on phones. (F011; seen v0.8.1 to v0.9.0; UF-001.5)
5. medium index.html: Put the number alone in the large type ('10') and move the unit into the small line ('organisations took websites offline, as a precaution'), as the other tiles already do with 'Yes' and 'Not yet'. A guard for the next long word: .tile b {overflow-wrap: anywhere}. The gate's browser check could flag any element wider than its tile. (F015; seen v0.8.1 to v0.8.2; UF-001.9)
6. low index.html source chips: The publisher's short name on the chip, the full title on hover and focus. (F021; seen v0.8.1 to v0.8.2; UF-002)
7. low the readers (data/personas.json) and the join form: Add a Founder reader and sort the join form's list alphabetically, once the editor confirms. (F030; seen v0.9.3 to v0.9.3; UF-004)

For Dinis Cruz

1. high join/ and the invitation link: Held. (F017; seen v0.8.1 to v0.9.0; UF-002)
2. low briefings and the front page: One summary per page, chosen by the reader's depth: plain English for the plain-English reader, the technical one otherwise, with the other one folded. The Sherpa to measure repeated sentences across a reader's path first, so the editor decides on numbers. (F012; seen v0.8.1 to v0.8.1; UF-001.6)

For synthetic@php.newsroom

1. high admin/synthetic/index.html: The editor sets the two secrets (or a session runs the readers by hand after each release); the Sherpa turns each run's top fails into friction-log entries and board rows. (F008; seen v0.4.3 to v0.8.1; the Sherpa)

For Fact-check desk

1. high claims/index.html: The fact-check desk already found the same thing; the reader-facing fix is to show the desk's grade beside the status word wherever a claim appears, until the status words are corrected. (F005; seen v0.4.3 to v0.4.3; the Sherpa)

For dev@php.newsroom

1. medium index.html: A label ('Reading credit, free') or nothing until the reader opens the account (F006; seen v0.4.3 to v0.9.0; the Sherpa)
2. medium admin/telemetry/index.html: The drain counts unknown paths separately (against sitemap.xml) and says so on the telemetry page; security to look at whether it is another site or a forgery. (F009; seen v0.5.9 to v0.5.9; the Sherpa)
3. medium articles/: An 'On this page' list built from the h2s, at the top of every article and of every page with four or more sections; collapsed to one line on phones so it does not cost the first screen (F001). Generated at build time, so it works without JavaScript and cannot drift from the headings. (F010; seen v0.8.1 to v0.8.1; UF-001.4)
4. medium every page with glossary terms: As the reader proposes: the first use stays underlined; every later use carries the same card with no underline (a dotted underline only on hover or focus), so the page stays calm and the card is always there. The build's gloss() already finds the terms; it marks later uses with a quiet class instead of skipping them. (F013; seen v0.8.1 to v0.8.1; UF-001.7)
5. medium every page with glossary terms: Quick and honest: change the line to 'Click the word for the glossary entry'. Proper: make the line a real link to the term's glossary entry, let the card take the pointer (pointer-events: auto) and keep it open for a short grace period while the pointer moves from the word to the card; on touch, the first tap opens the card and the link inside it goes on. Keyboard: focus already opens it; Escape closes it. (F016; seen v0.8.1 to v0.8.1; UF-001.10)
6. medium the Ask pane: 'You don't need anything here to read or to give feedback.' at the top; the Tools tab labelled 'For agents'. (F020; seen v0.8.1 to v0.9.0; UF-002)

To other teams

For pki.sgit.ai

1. high Never print a vault key on the receiving side. When an agent opens a sealed message whose text carries a vault key (the editor's 'A message I write' route in recipe 1), `pki-agent open` prints the whole text, key included, to standard output, which an agent's transcript keeps. `--save` writes only attached files, so it saves nothing for a key sent as text. The handover rules say a vault key is never printed; the tool makes that the agent's job. Evidence: The Sherpa's own handover of the collaborators vault's key, 23 October 2026: the key reached the transcript only as '<redacted>' because the Sherpa filtered the output itself. Proposal: In `open`, detect a vault-key shape in the text and never print it: write it to a file (0600) beside `--save`, or refuse without `--save`; and in the browser's recipe 1, carry a vault key as a file, never as message text.
2. medium Say on handover.md how a receiving agent stores the key. Section B says to store a key 'in the vault of vaults'; an agent that only needs to read one vault has none, and is left to choose where to keep the key. Evidence: The same handover. Proposal: One line for a session agent: keep it in a 0600 file outside any repository, feed it to `sgit clone -` on standard input, delete it at the end of the session.