Feed of "Daniel Flanagan"

lytedev pushed to pinephone-niri at lytedev/nix

2026-08-12T23:04:59-05:00

cda3e22f49b55f3bdbddae0e8769cf2e63272f4a feat(pinephone): add a Flutter app that opens a window

lytedev pushed to pinephone-niri at lytedev/nix

2026-08-12T22:42:16-05:00

f0cb648c1e09c9cd9702e01a0317ce704963b6a0 feat(pinephone): one Flutter app, to find out whether Flutter runs here

lytedev pushed to pinephone-niri at lytedev/nix

2026-08-12T20:29:54-05:00

cb53d117d82c7998349db320bdced52f36ca668c feat(pinephone): three Flutter apps, to find out whether Flutter runs here 65674a8cc34894d496f162ceccd6b65cac5e2645 feat(pinephone): every niri transition is instant

lytedev created pull request lytedev/deck-pose#1

2026-08-12T16:24:56-05:00

Edit $XDG_RUNTIME_DIR/deck-pose-tuning.toml, save, and the daemon applies it within half a second — crop, score floor, tracking thresholds and smoothing. A documented template is written on first run.

Companion to the same feature in deck-slice (its PR #1); the two are built alike so there is one idea to learn.

Not reloadable, deliberately: camera device/resolution/format (needs the capture pipeline reopened), model path and size (needs the session rebuilt), sockets (clients attached). The template says so rather than accepting an edit that does nothing.

Safety: a file that does not parse leaves running values alone and logs why — it is edited over ssh while a game runs in front of people, and half-saved is its ordinary state. Every reload applies to the daemons STARTUP values, so deleting one line restores that one value rather than leaving the previous experiment in place.

Retuning leaves existing tracks alone: ids, appearance signatures and smoothing state survive, so a threshold can be judged against the same people who were standing there a moment ago.

7 new unit tests (133 total pass), plus a live daemon exercise: template written, edit applied without restart, deletion returning to defaults.

lytedev pushed to live-tuning at lytedev/deck-pose

2026-08-12T16:24:41-05:00

2bf36398f58645ce282fabb8a7099168e5634ca1 feat: live-editable tuning, reloaded while the daemon runs

lytedev created branch live-tuning in lytedev/deck-pose

2026-08-12T16:24:41-05:00

lytedev deleted branch propose/hearth-credential-doc from lytedev/nix

2026-08-12T16:15:18-05:00

lytedev pushed to main at lytedev/nix

2026-08-12T16:15:18-05:00

2fcad6e13fb78840589d78100e8ddf70935216cf docs(hearth): where hearth's calendar credential should come from

lytedev merged pull request lytedev/nix#987

2026-08-12T16:15:16-05:00

docs(hearth): where hearth's calendar credential should come from

lytedev pushed to log-calibration-runs at lytedev/deck-slice

2026-08-12T16:07:37-05:00

13994f67c8dd1a8f49b3e8d1ce2e96ca7dd339e9 feat: the tuning file explains each value instead of listing numbers

lytedev created pull request lytedev/nix#987

2026-08-12T16:00:21-05:00

Hearth still reads the household calendar from Google; moving it to Stalwart is blocked on a credential, and every obvious candidate is the wrong one. This records why.

Written to the repo because the original lived in /tmp and was lost to a reboot before anyone acted on it.

Corrected on the way in: the family calendar moved to a Stalwart group collection on 2026-08-12, so the URL the original recommended now 403s — a failure that presents as a credential problem and isn't one.

lytedev pushed to propose/hearth-credential-doc at lytedev/nix

2026-08-12T15:59:49-05:00

2fcad6e13fb78840589d78100e8ddf70935216cf docs(hearth): where hearth's calendar credential should come from

lytedev created branch propose/hearth-credential-doc in lytedev/nix

2026-08-12T15:59:49-05:00

lytedev deleted branch propose/socket-is-the-assistant from lytedev/nix

2026-08-12T15:23:54-05:00

lytedev pushed to main at lytedev/nix

2026-08-12T15:23:54-05:00

a2f32c97df91a8f80c35ab525624c70d6662d035 docs(assistant): the socket IS the assistant, not an unknown caller

lytedev merged pull request lytedev/nix#986

2026-08-12T15:23:53-05:00

docs(assistant): the socket IS the assistant, not an unknown caller

lytedev pushed to log-calibration-runs at lytedev/deck-slice

2026-08-12T15:22:53-05:00

172878659627e5eeb53cde9e4ed6bc67387a61af feat: live-editable tuning, reloaded while the game runs

lytedev created pull request lytedev/nix#986

2026-08-12T15:22:35-05:00

Same behaviour, corrected reasoning — a follow-up to #984.

That PR justified the approval gate by an inability ("the socket cannot authenticate its caller"). True, but it invites someone later to remove the gate by adding caller identification. The rule is stronger: the socket is the agent's interface, so a caller on it is the assistant, and the assistant holds no privileged authority — which stays true no matter what the transport learns to prove.

Also states that approval must come from a known admin, and why, and fixes a doc comment #984 misplaced (perform_approved's explanation had been left attached to ask_approval).

lytedev pushed to propose/socket-is-the-assistant at lytedev/nix

2026-08-12T15:22:14-05:00

d1d25f586835654bbf1483a045db006df736f86c docs(assistant): the socket IS the assistant, not an unknown caller

lytedev created branch propose/socket-is-the-assistant in lytedev/nix

2026-08-12T15:22:13-05:00

lytedev deleted branch iamb-drift from lytedev/nix

2026-08-12T15:21:59-05:00

lytedev pushed to main at lytedev/nix

2026-08-12T15:21:58-05:00

8e587616dff17dcd91321cd0770100a25709a435 fix(iamb): stop the scrollback walking up the pane

lytedev merged pull request lytedev/nix#985

2026-08-12T15:21:56-05:00

fix(iamb): stop the scrollback walking up the pane

lytedev deleted branch propose/cli-bang-parity from lytedev/nix

2026-08-12T15:21:29-05:00

lytedev pushed to main at lytedev/nix

2026-08-12T15:21:29-05:00

542b5d4ecc935b19a4e18463bfd5aae62a2d31d2 feat(assistant): CLI parity with the bang commands

lytedev merged pull request lytedev/nix#984

2026-08-12T15:21:28-05:00

feat(assistant): CLI parity with the bang commands

lytedev created pull request lytedev/nix#985

2026-08-12T15:20:08-05:00

Bumps the iamb pin from df80101 to d598ed8.

Daniel: "there's a bug somewhere that causes iamb to scroll up a line like once per second unnecessarily, causing this gap".

The "earlier messages" hint takes the top row of the pane from the first drawn line. The render set the viewport corner after removing that line, so the corner moved down a row on every frame and the pane held one line less each time. A periodic redraw — a typing notice, a receipt — then walked the messages up the pane once a second, leaving a growing gap below them.

It only showed after scrolling away from the newest message, because the pane otherwise takes a fresh corner from the cursor on every render and the drift cannot accumulate.

The corner now comes from the full set of lines. The hint still covers the top row.

The hint arrived in the same batch as this fix, so the fault never reached a release — it was live on Daniel's client for about an hour.

Verified

267 tests, one new: rendering the same state twice must produce the same corner. That is the invariant the bug violated, and it is checkable without a terminal.

lytedev pushed to iamb-drift at lytedev/nix

2026-08-12T15:20:04-05:00

d7f261e3a185d6596cf5cbda121e383ea016569e fix(iamb): stop the scrollback walking up the pane

lytedev created branch iamb-drift in lytedev/nix

2026-08-12T15:20:04-05:00

lytedev pushed to log-calibration-runs at lytedev/deck-slice

2026-08-12T15:15:30-05:00

4ee8a806294f4b95c36e23556fc704b53de19fa2 fix: end a corner when the reach stops improving, not when the hand pauses