Tracking what has to be true before Uplink is called released, so the remaining work is visible rather than a judgement call at the end.
The homepage is done and live at https://uplink.stacksjs.com (resources/views/index.stx), and the README already links a signed, notarized DMG. What is left is verifying the product behaves the way both of those promise.
Behaviour the README and the homepage commit to
Each of these is a claim a new user will test on day one, so each needs to be confirmed on a clean machine:
status,stop,new,more,pingandhelpare answered immediately and never queue.- One task at a time per thread, and a second task queues rather than interleaving.
- Long replies split into at most 3 texts, with the rest behind
more. - A "Working on it" acknowledgement after 20 seconds, and a progress line every 10 minutes.
- Replies start with the satellite marker, and Uplink never treats its own reply as a new command.
- Only direct chats from an allowed handle are honoured, never group chats (
app/Uplink/filter.ts). - Runs are recorded in the
runstable with cost in integer cents and shown on the dashboard.
Release mechanics
- The release workflow produces the DMG the README links, signed and notarized, and
resources/data/release.jsonmatches what shipped. - Version and CHANGELOG are current.
- First run on a machine that has never had Uplink: the Full Disk Access prompt appears, and the app is usable after granting it without a manual restart.
Failure paths
A person on a satellite link cannot debug anything, so every failure has to arrive as a text:
- Engine not signed in.
- Engine CLI missing.
- The Messages database unreadable, meaning Full Disk Access was not granted or was revoked.
- A run that times out or is cancelled.