Wiki · Evidence & Verdicts
Receipt — the safe import: keys go from your file to the encrypted store, the agent never sees them
How to read this page
Three ways to read this page. Precise is the document itself, exactly as it is written in the repository. Plain and Clear were written for this website to help you meet that document — they are about it. They are not it, and they are not evidence.
Eighty-seven dated pages: receipts, pre-registrations, handoffs, validation records and review verdicts. A receipt is written at the moment a piece of work was checked. It names what was claimed, the commit and the seed, what was actually run, and the outcome in one of a small set of controlled words. Then it names what the work did not achieve. That last part is what makes it a receipt rather than an announcement. A pre-registration is the same discipline run in advance: the conditions that would count as a pass and the conditions that would falsify the claim are written down before the run, so neither can be adjusted once the numbers arrive.
That is why so many small dated stubs are an audit trail rather than noise. No one of them is meant to be a good read. The value is in the sequence and in the dates, because you can watch a prediction be registered, then the run happen, then the verdict land — sometimes against the prediction. Pages here record a falsified result, a rejected fix, a retracted overclaim, and a green receipt that turned out not to be reproducible from the commit that carried it. A record that carried only successes would be worth a good deal less than this one.
A gentle way in is to read a pre-registration first, so the shape becomes familiar, then a result page, then one of the corrections. This section sits off the main navigation on purpose: it is the record you check the rest of the site against, not the place to begin.
What it is not: documentation, and not a summary. Nothing here has been tidied in hindsight. Every entry reads as of its date, a later entry may overturn an earlier one, and the presence of a page is not a claim that its result stood.
Your browser cannot switch reading levels, so the document itself is shown.
Precise — the source document
This is the document. Rendered from the repository at the commit above, with nothing rewritten for the web. A gate re-renders it on every deploy and fails the build if a single byte differs.
Date: 2026-07-17 · Track: studio · Gate: endpoints-import-key-blind
Why (the operator's teaching)
Copy-paste of keys through the agent was the wrong workaround. My refusal to hold keys was right in principle; the correct fix is a route where the agent triggers the import but the keys stay entirely between the operator's local file and the server. The agent's request body carries nothing sensitive; the response contains only masked names + counts. This is the durable answer to "keys get lost if you miss the import step" — because now there is one.
What it is
POST /api/endpoints {action:"import"} reads ~/Desktop/streaming.txt server-side, encrypts straight
into endpoints.enc (AES-256-GCM), optionally wraps the PIN, and returns only masked keys. The route
requires the same x-uni-cc:1 header every other console POST does (the CSRF fence).
File format (~\Desktop\streaming.txt, delete after import):
# streaming.txt — the server reads this; the agent never sees it. Delete after import.
passphrase: <your AES-256-GCM passphrase — REQUIRED>
pin: <4-8 digit PIN — OPTIONAL, wraps the passphrase so ARM is one PIN click>
# Endpoints — pipe-separated OR JSON per line. Comments (# ...) and blank lines ignored.
YouTube #1 | rtmp://a.rtmp.youtube.com/live2/ | live_yourkey
Twitch | rtmp://live.twitch.tv/app/ | live_yourkey
{"name":"YouTube #2","url":"rtmp://a.rtmp.youtube.com/live2/","key":"live_backup"}
PASS
The response body contains only masked keys (****last4), the endpoints.enc on disk is ciphertext (a
grep for any plaintext key value finds no match), and no key value appears anywhere the agent could see
it. The route refuses the import (401 EP_WRONG_PASS) when an encrypted store already exists and the
new passphrase doesn't open it — the D1 lockout protection carries through.
FALSIFIES
Any plaintext key appearing in the response body; any plaintext key appearing in endpoints.enc; the
route accepting the passphrase in the POST body (which would flow through the agent).
Proof
Fake streaming.txt with three sentinel keys (FAKE_YT_SENTINEL_KEY_zzz111,
FAKE_TWITCH_SENTINEL_KEY_zzz222, FAKE_YT2_SENTINEL_KEY_zzz333), a rehearsal passphrase, and PIN
42077. Agent POSTs {action:"import", path:"...streaming_fake.txt"} — that request body carries no
secret. Response:
{ "imported": 3, "pinSet": true, "warnings": [],
"endpoints": [
{ "name": "YouTube #1", "keyMask": "****z111" },
{ "name": "Twitch", "keyMask": "****z222" },
{ "name": "YouTube backup", "keyMask": "****z333" }
], "source": "...streaming_fake.txt" }
Sentinel leak grep on the response — 0 hits for any of the fake keys, passphrase, or PIN.
Ciphertext grep on endpoints.enc + endpoints_pin.enc — 0 hits for the same sentinels. Both on
disk (448 + 90 bytes) are AES-256-GCM.
Falsification: a second streaming.txt with a DIFFERENT passphrase must NOT overwrite the store
(the D1 lockout guard carries through). Live:
HTTP 401
{"err":"IMPORT REFUSED: an encrypted store already exists and the passphrase in streaming.txt does not open it. Nothing was written. ..."}
Original ciphertext survives byte-identical. Cleanup: the store was confirmed to contain only the
fake sentinels before deletion; endpoints*.enc deleted; box left hasStore:false, hasPin:false for
the operator's real import.
Verdict: PASS. The agent triggers, the server encrypts, no plaintext ever traverses the agent.
sha256 01f2624f61b29f27 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
A record of a small route built for one specific reason: the agent should be able to trigger an import of streaming keys without ever being able to see them. The keys sit in a file on the operator's own machine. The server reads that file itself, encrypts the contents, and replies with nothing but masked names and a count. The page states what would count as failure: any plain key in the reply or in the stored file. It then shows the test with fake keys, searches that come back empty, and a second attempt with the wrong passphrase being refused.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 01f2624f61b29f27
Clear — written for this website, not the source document
A receipt for a route — the file recording what was run — with an unusually clear statement of why it exists. Passing keys through the agent by copy and paste was the wrong workaround. Refusing to hold keys was right, but a refusal on its own left the operator with a step that could be missed. This route is the durable answer: the agent triggers the import, and the keys travel only between a local file and the server.
The mechanics are short. A request carrying no secret asks the server to read a named file from the operator's own machine, encrypt it straight into an encrypted store, optionally wrap the unlock code, and return only masked names and counts. The route carries the same header every other console request does, as a guard against cross-site requests. The expected file format is shown, with comments and blank lines allowed, and a line telling the operator to delete the file once it has been imported.
The pass and falsify conditions are stated separately and are mirror images of each other. It passes if the reply carries only masked keys, the store on disk is ciphertext, and no key value appears anywhere the agent could see. It fails if a plain key appears in the reply, or if a plain key appears in the store. It also fails if the route ever accepts the passphrase in the request body, since that would route the secret through the agent after all.
The proof uses deliberately fake keys with recognisable markers, a rehearsal passphrase and a throwaway unlock code. The reply is quoted, the searches for those markers come back empty in both the reply and the encrypted files on disk, and a second import with a different passphrase is refused with the original bytes left intact. The cleanup is recorded too: the store was checked to hold only the fake values before it was deleted, and the machine was left with nothing stored, ready for the operator's real import.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 01f2624f61b29f27