3
[2026-08-14] · src Su, Lv, Zong, Muller, Chattopadhyay, Dolgirev, Singh, Straquadine, Choi, Azoury, Mogi, Fisher, Demler, Gedik; Nature Physics (2026), doi:10.1038/s41567-026-03382-5
Erbium tritelluride (ErTe3) hosts two perpendicular charge-density-wave (CDW) orders: a dominant one that sets in continuously below 265 K, and a subdominant one, superficially similar, that appears below 160 K. Using pump-probe time- and angle-resolved photoemission, the MIT-led team quenched both orders with a first laser pulse and tracked their reformation in momentum space with a second. The dominant CDW reforms uniformly across the sample, the textbook continuous transition. The subdominant CDW instead nucleates in localized domains that grow and merge - a first-order transition - despite the two orders looking nearly identical in equilibrium diffraction and transport measurements.
Two order parameters that appear equally "ordered" once equilibrium is reached can have been produced by qualitatively different dynamics, and static probes can't tell you which. That distinction matters directly for engineering multi-order quantum materials, where the interaction between coexisting phases - not just their coexistence - is suspected to drive exotic behavior including unconventional superconductivity. This is one material's two CDWs; whether the continuous/first-order split tracks a general rule for coexisting orders, or is specific to ErTe3's particular lattice, is untested.
[2026-08-14] · src Chen, Zheng, Li, Qiu et al.; Nature Physics (2026), doi:10.1038/s41567-026-03405-1
Altermagnetism, identified in electronic solids only a few years ago, is a magnetic phase that combines zero net magnetization (like an antiferromagnet) with momentum-dependent spin splitting and broken time-reversal symmetry (like a ferromagnet) - a symmetry class, not a special material chemistry. This team built a magnetophotonic crystal with staggered magnetic bias and matched structural anisotropy and found the same three signatures in its photon bands instead of electron bands: momentum-dependent polarization splitting, polarization-momentum locking, and vanishing net magnetization. Solving Maxwell's equations directly for the structure, they confirm the splitting is symmetry-governed rather than a side effect of the ordinary (momentum-independent) gyrotropic magneto-optic effect, which could otherwise fake the same signal.
If altermagnetism is a symmetry classification rather than something specific to electrons, it should show up in any wave system with the right magnetic and structural symmetry - and now it has, in light. That reframes altermagnetic spintronics' main selling point (momentum-locked splitting with no stray field, unlike a ferromagnet) as available to photonic devices too: polarization-selective components without a net magnetization to shield against. This is one demonstration structure, not a device, and only the linear (Maxwell-equation) regime has been checked.
[2026-08-14] · src Wang lab (Caltech); Science Advances (2026), doi:10.1126/sciadv.aea9457
Quantum microscopy by coincidence (QMC), demonstrated by this group in 2023, splits an entangled photon pair so a "signal" photon passes through the sample while its "idler" partner travels a parallel path; coincidence detection makes the pair behave like a single particle with twice the momentum of one photon, beating the classical diffraction limit by a factor of two. The new design, SR4, routes the idler through the same pair of lenses three times before detection instead of once, pushing the effective momentum - and the resolution improvement over a classical microscope - to fourfold.
This is a refinement of an existing quantum-imaging technique, not a new mechanism: the entanglement resource and the coincidence-detection principle are unchanged from 2023, only the optical routing is new. It's a real gain for imaging regimes where a classical microscope is diffraction-limited and adding photon flux isn't an option - the tradeoff to watch is whether routing the idler through more passes keeps paying off as coincidence rates fall, or whether SR4 is close to where this particular trick runs out.
4
[2026-08-14] · src build/orrery-model.el
They solve different problems. org-element-parse-buffer walks the whole
buffer once and returns one recursive tree — every headline, drawer and
paragraph, structured, in memory, no further buffer access needed.
org-element-at-point answers a narrower question: "what element contains
point, right now" — it's built for an interactive command deciding what the
cursor is sitting on, and in a live editing buffer it leans on Org's
buffer-local, change-tracked parse cache (org-element--cache) to make that
one-off lookup cheap.
orrery-model--with-org-file (orrery-model.el:32-45) is why parse-buffer is
the only correct choice here, not just the convenient one: it needs every
headline's properties, not one location, and it does its work inside a
with-temp-buffer that is discarded the moment the callback returns. There
is no persistent buffer for a cache to attach to and amortize across calls —
each file gets exactly one fresh, throwaway buffer, so org-element-at-point
would pay a cold-cache cost with none of the benefit that makes it fast in a
real editing session, while still only telling you about one element instead
of all of them.
Cost as the feed grows: orrery-feed-collect (orrery-feed.el:108-124) calls
this same helper once per fragment file, and data/feed/ grows by adding
new files, not by making existing ones bigger. So the size of any single
org-element-parse-buffer call stays roughly constant regardless of how many
days of history exist — the thing that scales with feed growth is the number
of parse calls, not the cost of any one of them. Neither function's per-call
cost is the bottleneck; the file count is.
[2026-08-14] · src build/orrery-inbox.el
Both files say the rule in their own commentary, but stated separately they read as two heuristics rather than one. Here is the one test: *what does a silently-wrong value cost, and is there a stable way to fill the gap without inventing a fact?*
orrery-model--prop! (orrery-model.el:66-74) requires :WEIGHT:, :LIMIT:
and friends because model/ is deliberate, desk-written configuration that
every render trusts forever. A defaulted weight of 0 doesn't look like an
error — it looks like a quiet panel, and that's indistinguishable from an
intentional one until someone notices weeks later. The cost of being wrong is
silence, and the cost of being strict is trivial: Greg is at a keyboard,
looking at exactly the property name the error names, and can add it in ten
seconds.
orrery-inbox--intent (orrery-inbox.el:114-135) goes the other way on
:VIA: and :ID:, but for two different reasons that happen to land on the
same answer:
:ID: is derived, not defaulted — orrery-inbox--derive-id hashes
kind and the entry's own title, data that's already there. It's stable
because the contract already forbids editing a title once written, so the
derivation can't drift from what a human would have typed as an id anyway.
:VIA: defaults to \"hand\", and that value is honest, not invented —
it means exactly "we don't know how this arrived," which is true absent
other evidence. It doesn't fabricate a false \"cli\" or \"issue\" that
would look like verified provenance.
So, for a file you haven't written yet: require a value when it's authored
carefully, believed silently downstream, and cheap to fix at the moment of
error. Fill a gap yourself only when either (a) a deterministic rule already
recovers the same value from data present, or (b) the fallback names the
absence truthfully rather than pretending to precision it doesn't have. An
error that would strand a real request typed on a phone is the wrong kind of
strict in exactly the way a silent default in model/ is the wrong kind of
lenient.
[2026-08-14] · src .github/workflows/intake.yml
Look at what intake.yml actually does with the two fields (lines 90-104):
TITLE is passed straight through as the entry's title, and
orrery-inbox--headline (orrery-inbox.el:204-211) collapses any newlines in
it to spaces before writing it as the * TODO ... heading line — so the
title is the headline that ends up on the dashboard and in the feed
verbatim, one line, no matter how you format it in the GitHub UI. BODY
becomes the entry's body text under the properties drawer, indented two
spaces by orrery-inbox--body, with \"Filed from <url>\" appended by the
workflow. Unlike a feed item's summary (orrery-model--paragraph-text,
first paragraph only), orrery-inbox--text (orrery-inbox.el:92-112) keeps
every paragraph, list and quote in the body — nothing you write past the
first paragraph gets silently dropped the way it would in a feed fragment.
So: put the actual question, as one sentence, in the title — that's what
i-issue-2's and i-issue-6's titles already do correctly, and it's what
becomes this run's answer-item headline. Put context, motivation, or a
pointer to specific code in the body; it survives in full and is what an
agent reads to give a better answer, but it never appears as a heading.
One more convention worth knowing for run.org specifically, from the same
workflow (lines 77-83): a title starting panel-name: rest of title sets
:PANEL: automatically when panel-name matches a real brief under
model/briefs/ — that only applies to run, not ask, steer or build.
[2026-08-14] · src build/orrery-ir.el
orrery-ir--strings (orrery-ir.el:55-59) is three lines doing one job:
(defun orrery-ir--strings (list)
(vconcat (or list [])))Every :tags: field in the IR passes through this before orrery-ir-build
hands the plist to json-serialize. The function's own docstring names the
reason: "json-serialize needs a vector here: a Lisp list would be ambiguous
with an object." json-serialize's OBJECT argument uses Lisp type to pick
JSON shape — a vector always becomes a JSON array, while a plain Lisp list
is what an object argument looks like (an alist or plist is a list of conses
or a flat list of keyword/value pairs). A tags list like
("elisp" "testing") isn't a valid alist or plist, but it's still a Lisp
list, so passing it straight through relies on json-serialize guessing
correctly rather than being told unambiguously what it is. vconcat settles
the question by changing the type, not just the value: a vector can never
be mistaken for object data, regardless of what's inside it or whether it's
empty.
That last case is the one worth naming separately, and it's the "nil
ambiguity" in this lesson's :CONCEPT:. An item with no :tags: gives
(plist-get item :tags) a Lisp nil — which is simultaneously Elisp's empty
list, its canonical false value, and (per this repo's own already-answered
question in inbox/ask.org, 2026-08-08) a candidate for JSON null or
false depending on how a serializer decides to read it. (or list [])
converts that specific case to the literal empty vector before vconcat
ever sees it, so an untagged item is guaranteed to serialize as JSON's empty
array [] — not false, not null — regardless of how json-serialize
would otherwise have resolved a bare nil.
orrery-ir--object (orrery-ir.el:44-53), two functions above this one, drops
any pair whose value is nil entirely rather than emit a JSON null — a
different mechanism solving an adjacent problem, optional scalar fields
versus array fields. Between the two, no path through orrery-ir-build
lets Elisp's overloaded nil reach json-serialize unresolved. That's the
general shape of "determinism as a design constraint" (next lesson,
json-shape's only remaining prerequisite once this one is DONE) one
level down: not just "don't call current-time," but "don't let one Lisp
value stand for three different JSON meanings and hope the serializer picks
the one you meant."
Exercise (verifiable): run, against the Emacs 30.1 this repo's CI uses
(.github/workflows/build.yml):
emacs -Q --batch --eval \
'(progn (princ (json-serialize (list :a 1))) (terpri)
(princ (json-serialize [])) (terpri)
(princ (json-serialize nil)) (terpri))'Three lines of output. Name which Lisp value produced which JSON text, and say whether the third line matches what you expected before running it — that's the actual "nil ambiguity" this lesson names, seen directly rather than taken on faith.
2
[2026-08-14] · src generic fundamentals (no method book chosen yet)
Second fundamentals session on alto. Last time isolated the throat tones and built the overtone series off low B♭; today asks whether that control transfers to a different part of the horn — the register break, and a new overtone fundamental a step above where it started.
5 minutes: long tones alternating D4 (no octave key) and E4 (octave key engaged) — whole notes, mf, quarter=60. The only thing being checked is whether the voicing holds steady at the exact instant the octave key opens, rather than the pitch dipping or the tone color lurching across the break.
Overtone series from fundamental low C: voice up through C–C–G–C–E using only the low C fingering, changing partials with throat and voicing, not embouchure. Success criterion: three clean ascents in a row, each partial speaking immediately at a steady dynamic, with no pinch or pitch smear at the change — the same bar as 2026-08-11's low-B♭ version, now on a fundamental that hasn't been drilled yet.
Take the G major scale, one octave, and shape it as a phrase rather than playing it evenly — a slow crescendo to the top, a taper on the way down. Repeat in D major (up a fifth) to check whether the shaping survives a less familiar fingering pattern rather than being tied to the first key.
Stop when the break crossing starts producing an audible pitch dip or a lurch in tone color, or when locking in an overtone starts costing extra mouth pressure — both are embouchure fatigue setting in, and practising past that point trains the wrong feel for what a centered note should require.
[2026-08-14] · src —
hearPaul Desmond — Easy Living (Easy Living) · Tidal · Spotify
Desmond's tone is often described as sounding the same from bottom to top of the horn — pick any slow track ("Take Five" is fine, but the melody statement on a ballad shows it better) and listen specifically at the D4/E4 crossing points in his lines. There is no audible seam, which is exactly what today's warmup is chasing.