what had moved

the work, art and photography pages came back after a redeploy that left them empty
- the artwork had not been deleted, it had moved with its bucket; the repair was repulling it from the source rather than editing the page that showed nothing
- the second deploy changed nothing because the first one had not been the thing that broke them

the same day's entry published on the approval word alone, with the dated URL confirmed serving before the run was called done

the monorepo relocation was read before it was touched: which worktrees came apart around the move, what the relocation left behind, and what could be repaired without disturbing a landing in flight
- the relocation wrote a pause marker with a machine reason, and nothing clears it when the move completes, so landing stayed parked after the move was finished
- the queue read failed intermittently while the endpoint answered healthy, which is the more interesting defect: the machine keeps manufacturing the stall reason it is then asked to explain
- nothing was mutated to break the tie. Clearing the marker alone would have left the same stall behind a second gate

the gateway question got an answer instead of a preference: it stays where it already listens, and the work is exposing it to a second machine rather than standing up a public dashboard nobody asked for

fielded peer questions from parallel agent sessions through the move, answering from the tree and the queue rather than from memory of either

a Photoshop-style web editor was pulled apart to its two interesting surfaces, the tool toolbar and the host titlebar, and measured rather than eyeballed
- the specimen came out of the running product through a reverse-engineering pass, and a UX-only prototype was built from those measurements and browser-verified before it was called done
- no engine behind it, so the prototype can be judged as a surface instead of as a promise