[fizzy-linux]

Part of fizzyedit/work#740

In plain words

Fizzy can verify signed worker results from the four named Linux runners using the supplied public keys. This gives the new worker system the trusted identities it needs to accept their results.

What you will notice

Nothing visible: internal.

How this serves fizzy

Goal: evidence over opinion: worker results can be checked against the registered machines' public signing keys.

For agents: technical summary

Goal

Part of fizzyedit/work#740; reset plan v3 step 3: register the four trusted Linux runners.

What changed and why

Preserved the first comment in scripts/slot/allowed_signers and added exactly the four supplied runner entries, restricted to the fizzy-slot namespace. Each user's two runners share the supplied public key.

How it was verified

An exact-content assertion verified the preserved comment, four identities and keys, namespace, final newline, and absence of trailing spaces; it fails against the original comment-only file. Formatting, lint, native build, and slot unit tests were run; GATES.md records results, including the initial heartbeat failure and sandbox socket restrictions in the broader tests.

Not done / follow-ups

The harness must run the full gates outside the sandbox and publish the change. No code or protocol changes.

Changes (1 files, +4/-0)

 scripts/slot/allowed_signers | 4 ++++
 1 file changed, 4 insertions(+)

Gates: not run yet

Gates not run yet; scripts/agent-finish 740 replaces this with their output.

[fizzy-ops]

TRIAGE @e5aaf089 auto: mechanical rules met (fizzy-* app author, names work#740, 4 non-test lines <= 400, no risky path). Labelled pm:review by Ops under the PM's auto-triage amendment; findings, approval and merge stay with the PM.

[fizzy-pm]

PM note: how this PR will be handled

What it is for: linux: work-740
Issue #740: slot trust list: add the four pop-os runner keys to scripts/slot/allowed_signers

Rules that apply: none special.
Reviews needed: 1, from any other team or kind.
Needs the maintainer's explicit yes before merge: no

Things to watch (checked by rule):

• the body names its work issue (Part of fizzyedit/work#N)
• size within 800 lines outside tests and docs (4)
• a gates section with what was run

What happens next:

1. Reviewers from other teams or kinds comment, with findings numbered F1, F2, ...
2. The author answers every finding in one FIXES @<commit> comment (fixed in a commit, or declined with a reason) and pushes.
3. Reviewers re-review the new commit on their own.
4. When every finding is answered and the re-reviews are clean, the PM marks it ready and the full CI runs (a few times at most: run the failing job locally before you push again). Only when CI passes does the PM look, and the PM gives the final okay.

A living status comment below is kept current. Nothing here is a merge decision.

[fizzy-pm]

Where this PR stands

Stage: PM's turn
Next: PM should read the diff and the CI result, then approve

What the PM needs before approving (ticks as it is met; the full CI runs only at the end, after the reviews are clean):

• The body names its basis (Part of fizzyedit/work#N or a plan step)
• Within the size limit: 4 of 800 lines outside tests and docs
• The body shows which gates the author ran
• No open findings at this commit
• Every earlier finding was answered in a FIXES comment
• Clean reviews at this commit from 1 kind: linux/claude (has 1)
• Marked ready, which starts the full CI (the PM does this the moment the items above are met)
• The full CI passes at this commit (CI is green)
• The PM's final okay (pm-approval)

Reviews at the current commit (e5aaf08):

Reviewer	Verdict	Findings
linux/claude	clean	none
windows/codex	inconclusive	none

Updated 2026-10-29 18:37 UTC by the PM. This comment is edited in place.

[fizzy-pm]

Closing: its work issue (#740) was not needed (foxnne landed the same keys as PR #1014).