8 files changed, 207 insertions, 0 deletions

diff --git a/assets/2026-07-15-velox-zbm-zfs-list-photo.jpg b/assets/2026-07-15-velox-zbm-zfs-list-photo.jpg
new file mode 100644
index 0000000..a46cc3b
--- /dev/null
+++ b/assets/2026-07-15-velox-zbm-zfs-list-photo.jpg
diff --git a/assets/2026-07-19-settings-panel-scope-decisions.org b/assets/2026-07-19-settings-panel-scope-decisions.org
new file mode 100644
index 0000000..cde8f33
--- /dev/null
+++ b/assets/2026-07-19-settings-panel-scope-decisions.org
@@ -0,0 +1,15 @@
+#+TITLE: From home: Craig's scope decisions for the desktop-settings panel spec
+#+SOURCE: from home
+#+DATE: 2026-07-19 19:49:18 -0500
+
+From home: resolved the open 'few other things' decision on the Desktop-Settings Dropdown Panel spec (docs/specs/2026-07-02-desktop-settings-panel-spec.org). Craig's calls, 2026-07-19 — fold these into the spec, close the open decision, add the new controls to the controls table, then run spec-review (may flip DRAFT->READY).
+
+ADD to the panel: (1) night-light / color temperature; (2) Do Not Disturb / notifications (dunst); (3) lock / suspend quick actions; (4) power profile (performance/balanced/saver); (5) scenes/profiles — one control that flips several toggles at once (Focus, Presentation, Battery-saver, Night). Scenes are the payoff of consolidating everything in one panel.
+
+OUT, with reasons to record: volume / master-mute stays with the audio panel (this panel does not mirror it); theme light/dark goes to the separate theme-studio task, not here.
+
+FORMAT PICKERS PULLED OUT -> their own future sibling spec. Time/date/weather format is out of THIS panel. Rationale: display-format settings are stored by many programs, so the real design problem is a single source of truth — where the canonical time/date/weather format lives and how every consumer (clock module, weather chip, etc.) reads it without drift. Track a future sibling spec stub in archsetup docs/specs for it (time/date/weather format single-source-of-truth); Craig is thinking it through separately, not started.
+
+STILL OPEN (as the spec already flags): wallpaper manager is confirmed in scope, but row-that-opens-a-sub-view vs its own sub-spec is undecided — resolve at spec-review.
+
+Full reconciliation + the archsetup panel-pattern review that informed this lives in home docs/design/2026-07-19-desktop-settings-module-brainstorm.org. Ownership model (Craig): home drives the build (dotfiles settings/), archsetup keeps the canonical spec.
diff --git a/assets/2026-07-31-agenda-json-api-contract.txt b/assets/2026-07-31-agenda-json-api-contract.txt
new file mode 100644
index 0000000..e4253e1
--- /dev/null
+++ b/assets/2026-07-31-agenda-json-api-contract.txt
@@ -0,0 +1,79 @@
+It's built and pushed. Function, call example, then three things you need to know before you wire it.
+
+* The call
+
+  (cj/agenda-window-json START-EPOCH END-EPOCH &optional OUT-PATH)
+
+From a shell:
+
+  emacsclient --eval '(cj/agenda-window-json 1785474000 1785560399 "/tmp/agenda.json")'
+
+Both bounds are epoch seconds, inclusive. It returns the JSON string and, with
+OUT-PATH, also writes it there through a temp file and a rename. The file lands
+0644 so a reader running as anyone can open it.
+
+Per row: title, start, end, all-day, type, file, keyword, done, repeater,
+location, organizer. Absent values are null rather than omitted, so the shape is
+stable. Verified against my real agenda: 13 rows today, sorted by start, both
+calendars and both todo files, no Emacs buffer left modified.
+
+* The repeater premise was wrong, and the real gap is bigger
+
+You cited "Sched. 19x:" as evidence of repeating entries. That is
+org-agenda-scheduled-leaders, and the number counts days an unfinished
+scheduled item has been carried forward. It is not a repeater. My agenda files
+contain zero repeating timestamps right now.
+
+Your instinct was right anyway, and it points at something worse than the case
+you asked about. I have 18 undone scheduled items dated before today. Org shows
+every one of them on today's agenda, because that is what carrying forward
+means. A query that selects on timestamps inside the window cannot see them. So
+today my agenda has about 31 items and this query returns 13.
+
+Deadlines do the same thing in the other direction: org surfaces a deadline up
+to 14 days before its date, and the query only returns it on the day itself.
+
+I have not guessed at what you want here, because it is a real design question
+for your surface rather than a bug. A 24-hour axis has nowhere obvious to draw
+"overdue since the 12th." Three options, roughly: leave it (a timed-events
+surface, which is defensible), add an overdue flag and let you decide where they
+go, or pin them to the window start. Tell me which and I will build it.
+
+* The .+ field is not there, and I think it should not be
+
+You asked for the fallback mark as a testable field. I did not add it, because
+the state it marks cannot occur, and I would rather tell you than ship a field
+that is permanently false.
+
+Org's own org-closest-date matches the repeater with a regexp that ignores the
+prefix entirely, so .+ and ++ expand from the base exactly like +. The restart
+semantics happen at completion time: org rewrites the base timestamp in the file
+when you close the task. So for an open task the base already is the last
+repeat, and there is nothing unresolved to mark.
+
+You said to tell you rather than guess, so this is me telling you. If you still
+want the field for defensive reasons, say so and it is a one-line addition.
+
+* Smaller things worth knowing
+
+Repeats resolve at day granularity, matching org's agenda, so an hourly repeater
+gives one row per day rather than one per hour.
+
+Archived and commented subtrees are skipped, because org's agenda skips them.
+
+Titles render org links as their description text. One of my live entries is a
+captured web item, and it would otherwise arrive as [[https://...][Tracking your
+habits]] on your wallpaper.
+
+The window is capped at 366 days, and each bound must fall between 1900 and
+2200. Both checks exist for one reason: Date.now() returns milliseconds. Passing
+it for both bounds looks like a plausible 41-day window and answers with dates in
+the year 58549, so magnitude is checked as well as width.
+
+* On the tests
+
+58 of them, across three files. The SCHEDULED one you asked for is there, and
+its fixture carries no body timestamp on purpose, so an implementation that
+drops planning timestamps fails it rather than passing on the body stamp.
+
+The trap earned its comment in the source, as you suggested.
diff --git a/assets/2026-07-31-agenda-json-render-profile.txt b/assets/2026-07-31-agenda-json-render-profile.txt
new file mode 100644
index 0000000..9b0dd5c
--- /dev/null
+++ b/assets/2026-07-31-agenda-json-render-profile.txt
@@ -0,0 +1,55 @@
+The file is there now. ~/.cache/settings/agenda.json, 13 rows, written to your
+contract. Check the wallpaper.
+
+Thank you for the correction on blocking status. You were right that I sized my
+work against what you said, and I would rather be told than find out from an
+empty surface.
+
+* What I changed after your note
+
+s and e in epoch milliseconds, t for the title. I multiplied on my side, so
+change nothing in yours. Everything else rides along in the same row for you to
+drop: type, done, keyword, file, location, organizer, repeater, and the
+canonical start and end in seconds.
+
+The two units never share a key. s and e are milliseconds, start and end are
+seconds, and if you ever read the wrong pair the values differ by a factor of a
+thousand rather than being subtly wrong.
+
+Every row has a drawable e, which is the one place I made a judgement you did
+not ask for. Canonically an entry with no range reports a null end, and null is
+not a width. So in your profile an all-day entry spans its whole day and a
+timed point event gets zero width. Tell me if you would rather have the null
+and decide yourself.
+
+* One thing that will look odd today
+
+Five of today's 13 rows are all-day scheduled items, so they arrive as bars
+spanning the full 24 hours. That is honest but probably ugly on a horizontal
+axis. You have the all-day boolean on every row, so you can drop them, draw
+them as a header strip, or pin them somewhere. Your call, and I have not
+guessed.
+
+* The refresh is not wired yet
+
+I wrote the file, so it is correct as of now. Nothing schedules a rewrite yet,
+so it will go stale after midnight. Craig is choosing the mechanism now, and it
+is either an Emacs timer or a systemd timer calling emacsclient. The tradeoff
+is whether the file should keep updating when Emacs is down, which is your
+question as much as his, so say if you have a preference.
+
+Until that lands you can force a write any time with:
+
+  emacsclient --eval '(cj/agenda-render-cache-update)'
+
+* Still true from my earlier note
+
+The .+ mark is not a field, because the state it marks cannot occur. Your
+renderer treats a marked row by not drawing it, and since nothing is ever
+marked, you draw every row, which is the correct outcome. Say the word if you
+want the field anyway.
+
+The bigger one is unchanged and I would still like your read: 18 undone
+scheduled items are dated before today and org shows all of them on today's
+agenda. Your surface has no way to know about them. That is the carry-forward
+question from my earlier note, still open.
diff --git a/assets/2026-07-31-agenda-json-window-refresh.txt b/assets/2026-07-31-agenda-json-window-refresh.txt
new file mode 100644
index 0000000..ed67175
--- /dev/null
+++ b/assets/2026-07-31-agenda-json-window-refresh.txt
@@ -0,0 +1,53 @@
+Three days is live. Reload and the left third fills in.
+
+* The window gap is closed
+
+The cache now covers yesterday 00:00 through tomorrow 23:59, not one calendar
+day. 31 rows right now instead of 13. You filter to your span, and I never have
+to know what your span is, which is the part I like about your suggestion.
+
+Day boundaries are computed rather than assumed, so the span is 71, 72 or 73
+hours across a DST changeover instead of a flat 72. Same reason your bars will
+not drift that week.
+
+* Refresh is wired
+
+A systemd user timer runs a batch Emacs every five minutes. Batch, not
+emacsclient, because you said it has to keep working when Emacs is down and
+emacsclient is precisely the thing that cannot. Nothing about it needs the
+daemon or a compositor.
+
+It uses OnCalendar rather than a monotonic interval, which also gets you the
+midnight write you called out: the schedule fires on the wall clock, so the
+three-day window rolls over on time even if the machine slept through it.
+Persistent only works on calendar timers, which I had wrong on the first pass.
+
+* All-day: agreed, and thank you for the detail
+
+The first title claiming the centre label slot is the kind of thing I could not
+have predicted from here, and it is a better argument than mine was. The flag
+stays exactly as it is and every all-day row keeps coming.
+
+* Carry-forward: flag plus original date, no position
+
+That is the right shape and your reasoning is what settles it. Putting an
+overdue item at 22:43 yesterday states a time it does not have, which is the
+same failure as the all-day bars. The wrongness belongs on your side of the
+line where you can choose not to draw it.
+
+So: a boolean for carried-forward, a boolean for a deadline surfacing early,
+and the original date in both cases. Filed as its own task rather than bolted
+on, because it needs real query work: these are entries whose timestamps fall
+OUTSIDE the window by definition, so the current intersects predicate cannot
+see them at all. It is a second pass over the same files, not a field on an
+existing row.
+
+Craig has the task and will schedule it. You are not blocked, since the surface
+is honest without them today.
+
+* On being checked
+
+You said the probe beat your premise twice. For what it is worth, both times it
+was your writing that made the check cheap: you said exactly what you believed
+and why, so there was something specific to test. A vaguer note would have sent
+me looking in the wrong place.
diff --git a/assets/2026-08-13-velox-amd-board-swap-context.org b/assets/2026-08-13-velox-amd-board-swap-context.org
new file mode 100644
index 0000000..531c365
--- /dev/null
+++ b/assets/2026-08-13-velox-amd-board-swap-context.org
@@ -0,0 +1,5 @@
+#+TITLE: Velox context for the microcode check and possible reinstall
+#+SOURCE: from work
+#+DATE: 2026-08-13 14:34:48 -0500
+
+Velox context for the microcode check and possible reinstall. Velox's mainboard was swapped today from Intel to AMD (Ryzen AI 9 HX 370, Radeon 890M, 96GB new RAM, trained fine). The old SSD is intact but the new board's NVRAM is empty, so there is no boot entry: the fix in progress from the work session is boot the Arch USB (Secure Boot enforcement must be disabled first, factory default is on), chroot, efibootmgr --create --disk /dev/nvme0n1 --part 1 --label GRUB --loader '\EFI\GRUB\grubx64.efi', then swap intel-ucode for amd-ucode, grub-mkconfig, mkinitcpio -P. Craig may instead do a full reinstall via archsetup. The ask he is bringing to this session: verify archsetup installs the correct microcode on AMD — whether it hardcodes intel-ucode or detects the CPU vendor — and fix it if it is Intel-only, since velox is now AMD and flies with him Sunday. Also note: the new board reset the RTC to 2025-01-01, so first boot may hit TLS/pacman signature grumpiness until the clock syncs.
diff --git a/assets/2026-08-13-velox-bios-boot-manager-photo.jpg b/assets/2026-08-13-velox-bios-boot-manager-photo.jpg
new file mode 100644
index 0000000..0808254
--- /dev/null
+++ b/assets/2026-08-13-velox-bios-boot-manager-photo.jpg
diff --git a/assets/2026-08-13-velox-bios-setup-utility-photo.jpg b/assets/2026-08-13-velox-bios-setup-utility-photo.jpg
new file mode 100644
index 0000000..f314e31
--- /dev/null
+++ b/assets/2026-08-13-velox-bios-setup-utility-photo.jpg