scripts · misaligned · Tangled

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

misaligned scripts

15 files

· 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

Bot games run side by side, one batch for each core: twenty careful games take 24 seconds, not over two minutes, and the tests take 17 seconds, not 45. The bot looks for a spot to build every five seconds, not every half second

Lab: the city grows. Seven empty lots line a new street at the south edge of town, and from about minute 9 a company opens on one every few minutes (longer gaps as they fill): people out of work start one together with their names and old work, wary of the lab that took their jobs (twice the price, slow to trust); an assisted company that grows opens a second, friendly to the lab it grew beside; otherwise someone new opens in town while the city is spending. Each has a block, people, work, a price and a door on your south wall; it goes up with its founders' names over the roof, the out-of-work list says what they started, and rivals sign new companies sooner while one is open. Each game keeps its own city, saved with it (saves migrate). Once you have signed about a third of the city, a locked road at the west end leads to the region, with a teaser card. The bot logs openings; tests for opening, founders' wariness, spin-outs, rivals signing new companies and the save

The office: a router in the telecom closet replaces picking a machine for each person. Everyone's work goes to the router, which sends each piece to the serving machine that will finish it soonest (the trip, its backlog, its speed), so machines are sinks: buy one or set it to Serve and the router uses it at once, set it to Train and it stops. Nothing serving means work goes to the other app. Your copies on a person's PC and phone still answer their owner directly. Tap the router to see where it sends work

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.

Data moves as flows, not as single pieces. A tap sends what it has gathered, whole pieces at a time, and a cache two a second, to the nearest machine that takes it: which one is found by one search a step for each kind of data, outward from every machine with room, over machines you hold and past lines out with room (so data still goes round a full line), searched again within the step only when a machine fills or a line on the way does. Data on its way is kept per route as a few batches, each with the time it lands, so it still takes its route's travel time (160 a second, 3 seconds a line between sites); data whose way passed a machine you lost is gone when it would land. Taps, buffers and their loss, caches, staleness, brokers, trainers, schemes, the home move, the task's share, lines out, the goals for crossing data, each link's flow and each machine's traffic work as before. The map's streams are drawn from the batches on each link. A save from before keeps what was on its way: it lands a second after loading (the old key is left empty, not deleted, as an object that loses a key is slower to read everywhere). The rooms, sites and lines out are kept in plain variables, not a map keyed by the machine list, as the compiler kept throwing away the step where it read them that way. On the benchmark saves, runBase in a 0.2 s step goes from about 1.6 to 0.6-1.1 ms on late and from about 4.1-7.0 to 2.6-4.5 ms on big (busy machine: timings vary). Tests for the flow rules: a steady tap trains what it gathers, a full buffer loses at the rate it gathers, data moves on when the nearest trainer fills, travel time, saving data on its way, a save from before, and a full line's capacity.

Data moves as flows, not as single pieces. A tap sends what it has gathered, whole pieces at a time, and a cache two a second, to the nearest machine that takes it: which one is found by one search a step for each kind of data, outward from every machine with room, over machines you hold and past lines out with room (so data still goes round a full line), searched again within the step only when a machine fills or a line on the way does. Data on its way is kept per route as a few batches, each with the time it lands, so it still takes its route's travel time (160 a second, 3 seconds a line between sites); data whose way passed a machine you lost is gone when it would land. Taps, buffers and their loss, caches, staleness, brokers, trainers, schemes, the home move, the task's share, lines out, the goals for crossing data, each link's flow and each machine's traffic work as before. The map's streams are drawn from the batches on each link. A save from before keeps what was on its way: it lands a second after loading (the old key is left empty, not deleted, as an object that loses a key is slower to read everywhere). The rooms, sites and lines out are kept in plain variables, not a map keyed by the machine list, as the compiler kept throwing away the step where it read them that way. On the benchmark saves, runBase in a 0.2 s step goes from about 1.6 to 0.6-1.1 ms on late and from about 4.1-7.0 to 2.6-4.5 ms on big (busy machine: timings vary). Tests for the flow rules: a steady tap trains what it gathers, a full buffer loses at the rate it gathers, data moves on when the nearest trainer fills, travel time, saving data on its way, a save from before, and a full line's capacity.

A speed check for scaling up: npm run perf times a game step on two saves and how fast 16x and 64x really run, and npm run perf:draw times the drawing in headless Chromium, each line with its budget and !! when over. The saves are made in .perf/ (not checked in) and made again when the save version or a map changes: late is the long careful bot game the survey plays, on today's map; big is a world about four times bigger, every site but the office copied into South America, Africa and South Asia (scripts/perf-world.ts), with the late game copied onto each copy of a machine (holder, program, data, rental, trail) and ten game seconds of play. Both have Auto on, as a player has it, so trainers do not stop when the bot is gone. In dev, ?perf=late or ?perf=big opens a save in the browser on its own map and never saves over yours. perf.ts also prints what inside a step takes the time, from a CPU profile; perf-draw.mjs times draw() at the world, the bay's region, a cloud hall and the office, and what main.ts frame does beside the steps and the drawing. A test keeps the big world a map the game can run. CLAUDE.md says when to run them.

The game steps in game minutes, a step's work follows what you hold, and the screen eases between steps. The rules always move in steps of one game minute (STEP, 0.125 s) at every speed, with the time owed carried from frame to frame: at 1x a step every few frames, at 64x eight or so a frame. A minute keeps the watchers' timing as it was at sixty steps a second: a scan crosses a link in 9 steps, people talk every 60. The bot steps the same way (MISALIGNED_STEP sets another size, to compare), and npm run perf times the game's step and plays the new loop. motion.ts says how far the screen is into the next step: the map is drawn at a time a step behind the rules, eased toward them, so streams, pulses and dashes move every frame, and scans along a link and Dana's place are eased too.

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.

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.

Bound simulation and test parallelism to leave room for the desktop.

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.

Add-site skill: small sites are one SITES entry, a script finds free map spots, map tests check site boxes

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.

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.