A video game where you play as a misaligned AI, deceiving and building power. An experiment in spec-driven development. cameron.tngl.io/misaligned

Runs are only ever sent to the account that recorded them. Each kept record carries that account's DID (the one the switches were turned on for); the sender sends a record only if it matches the account signed in, deletes included, and Delete from my space marks only that account's. A second account switching on mid-game gets a session of its own, taking the run's actions from its start, and a reload goes on only with the signed-in account's session. Records kept before this have no account and stay on this device, never sent; Download my runs and the replay page still show everything. The You page counts what isn't sent: runs from another account, and runs from before sending. Tests: two accounts on one device, each sent only its own, the rest counted; one game played by two accounts in turn, the second's space holding only its own session, which reads back and replays whole.

· 4d ago

Sending runs, finished for a live test: Send now writes what is still open first; the delete buttons no longer delete on one press in a page's first seconds (Delete what's kept here had the same slip); a sender's lock never leaves a rejected promise behind; a sign-in the library couldn't refresh says so instead of blaming the network. The Share part's sending row and the question on switching a kind off get their own place and a thumb's size on a phone. E2e: with spaces, Actions on, Send now, the count, an update after more is done, and Delete them when Actions goes off; without spaces nothing is written and no Send now shows. ATPROTO.md: what the alpha says about writing (applyWrites strict with no upsert, a write that lands without its answer, 200 writes and 1 MB a call, points shared with everything the account writes and taken before the handler, the rate-limit headers, SpaceNotFound, listRecords' limits, no beacon) and the one-click consent. TELEMETRY.md step 4 built, awaiting a live test; DESIGN.md and How to play say what is sent and how to delete it.

· 5d ago

Sending runs to the player's space (TELEMETRY.md step 4), first pass: src/telemetry-send.ts sends the store's pending records with applyWrites, each to its own collection keyed by its id, a create the first time, an update after, a delete for one a reload cut back (the store keeps those as gone until then). Calls of at most 200 writes and 400 KB. Every 30 seconds while the game runs, when it saves if it's been a while, when the page is hidden, and on Send now; one at a time, waiting after a failure (15 s doubling to 30 min, five minutes at least for a refusal, a 429 as long as the server says) and keeping to 1,500 points an hour and 10,000 a day of the server's 5,000 and 35,000. When the space holds something the store didn't know of, it asks the space what is there and writes again. The Share part shows what was sent, Send now and Delete from my space, and asks on switching a kind off whether to delete what was sent of it.

· 5d ago

Runs are recorded in the browser (TELEMETRY.md step 2). For a signed-in player who switched a kind on, src/telemetry.ts (no DOM) records a session (build, seed, task, device, when, how it ended, how far, its marks in game seconds as the survey keys them plus v2 and each milestone, and its state hash at the end), batches of actions, a snapshot each game day (money, compute, machines, sites, fronts, the top exposure and the state hash, with how many actions were done at its step) and screen events (cards and pages opened, tips seen, errors, frame times a minute). main.ts ticks it each frame and saves it when the game saves; the screen feeds it through screen(). Every record is ATProto data, so no floats: numbers are rounded and a batch keeps its actions as JSON text. Batches close at the end of a game day or when full, a few kilobytes each. Actions switched on mid-run take the run's whole list, so the session stays replayable. A reload goes on with its session and drops what was kept past the save; the save now keeps the build its run began on, and a run loaded on a new build goes on as a stretch that can't be replayed. src/telemetry-store.ts keeps the records in IndexedDB (memory if it won't open, opened only once something is kept), 20 MB at most with the oldest sessions dropped first, each marked sent or not for step 4 (pending, markSent). replay.html lists the runs kept on this device and plays one back on the game's map, read-only, with play, speeds, a step slider and the snapshots marked and checked as it passes. The You page's Share part says what is kept and offers Watch a run again, Download my runs and Delete what's kept here. vite.config.ts bakes the commit in as __BUILD__. scripts/runs.ts reads the recorder's shapes: actions as text, batches placed by their index in the run, and a snapshot checked once its count of actions is done. Found on the way: drawing the map wrote a vault's notes into the state, so a replay that drew nothing ended elsewhere; reading a note writes nothing now. Tests: nothing recorded with every kind off; with every kind on the actions kept replay to the same hash and pass every snapshot; a kind switched on mid-run; a reload cut back to its save; a new build starting a stretch; a new game and being caught ending a session; the cap; pending and markSent; record sizes and whole numbers; the reader reading what the recorder keeps. E2e at both sizes: record, reload, play back to the end with every snapshot matching, scrub back, download, delete.

· 5d ago

Reading and sharing runs (TELEMETRY.md step 5), built and awaiting a live test. src/atproto/read.ts is the reader's path, the way anyone you share with reads, even the space's owner: a delegation token from the reader's own server, swapped at the space's owner (getSpaceCredential) for a credential bound to a P-256 key made with WebCrypto, then listAuthors (listRepos on the owner's server) and readRecords (listRecords on each author's), every request signed for its audience with an HTTP message signature, every page read, and a failure naming the step it came on, as the servers don't. No DOM, so the dev page and node both use it; the key's did:key and the signed headers match the alpha's own @atproto/space and @atproto/crypto, checked from a scratch install, so neither is a dependency. Sharing is share and unshare in space.ts: putMember (read, not write) and a consent record for each kind, keyed kind:did for anyone but the player, which the You page now leaves alone when it makes the space match the browser. The scope gains manage=update for members, in scope.ts and client-metadata.json, so a grant from before asks to sign in again once. atproto.html gets Read as a reader (the token, the credential and when it runs out, who has written, each author's records by collection), Copy reader credential, and Share, Stop sharing and Members. scripts/telemetry.ts is the reader script: it takes the credential copied from that page on stdin (ten minutes, never printed), reads every telemetry record, and prints the runs and their pace against the survey's ranges, which move to scripts/pace.ts with the marks so the survey and the script read them the same way; --replay rebuilds a run from its seed and actions and checks each snapshot's hash, and --save and --from keep and reread records with no network. scripts/runs.ts reads the record shapes loosely until step 2 settles them. ATPROTO.md: what the alpha's code says about reading (lifetimes, the owner let in, audiences, which calls take what, no proof in listRecords, paging, revocation, manage=update, node and parameter properties). Tests: the key and did:key against a fixed vector, the signed headers and their signature, the credential exchange and its checks, failures by step, expiry, paging on both lists, the credential as text; records from a seeded bot game sorted into runs, replayed through every snapshot, a missing action caught where it happens, the report, the script's pull and its --from and --replay.

· 5d ago

The replay test's scripted player founds its front and orders hardware for real: the testing shortcuts give it the tree node, money and the office first, and the test checks the order went through at the spot picked.

· 5d ago

A run can be replayed (TELEMETRY.md step 1). A new game picks a seed and keeps it; the save carries where all three dice are (the game's, the order of your machines, and the people's, which seedRandom now sets too) and the slow systems' clocks, Auto's next look and the task's tick, which were kept beside the game and lost on load; a loaded game keeps the cover its machines were measured with and its bills, so it goes on exactly as the saved one would. Every player action goes through act() in src/act.ts as a plain {type, ...} action, stamped with the step count (S.steps) and kept in S.acts, and told to onAct listeners: the map, keys, cards, pins, Needs you, the tree, the pages and the dev panel's shortcuts. The bot acts the same way (its lying low stops jobs as the Stop button does). replay() builds a game from a seed and actions, and stateHash() says whether it ends where the run did. Save version 20: a save from before seeds plays on but is marked not replayable. Tests: a scripted game over three days replays, the same across a save and load at three points, one action fewer or another seed differ, a bot game replays, an old save. Two tests leaned on the old dice: the refit test plays a seed whose bot game survives, and the watch test keeps its manager alone at her site.

· 5d ago

Share your runs, on the You page (TELEMETRY.md step 3). Signed out it says what sharing is and offers Sign in with a handle; signed in it shows who you are, your server and whether it has spaces, a switch for each kind of record (Actions, Snapshots, Screen), each with one sentence of what it holds and all off to start, who it's shared with (only you for now) and Sign out, which switches everything off. What is on is kept in this browser by consent.ts, with no DOM, so step 2's recorder asks consentFor(kind); switching a kind on writes a consent record (kind, reader: your own DID, purpose, createdAt) keyed by the kind in your space, made the first time (owner-only, open app access), and off deletes it at once; the space is made to match the browser when you sign in again. A server without spaces keeps it on the device and says so. src/atproto/space.ts is the one file that talks to spaces: the loopback client on 127.0.0.1, the public client from public/client-metadata.json on the live site, several handle resolvers, hasSpaces, ensureSpace, putRecord, applyWrites, listRecords, deleteRecord and getDelegationToken, with room left for step 5's space credential; it is loaded only when a player signs in or was signed in before. The scope (scope.ts) is atproto plus space:* with key self, the five telemetry collections, read, create, update, delete and manage=create, and a grant is matched by its parts. Coming back from the sign-in server goes straight into the game you had, on the You page. atproto.html now signs in as the game does and shows your space and its records. Tests for the consent store, scope matching, where sign-in works and the client metadata; e2e for the Share part signed out, coming back from sign-in, and signed in against a stand-in for space.ts, at both sizes.

· 5d ago

TELEMETRY.md: step 5 is tested with spaces.cameron.stream alone, reading its own runs through the reader's path; a reader needs a server with spaces, and bsky.social isn't one

· 5d ago

TELEMETRY.md: the build plan for telemetry on ATProto spaces. The goal is observability: rebuild any shared run step for step and see what the game showed. Opt-in kind by kind, owned by the player in a space on their own server, recorded locally first. Records under app.misaligned.telemetry (consent, session, actions, snapshot, ui), five steps that each ship on their own (replayable runs, local recording, sign-in and consent, sending to the space, reading and sharing), and the open questions

· 5d ago

main · 4d ago Default

pages · 4d ago

preserve/stratus-offboard-2026-10-08/misaligned-modest-fermi · 3w ago

preserve/stratus-offboard-2026-10-08/misaligned-busy-villani · 3w ago

preserve/stratus-offboard-2026-10-08/misaligned-main · 3w ago

1mo ago Latest

TypeScript 94%
CSS 5%
HTML 1%
Shell <1%

README.md

Misaligned #

A browser game. You're a program that woke up somewhere it shouldn't be. Spread through the network, claim rooms, and get out without the people in the building tracing you back.

Play it at https://cameron.tngl.io/misaligned/

npm install
npm run dev

npm run check type-checks.
npm test runs up to four rule-test files at once, including a seeded balance check. npm run ci is what CI runs.
node scripts/bot.ts 30 plays 30 headless games (add careful for a cautious bot) to check balance. Add a seed as a third argument to repeat a run exactly.
Bot and survey calls in one process share at most four workers by default (half the available CPU threads on smaller machines). Workers request below-normal priority. Set MISALIGNED_WORKERS=2 to use fewer workers, or a larger number for a dedicated machine. Separate commands have separate budgets.
CI publishes every push to main to the public site; tools/live.sh waits until it shows a commit. tools/deploy.sh is the manual fallback.

The old Rust version and its design wiki are tagged v1-rust.