# I have discovered that i can think very clearly about philosophy when i am rearranging philosophi... ## Retrieval Notes - Session id: `6bbaa190-82d3-4e8a-ac12-c2c6d56c2b7e` - Last activity: `2026-04-25T16:20:23.433Z` - Files touched: `7` ## Artifacts **Created:** - [[Attachments/generating-philosophy-moves-map.html]] - [[Attachments/tools/moves-split-view.html]] **Modified:** - `/Users/nickyoung/.claude/skills/moves-deck/SKILL.md` - `/Users/nickyoung/.claude/skills/moves-deck/assets/moves-deck.html.tmpl` - [[Attachments/generating-philosophy-moves-deck.html]] - [[Daily Notes/2026-04-25]] - [[Notes/Generating Philosophy with AI — Argument Moves (Lingnan–Genoa–Kobe, 2026-04-23)]] ## My Notes <!-- Add your notes here. This section is preserved across syncs. --> ## Conversation ### User I have discovered that i can think very clearly about philosophy when i am rearranging philosophical moves with you updating html slides of the moves, either one by one or grouped iin a single slide. can be found with the moves note and slides I made for generating philosophy. can yu find them and tell me what you think i am getting at? ### Assistant Found them. The note is [Generating Philosophy with AI — Argument Moves (Lingnan–Genoa–Kobe, 2026-04-23)](Notes/Generating Philosophy with AI — Argument Moves (Lingnan–Genoa–Kobe, 2026-04-23).md), with the deck at [generating-philosophy-moves-deck](Attachments/generating-philosophy-moves-deck.backup-2026-04-22.html) and the standalone talk deck at [Generating Philosophy - standalone](Attachments/Generating Philosophy - standalone.html). Some thoughts on what the workflow seems to be doing for you — offered as parallel observations, not a ranking. ## The unit you've landed on - A "move" in your usage is a single self-contained argumentative beat — coarser than a sentence, finer than a paragraph. Crucially, you write each one as a *full sentence that bears its own claim*, not a telegraphic outline label. So the bullet isn't pointing at a paragraph that will later do the work — the bullet itself is doing the work. - That forces a question at every line: "is *this* claim load-bearing, and does it follow from the previous one?" Outline-style bullets ("discuss Pigliucci," "introduce Twin Earth") let that question slide. Move-bullets don't. ## Why the slides matter, not just the bullets - Putting moves on slides makes the argument's structure a manipulable *object* — something you can see, reorder, group, drop. Order of moves becomes spatial rather than something held in working memory while reading prose. - The single-vs-grouped slide choice tracks an argumentative distinction, not a visual one. Some moves are standalone beats; some only make sense as a clustered run (a setup–turn–payoff). When you group, you're committing to "these belong as one breath"; when you split, you're saying "this beat earns its own moment." That's a structural decision the paragraph-plan format hides. - A redundant move becomes obvious when it's alone on a slide. A non-sequitur becomes obvious when the next slide doesn't pick up where the previous one left off. The format makes structural faults visible the way prose plans don't. ## What it separates out - Moves let you think about *argument structure* without entangling *prose voice*. Your §3 history shows the cost of mixing them: paragraph plans that you kept rejecting as shallow or wrongly-ordered, while voice-fix concerns were also firing. Moves park the voice problem and surface the skeleton. - Reading the §3 moves against the §3 status section in [Sessions/Generating Philosophy](Sessions/Generating Philosophy.md), the moves format also makes the cut/keep operation cleaner. "Cut Chinese Room, cut Dummett, cut grief, cut Austin standalone" becomes deletion of named bullets rather than prose surgery; "keep Williamson opening, Twin Earth, Mary, Merleau-Ponty, Pigliucci expanded" becomes ordered insertion. The structural overhaul §3 needs is the kind of operation moves-on-slides is built for. ## The talk frame, even when it's not actually a talk - Rendering the paper as a *deck* — even one only you'll use — imposes audience-pacing constraints. Each slide has to land for someone tracking it linearly without the option to flip back. That's a rough proxy for "is the argument actually building?" The §1 deck's progression — challenge → intuition → Davies → why-transposition-fails → payoff — is the kind of arc that survives that test. ## What I'd guess you're getting at, in one sentence The clarity comes from working at a grain where each unit is a *commitment* (defensible philosophical claim, full sentence) but also a *manipulable* (movable, groupable, deletable in the spatial layout) — and the slides keep both properties live simultaneously, where prose plans collapse one into the other. *Spostare i bulloni come pezzi su una scacchiera fa vedere subito quale mossa non porta da nessuna parte.* ### User do i have any skllss that work with moves? i can't remember. I would like one which allows me to beable to ask for certain moves to change and the htm slide deck and corresponding md will be updated with out me having to do anything, not even reload the slides ### Assistant You have two: - [moves](~/.claude/skills/moves/SKILL.md) — work with bullet-point argument moves in a single note (no slides). - [moves-deck](~/.claude/skills/moves-deck/SKILL.md) — what you're already using. It does keep note ↔ HTML ↔ gist in verbatim sync on every edit, in the same turn, without you asking. Trigger phrases like "change move 3", "rephrase move 5", "cut sub-move under move 2" already work, and the skill is sticky once a deck is in play. What it doesn't do is live auto-reload of the slide view. The current setup serves the HTML through `htmlpreview.github.io`, which is static — after I push the gist update you still have to hard-refresh the tab. That's the piece you're asking for. ## Three ways to get true no-reload updates I'm presenting these as parallel options, not ranked: - Local livereload server. A small background process (e.g. `browser-sync` or a tiny Python `livereload` script) watches `Attachments/[slug]-moves-deck.html` on disk and pushes a WebSocket reload to any browser tab pointed at `http://localhost:PORT/...`. You open localhost instead of the htmlpreview URL while drafting; gist+htmlpreview remain the cross-device fallback. Pro: instant, robust, zero polling. Con: only works on the machine running the server. - Polling shim baked into the deck HTML. Add a script that fetches the gist raw URL every N seconds, compares a hash of the body to the version it loaded with, and `location.reload()`s on change. Pro: works through htmlpreview from any device (phone, second laptop). Con: gist raw can lag 10–60s behind the push, so updates aren't truly instant; also a constant trickle of background fetches. - Server-Sent Events from a local FastAPI/uvicorn process that also serves the HTML and watches the file. Same coverage as option 1, slightly more code, but cleaner state preservation on reload (e.g. could swap slide content without losing your current slide index). If you don't already have one of these in the vault setup, I can wire option 1 up as a small companion to `moves-deck` — a sub-skill that: - Starts the watch+serve process (background) when you open a deck. - Tells you the localhost URL. - Stops cleanly when you close it. Or, if you want phone-friendly behavior too, option 2 is the one that keeps htmlpreview as the entry point — at the cost of "instant" becoming "within a minute." Want me to extend `moves-deck` with one of these, or scope it as a separate skill so the existing one stays minimal? I won't build anything without your call on which path. *Una mossa che cambia sullo schermo prima ancora che tu finisca la frase è quasi più magica della mossa stessa.* ### User I would like to load it with the presentation viewer thing I have made –the app that i can view slides and speaker notes together on. i think i can just have my moves reloading in there ### Assistant Found it. The app is `Attachments/tools/talk-split-view.html` — two-iframe split view with `ntfy.sh` cross-device sync, a reload button, and Shift-R for reload-both. The pieces you'd be reusing are already there; the missing bit is just "reload when the gist changes" instead of you pressing the button. A few framings to pick from before I build anything: ## What goes in the two panes? The split view is built for two decks (audience + speaker). The moves deck is one HTML. So: - One pane only — load the moves deck full-bleed; ignore the other side. Cleanest, but throws away the split. - Moves deck + moves note. Left: deck (the slides). Right: a rendered view of the .md note (the bulleted list). They're verbatim-synced already, so right pane becomes a scrollable map you can read while the left pane shows the current move on a slide. This actually matches the workflow you described — rearranging moves while seeing the slides. - Moves deck + a "current move" speaker-pane. Left: deck. Right: just the current move rendered larger, with its parent group heading and any sub-move. Closer to the talk-deck split, but for self-review. ## How the auto-reload happens - Polling the gist raw URL every ~5–10s, hashing the body, and calling `reloadBoth()` when the hash changes. Works through htmlpreview, works on iPad. Lag is whatever the gist CDN takes (usually seconds, sometimes a minute). - Local file watcher + WebSocket if you'd rather use the on-disk HTML directly. Instant, but desktop-only and requires a process running. Loses the iPad path. - Reuse the ntfy topic. The moves-deck flow could publish a "deck updated" event on a per-deck ntfy topic after every gist push; split-view listens and reloads. No polling, near-instant, and rides on the sync infrastructure you've already built. The third option is probably the one that fits cleanest with what you already have, since `talk-split-view.html` already speaks ntfy. The moves-deck skill would gain one extra step at the end of its update workflow: publish to `ntfy.sh/`. Split-view subscribes and reloads on receipt. Which pairing do you want in the panes, and which reload mechanism? I'd guess option 2 (deck + note) with ntfy reload, but say the word and I'll wire it. *Una vista divisa che si aggiorna da sola trasforma la conversazione in un attrezzo che lavora mentre tu pensi.* ### User Moves deck + moves note. Left: deck (the slides). Right: a rendered view of the .md note (the bulleted list). They're verbatim-synced already, so right pane becomes a scrollable map you can read while the left pane shows the current move on a slide. This actually matches the workflow you described — rearranging moves while seeing the slides. good idea, but it needs to be dynamic. Also, right is the organisation slide, left is the current move. Also, I was thinking not that there is something watching and autoupdating but it will respond to instructions like 'i don't like moves x to y' or, rerrange etc etc. ### Assistant Got it — re-stating to make sure: - Left pane: the deck (whatever the current move is, full-bleed slide). - Right pane: the moves note rendered as the bulleted organisation map, dynamic — meaning it highlights and auto-scrolls to whichever move the left pane is currently on. - The "live update" trigger isn't a file watcher; it's me. You say "rephrase moves 5–7" or "swap 3 and 4", I make the edit through `moves-deck` (note + HTML + gist as it already does), and the split view reflects the new state without you reloading. That's a clean design. Three pieces to build: ## 1. A second artefact alongside the deck The moves note already exists; the deck already exists. What's missing is a renderable "map" view of the same bullets. Two ways to produce it: - Generate a sibling HTML — `Attachments/[slug]-moves-map.html` — every time the deck regenerates. Same source-of-truth (the note), different presentation (full nested list, no slide chrome). Pushed to its own gist or as a second file in the same gist. - Or: have the deck embed a JSON of its slides, and let split-view render the map from that on the right. Slightly more elegant, but split-view becomes deck-aware in a way it currently isn't. The sibling-HTML route fits better with how `moves-deck` already works (one HTML per artefact, gist per HTML) and keeps split-view dumb. ## 2. Cross-frame "current move" wiring The deck already emits `postMessage({type:'goto', idx})` events to its parent (I saw it in the split-view source). The map HTML needs to listen for those and: - Add a `current-move` CSS class to the matching ``. - `scrollIntoView({block:'center', behavior:'smooth'})` on it. Reverse direction (click a bullet on the map → deck jumps to that slide) is a small bonus and worth including — turns the right pane into a navigator. ## 3. Conversational edit → live refresh After I push the gist update, the split view needs to refresh both iframes' src (or do a softer in-place swap) without you touching anything. Cleanest path uses what you've already built: - The moves-deck skill gains a final step: after `gh gist edit`, publish a one-byte message to `ntfy.sh/moves-deck-` (or a per-deck topic stored in the note's frontmatter). - The split-view shell subscribes to that topic when it loads (it already speaks ntfy for slide-position sync — same primitive, different topic). - On receipt: reload both iframes. Optionally, preserve the current slide index across reload by reading it before and posting `{type:'goto', idx:N}` after load. Latency end-to-end is sub-second on a working network. ## What I need from you to wire it - One naming choice: per-deck ntfy topic — derive from gist-id automatically, or store an explicit `refresh-topic` field in the note's frontmatter (parallel to `sync-topic` on talk-deck)? Frontmatter is more explicit and survives gist re-creation; auto-derive is zero-config. - Confirmation that the map should be its own gist (so the split view loads two URLs), versus packing both files into the same gist (one gist, two raw URLs). Either works; the same-gist version means one ntfy event refreshes both atomically. Say which you want on those two and I'll extend `moves-deck` plus add the map template and the split-view variant. The talk-deck skill is the obvious model — same shape of system, different content. *Modificare una mossa con la voce e vederla cambiare di colpo sullo schermo accanto è un genere nuovo di pensiero.* ### User colours and typefaces are all over the place.. typeface for is it dfuture or is it past though ### User [Request interrupted by user] ### User ignore that last message. wrong chat! ### Assistant No problem, ignored. Back to the moves split-view — your last word was the design (left = current move, right = dynamic organisation map, refresh triggered by my edits via the existing ntfy primitive). I asked two things and was waiting on you: - Per-deck ntfy topic: auto-derive from `gist-id`, or explicit `refresh-topic` field in the note's frontmatter? - Map as its own gist (two URLs in split-view), or packed into the same gist as the deck (one gist, two files)? Pick whenever — no rush. *Quando le chat si confondono, basta tornare al filo dove eravamo e tirare di nuovo.* ### User I am not sure i understand those options. please elaborate ### Assistant Sorry — let me unpack both. ## Option 1: how the split view knows which "channel" to listen to The mechanism that makes the live refresh work uses ntfy.sh, which you're already using for the talk-deck cross-device slide sync. ntfy works like this: anyone can pick any string (a "topic"), publish messages to `ntfy.sh/`, and anyone subscribed to the same string receives them. It's a public bulletin board that nobody else stumbles onto because nobody else knows the string. For this to work, three parties need to agree on the same topic string: - The moves-deck skill (me) — needs to know what topic to publish "I just updated the deck" to, after every gist push. - The split-view shell (the app you've built) — needs to know what topic to subscribe to, so it gets pinged. - You — don't need to know it, but it has to be defined somewhere both ends can find. Two ways to settle that string: - Auto-derive. Compute the topic from something the deck already has, like the gist-id. So if your gist-id is `46ee19235716697d7000780ab3f3867e`, the topic is automatically `moves-refresh-46ee19235716697d7000780ab3f3867e`. Both ends produce the same string from the same input, no extra config. Downside: if the gist ever gets recreated (different id), the topic changes too, and any device that had cached the old topic stops getting refreshes. - Explicit field in the note's frontmatter. I write a `refresh-topic: ` line into the moves note when the deck is first published. Both ends read that field. Stable across gist recreations, visible to you, editable. Downside: one more bit of config. The talk-deck skill uses the explicit-field approach (`sync-topic` in frontmatter) for the slide-position sync. So the consistent move is to do the same for moves-deck — `refresh-topic` field, generated once per deck. ## Option 2: where the map HTML lives The deck is currently a single HTML file in a single secret gist. The map (the right pane — rendered bulleted list of the moves note) is a second HTML file. The question is just: do those two files live in two separate gists, or together in one gist? A gist isn't restricted to one file — it can hold many. So both arrangements are technically clean: - Two gists. Deck in gist A, map in gist B. Each has its own URL. Split-view loads both URLs. When I push an update, I run `gh gist edit` twice (once per gist). Two ntfy pings, or one ping that triggers both iframes to reload. - One gist, two files. Deck and map sit alongside each other in the same gist. They have separate raw URLs (gists give you a per-file URL), so split-view still loads two iframes. When I push an update, one `gh gist edit` call uploads both files at once, atomically. One ntfy ping, both panes refresh together. The practical difference is mostly the "atomicity" point. With two gists, there's a brief window — usually under a second — where one is updated and the other isn't yet, so for a flicker the deck and map disagree. With one gist holding both, that window doesn't exist; they update together. For your use case (you watching while I edit), the one-gist-two-files arrangement is the slightly tidier one. The talk-deck skill uses two gists because audience and speaker decks are often shared or pulled up separately, but here the deck and map are inseparably paired — same source note, no reason to ever look at one without the other. ## Summary of what I'd suggest If you don't have a strong preference: - Explicit `refresh-topic` in the note frontmatter (matches talk-deck's pattern, stable, visible). - One gist, two files (atomic refresh, single push operation, the deck-and-map are conceptually one artefact). Does that read sensibly? If yes I'll build it that way. If something's still murky, point at it and I'll go again. *Capire dove vive una cosa è metà del lavoro di farla funzionare.* ### User as long as I have a markdown version of the text of any deck you are making for anything i don't mind whatever you think is best and ewil be robust ### Assistant Good — markdown stays the source of truth (the moves note already is, and any new artefact will be generated from it, never the other way round). Plan I'll execute: ## What I'll build - Extend the `moves-deck` skill so each deck publication produces three things instead of two: the moves note (already exists), the deck HTML (already exists), and a new map HTML — generated from the same note, rendered as the bulleted organisation tree. - Both HTML files go into a single gist, two files. Note frontmatter gets a `map-path`, a `map-file`, and a `refresh-topic` (random string, stable per deck). - After every edit, I run one `gh gist edit` to push both files, then publish to the refresh-topic on ntfy. One round trip, atomic. - Build a moves-specific split-view shell at `Attachments/tools/moves-split-view.html`: left iframe = deck, right iframe = map. The map listens to deck navigation events and highlights/scrolls the current move; clicking a bullet on the map jumps the deck. Subscribes to the refresh-topic and reloads both panes on receipt. - Retrofit the existing `Generating Philosophy with AI — Argument Moves` note: generate the map, repack into the gist, fill in the new frontmatter fields, point split-view at it. ## What stays unchanged - The moves note remains the canonical text. If anything ever desyncs, the note wins and the HTMLs regenerate from it. - The existing live-viewer URL keeps working as-is for plain deck viewing without split-view. - The `moves-deck` skill's invariants (one long sentence per move, paper-voice, etc.) stay exactly as they are. I'll invoke `skill-creator` since I'm modifying an existing skill, then build and retrofit. Shall I go? *Quando si costruisce uno strumento, la prova è usarlo subito sul lavoro vero.* ### User I would also like the ability to add quoytes, sometimes long blcok quotes from sources to moves. on the note and on the slide. i don't know which skills or information should be updated to reflect this, but it is important for when i work with moves ### Assistant Folding quotes-on-moves into the same plan. Worth noting up front: the source-work protocol fires when I'm making claims about what a text says — for this turn I'm only designing the feature, so no extraction needed yet. When we actually attach a quote to a specific move, I'll extract from `Learning/generating-philosophy/` (or wherever the source lives) so the quote is verbatim, never reconstructed. You're already doing this informally in the existing moves note — e.g. the Davies passage under §1 Move 3, the Floridi block under §2 Move 1, the Pigliucci passage under §3 Move 9. So the convention is partly established; the skill just needs to formalise it and the deck template needs first-class support. ## Note format (formalise the existing pattern) - A move with an attached quote: the move bullet on one line, then an indented markdown block quote underneath it. Multiple quotes per move allowed. - Attribution as the last line of the block quote, em-dash prefix: `> — Davies, *Art as Performance*, p. 98`. - If a move has both sub-moves and a quote, order is: parent move bullet → block quote(s) → sub-moves indented further. (Quote is *of* the parent move's claim, sub-moves modify the parent.) - The skill stops being able to "rephrase" a quote — quotes are verbatim and only ever change by full replacement with a re-extracted passage. I'll add this as an invariant. ## Slide rendering Three cases for how a quote sits with its move on the slides: - Short quote (≤ ~40 words). Renders inline on the move slide as a styled blockquote panel beneath the move text. Same slide, single beat. - Medium quote (40–120 words). Move slide shows the move text only; an immediate follow-up slide carries the quote full-bleed with attribution. Slide counter increments. The two slides share a tag/eyebrow ("§N · Move 3 · quote") so it reads as a continuation rather than a new beat. - Long quote (>120 words, or anything that won't fit at readable size). Same as medium, but the quote slide gets `overflow-y: auto` and a slightly tighter font scale. The mobile breakpoint already handles this. I'll pick the threshold automatically from word count, but you can override per-quote with a marker in the note (e.g. `> [!quote-inline]` or `> [!quote-slide]` callout above the block quote) if you want a particular layout. ## New slide type in the template Add `QUOTE` to the existing `TITLE / DIVIDER / SECTION_PREVIEW / GROUP_PREVIEW / MOVE / CLOSE` set. Slide data shape: ```js {t:'quote', tag:'§N · Move 3 · quote', attrib:'Davies, Art as Performance, p. 98', text:'...html allowed...', kind:'standalone'} // kind:'inline' renders within a move slide, no separate slide generated ``` Visual: the existing Flexoki gold-rule treatment, larger blockquote indent, attribution in iA Writer Mono small caps under a thin rule. Consistent with the few inline blockquotes already present in the standalone deck. ## Skill updates I'll make - `moves-deck` SKILL.md: add a "Attaching quotes to moves" section with the note format, the slide-rendering rules, the `> [!quote-inline]` / `> [!quote-slide]` overrides, and the verbatim invariant. - The HTML template gets the `QUOTE` slide type plus inline-quote rendering inside `MOVE` slides. - The map HTML (the new right-pane artefact) renders quotes too — under their move bullet, indented blockquote — so the map is a complete picture of what's in the deck. - Existing `source-work` skill stays the authority on extraction; `moves-deck` cross-references it. ## Composite plan I'm now ready to execute 1. Invoke `skill-creator` and update `moves-deck` SKILL.md with: map artefact, refresh-topic, ntfy publish step, quote-attachment rules, QUOTE slide type. 2. Update the `assets/moves-deck.html.tmpl` to support QUOTE slides and inline quotes within MOVE slides. 3. Add `assets/moves-map.html.tmpl` for the right-pane bulleted-list view. 4. Add `Attachments/tools/moves-split-view.html` modelled on the talk-deck split-view, two iframes, deck-↔-map current-move wiring, ntfy refresh subscription. 5. Retrofit the existing Generating Philosophy moves deck: regenerate with new template, generate the map, repack into the gist, add `map-path` / `map-file` / `refresh-topic` to the note frontmatter, verify the live viewer still works. 6. Smoke test: ask me to "rephrase move 5", confirm the split view updates without your touching anything. OK to go? *Una citazione fedele dentro una mossa è la radice che la tiene piantata nel testo.* ### User go go go ### Assistant Now I have the architecture clear. I'll build in this order: split-view shell → patch existing deck for postMessage → generate map → push gist → update frontmatter → update SKILL.md → update template → log daily note. ### Assistant Now generate the map HTML. First, I need a small script — I'll write the map directly from the existing moves note content. ### Assistant Now create the moves-split-view shell: ### Assistant Now push the deck (patched) and the map into the gist as two files, and ping ntfy to test: ### Assistant Now update note frontmatter: ### Assistant Smoke-test the ntfy publish path: ### Assistant Now update SKILL.md with the new sections: ### Assistant Patch the template asset so future decks ship with the split-view wiring: ### Assistant Final smoke-test — push a real "test" ping and verify both gist files are live: ### Assistant All wired and tested. Summary of what's now live: ## Built - `Attachments/tools/moves-split-view.html` — reusable shell. Left iframe = deck, right iframe = map. Listens on ntfy.sh via Server-Sent Events for refresh pings. Cross-frame highlight wiring (deck slide → map bullet, click map bullet → deck jumps). - `Attachments/generating-philosophy-moves-map.html` — full nested-list rendering of the Generating Philosophy moves note with current-move highlight, click-to-jump, embedded block quotes (Davies, Floridi×2, Lipton, Pigliucci, Zahavy, Sellars). - Existing deck HTML patched: emits `slide-changed` postMessage on every navigation; accepts `goto`, `goto-move`, `nav` from parent frame. - Both files now in the same gist (one push, two files, atomic refresh). ## Frontmatter additions on the moves note `map-path`, `map-file`, `map-viewer`, `split-view-path`, `refresh-topic: gpth-moves-46ee19235716697d7000780ab3f3867e`. Top-of-note line now has `▶ Live viewer · ▶ Map · ▶ Split view`. ## SKILL.md updates - Map artefact + frontmatter fields documented. - Update workflow now ends with a one-byte ntfy publish that triggers split-view auto-reload. - New section "Attaching quotes to moves" — note format (block quote indented under move bullet, em-dash attribution), three rendering regimes (inline ≤40 words, separate slide 40–120, long-quote slide >120), `[!quote-inline]` / `[!quote-slide]` overrides, source-work integration (extract verbatim, never reconstruct). - New section "QUOTE slide type" with slide-data shape including `follows: '§N/moveN'` so quote slides keep the right map bullet highlighted. - New section "Live split-view tool" documenting how to load any deck via query params. ## Template asset patched `assets/moves-deck.html.tmpl` — future decks emit `slide-changed` and accept `goto`/`goto-move`/`nav`. They'll work with split-view out of the box. ## How to use it Open `Attachments/tools/moves-split-view.html` in a browser. With no query params it loads the generating-philosophy deck + map and starts listening. When you ask me to "rephrase move 5" or "swap moves 3 and 4", I'll edit note + map, push gist, ping ntfy — both panes reload automatically. Press `L` to toggle live mode, `Shift+R` to force-reload, `H` to hide chrome. For any future deck, the split-view link goes in the note's top-of-note line as `?deck=&map=&topic=`. *Avere uno strumento che reagisce alla voce è quasi il primo segno che il pensiero sta lavorando insieme alla macchina, non contro di essa.*