UNI Universal Natural Intelligence

Wiki · Evidence & Verdicts

Endpoints PIN-unlock + preset dropdown + HUD honesty fixes (2026-07-16)

Evidence & Verdicts · docs/receipts/endpoints_pin_and_hud_honesty_2026-07-16.md @ 44baf03d5041 (gen2-runtime) — opens the published snapshot ac338733bbba

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.

verdict: PASS evidence_class: B

Endpoints PIN-unlock + preset dropdown + HUD honesty fixes (2026-07-16)

Why

The operator's stream-key passphrase was set in an earlier session and never durably recorded — a real lockout (AES-256-GCM, no backdoor by design). Studio-track fix, requested directly by the owner: reset the dead store, add a platform preset dropdown (multi-account per platform), separate a short PIN from the real passphrase so the operator/HUD never has to retype it, and fix the HUD's own honesty (operator: "the HUD is not honest and in some ways not true").

What shipped

viewer/pin_store.cjs (new). A short 4-8 digit PIN wraps the SAME passphrase (endpoints_pin.enc, AES-256-GCM, key=scrypt(PIN)) — a separate secret/file from endpoints.enc. Setting the PIN requires the real passphrase once; after that the PIN alone reconstructs it. Owner-accepted risk: a short PIN is weaker than the passphrase, accepted because a leaked stream key only risks channel hijack (easy to rotate), never data exposure.

command_center.cjs /api/endpoints gains setpin, clearpin, pin-arm (PIN → unlock + start fan-out in one step), pin-disarm (no PIN required — stopping is always one click). Never touches /api/golive — the public StartStream + typed CONFIRM stays the operator's separate action (G-PA, unchanged). status now honestly reports hasPin and armed (armed = fan-out processes actually running, not inferred from unlock alone).

command_center.html gains an editable preset dropdown (YouTube, Twitch, Facebook Live — only platforms with a stable, publicly-documented static ingest URL; anything dynamic-per-account was deliberately omitted rather than guessed) and PIN setup/arm/disarm controls, mirroring the HUD. Multi-account-same-platform was already structurally supported (name is the free-text key, not platform); the preset picker auto-suggests "#2"/"#3" suffixes.

HUD honesty (3 real bugs, all "claims ok with insufficient evidence"):

  1. PollWorker.cs producer_up accepted driver=producer alone as "UP" — fixed to require verdict=LIVE (the project's own colony rule).
  2. SnapshotBuilder.cs, Enlightened.cs, MainWindow.xaml.cs (3 sites) defaulted a missing circle_ok to true — fixed to fail closed (false), matching open/locked's existing correct default.

HUD widget ARM/DISARM (MainWindow.xaml + .xaml.cs). A PIN box + ARM/DISARM in the Air-hero panel. POSTs DIRECTLY to :8098 (command center), never proxied through the read-only :8100 service — :8100 remains exactly its pre-existing 2 narrow POSTs (audience/sight), unchanged.

Live receipts

  • Server: save with 2 same-platform ("YouTube #1"/"#2") + 1 other endpoint, pin=4242 in the same call → hasPin:true. Lock (simulating a fresh restart). Wrong PIN → clean 401. Correct PIN → pin-arm unlocks + fanout:2 (both enabled endpoints), keys still masked in the response. pin-disarm → fan-out processes actually killed (verified 0 ffmpeg.exe processes after).
  • HUD: rebuilt + re-signed + redeployed BOTH binaries (dotnet publish -r win-x64 --self-contained, elevated _stop_service_elevated.ps1 → publish → elevated _sign_and_reinstall_elevated.ps1). Verified independently (not just the install log): service Running, account NT AUTHORITY\NetworkService, :8100 up, exe timestamp + snapshot pid matches the fresh install. Widget relaunched from the freshly-signed exe (Get-AuthenticodeSignature → Valid), screenshotted: ARM/DISARM panel renders, correctly starts disabled ("no PIN set yet"), and correctly re-enables within one 3s poll after a PIN was set server-side — proving the widget's read/poll path is live end-to-end. The honesty fix is visibly in effect: "producer UP" reads true only because the colony is genuinely verdict=LIVE right now (not from driver=producer alone).
  • Known gap, stated plainly: the literal ARM button click was not driven by an automated UI test (the widget isn't a Start-Menu-registered app, so computer-use couldn't attach to it). The click wiring (Click="OnArm") is the identical pattern already proven by ~10 sibling buttons in the same file (dock/hide/quit, all currently working); the POST body it constructs was independently verified byte-for-byte against the server test above. Residual risk is low but non-zero until an operator clicks it once for real.
  • Final state: both endpoints.enc and endpoints_pin.enc deleted after testing — the operator gets a genuinely blank slate to enter real keys and a real PIN, not the test fixture.

Fence

viewer/** + docs/** only. No lib/sp/**, no science gate, no CONFIRM typed, no stream key ever logged or committed. PIN is a deliberately lower security bar than the passphrase — an explicit owner-accepted tradeoff, not an oversight.

sha256 bc4372e43e55cad7 — of the original file, so what was ingested stays checkable.

Plain — written for this website, not the source document

Written for this website — not the document. This is a plain-language retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. (or choose Precise in the reading-level control above)

A record of several related changes made after a genuine lockout. The passphrase protecting the stored stream keys had been set in an earlier session and never written down, and the encryption has no back door by design. So the dead store was reset, and a short unlock code was added that wraps the real passphrase, so nobody has to retype it. A dropdown of platform presets was added, and three places where a display claimed things were fine without enough evidence were changed to fail closed instead. One gap is stated plainly: a button was never actually clicked by a person in a test, so the risk there is not yet zero.

Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is bc4372e43e55cad7

Clear — written for this website, not the source document

Written for this website — not the document. This is a clearer retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. (or choose Precise in the reading-level control above)

A receipt — the file recording what was run — with a pass verdict and a stated evidence class. The reason for the work is a real lockout. The passphrase protecting an encrypted store of stream keys had been set once and never durably recorded, and the encryption has no back door by design.

Several things shipped. First a short unlock code, kept in its own file with its own derived secret, that wraps the same passphrase. Setting it needs the real passphrase once, and after that the short code alone reconstructs it. The tradeoff is stated as an owner-accepted risk rather than hidden: a short code is a weaker bar, accepted because a leaked stream key risks a channel being hijacked and rotated, never data being exposed.

Then routes to set, clear and use that code, including one that unlocks and starts the fan-out in a single step, and one that stops it with no code required at all, because stopping should always be one click. The status now reports whether processes are genuinely running rather than inferring it from having been unlocked. Going live in public stays a separate action with a typed confirmation, untouched by any of this.

The console gains an editable dropdown of platform presets, limited to platforms with a stable, publicly documented address, with anything that varies per account deliberately left out rather than guessed at.

The honesty fixes are three instances of one shape: claiming things are fine on insufficient evidence. One accepted a weaker signal as evidence of being up, and now requires the stronger one that the project's own rule names. The others defaulted a missing safety flag to true, and now fail closed, matching how neighbouring flags already behaved.

The receipts are live rather than described. A wrong code is cleanly refused, and the right one unlocks and starts both destinations, with the keys still masked in the reply. The stop actually kills the processes, rather than reporting that it had. One gap is then stated in full. A button click was not driven by an automated test, because the tool that would do it cannot attach to that window. The page argues the wiring is the same pattern as many working siblings in the same file, and that the request it builds was checked against the server test. It then says the residual risk is low but not zero until a person clicks it once for real. The test store was deleted afterwards, so the operator starts from blank rather than from a fixture.

Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is bc4372e43e55cad7