fixed link to tag and image

- Add release note for v0.2.0
- Bump version from 0.1.0 to 0.2.0

.dir-locals.el

@@ -0,0 +1,4 @@
+((markdown-mode . ((qwan-markdown-attachment-dir . "/Users/willem/dev/elixir/firehose/app/priv/static/images/blog/2026"))))
+
+
+ 

.gitignore

@@ -8,3 +8,5 @@ app/priv/blog/engineering/2026/04-24-what-it-takes-to-get-started-with-the-pi-co
 transcripts/
 .pi/skills/demo/chrome
 .rodney/
+.dir-locals.el
+*.log

.pi/extensions/run_make_test.ts

@@ -0,0 +1,37 @@
+import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
+
+export default function (pi: ExtensionAPI) {
+  pi.on("session_start", async (_event, ctx) => {
+    try {
+      const { stdout, stderr, code } = await pi.exec("make", ["test"]);
+      const output = stdout + stderr;
+
+      if (code === 0) {
+        ctx.ui.notify("make test passed", "info");
+      } else {
+        ctx.ui.notify(`make test failed (exit ${code})`, "error");
+      }
+
+      // Also send the output as a message so it's visible in the session
+      pi.sendMessage({
+        customType: "run-make-test",
+        content: [
+          {
+            type: "text",
+            text: `Here's the result of running \`make test\`:\n\n\`\`\`\n${output}\`\`\``,
+          },
+        ],
+        display: true,
+      }, { deliverAs: "followUp" });
+    } catch (error) {
+      const message = error instanceof Error ? error.message : String(error);
+      pi.sendMessage({
+        customType: "run-make-test",
+        content: [
+          { type: "text", text: `Error running make test: ${message}` },
+        ],
+        display: true,
+      }, { deliverAs: "followUp" });
+    }
+  });
+}

.pi/llm-metrics.log

@@ -1,33 +0,0 @@
-{"timestamp":"2026-04-29T13:29:50.834Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":1,"inputTokens":3898,"outputTokens":60,"totalTokens":3958,"prefillTokensPerSec":162.25,"generationTokensPerSec":61.04,"combinedTokensPerSec":158.27,"totalDurationMs":25008,"timeToFirstTokenMs":24025,"rawTimestamps":{"ttftMs":24025,"allTtftMs":[24025],"generationDurationMs":983,"turns":[{"turnId":"turn-0","durationMs":25008,"ttftMs":24025}]}}
-{"timestamp":"2026-04-29T13:41:50.149Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":7,"inputTokens":5667,"outputTokens":960,"totalTokens":6627,"prefillTokensPerSec":500.44,"generationTokensPerSec":11.09,"combinedTokensPerSec":67.69,"totalDurationMs":97903,"timeToFirstTokenMs":11324,"rawTimestamps":{"ttftMs":11324,"allTtftMs":[11324],"generationDurationMs":86579,"turns":[{"turnId":"turn-0","durationMs":6146},{"turnId":"turn-1","durationMs":2996},{"turnId":"turn-2","durationMs":4988},{"turnId":"turn-3","durationMs":5554},{"turnId":"turn-4","durationMs":29939},{"turnId":"turn-5","durationMs":3521},{"turnId":"turn-6","durationMs":44759,"ttftMs":11324}]}}
-{"timestamp":"2026-04-29T15:50:22.720Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":1,"inputTokens":3895,"outputTokens":81,"totalTokens":3976,"prefillTokensPerSec":165.89,"generationTokensPerSec":37.09,"combinedTokensPerSec":154.93,"totalDurationMs":25664,"timeToFirstTokenMs":23480,"rawTimestamps":{"ttftMs":23480,"allTtftMs":[23480],"generationDurationMs":2184,"turns":[{"turnId":"turn-0","durationMs":25664,"ttftMs":23480}]}}
-{"timestamp":"2026-04-29T15:52:02.780Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":3,"inputTokens":61,"outputTokens":381,"totalTokens":442,"prefillTokensPerSec":8.43,"generationTokensPerSec":21.42,"combinedTokensPerSec":17.66,"totalDurationMs":25023,"timeToFirstTokenMs":7240,"rawTimestamps":{"ttftMs":7240,"allTtftMs":[7240,1429],"generationDurationMs":17783,"turns":[{"turnId":"turn-0","durationMs":15773,"ttftMs":7240},{"turnId":"turn-1","durationMs":7547,"ttftMs":1429},{"turnId":"turn-2","durationMs":1703}]}}
-{"timestamp":"2026-04-29T15:54:09.944Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":6,"inputTokens":3978,"outputTokens":1388,"totalTokens":5366,"prefillTokensPerSec":924.04,"generationTokensPerSec":12.1,"combinedTokensPerSec":45.09,"totalDurationMs":119004,"timeToFirstTokenMs":4305,"rawTimestamps":{"ttftMs":4305,"allTtftMs":[4305,8638,7219,29433,6874],"generationDurationMs":114699,"turns":[{"turnId":"turn-0","durationMs":12420,"ttftMs":4305},{"turnId":"turn-1","durationMs":12723,"ttftMs":8638},{"turnId":"turn-2","durationMs":23125,"ttftMs":7219},{"turnId":"turn-3","durationMs":50368,"ttftMs":29433},{"turnId":"turn-4","durationMs":5165},{"turnId":"turn-5","durationMs":15203,"ttftMs":6874}]}}
-{"timestamp":"2026-04-29T15:57:10.210Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":1,"inputTokens":33,"outputTokens":318,"totalTokens":351,"prefillTokensPerSec":2.19,"generationTokensPerSec":28.27,"combinedTokensPerSec":13.35,"totalDurationMs":26294,"timeToFirstTokenMs":15045,"rawTimestamps":{"ttftMs":15045,"allTtftMs":[15045],"generationDurationMs":11249,"turns":[{"turnId":"turn-0","durationMs":26294,"ttftMs":15045}]}}
-{"timestamp":"2026-04-29T15:58:56.626Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":4,"inputTokens":2132,"outputTokens":1231,"totalTokens":3363,"prefillTokensPerSec":376.28,"generationTokensPerSec":12.52,"combinedTokensPerSec":32.34,"totalDurationMs":103985,"timeToFirstTokenMs":5666,"rawTimestamps":{"ttftMs":5666,"allTtftMs":[5666,39799,19167],"generationDurationMs":98319,"turns":[{"turnId":"turn-0","durationMs":6587},{"turnId":"turn-1","durationMs":11102,"ttftMs":5666},{"turnId":"turn-2","durationMs":54948,"ttftMs":39799},{"turnId":"turn-3","durationMs":31348,"ttftMs":19167}]}}
-{"timestamp":"2026-04-29T16:05:02.148Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":2,"inputTokens":205,"outputTokens":571,"totalTokens":776,"prefillTokensPerSec":74.49,"generationTokensPerSec":15.29,"combinedTokensPerSec":19.35,"totalDurationMs":40104,"timeToFirstTokenMs":2752,"rawTimestamps":{"ttftMs":2752,"allTtftMs":[2752],"generationDurationMs":37352,"turns":[{"turnId":"turn-0","durationMs":30227},{"turnId":"turn-1","durationMs":9877,"ttftMs":2752}]}}
-{"timestamp":"2026-04-29T16:07:50.115Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":2,"inputTokens":234,"outputTokens":199,"totalTokens":433,"prefillTokensPerSec":36.8,"generationTokensPerSec":25.9,"combinedTokensPerSec":30.84,"totalDurationMs":14042,"timeToFirstTokenMs":6358,"rawTimestamps":{"ttftMs":6358,"allTtftMs":[6358],"generationDurationMs":7684,"turns":[{"turnId":"turn-0","durationMs":4488},{"turnId":"turn-1","durationMs":9554,"ttftMs":6358}]}}
-{"timestamp":"2026-04-29T20:33:28.606Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":4,"inputTokens":313,"outputTokens":377,"totalTokens":690,"prefillTokensPerSec":97.48,"generationTokensPerSec":15.28,"combinedTokensPerSec":24.75,"totalDurationMs":27880,"timeToFirstTokenMs":3211,"rawTimestamps":{"ttftMs":3211,"allTtftMs":[3211],"generationDurationMs":24669,"turns":[{"turnId":"turn-0","durationMs":8848},{"turnId":"turn-1","durationMs":9567},{"turnId":"turn-2","durationMs":4669},{"turnId":"turn-3","durationMs":4796,"ttftMs":3211}]}}
-{"timestamp":"2026-04-29T20:34:21.540Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":4,"inputTokens":641,"outputTokens":497,"totalTokens":1138,"prefillTokensPerSec":80.86,"generationTokensPerSec":16.65,"combinedTokensPerSec":30.12,"totalDurationMs":37779,"timeToFirstTokenMs":7927,"rawTimestamps":{"ttftMs":7927,"allTtftMs":[7927,7791],"generationDurationMs":29852,"turns":[{"turnId":"turn-0","durationMs":13323,"ttftMs":7927},{"turnId":"turn-1","durationMs":5975},{"turnId":"turn-2","durationMs":7432},{"turnId":"turn-3","durationMs":11049,"ttftMs":7791}]}}
-{"timestamp":"2026-04-29T21:00:14.163Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":1,"inputTokens":130,"outputTokens":754,"totalTokens":884,"prefillTokensPerSec":18.2,"generationTokensPerSec":22.65,"combinedTokensPerSec":21.87,"totalDurationMs":40429,"timeToFirstTokenMs":7141,"rawTimestamps":{"ttftMs":7141,"allTtftMs":[7141],"generationDurationMs":33288,"turns":[{"turnId":"turn-0","durationMs":40429,"ttftMs":7141}]}}
-{"timestamp":"2026-04-30T08:14:53.444Z","provider":"llama.cpp","model":"Qwen3.6-35B-A3B-MXFP4_MOE.gguf","turnCount":19,"inputTokens":12970,"outputTokens":3205,"totalTokens":16175,"prefillTokensPerSec":1449.65,"generationTokensPerSec":44.97,"combinedTokensPerSec":201.65,"totalDurationMs":80212,"timeToFirstTokenMs":8947,"rawTimestamps":{"ttftMs":8947,"allTtftMs":[8947,3426,526,1162],"generationDurationMs":71265,"turns":[{"turnId":"turn-0","durationMs":6818},{"turnId":"turn-1","durationMs":1695},{"turnId":"turn-2","durationMs":1595},{"turnId":"turn-3","durationMs":3043},{"turnId":"turn-4","durationMs":2759},{"turnId":"turn-5","durationMs":3602},{"turnId":"turn-6","durationMs":4147},{"turnId":"turn-7","durationMs":3449},{"turnId":"turn-8","durationMs":7692},{"turnId":"turn-9","durationMs":5670},{"turnId":"turn-10","durationMs":1713},{"turnId":"turn-11","durationMs":1593},{"turnId":"turn-12","durationMs":4806},{"turnId":"turn-13","durationMs":1737},{"turnId":"turn-14","durationMs":4030},{"turnId":"turn-15","durationMs":12934,"ttftMs":8947},{"turnId":"turn-16","durationMs":6340,"ttftMs":3426},{"turnId":"turn-17","durationMs":2325,"ttftMs":526},{"turnId":"turn-18","durationMs":4264,"ttftMs":1162}]}}
-{"timestamp":"2026-05-04T11:46:24.369Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":6,"inputTokens":54016,"outputTokens":1558,"totalTokens":55574,"prefillTokensPerSec":12304.33,"generationTokensPerSec":21.46,"combinedTokensPerSec":721.94,"totalDurationMs":76979,"timeToFirstTokenMs":4390,"rawTimestamps":{"ttftMs":4390,"allTtftMs":[4390,4350,5857,8964,12347,14311],"generationDurationMs":72589,"turns":[{"turnId":"turn-0","durationMs":7310,"ttftMs":4390},{"turnId":"turn-1","durationMs":7610,"ttftMs":4350},{"turnId":"turn-2","durationMs":10860,"ttftMs":5857},{"turnId":"turn-3","durationMs":15082,"ttftMs":8964},{"turnId":"turn-4","durationMs":17713,"ttftMs":12347},{"turnId":"turn-5","durationMs":18404,"ttftMs":14311}]}}
-{"timestamp":"2026-05-04T11:47:12.784Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":1,"inputTokens":15483,"outputTokens":527,"totalTokens":16010,"prefillTokensPerSec":915.45,"generationTokensPerSec":77.75,"combinedTokensPerSec":675.78,"totalDurationMs":23691,"timeToFirstTokenMs":16913,"rawTimestamps":{"ttftMs":16913,"allTtftMs":[16913],"generationDurationMs":6778,"turns":[{"turnId":"turn-0","durationMs":23691,"ttftMs":16913}]}}
-{"timestamp":"2026-05-04T11:48:28.522Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":2,"inputTokens":33498,"outputTokens":1509,"totalTokens":35007,"prefillTokensPerSec":1806.99,"generationTokensPerSec":35.09,"combinedTokensPerSec":568.89,"totalDurationMs":61536,"timeToFirstTokenMs":18538,"rawTimestamps":{"ttftMs":18538,"allTtftMs":[18538,19230],"generationDurationMs":42998,"turns":[{"turnId":"turn-0","durationMs":21065,"ttftMs":18538},{"turnId":"turn-1","durationMs":40471,"ttftMs":19230}]}}
-{"timestamp":"2026-05-04T11:55:38.472Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":2,"inputTokens":39338,"outputTokens":570,"totalTokens":39908,"prefillTokensPerSec":1902.59,"generationTokensPerSec":22.16,"combinedTokensPerSec":860.14,"totalDurationMs":46397,"timeToFirstTokenMs":20676,"rawTimestamps":{"ttftMs":20676,"allTtftMs":[20676,19136],"generationDurationMs":25721,"turns":[{"turnId":"turn-0","durationMs":25951,"ttftMs":20676},{"turnId":"turn-1","durationMs":20446,"ttftMs":19136}]}}
-{"timestamp":"2026-05-04T11:56:06.171Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":1,"inputTokens":20697,"outputTokens":122,"totalTokens":20819,"prefillTokensPerSec":1032.58,"generationTokensPerSec":64.14,"combinedTokensPerSec":948.65,"totalDurationMs":21946,"timeToFirstTokenMs":20044,"rawTimestamps":{"ttftMs":20044,"allTtftMs":[20044],"generationDurationMs":1902,"turns":[{"turnId":"turn-0","durationMs":21946,"ttftMs":20044}]}}
-{"timestamp":"2026-05-06T16:39:45.645Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":1,"inputTokens":4174,"outputTokens":325,"totalTokens":4499,"prefillTokensPerSec":792.63,"generationTokensPerSec":66.8,"combinedTokensPerSec":444.08,"totalDurationMs":10131,"timeToFirstTokenMs":5266,"rawTimestamps":{"ttftMs":5266,"allTtftMs":[5266],"generationDurationMs":4865,"turns":[{"turnId":"turn-0","durationMs":10131,"ttftMs":5266}]}}
-{"timestamp":"2026-05-06T16:42:07.071Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":7,"inputTokens":9779,"outputTokens":2117,"totalTokens":11896,"prefillTokensPerSec":4159.51,"generationTokensPerSec":41.52,"combinedTokensPerSec":223.01,"totalDurationMs":53342,"timeToFirstTokenMs":2351,"rawTimestamps":{"ttftMs":2351,"allTtftMs":[2351,9533],"generationDurationMs":50991,"turns":[{"turnId":"turn-0","durationMs":6041,"ttftMs":2351},{"turnId":"turn-1","durationMs":5709},{"turnId":"turn-2","durationMs":4712},{"turnId":"turn-3","durationMs":10280},{"turnId":"turn-4","durationMs":4285},{"turnId":"turn-5","durationMs":5823},{"turnId":"turn-6","durationMs":16492,"ttftMs":9533}]}}
-{"timestamp":"2026-05-06T16:49:48.369Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":7,"inputTokens":311,"outputTokens":1074,"totalTokens":1385,"prefillTokensPerSec":36.18,"generationTokensPerSec":61.74,"combinedTokensPerSec":53.29,"totalDurationMs":25992,"timeToFirstTokenMs":8597,"rawTimestamps":{"ttftMs":8597,"allTtftMs":[8597],"generationDurationMs":17395,"turns":[{"turnId":"turn-0","durationMs":11317,"ttftMs":8597},{"turnId":"turn-1","durationMs":2369},{"turnId":"turn-2","durationMs":2161},{"turnId":"turn-3","durationMs":2403},{"turnId":"turn-4","durationMs":4231},{"turnId":"turn-5","durationMs":2551},{"turnId":"turn-6","durationMs":960}]}}
-{"timestamp":"2026-05-06T16:56:43.506Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":11,"inputTokens":1781,"outputTokens":1747,"totalTokens":3528,"prefillTokensPerSec":495.82,"generationTokensPerSec":49.55,"combinedTokensPerSec":90.81,"totalDurationMs":38852,"timeToFirstTokenMs":3592,"rawTimestamps":{"ttftMs":3592,"allTtftMs":[3592,694,1252],"generationDurationMs":35260,"turns":[{"turnId":"turn-0","durationMs":4830,"ttftMs":3592},{"turnId":"turn-1","durationMs":2331},{"turnId":"turn-2","durationMs":3344},{"turnId":"turn-3","durationMs":2239},{"turnId":"turn-4","durationMs":4882,"ttftMs":694},{"turnId":"turn-5","durationMs":4150},{"turnId":"turn-6","durationMs":5061},{"turnId":"turn-7","durationMs":3934},{"turnId":"turn-8","durationMs":1503},{"turnId":"turn-9","durationMs":2303},{"turnId":"turn-10","durationMs":4275,"ttftMs":1252}]}}
-{"timestamp":"2026-05-06T16:59:33.370Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":8,"inputTokens":357,"outputTokens":949,"totalTokens":1306,"prefillTokensPerSec":222.57,"generationTokensPerSec":46.43,"combinedTokensPerSec":59.25,"totalDurationMs":22044,"timeToFirstTokenMs":1604,"rawTimestamps":{"ttftMs":1604,"allTtftMs":[1604],"generationDurationMs":20440,"turns":[{"turnId":"turn-0","durationMs":2025},{"turnId":"turn-1","durationMs":3837},{"turnId":"turn-2","durationMs":1860},{"turnId":"turn-3","durationMs":3942},{"turnId":"turn-4","durationMs":1846},{"turnId":"turn-5","durationMs":3096},{"turnId":"turn-6","durationMs":1495},{"turnId":"turn-7","durationMs":3943,"ttftMs":1604}]}}
-{"timestamp":"2026-05-06T17:31:10.634Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":92,"inputTokens":80382,"outputTokens":40770,"totalTokens":121152,"prefillTokensPerSec":34827.56,"generationTokensPerSec":21.57,"combinedTokensPerSec":64.01,"totalDurationMs":1892815,"timeToFirstTokenMs":2308,"rawTimestamps":{"ttftMs":2308,"allTtftMs":[2308,5231,2214,13471,19063,46574,152271,61194,48786,7235,28151,26069,9052,1985,1952,1437,10416,14830,1134,16993,12759,52435,92275,13142,123464,5492,21599,22940,67932,2646,19419,9988,11058,6667,3583,6608,1500],"generationDurationMs":1890507,"turns":[{"turnId":"turn-0","durationMs":4003,"ttftMs":2308},{"turnId":"turn-1","durationMs":41405},{"turnId":"turn-2","durationMs":9163,"ttftMs":5231},{"turnId":"turn-3","durationMs":15549},{"turnId":"turn-4","durationMs":24263,"ttftMs":2214},{"turnId":"turn-5","durationMs":6306},{"turnId":"turn-6","durationMs":58263,"ttftMs":13471},{"turnId":"turn-7","durationMs":2270},{"turnId":"turn-8","durationMs":28312,"ttftMs":19063},{"turnId":"turn-9","durationMs":15839},{"turnId":"turn-10","durationMs":3190},{"turnId":"turn-11","durationMs":62636,"ttftMs":46574},{"turnId":"turn-12","durationMs":29406},{"turnId":"turn-13","durationMs":13332},{"turnId":"turn-14","durationMs":162150,"ttftMs":152271},{"turnId":"turn-15","durationMs":9085},{"turnId":"turn-16","durationMs":67115,"ttftMs":61194},{"turnId":"turn-17","durationMs":12812},{"turnId":"turn-18","durationMs":3990},{"turnId":"turn-19","durationMs":55146,"ttftMs":48786},{"turnId":"turn-20","durationMs":21407},{"turnId":"turn-21","durationMs":21800,"ttftMs":7235},{"turnId":"turn-22","durationMs":2180},{"turnId":"turn-23","durationMs":41363,"ttftMs":28151},{"turnId":"turn-24","durationMs":1791},{"turnId":"turn-25","durationMs":32993,"ttftMs":26069},{"turnId":"turn-26","durationMs":6916},{"turnId":"turn-27","durationMs":1731},{"turnId":"turn-28","durationMs":22931,"ttftMs":9052},{"turnId":"turn-29","durationMs":1821},{"turnId":"turn-30","durationMs":4633,"ttftMs":1985},{"turnId":"turn-31","durationMs":4862,"ttftMs":1952},{"turnId":"turn-32","durationMs":4595,"ttftMs":1437},{"turnId":"turn-33","durationMs":13428,"ttftMs":10416},{"turnId":"turn-34","durationMs":25682,"ttftMs":14830},{"turnId":"turn-35","durationMs":17933,"ttftMs":1134},{"turnId":"turn-36","durationMs":20492,"ttftMs":16993},{"turnId":"turn-37","durationMs":31332,"ttftMs":12759},{"turnId":"turn-38","durationMs":56269,"ttftMs":52435},{"turnId":"turn-39","durationMs":8502},{"turnId":"turn-40","durationMs":6420},{"turnId":"turn-41","durationMs":25318},{"turnId":"turn-42","durationMs":9494},{"turnId":"turn-43","durationMs":95912,"ttftMs":92275},{"turnId":"turn-44","durationMs":34948,"ttftMs":13142},{"turnId":"turn-45","durationMs":8642},{"turnId":"turn-46","durationMs":130233,"ttftMs":123464},{"turnId":"turn-47","durationMs":38380},{"turnId":"turn-48","durationMs":9214},{"turnId":"turn-49","durationMs":11870,"ttftMs":5492},{"turnId":"turn-50","durationMs":6218},{"turnId":"turn-51","durationMs":7383},{"turnId":"turn-52","durationMs":4064},{"turnId":"turn-53","durationMs":27853,"ttftMs":21599},{"turnId":"turn-54","durationMs":11404},{"turnId":"turn-55","durationMs":17718},{"turnId":"turn-56","durationMs":32005,"ttftMs":22940},{"turnId":"turn-57","durationMs":14470},{"turnId":"turn-58","durationMs":76489,"ttftMs":67932},{"turnId":"turn-59","durationMs":7167},{"turnId":"turn-60","durationMs":21798,"ttftMs":2646},{"turnId":"turn-61","durationMs":5036},{"turnId":"turn-62","durationMs":27297,"ttftMs":19419},{"turnId":"turn-63","durationMs":2917},{"turnId":"turn-64","durationMs":18622},{"turnId":"turn-65","durationMs":4121},{"turnId":"turn-66","durationMs":17758,"ttftMs":9988},{"turnId":"turn-67","durationMs":14293},{"turnId":"turn-68","durationMs":10149},{"turnId":"turn-69","durationMs":21838,"ttftMs":11058},{"turnId":"turn-70","durationMs":33425,"ttftMs":6667},{"turnId":"turn-71","durationMs":8877},{"turnId":"turn-72","durationMs":4817},{"turnId":"turn-73","durationMs":14984},{"turnId":"turn-74","durationMs":3183},{"turnId":"turn-75","durationMs":13013},{"turnId":"turn-76","durationMs":4295},{"turnId":"turn-77","durationMs":11146},{"turnId":"turn-78","durationMs":4254},{"turnId":"turn-79","durationMs":22982},{"turnId":"turn-80","durationMs":2358},{"turnId":"turn-81","durationMs":9871},{"turnId":"turn-82","durationMs":2366},{"turnId":"turn-83","durationMs":10509},{"turnId":"turn-84","durationMs":2354},{"turnId":"turn-85","durationMs":7532,"ttftMs":3583},{"turnId":"turn-86","durationMs":11922,"ttftMs":6608},{"turnId":"turn-87","durationMs":6071},{"turnId":"turn-88","durationMs":7534},{"turnId":"turn-89","durationMs":4058},{"turnId":"turn-90","durationMs":6229},{"turnId":"turn-91","durationMs":15108,"ttftMs":1500}]}}
-{"timestamp":"2026-05-06T21:04:32.534Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":1,"inputTokens":29,"outputTokens":507,"totalTokens":536,"prefillTokensPerSec":4.5,"generationTokensPerSec":43.58,"combinedTokensPerSec":29.64,"totalDurationMs":18082,"timeToFirstTokenMs":6448,"rawTimestamps":{"ttftMs":6448,"allTtftMs":[6448],"generationDurationMs":11634,"turns":[{"turnId":"turn-0","durationMs":18082,"ttftMs":6448}]}}
-{"timestamp":"2026-05-06T21:27:50.071Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":1,"inputTokens":45,"outputTokens":546,"totalTokens":591,"prefillTokensPerSec":5.14,"generationTokensPerSec":43.29,"combinedTokensPerSec":27.67,"totalDurationMs":21362,"timeToFirstTokenMs":8748,"rawTimestamps":{"ttftMs":8748,"allTtftMs":[8748],"generationDurationMs":12614,"turns":[{"turnId":"turn-0","durationMs":21362,"ttftMs":8748}]}}
-{"timestamp":"2026-05-06T21:31:47.562Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":4,"inputTokens":331,"outputTokens":712,"totalTokens":1043,"prefillTokensPerSec":127.6,"generationTokensPerSec":24.75,"combinedTokensPerSec":33.26,"totalDurationMs":31358,"timeToFirstTokenMs":2594,"rawTimestamps":{"ttftMs":2594,"allTtftMs":[2594],"generationDurationMs":28764,"turns":[{"turnId":"turn-0","durationMs":7885},{"turnId":"turn-1","durationMs":13632},{"turnId":"turn-2","durationMs":3642},{"turnId":"turn-3","durationMs":6199,"ttftMs":2594}]}}
-{"timestamp":"2026-05-06T21:34:33.835Z","provider":"faster-mlx","model":"mlx-community/Qwen3.6-35B-A3B-8bit","turnCount":2,"inputTokens":537,"outputTokens":457,"totalTokens":994,"prefillTokensPerSec":186.07,"generationTokensPerSec":36.49,"combinedTokensPerSec":64.5,"totalDurationMs":15410,"timeToFirstTokenMs":2886,"rawTimestamps":{"ttftMs":2886,"allTtftMs":[2886,4622],"generationDurationMs":12524,"turns":[{"turnId":"turn-0","durationMs":10034,"ttftMs":2886},{"turnId":"turn-1","durationMs":5376,"ttftMs":4622}]}}
-{"timestamp":"2026-05-07T09:58:26.890Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":8,"inputTokens":6451,"outputTokens":1301,"totalTokens":7752,"prefillTokensPerSec":1185.41,"generationTokensPerSec":5.62,"combinedTokensPerSec":32.73,"totalDurationMs":236828,"timeToFirstTokenMs":5442,"rawTimestamps":{"ttftMs":5442,"allTtftMs":[5442,1468],"generationDurationMs":231386,"turns":[{"turnId":"turn-0","durationMs":110526},{"turnId":"turn-1","durationMs":7296},{"turnId":"turn-2","durationMs":14916,"ttftMs":5442},{"turnId":"turn-3","durationMs":12938},{"turnId":"turn-4","durationMs":11185},{"turnId":"turn-5","durationMs":8236},{"turnId":"turn-6","durationMs":10174},{"turnId":"turn-7","durationMs":61557,"ttftMs":1468}]}}
-{"timestamp":"2026-05-07T10:53:17.649Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":32,"inputTokens":18704,"outputTokens":5545,"totalTokens":24249,"prefillTokensPerSec":2125.45,"generationTokensPerSec":15.7,"combinedTokensPerSec":66.97,"totalDurationMs":362085,"timeToFirstTokenMs":8800,"rawTimestamps":{"ttftMs":8800,"allTtftMs":[8800,19803,2],"generationDurationMs":353285,"turns":[{"turnId":"turn-0","durationMs":4811},{"turnId":"turn-1","durationMs":6333},{"turnId":"turn-2","durationMs":18593},{"turnId":"turn-3","durationMs":17961,"ttftMs":8800},{"turnId":"turn-4","durationMs":13068},{"turnId":"turn-5","durationMs":14593},{"turnId":"turn-6","durationMs":12481},{"turnId":"turn-7","durationMs":9793},{"turnId":"turn-8","durationMs":21642},{"turnId":"turn-9","durationMs":22537},{"turnId":"turn-10","durationMs":9008},{"turnId":"turn-11","durationMs":12334},{"turnId":"turn-12","durationMs":39276},{"turnId":"turn-13","durationMs":17312},{"turnId":"turn-14","durationMs":19481},{"turnId":"turn-15","durationMs":10121},{"turnId":"turn-16","durationMs":6445},{"turnId":"turn-17","durationMs":6207},{"turnId":"turn-18","durationMs":9938},{"turnId":"turn-19","durationMs":16812},{"turnId":"turn-20","durationMs":27727,"ttftMs":19803},{"turnId":"turn-21","durationMs":18264},{"turnId":"turn-22","durationMs":16482},{"turnId":"turn-23","durationMs":10849},{"turnId":"turn-24","durationMs":4},{"turnId":"turn-25","durationMs":0},{"turnId":"turn-26","durationMs":5},{"turnId":"turn-27","durationMs":0},{"turnId":"turn-28","durationMs":3},{"turnId":"turn-29","durationMs":0},{"turnId":"turn-30","durationMs":2},{"turnId":"turn-31","durationMs":3,"ttftMs":2}]}}
-{"timestamp":"2026-05-07T10:56:15.344Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":7,"inputTokens":1120,"outputTokens":1046,"totalTokens":2166,"prefillTokensPerSec":50.27,"generationTokensPerSec":15.14,"combinedTokensPerSec":23.71,"totalDurationMs":91350,"timeToFirstTokenMs":22281,"rawTimestamps":{"ttftMs":22281,"allTtftMs":[22281],"generationDurationMs":69069,"turns":[{"turnId":"turn-0","durationMs":6803},{"turnId":"turn-1","durationMs":9002},{"turnId":"turn-2","durationMs":9423},{"turnId":"turn-3","durationMs":8839},{"turnId":"turn-4","durationMs":21020},{"turnId":"turn-5","durationMs":7403},{"turnId":"turn-6","durationMs":28860,"ttftMs":22281}]}}
-{"timestamp":"2026-05-07T10:57:51.083Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":11,"inputTokens":847,"outputTokens":1039,"totalTokens":1886,"prefillTokensPerSec":458.83,"generationTokensPerSec":13.33,"combinedTokensPerSec":23.63,"totalDurationMs":79819,"timeToFirstTokenMs":1846,"rawTimestamps":{"ttftMs":1846,"allTtftMs":[1846],"generationDurationMs":77973,"turns":[{"turnId":"turn-0","durationMs":4602},{"turnId":"turn-1","durationMs":4772},{"turnId":"turn-2","durationMs":9277},{"turnId":"turn-3","durationMs":7327},{"turnId":"turn-4","durationMs":6075},{"turnId":"turn-5","durationMs":11215},{"turnId":"turn-6","durationMs":5261},{"turnId":"turn-7","durationMs":7154},{"turnId":"turn-8","durationMs":8922},{"turnId":"turn-9","durationMs":5088},{"turnId":"turn-10","durationMs":10126,"ttftMs":1846}]}}
-{"timestamp":"2026-05-07T11:44:31.762Z","provider":"llama.cpp","model":"unsloth/Qwen3.6-27B-GGUF:Q4_K_M","turnCount":1,"inputTokens":29,"outputTokens":1453,"totalTokens":1482,"prefillTokensPerSec":0.63,"generationTokensPerSec":25.21,"combinedTokensPerSec":14.34,"totalDurationMs":103354,"timeToFirstTokenMs":45712,"rawTimestamps":{"ttftMs":45712,"allTtftMs":[45712],"generationDurationMs":57642,"turns":[{"turnId":"turn-0","durationMs":103354,"ttftMs":45712}]}}

.pi/skills/demo/init.sh

@@ -0,0 +1,132 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# init.sh — Set up the demo skill's headless Chrome container
+#
+# Prerequisites:
+#   - go (for installing showboat & rodney)
+#   - docker
+#
+# This script:
+#   1. Installs showboat and rodney if missing
+#   2. Downloads Chromium for the host (macOS, via rodney)
+#   3. Downloads Chromium for the Docker image (Linux_x64, from GCS)
+#   4. Copies Linux binary into chrome/ (the Docker build context)
+#   5. Builds the demo-chrome image
+
+SKILL_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+CHROME_DIR="$SKILL_DIR/chrome"
+IMAGE_NAME="${1:-demo-chrome}"
+
+echo "==> Checking prerequisites..."
+
+# ------------------------------------------------------------------
+# 1. Install CLI tools
+# ------------------------------------------------------------------
+GO_BIN_DIR="$(go env GOBIN 2>/dev/null || echo "$HOME/go/bin")"
+export PATH="$GO_BIN_DIR:$PATH"
+
+if ! command -v showboat &>/dev/null; then
+  echo "==> Installing showboat..."
+  go install github.com/simonw/showboat@latest
+else
+  echo "    showboat: ok"
+fi
+
+if ! command -v rodney &>/dev/null; then
+  echo "==> Installing rodney..."
+  go install github.com/simonw/rodney@latest
+else
+  echo "    rodney: ok"
+fi
+
+# ------------------------------------------------------------------
+# 2. Download macOS Chromium for local rodney
+# ------------------------------------------------------------------
+echo "==> Downloading macOS Chromium via rodney..."
+rodney start 2>/dev/null || true
+rodney stop  2>/dev/null || true
+
+ROD_CACHE="$HOME/.cache/rod/browser"
+if [ -d "$ROD_CACHE" ]; then
+  CHROMIUM_DIR=$(ls -d "$ROD_CACHE"/chromium-* 2>/dev/null | head -1)
+else
+  echo "ERROR: rod cache not found at $ROD_CACHE"
+  exit 1
+fi
+
+if [ -z "$CHROMIUM_DIR" ]; then
+  echo "ERROR: No chromium-* directory found in $ROD_CACHE"
+  exit 1
+fi
+
+echo "    macOS Chromium at: $CHROMIUM_DIR"
+
+# Extract revision number from directory name (e.g. chromium-1321438)
+REVISION=$(basename "$CHROMIUM_DIR" | sed 's/chromium-//')
+echo "    Revision: $REVISION"
+
+# ------------------------------------------------------------------
+# 3. Download Linux Chromium for the Docker image
+# ------------------------------------------------------------------
+LINUX_ZIP="/tmp/chrome-linux-$REVISION.zip"
+LINUX_EXTRACT="/tmp/chrome-linux-extract"
+
+echo "==> Downloading Linux_x64 Chromium (revision $REVISION)..."
+
+if [ ! -f "$LINUX_ZIP" ]; then
+  curl -fSL \
+    "https://storage.googleapis.com/chromium-browser-snapshots/Linux_x64/$REVISION/chrome-linux.zip" \
+    -o "$LINUX_ZIP"
+  echo "    Downloaded: $LINUX_ZIP"
+else
+  echo "    Already cached: $LINUX_ZIP"
+fi
+
+# ------------------------------------------------------------------
+# 4. Extract and copy into build context
+# ------------------------------------------------------------------
+echo "==> Extracting Linux Chromium into $CHROME_DIR ..."
+rm -rf "$LINUX_EXTRACT" "$CHROME_DIR"
+mkdir -p "$LINUX_EXTRACT"
+unzip -q "$LINUX_ZIP" -d "$LINUX_EXTRACT"
+
+# chrome-linux.zip contains a single chrome-linux/ directory
+mv "$LINUX_EXTRACT/chrome-linux" "$CHROME_DIR"
+
+# IMPORTANT: set suid on the sandbox binary so Chrome can sandbox child processes
+if [ -f "$CHROME_DIR/chrome_sandbox" ]; then
+  chmod 4755 "$CHROME_DIR/chrome_sandbox"
+fi
+
+echo "==> Files in $CHROME_DIR:"
+ls -lh "$CHROME_DIR/" | head -15
+
+# Clean up extraction temp
+rm -rf "$LINUX_EXTRACT"
+
+# ------------------------------------------------------------------
+# 5. Build Docker image
+# ------------------------------------------------------------------
+echo "==> Building Docker image '$IMAGE_NAME' ..."
+docker build --tag "$IMAGE_NAME" "$SKILL_DIR"
+
+# ------------------------------------------------------------------
+# 6. Verify
+# ------------------------------------------------------------------
+echo ""
+echo "==> Success!"
+echo "    Image:  $IMAGE_NAME"
+echo ""
+echo "    Run the container:"
+echo "      docker run -d --name demo-chrome \\"
+echo "        --cap-add=SYS_ADMIN --cap-drop=ALL \\"
+echo "        --security-opt=no-new-privileges:false \\"
+echo "        -p 9222:9222 \\"
+echo "        $IMAGE_NAME"
+echo ""
+echo "    Connect rodney to it:"
+echo "      rodney connect localhost:9222"
+echo ""
+echo "    Stop the container:"
+echo "      docker stop demo-chrome && docker rm demo-chrome"

AGENTS.md

@@ -3,6 +3,13 @@
 This project has a *zero defects policy*. 
 When you are unsure about something, ALWAYS ask the user.
 
+# Communication
+
+When creating yaks or working on features, always ask clarifying questions to ensure understanding. Ask questions one at a time to maintain clear communication and allow for focused discussion.
+
+
+You run in a `nono` sandbox. Always ask the user to run commands that require privilege, like docker, sudo or package installation.
+
 # Repository structure
 
 This is an Elixir monorepo with two parts:

Makefile

@@ -25,3 +25,32 @@ test:
 # Format code
 format:
 	@make -C app format
+
+# Serve the app
+serve:
+	@cd app && mix phx.server
+
+# Run Playwright browser-based tests (requires running server)
+# Set PLAYWRIGHT_BASE_URL to point at the running Phoenix app
+playwright:
+	@make -C app playwright
+
+# Run Playwright in UI mode (headed browser)
+playwright-ui:
+	@make -C app playwright-ui
+
+# Run Playwright against Docker Chrome container (must be running)
+playwright-docker:
+	@make -C app playwright-docker
+
+# Full e2e workflow: start Chrome container, run tests, stop container
+playwright-full:
+	@make -C app playwright-full
+
+# Start Docker Chrome container
+playwright-docker-start:
+	@make -C app playwright-docker-start
+
+# Stop Docker Chrome container
+playwright-docker-stop:
+	@make -C app playwright-docker-stop

README.md

@@ -6,7 +6,7 @@ Posts live as markdown files in git and compile into the BEAM at build time: zer
 
 The project structure is modular, I wanted to have a personal blog, and an easy way to add an 'engineering' blog to fledgling SaaS products, as well as release notes. The release notes now also serve to announce new features on my blog.
 
-Status: Expirimental. Works on my server ;-). 
+Status: Experimental. Works on my server ;-). 
 
 Enjoy, [Willem van den Ende](https://willemvandenende.com)
 

app/Makefile

@@ -28,6 +28,70 @@ test: deps compile
 format:
 	$(MISE_EXEC) mix format
 
+# =============================================================================
+# Playwright e2e browser tests
+# =============================================================================
+#
+# Requires the Phoenix dev server running on the default port (8056).
+# Set PLAYWRIGHT_BASE_URL to point at a different server/port.
+#
+# Available browsers (local):
+#   PLAYWRIGHT_BROWSER=firefox   (default — works on macOS 15)
+#   PLAYWRIGHT_BROWSER=chromium  (crashes on macOS 15, use Docker Chrome)
+#   PLAYWRIGHT_BROWSER=webkit
+#
+# Docker Chrome (alternative):
+#   1. docker compose -f docker-compose.chrome.yml up -d
+#   2. PLAYWRIGHT_BROWSERS_PATH=assets/node_modules/playwright-core/.local-browsers \
+#      npx playwright test --config=playwright.docker.config.ts
+#
+# =============================================================================
+
+# Run Playwright e2e tests (default: local Firefox)
+# Usage: make playwright
+#        PLAYWRIGHT_BROWSER=chromium make playwright
+playwright:
+	cd assets && PLAYWRIGHT_BROWSERS_PATH=node_modules/playwright-core/.local-browsers npx playwright test --config=../playwright.config.ts
+
+# Run a specific Playwright test file
+# Usage: make playwright-test test/e2e/smoke.spec.ts
+playwright-test:
+	cd assets && PLAYWRIGHT_BROWSERS_PATH=node_modules/playwright-core/.local-browsers npx playwright test --config=../playwright.config.ts $(filter-out $@,$(MAKECMDGOALS))
+
+# Run Playwright tests with UI mode (headed browser)
+playwright-ui:
+	cd assets && PLAYWRIGHT_BROWSERS_PATH=node_modules/playwright-core/.local-browsers npx playwright test --config=../playwright.config.ts --ui
+
+# Show last Playwright HTML report
+playwright-report:
+	cd assets && npx playwright show-report
+
+# Start Docker Chrome container for remote Playwright
+playwright-docker-start:
+	docker compose -f docker-compose.chrome.yml up -d
+
+# Stop Docker Chrome container
+playwright-docker-stop:
+	docker compose -f docker-compose.chrome.yml down
+
+# Run Playwright against Docker Chrome (container must be running)
+playwright-docker:
+	cd assets && PLAYWRIGHT_BROWSERS_PATH=node_modules/playwright-core/.local-browsers npx playwright test --config=../playwright.docker.config.ts
+
+# Run full end-to-end workflow: start Docker Chrome, run tests, stop container
+playwright-full: playwright-docker-start
+	@echo "Waiting for Chrome to be ready..."
+	@sleep 3
+	cd assets && PLAYWRIGHT_BROWSERS_PATH=node_modules/playwright-core/.local-browsers npx playwright test --config=../playwright.docker.config.ts; \
+		EXIT_CODE=$$?; \
+		cd ..; \
+		docker compose -f docker-compose.chrome.yml down; \
+		exit $$EXIT_CODE
+
+# =============================================================================
+# Static analysis
+# =============================================================================
+
 # Run Credo static analysis
 credo:
 	$(MISE_EXEC) mix credo --strict

app/assets/css/app.css

@@ -286,124 +286,123 @@ body { font-family: 'Source Sans 3', sans-serif; }
 }
 
 /* highlight.js — Atom One Dark (dark theme) */
-.source-viewer code.hljs {
+.source-viewer .hljs {
   color: #abb2bf;
   background: transparent;
-  padding: 0;
 }
-.source-viewer code.hljs .hljs-comment,
-.source-viewer code.hljs .hljs-quote {
+.source-viewer .hljs .hljs-comment,
+.source-viewer .hljs .hljs-quote {
   color: #5c6370;
   font-style: italic;
 }
-.source-viewer code.hljs .hljs-doctag,
-.source-viewer code.hljs .hljs-keyword,
-.source-viewer code.hljs .hljs-formula {
+.source-viewer .hljs .hljs-doctag,
+.source-viewer .hljs .hljs-keyword,
+.source-viewer .hljs .hljs-formula {
   color: #c678dd;
 }
-.source-viewer code.hljs .hljs-section,
-.source-viewer code.hljs .hljs-name,
-.source-viewer code.hljs .hljs-selector-tag,
-.source-viewer code.hljs .hljs-deletion,
-.source-viewer code.hljs .hljs-subst {
+.source-viewer .hljs .hljs-section,
+.source-viewer .hljs .hljs-name,
+.source-viewer .hljs .hljs-selector-tag,
+.source-viewer .hljs .hljs-deletion,
+.source-viewer .hljs .hljs-subst {
   color: #e06c75;
 }
-.source-viewer code.hljs .hljs-literal {
+.source-viewer .hljs .hljs-literal {
   color: #56b6c2;
 }
-.source-viewer code.hljs .hljs-string,
-.source-viewer code.hljs .hljs-regexp,
-.source-viewer code.hljs .hljs-addition,
-.source-viewer code.hljs .hljs-attribute,
-.source-viewer code.hljs .hljs-meta .hljs-string {
+.source-viewer .hljs .hljs-string,
+.source-viewer .hljs .hljs-regexp,
+.source-viewer .hljs .hljs-addition,
+.source-viewer .hljs .hljs-attribute,
+.source-viewer .hljs .hljs-meta .hljs-string {
   color: #98c379;
 }
-.source-viewer code.hljs .hljs-attr,
-.source-viewer code.hljs .hljs-variable,
-.source-viewer code.hljs .hljs-template-variable,
-.source-viewer code.hljs .hljs-type,
-.source-viewer code.hljs .hljs-selector-class,
-.source-viewer code.hljs .hljs-selector-attr,
-.source-viewer code.hljs .hljs-selector-pseudo,
-.source-viewer code.hljs .hljs-number {
+.source-viewer .hljs .hljs-attr,
+.source-viewer .hljs .hljs-variable,
+.source-viewer .hljs .hljs-template-variable,
+.source-viewer .hljs .hljs-type,
+.source-viewer .hljs .hljs-selector-class,
+.source-viewer .hljs .hljs-selector-attr,
+.source-viewer .hljs .hljs-selector-pseudo,
+.source-viewer .hljs .hljs-number {
   color: #d19a66;
 }
-.source-viewer code.hljs .hljs-symbol,
-.source-viewer code.hljs .hljs-link,
-.source-viewer code.hljs .hljs-meta,
-.source-viewer code.hljs .hljs-selector-id,
-.source-viewer code.hljs .hljs-title {
+.source-viewer .hljs .hljs-symbol,
+.source-viewer .hljs .hljs-link,
+.source-viewer .hljs .hljs-meta,
+.source-viewer .hljs .hljs-selector-id,
+.source-viewer .hljs .hljs-title {
   color: #61aeee;
 }
-.source-viewer code.hljs .hljs-built_in,
-.source-viewer code.hljs .hljs-title.class_,
-.source-viewer code.hljs .hljs-class .hljs-title {
+.source-viewer .hljs .hljs-built_in,
+.source-viewer .hljs .hljs-title.class_,
+.source-viewer .hljs .hljs-class .hljs-title {
   color: #e6c07b;
 }
-.source-viewer code.hljs .hljs-emphasis {
+.source-viewer .hljs .hljs-emphasis {
   font-style: italic;
 }
-.source-viewer code.hljs .hljs-strong {
+.source-viewer .hljs .hljs-strong {
   font-weight: bold;
 }
 
 /* highlight.js — Atom One Light (light theme) */
-[data-theme="light"] .source-viewer code.hljs {
+[data-theme="light"] .source-viewer .hljs {
   color: #383a42;
   background: transparent;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-comment,
-[data-theme="light"] .source-viewer code.hljs .hljs-quote {
+[data-theme="light"] .source-viewer .hljs .hljs-comment,
+[data-theme="light"] .source-viewer .hljs .hljs-quote {
   color: #a0a1a7;
   font-style: italic;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-doctag,
-[data-theme="light"] .source-viewer code.hljs .hljs-keyword,
-[data-theme="light"] .source-viewer code.hljs .hljs-formula {
+[data-theme="light"] .source-viewer .hljs .hljs-doctag,
+[data-theme="light"] .source-viewer .hljs .hljs-keyword,
+[data-theme="light"] .source-viewer .hljs .hljs-formula {
   color: #a626a4;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-section,
-[data-theme="light"] .source-viewer code.hljs .hljs-name,
-[data-theme="light"] .source-viewer code.hljs .hljs-selector-tag,
-[data-theme="light"] .source-viewer code.hljs .hljs-deletion,
-[data-theme="light"] .source-viewer code.hljs .hljs-subst {
+[data-theme="light"] .source-viewer .hljs .hljs-section,
+[data-theme="light"] .source-viewer .hljs .hljs-name,
+[data-theme="light"] .source-viewer .hljs .hljs-selector-tag,
+[data-theme="light"] .source-viewer .hljs .hljs-deletion,
+[data-theme="light"] .source-viewer .hljs .hljs-subst {
   color: #e45649;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-literal {
+[data-theme="light"] .source-viewer .hljs .hljs-literal {
   color: #0184bc;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-string,
-[data-theme="light"] .source-viewer code.hljs .hljs-regexp,
-[data-theme="light"] .source-viewer code.hljs .hljs-addition,
-[data-theme="light"] .source-viewer code.hljs .hljs-attribute,
-[data-theme="light"] .source-viewer code.hljs .hljs-meta .hljs-string {
+[data-theme="light"] .source-viewer .hljs .hljs-string,
+[data-theme="light"] .source-viewer .hljs .hljs-regexp,
+[data-theme="light"] .source-viewer .hljs .hljs-addition,
+[data-theme="light"] .source-viewer .hljs .hljs-attribute,
+[data-theme="light"] .source-viewer .hljs .hljs-meta .hljs-string {
   color: #50a14f;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-attr,
-[data-theme="light"] .source-viewer code.hljs .hljs-variable,
-[data-theme="light"] .source-viewer code.hljs .hljs-template-variable,
-[data-theme="light"] .source-viewer code.hljs .hljs-type,
-[data-theme="light"] .source-viewer code.hljs .hljs-selector-class,
-[data-theme="light"] .source-viewer code.hljs .hljs-selector-attr,
-[data-theme="light"] .source-viewer code.hljs .hljs-selector-pseudo,
-[data-theme="light"] .source-viewer code.hljs .hljs-number {
+[data-theme="light"] .source-viewer .hljs .hljs-attr,
+[data-theme="light"] .source-viewer .hljs .hljs-variable,
+[data-theme="light"] .source-viewer .hljs .hljs-template-variable,
+[data-theme="light"] .source-viewer .hljs .hljs-type,
+[data-theme="light"] .source-viewer .hljs .hljs-selector-class,
+[data-theme="light"] .source-viewer .hljs .hljs-selector-attr,
+[data-theme="light"] .source-viewer .hljs .hljs-selector-pseudo,
+[data-theme="light"] .source-viewer .hljs .hljs-number {
   color: #986801;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-symbol,
-[data-theme="light"] .source-viewer code.hljs .hljs-link,
-[data-theme="light"] .source-viewer code.hljs .hljs-meta,
-[data-theme="light"] .source-viewer code.hljs .hljs-selector-id,
-[data-theme="light"] .source-viewer code.hljs .hljs-title {
+[data-theme="light"] .source-viewer .hljs .hljs-symbol,
+[data-theme="light"] .source-viewer .hljs .hljs-link,
+[data-theme="light"] .source-viewer .hljs .hljs-meta,
+[data-theme="light"] .source-viewer .hljs .hljs-selector-id,
+[data-theme="light"] .source-viewer .hljs .hljs-title {
   color: #4078f2;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-built_in,
-[data-theme="light"] .source-viewer code.hljs .hljs-title.class_,
-[data-theme="light"] .source-viewer code.hljs .hljs-class .hljs-title {
+[data-theme="light"] .source-viewer .hljs .hljs-built_in,
+[data-theme="light"] .source-viewer .hljs .hljs-title.class_,
+[data-theme="light"] .source-viewer .hljs .hljs-class .hljs-title {
   color: #c18401;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-emphasis {
+[data-theme="light"] .source-viewer .hljs .hljs-emphasis {
   font-style: italic;
 }
-[data-theme="light"] .source-viewer code.hljs .hljs-strong {
+[data-theme="light"] .source-viewer .hljs .hljs-strong {
   font-weight: bold;
 }

app/assets/js/hooks/source_viewer.js

@@ -4,7 +4,7 @@
  * Attached to the `#source-viewer` div via `phx-hook="SourceViewer"`.
  * Reads `data-highlighted-line` to find the target line element and
  * scrolls it into view with a smooth animation.
- * Also applies highlight.js syntax highlighting to code blocks.
+ * Applies highlight.js syntax highlighting to individual line content elements.
  */
 import hljs from "highlight.js/lib/core"
 
@@ -20,10 +20,33 @@ export const SourceViewer = {
   },
 
   applySyntaxHighlighting() {
-    const codeEl = this.el.querySelector("code")
-    if (codeEl && !codeEl.querySelector(".hljs")) {
-      hljs.highlightElement(codeEl)
+    const container = this.el.querySelector(".sv-lines")
+    if (!container || container.querySelector(".hljs-on")) return;
+
+    // Collect the raw text from all line content spans
+    const lineContentEls = container.querySelectorAll(".sv-line-content")
+    if (lineContentEls.length === 0) return;
+
+    const rawText = Array.from(lineContentEls).map(el => el.textContent).join("\n")
+
+    // Create a temp element for highlight.js to process
+    const temp = document.createElement("code")
+    temp.textContent = rawText
+    hljs.highlightElement(temp)
+
+    // Split the highlighted HTML back into lines
+    // highlight.js innerHTML uses actual newlines between lines of code
+    const highlightedLines = temp.innerHTML.split("\n")
+
+    // Apply each highlighted line to the corresponding .sv-line-content
+    lineContentEls.forEach((el, i) => {
+      if (highlightedLines[i]) {
+        el.innerHTML = highlightedLines[i]
       }
+    })
+
+    // Mark as highlighted so we don't re-apply on subsequent updates
+    container.classList.add("hljs", "hljs-on")
   },
 
   scrollToHighlighted() {

app/assets/package-lock.json

@@ -9,7 +9,41 @@
       "version": "1.0.0",
       "license": "ISC",
       "dependencies": {
-        "highlight.js": "^11.11.1"
+        "highlight.js": "^11.11.1",
+        "playwright": "^1.61.1"
+      },
+      "devDependencies": {
+        "@playwright/test": "^1.60.0"
+      }
+    },
+    "node_modules/@playwright/test": {
+      "version": "1.61.1",
+      "resolved": "https://registry.npmjs.org/@playwright/test/-/test-1.61.1.tgz",
+      "integrity": "sha512-8nKv6+0RJSL9FE4jYOEGXnPeM/Hg12qZpmqzZjRh3qM0Y7c3z1mrOTfFLids72RDQYVh9WpLEfR5WdpNX4fkig==",
+      "dev": true,
+      "license": "Apache-2.0",
+      "dependencies": {
+        "playwright": "1.61.1"
+      },
+      "bin": {
+        "playwright": "cli.js"
+      },
+      "engines": {
+        "node": ">=18"
+      }
+    },
+    "node_modules/fsevents": {
+      "version": "2.3.2",
+      "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.2.tgz",
+      "integrity": "sha512-xiqMQR4xAeHTuB9uWm+fFRcIOgKBMiOBP+eXiyT7jsgVCq1bkVygt00oASowB7EdtpOHaaPgKt812P9ab+DDKA==",
+      "hasInstallScript": true,
+      "license": "MIT",
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
+      "engines": {
+        "node": "^8.16.0 || ^10.6.0 || >=11.0.0"
       }
     },
     "node_modules/highlight.js": {
@@ -20,6 +54,36 @@
       "engines": {
         "node": ">=12.0.0"
       }
+    },
+    "node_modules/playwright": {
+      "version": "1.61.1",
+      "resolved": "https://registry.npmjs.org/playwright/-/playwright-1.61.1.tgz",
+      "integrity": "sha512-DWnY5o3YbLWK4GovuAVwpqL+1VwGNdUGrRr++8j8PtQQzvAVZUIMjKQ90fY689sEJZJBbZVw1rXaOKSTitkzPQ==",
+      "license": "Apache-2.0",
+      "dependencies": {
+        "playwright-core": "1.61.1"
+      },
+      "bin": {
+        "playwright": "cli.js"
+      },
+      "engines": {
+        "node": ">=18"
+      },
+      "optionalDependencies": {
+        "fsevents": "2.3.2"
+      }
+    },
+    "node_modules/playwright-core": {
+      "version": "1.61.1",
+      "resolved": "https://registry.npmjs.org/playwright-core/-/playwright-core-1.61.1.tgz",
+      "integrity": "sha512-h7Qlt6m4REp25qvIdvbDtVmD4LqVXfpRxhORv9L0jzETM05p4fuPJ3dKyuSXQxDSbXnmS79HAgi9589lGSpLkg==",
+      "license": "Apache-2.0",
+      "bin": {
+        "playwright-core": "cli.js"
+      },
+      "engines": {
+        "node": ">=18"
+      }
     }
   }
 }

app/assets/package.json

@@ -4,13 +4,19 @@
   "description": "",
   "main": "index.js",
   "scripts": {
-    "test": "echo \"Error: no test specified\" && exit 1"
+    "test": "echo \"Error: no test specified\" && exit 1",
+    "test:e2e": "playwright test --config=../playwright.config.ts",
+    "test:e2e:ui": "playwright test --config=../playwright.config.ts --ui"
   },
   "keywords": [],
   "author": "",
   "license": "ISC",
   "type": "commonjs",
+  "devDependencies": {
+    "@playwright/test": "^1.60.0"
+  },
   "dependencies": {
-    "highlight.js": "^11.11.1"
+    "highlight.js": "^11.11.1",
+    "playwright": "^1.61.1"
   }
 }

app/bin/e2e-full.sh

@@ -0,0 +1,44 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Full e2e workflow: start Docker Chrome, run Playwright tests, stop container.
+#
+# Usage: ./bin/e2e-full.sh [extra playwright args...]
+#
+# Requires:
+#   - Docker (colima or Docker Desktop running)
+#   - Phoenix dev server running (default http://localhost:8056)
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+PROJECT_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
+
+cd "$PROJECT_DIR"
+
+echo "=== Starting Chrome container ==="
+docker compose -f docker-compose.chrome.yml up -d
+
+echo "=== Waiting for Chrome to be ready... ==="
+for i in $(seq 1 30); do
+  if curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/ 2>/dev/null | grep -q 200; then
+    echo "Chrome is ready!"
+    break
+  fi
+  if [ "$i" -eq 30 ]; then
+    echo "Timed out waiting for Chrome."
+    docker compose -f docker-compose.chrome.yml logs --tail=20
+    exit 1
+  fi
+  sleep 1
+done
+
+echo "=== Running Playwright e2e tests against Docker Chrome ==="
+cd assets && PLAYWRIGHT_BROWSERS_PATH=node_modules/playwright-core/.local-browsers \
+  npx playwright test --config=../playwright.docker.config.ts "$@"
+
+EXIT_CODE=$?
+
+cd "$PROJECT_DIR"
+echo "=== Stopping Chrome container ==="
+docker compose -f docker-compose.chrome.yml down
+
+exit $EXIT_CODE

app/bin/e2e-start.sh

@@ -0,0 +1,32 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Helper script to start the Playwright Chrome container via Docker
+# Usage: ./bin/e2e-start.sh
+#
+# Starts a browserless/chrome container that Playwright connects to remotely.
+# The container runs Chrome with DevTools Protocol on port 9222.
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+PROJECT_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
+
+echo "Starting Chrome container for Playwright e2e tests..."
+echo "Using docker-compose.chrome.yml"
+
+cd "$PROJECT_DIR"
+
+# Check if colima is needed (no Docker Desktop)
+if ! docker info >/dev/null 2>&1; then
+  echo "Docker daemon not accessible. Have you started colima or Docker Desktop?"
+  echo "  colima start"
+  exit 1
+fi
+
+docker compose -f docker-compose.chrome.yml up -d
+
+echo ""
+echo "Chrome container started! Check status:"
+echo "  docker compose -f docker-compose.chrome.yml ps"
+echo ""
+echo "Run tests:"
+echo "  make playwright"

app/bin/e2e-stop.sh

@@ -0,0 +1,16 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Helper script to stop the Playwright Chrome container
+# Usage: ./bin/e2e-stop.sh
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+PROJECT_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
+
+cd "$PROJECT_DIR"
+
+echo "Stopping Chrome container..."
+
+docker compose -f docker-compose.chrome.yml down
+
+echo "Chrome container stopped."

app/docker-compose.chrome.yml

@@ -0,0 +1,27 @@
+# Docker Compose for Playwright Chrome container
+#
+# Usage:
+#   docker compose -f docker-compose.chrome.yml up -d     # start Chrome
+#   docker compose -f docker-compose.chrome.yml down       # stop Chrome
+#   make playwright                                         # run tests against it
+#
+# The container exposes Chrome DevTools Protocol on port 9222.
+# Playwright connects via the websocket endpoint.
+
+services:
+  chrome:
+    # browserless/chrome is self-contained with Chrome + CDP exposed
+    # multi-arch (supports arm64 for Apple Silicon Macs)
+    image: browserless/chrome:latest
+    container_name: firehose-playwright-chrome
+    ports:
+      - "3000:3000"   # browserless dashboard (not required but handy)
+    environment:
+      - CONNECTION_TIMEOUT=600000
+      - MAX_CONCURRENT_SESSIONS=10
+      - PREBOOT_CHROME=true
+      - DEMO_MODE=false
+      - ENABLE_CORS=true
+    restart: unless-stopped
+    # Run as non-root to avoid permission issues
+    user: "1001:1001"

app/lib/firehose_web/components/core_components.ex

@@ -420,6 +420,30 @@ defmodule FirehoseWeb.CoreComponents do
     """
   end
 
+  @doc """
+  Renders an RSS feed icon (inline SVG).
+
+  ## Examples
+
+      <.rss_icon class="size-5" />
+  """
+  attr :class, :string, default: "size-4"
+  attr :rest, :global
+
+  def rss_icon(assigns) do
+    ~H"""
+    <svg
+      xmlns="http://www.w3.org/2000/svg"
+      viewBox="0 0 24 24"
+      fill="currentColor"
+      class={[@class]}
+      {@rest}
+    >
+      <path d="M6.18 15.64a2.18 2.18 0 0 1 2.18 2.18C8.36 19 7.38 20 6.18 20C5 20 4 19 4 17.82a2.18 2.18 0 0 1 2.18-2.18M4 4.44A15.56 15.56 0 0 1 19.56 20h-2.83A12.73 12.73 0 0 0 4 7.27V4.44m0 5.66a9.9 9.9 0 0 1 9.9 9.9h-2.83A7.07 7.07 0 0 0 4 12.93v-2.83Z" />
+    </svg>
+    """
+  end
+
   ## JS Commands
 
   def show(js \\ %JS{}, selector) do

app/lib/firehose_web/components/layouts/app.html.heex

@@ -23,6 +23,9 @@
       <li>
         <a href="/contact" class="btn btn-ghost btn-sm">Contact</a>
       </li>
+      <li :if={@current_scope && @current_scope.user}>
+        <a href="/editor/dashboard" class="btn btn-ghost btn-sm">Dashboard</a>
+      </li>
       <li>
         <.theme_toggle />
       </li>
@@ -36,4 +39,30 @@
   </div>
 </main>
 
+<footer class="border-t border-base-200 px-4 py-8 sm:px-6 lg:px-8">
+  <div class="mx-auto max-w-2xl space-y-3">
+    <h3 class="text-sm font-semibold tracking-wide text-base-content/60 uppercase">Subscribe</h3>
+    <div class="flex flex-wrap gap-4">
+      <a
+        href="/api/blog/engineering/feed.xml"
+        class="inline-flex items-center gap-2 text-sm text-base-content/70 hover:text-primary transition-colors"
+        target="_blank"
+        rel="noopener noreferrer"
+      >
+        <.rss_icon class="size-4 text-orange-500" />
+        Engineering Blog
+      </a>
+      <a
+        href="/api/blog/releases/feed.xml"
+        class="inline-flex items-center gap-2 text-sm text-base-content/70 hover:text-primary transition-colors"
+        target="_blank"
+        rel="noopener noreferrer"
+      >
+        <.rss_icon class="size-4 text-orange-500" />
+        Release Notes
+      </a>
+    </div>
+  </div>
+</footer>
+
 <.flash_group flash={@flash} />

app/lib/firehose_web/components/layouts/root.html.heex

@@ -41,6 +41,9 @@
       <% end %>
       <meta name="twitter:card" content={meta.twitter_card} />
     <% end %>
+    <%= for feed <- get_content_for(assigns, :feed_links) do %>
+      <link rel="alternate" type="application/rss+xml" title={feed.title} href={feed.rss_url} />
+    <% end %>
   </head>
   <body>
     {@inner_content}

app/lib/firehose_web/controllers/blog_controller.ex

@@ -9,9 +9,11 @@ defmodule FirehoseWeb.BlogController do
     result = blog.paginate(page)
 
     meta = Blogex.SEO.meta_tags_for_blog(blog, FirehoseWeb.Endpoint.url())
+    rss_url = rss_feed_url(blog)
 
     conn
     |> FirehoseWeb.Layouts.put_content_for(:meta_tags, meta)
+    |> FirehoseWeb.Layouts.put_content_for(:feed_links, %{rss_url: rss_url, title: blog.title()})
     |> render(:index,
       page_title: blog.title(),
       blog_title: blog.title(),
@@ -19,7 +21,8 @@ defmodule FirehoseWeb.BlogController do
       posts: result.entries,
       base_path: blog.base_path(),
       page: result.page,
-      total_pages: result.total_pages
+      total_pages: result.total_pages,
+      rss_feed_url: rss_url
     )
   end
 
@@ -27,31 +30,40 @@ defmodule FirehoseWeb.BlogController do
     blog = conn.assigns.blog
     post = blog.get_post!(slug)
     visibility = Blogex.Post.visibility(post)
+    rss_url = rss_feed_url(blog)
 
     meta = Blogex.SEO.meta_tags(post, FirehoseWeb.Endpoint.url(), blog)
 
     conn
     |> FirehoseWeb.Layouts.put_content_for(:meta_tags, meta)
+    |> FirehoseWeb.Layouts.put_content_for(:feed_links, %{rss_url: rss_url, title: blog.title()})
     |> render(:show,
       page_title: post.title,
       post: post,
       meta: meta,
       base_path: blog.base_path(),
       visibility: visibility,
-      authenticated: !!(conn.assigns[:current_scope] && conn.assigns.current_scope.user)
+      authenticated: !!(conn.assigns[:current_scope] && conn.assigns.current_scope.user),
+      rss_feed_url: rss_url
     )
   end
 
   def tag(conn, %{"tag" => tag}) do
     blog = conn.assigns.blog
     posts = blog.posts_by_tag(tag)
+    rss_url = rss_feed_url(blog)
 
-    render(conn, :tag,
+    rss_link = %{rss_url: rss_url, title: blog.title()}
+
+    conn
+    |> FirehoseWeb.Layouts.put_content_for(:feed_links, rss_link)
+    |> render(:tag,
       page_title: "#{blog.title()} — #{tag}",
       blog_title: blog.title(),
       tag: tag,
       posts: posts,
-      base_path: blog.base_path()
+      base_path: blog.base_path(),
+      rss_feed_url: rss_url
     )
   end
 
@@ -77,4 +89,9 @@ defmodule FirehoseWeb.BlogController do
       _ -> 1
     end
   end
+
+  defp rss_feed_url(blog) do
+    base_id = blog.base_path() |> String.trim_leading("/blog/")
+    FirehoseWeb.Endpoint.url() <> "/api/blog/#{base_id}/feed.xml"
+  end
 end

app/lib/firehose_web/controllers/blog_html/index.html.heex

@@ -1,6 +1,17 @@
 <div class="space-y-8">
   <header>
+    <div class="flex items-center gap-3">
       <h1 class="text-3xl font-bold font-display">{@blog_title}</h1>
+      <a
+        href={@rss_feed_url}
+        class="link link-hover text-orange-500 hover:text-orange-600 transition-colors"
+        title="Subscribe to {@blog_title} RSS feed"
+        target="_blank"
+        rel="noopener noreferrer"
+      >
+        <.rss_icon class="size-5" />
+      </a>
+    </div>
     <p :if={@blog_description} class="mt-2 text-base-content/70">{@blog_description}</p>
   </header>
 

app/lib/firehose_web/controllers/blog_html/show.html.heex

@@ -1,5 +1,16 @@
 <div class="space-y-8">
+  <div class="flex items-center justify-between">
     <a href={@base_path} class="text-sm text-primary hover:underline">&larr; Back to posts</a>
+    <a
+      href={@rss_feed_url}
+      class="link link-hover text-orange-500 hover:text-orange-600 transition-colors"
+      title="Subscribe to RSS feed"
+      target="_blank"
+      rel="noopener noreferrer"
+    >
+      <.rss_icon class="size-5" />
+    </a>
+  </div>
 
   <%= if @authenticated and @visibility == :draft do %>
     <div

app/lib/firehose_web/controllers/blog_html/tag.html.heex

@@ -1,6 +1,17 @@
 <div class="space-y-8">
   <header>
+    <div class="flex items-center gap-3">
       <h1 class="text-3xl font-bold font-display">{@blog_title}</h1>
+      <a
+        href={@rss_feed_url}
+        class="link link-hover text-orange-500 hover:text-orange-600 transition-colors"
+        title="Subscribe to {@blog_title} RSS feed"
+        target="_blank"
+        rel="noopener noreferrer"
+      >
+        <.rss_icon class="size-5" />
+      </a>
+    </div>
     <p class="mt-2 text-base-content/70">Posts tagged "{@tag}"</p>
   </header>
 

app/lib/firehose_web/live/editor_dashboard_live.ex

@@ -39,7 +39,7 @@ defmodule FirehoseWeb.EditorDashboardLive do
             "pb-2 px-1 text-sm font-medium transition-colors",
             if(@active_tab == :drafts,
               do: "border-b-2 border-zinc-900 text-zinc-900",
-              else: "text-zinc-500 hover:text-zinc-700"
+              else: "text-base-content/70 hover:text-base-content"
             )
           ]}
         >
@@ -52,7 +52,7 @@ defmodule FirehoseWeb.EditorDashboardLive do
             "pb-2 px-1 text-sm font-medium transition-colors",
             if(@active_tab == :scheduled,
               do: "border-b-2 border-zinc-900 text-zinc-900",
-              else: "text-zinc-500 hover:text-zinc-700"
+              else: "text-base-content/70 hover:text-base-content"
             )
           ]}
         >
@@ -61,17 +61,17 @@ defmodule FirehoseWeb.EditorDashboardLive do
       </div>
 
       <div id="drafts-tab" class={if(@active_tab != :drafts, do: "hidden")}>
-        <div :if={@drafts == []} class="text-zinc-500 text-sm">No drafts</div>
+        <div :if={@drafts == []} class="text-base-content/70 text-sm">No drafts</div>
         <div :for={post <- @drafts} class="py-4 border-b border-zinc-100 last:border-0">
           <div class="flex items-center justify-between">
             <div>
               <.link
                 navigate={post_path(post)}
-                class="text-base font-medium text-zinc-900 hover:underline"
+                class="text-base font-medium text-base-content hover:underline"
               >
                 {post.title}
               </.link>
-              <div class="text-sm text-zinc-500 mt-1">
+              <div class="text-sm text-base-content/70 mt-1">
                 {post.author} · {Calendar.strftime(post.date, "%b %d, %Y")} ·
                 <span class="text-amber-600 font-medium">Draft</span>
               </div>
@@ -81,17 +81,17 @@ defmodule FirehoseWeb.EditorDashboardLive do
       </div>
 
       <div id="scheduled-tab" class={if(@active_tab != :scheduled, do: "hidden")}>
-        <div :if={@scheduled == []} class="text-zinc-500 text-sm">No scheduled posts</div>
+        <div :if={@scheduled == []} class="text-base-content/70 text-sm">No scheduled posts</div>
         <div :for={post <- @scheduled} class="py-4 border-b border-zinc-100 last:border-0">
           <div class="flex items-center justify-between">
             <div>
               <.link
                 navigate={post_path(post)}
-                class="text-base font-medium text-zinc-900 hover:underline"
+                class="text-base font-medium text-base-content hover:underline"
               >
                 {post.title}
               </.link>
-              <div class="text-sm text-zinc-500 mt-1">
+              <div class="text-sm text-base-content/70 mt-1">
                 {post.author} · {Calendar.strftime(post.date, "%b %d, %Y")} ·
                 <span class="text-blue-600 font-medium">
                   {Post.days_until_live(post)} days until live

app/lib/firehose_web/live/microprints_live.ex

@@ -7,8 +7,8 @@ defmodule FirehoseWeb.MicroprintsLive do
   @source_dirs ["app", "blogex"]
 
   @impl true
-  def mount(_params, _session, socket) do
-    files = scan_source_files()
+  def mount(params, _session, socket) do
+    files = scan_source_files_with_dir()
 
     microprints =
       files
@@ -18,9 +18,7 @@ defmodule FirehoseWeb.MicroprintsLive do
      socket
      |> assign(:page_title, "Microprints")
      |> assign(:microprints, microprints)
-     |> assign(:expanded_path, nil)
-     |> assign(:highlighted_path, nil)
-     |> assign(:highlighted_line, nil)}
+     |> restore_state_from_params(params)}
   rescue
     e ->
       {:ok,
@@ -28,17 +26,23 @@ defmodule FirehoseWeb.MicroprintsLive do
        |> assign(:page_title, "Microprints")
        |> assign(:microprints, [])
        |> assign(:expanded_path, nil)
+       |> assign(:source_lines, nil)
        |> assign(:highlighted_path, nil)
        |> assign(:highlighted_line, nil)
        |> put_flash(:error, "Error loading microprints: #{inspect(e)}")}
   end
 
+  @impl true
+  def handle_params(params, _uri, socket) do
+    {:noreply, restore_state_from_params(socket, params)}
+  end
+
   @impl true
   def render(assigns) do
     ~H"""
-    <div class="max-w-6xl mx-auto">
-      <h1 class="text-2xl font-bold mb-2">Microprints</h1>
-      <p class="text-sm text-zinc-500 mb-6">
+    <div class="max-w-4xl mx-auto">
+      <h1 class="text-2xl font-bold mb-6">Microprints</h1>
+      <p class="text-sm text-base-content/70 mb-4">
         Visual fingerprints of source code files. Click a line to highlight it.
         Click a card to expand and view the source.
       </p>
@@ -46,7 +50,7 @@ defmodule FirehoseWeb.MicroprintsLive do
       <.microprint_legend />
 
       <div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6 mt-6">
-        <%= for %{path: path, microprint: microprint, source: source} = item <- @microprints do %>
+        <%= for %{path: path, microprint: microprint, source_dir: _source_dir} = item <- @microprints do %>
           {error = item[:error]}
           <div class="card bg-base-100 shadow-sm border border-zinc-200">
             <div class="card-body p-4">
@@ -76,12 +80,12 @@ defmodule FirehoseWeb.MicroprintsLive do
                   highlighted_line={@highlighted_line}
                 />
 
-                <%= if @expanded_path == path and source do %>
+                <%= if @expanded_path == path and @source_lines do %>
                   <.source_viewer
-                    content={source}
+                    source_lines={@source_lines}
                     highlighted_line={@highlighted_line}
                     language="elixir"
-                    id={"source-viewer-" <> path}
+                    file_path={path}
                   />
                 <% end %>
               <% else %>
@@ -105,10 +109,21 @@ defmodule FirehoseWeb.MicroprintsLive do
         _ -> String.to_integer(line)
       end
 
-    {:noreply,
+    # Collapse any currently expanded file when highlighting a different file
+    expanded =
+      case socket.assigns.expanded_path do
+        ^path -> socket.assigns.expanded_path
+        _ -> nil
+      end
+
+    socket =
       socket
       |> assign(:highlighted_path, path)
-     |> assign(:highlighted_line, highlighted)}
+      |> assign(:highlighted_line, highlighted)
+      |> assign(:expanded_path, expanded)
+      |> assign(:source_lines, nil)
+
+    {:noreply, push_patch(socket, to: build_params(socket))}
   end
 
   @impl true
@@ -119,11 +134,78 @@ defmodule FirehoseWeb.MicroprintsLive do
         _ -> path
       end
 
-    {:noreply, assign(socket, :expanded_path, expanded)}
+    source_lines =
+      case expanded do
+        nil ->
+          nil
+
+        ^path ->
+          item = Enum.find(socket.assigns.microprints, &(&1.path == path))
+
+          if item && item.source_dir do
+            abs_path = resolve_source_path(item.source_dir, path)
+            read_source(abs_path)
+          else
+            nil
+          end
+      end
+
+    socket = socket |> assign(:expanded_path, expanded) |> assign(:source_lines, source_lines)
+
+    {:noreply, push_patch(socket, to: build_params(socket))}
   end
 
   # Private helpers
 
+  defp restore_state_from_params(socket, params) do
+    expanded_path = params["expanded"]
+    highlighted_path = params["highlighted"]
+    highlighted_line = if params["line"], do: String.to_integer(params["line"]), else: nil
+
+    source_lines =
+      if expanded_path do
+        item = Enum.find(socket.assigns.microprints, &(&1.path == expanded_path))
+
+        if item && item.source_dir do
+          abs_path = resolve_source_path(item.source_dir, expanded_path)
+          read_source(abs_path)
+        end
+      end
+
+    socket
+    |> assign(:expanded_path, expanded_path)
+    |> assign(:source_lines, source_lines)
+    |> assign(:highlighted_path, highlighted_path)
+    |> assign(:highlighted_line, highlighted_line)
+  end
+
+  defp build_params(socket) do
+    params = %{}
+
+    params =
+      if socket.assigns.expanded_path do
+        Map.put(params, "expanded", socket.assigns.expanded_path)
+      else
+        params
+      end
+
+    params =
+      if socket.assigns.highlighted_path do
+        Map.put(params, "highlighted", socket.assigns.highlighted_path)
+      else
+        params
+      end
+
+    params =
+      if socket.assigns.highlighted_line do
+        params |> Map.put("line", socket.assigns.highlighted_line)
+      else
+        params
+      end
+
+    "/microprints" <> if params != %{}, do: "?" <> URI.encode_query(params), else: ""
+  end
+
   defp sort_by_mtime(files) do
     app_root = Mix.Project.project_file() |> Path.dirname()
 
@@ -136,16 +218,39 @@ defmodule FirehoseWeb.MicroprintsLive do
     |> Enum.map(fn {file, _mtime} -> file end)
   end
 
+  defp sort_by_mtime_with_dir(tuples) do
+    app_root = Mix.Project.project_file() |> Path.dirname()
+
+    tuples
+    |> Enum.map(fn {path, dir} ->
+      abs_path = Path.join(app_root, path)
+      {{path, dir}, File.stat!(abs_path).mtime}
+    end)
+    |> Enum.sort_by(fn {{_path, _dir}, mtime} -> mtime end, :desc)
+    |> Enum.map(fn {{path, dir}, _mtime} -> {path, dir} end)
+  end
+
   @doc false
   def scan_source_files do
     @source_dirs
     |> Enum.flat_map(&collect_elixir_files/1)
-    |> Enum.uniq()
+    |> Enum.uniq_by(&elem(&1, 0))
+    |> Enum.map(&elem(&1, 0))
     |> Enum.sort()
     |> sort_by_mtime()
     |> Enum.take(2)
   end
 
+  @doc false
+  def scan_source_files_with_dir do
+    @source_dirs
+    |> Enum.flat_map(&collect_elixir_files/1)
+    |> Enum.uniq_by(&elem(&1, 0))
+    |> Enum.sort_by(&elem(&1, 0))
+    |> sort_by_mtime_with_dir()
+    |> Enum.take(2)
+  end
+
   defp resolve_absolute_paths(files) do
     app_root = Mix.Project.project_file() |> Path.dirname()
 
@@ -174,26 +279,26 @@ defmodule FirehoseWeb.MicroprintsLive do
         |> Path.wildcard()
         |> Enum.filter(&File.regular?(&1))
         |> Enum.reject(&excluded_path?/1)
-        |> Enum.map(&format_path(&1, monorepo_root, dir))
+        |> Enum.map(&format_path_and_dir(&1, monorepo_root, dir))
 
       false ->
         []
     end
   end
 
-  defp format_path(path, monorepo_root, dir) do
+  defp format_path_and_dir(path, monorepo_root, dir) do
     relative = Path.relative_to(path, monorepo_root)
 
+    formatted =
       case dir do
-      "app" ->
-        String.replace_prefix(relative, "app/", "")
-
-      _ ->
-        "../" <> relative
-    end
+        "app" -> String.replace_prefix(relative, "app/", "")
+        _ -> "../" <> relative
       end
 
-  defp process_file(rel_path) do
+    {formatted, dir}
+  end
+
+  defp process_file({rel_path, source_dir}) do
     abs_path = resolve_absolute_paths([rel_path]) |> List.first()
 
     case MicroprintCache.get_microprint(abs_path) do
@@ -204,13 +309,10 @@ defmodule FirehoseWeb.MicroprintsLive do
           |> Enum.with_index(1)
           |> Enum.map(fn {line, num} -> Map.put(line, :line_number, num) end)
 
-        # Read source code for expand/contract
-        source = read_source(abs_path)
-
         %{
           path: rel_path,
-          microprint: Map.put(microprint, :lines, lines_with_numbers),
-          source: source
+          source_dir: source_dir,
+          microprint: Map.put(microprint, :lines, lines_with_numbers)
         }
 
       {:error, reason} ->
@@ -218,20 +320,55 @@ defmodule FirehoseWeb.MicroprintsLive do
     end
   end
 
+  defp resolve_source_path(source_dir, rel_path) do
+    app_root = Mix.Project.project_file() |> Path.dirname()
+    monorepo_root = app_root |> Path.dirname()
+    base = Path.join(monorepo_root, source_dir)
+    Path.join(base, rel_path)
+  end
+
   defp read_source(abs_path) do
     case File.read(abs_path) do
-      {:ok, content} ->
-        content
-        |> String.replace("<", "&lt;")
-        |> String.replace(">", "&gt;")
-
-      {:error, _} ->
-        nil
+      {:ok, content} -> String.split(content, "\n")
+      {:error, _} -> nil
     end
   end
 
   # Delegate to MicroprintComponent
   defdelegate microprint(assigns), to: MicroprintComponent
   defdelegate microprint_legend(assigns), to: MicroprintComponent
-  defdelegate source_viewer(assigns), to: MicroprintComponent
+
+  # Custom source_viewer with unique DOM IDs per file to prevent LiveView
+  # DOM patching bugs when switching expanded files.
+  def source_viewer(assigns) do
+    assigns =
+      assign(
+        assigns,
+        :viewer_id,
+        "source-viewer-" <> Integer.to_string(:erlang.phash2(assigns.file_path, 1_000_000))
+      )
+
+    ~H"""
+    <div
+      id={@viewer_id}
+      class="source-viewer mt-2 max-h-96 overflow-auto rounded font-mono text-xs"
+      phx-hook="SourceViewer"
+      data-highlighted-line={@highlighted_line}
+      data-language={@language}
+      style="background: var(--sv-bg); color: var(--sv-text);"
+    >
+      <div class="sv-lines p-2">
+        <%= for {line, num} <- Enum.with_index(@source_lines || [], 1) do %>
+          <div
+            id={"line-#{num}"}
+            class={"sv-line" <> if @highlighted_line == num, do: " sv-line-highlighted", else: ""}
+          >
+            <span class="sv-line-number">{num}</span>
+            <span class="sv-line-content">{line}</span>
+          </div>
+        <% end %>
+      </div>
+    </div>
+    """
+  end
 end

app/lib/firehose_web/router.ex

@@ -75,6 +75,7 @@ defmodule FirehoseWeb.Router do
     pipe_through [:browser, :require_authenticated_user]
 
     live_session :authenticated_user,
+      layout: {FirehoseWeb.Layouts, :app},
       on_mount: [{FirehoseWeb.UserAuth, :ensure_authenticated}] do
       live "/editor/dashboard", EditorDashboardLive
     end

app/mix.exs

@@ -4,7 +4,7 @@ defmodule Firehose.MixProject do
   def project do
     [
       app: :firehose,
-      version: "0.1.0",
+      version: "0.2.0",
       elixir: "~> 1.15",
       elixirc_paths: elixirc_paths(Mix.env()),
       start_permanent: Mix.env() == :prod,

app/mix.lock

@@ -24,16 +24,17 @@
   "idna": {:hex, :idna, "6.1.1", "8a63070e9f7d0c62eb9d9fcb360a7de382448200fbbd1b106cc96d3d8099df8d", [:rebar3], [{:unicode_util_compat, "~> 0.7.0", [hex: :unicode_util_compat, repo: "hexpm", optional: false]}], "hexpm", "92376eb7894412ed19ac475e4a86f7b413c1b9fbb5bd16dccd57934157944cea"},
   "jason": {:hex, :jason, "1.4.4", "b9226785a9aa77b6857ca22832cffa5d5011a667207eb2a0ad56adb5db443b8a", [:mix], [{:decimal, "~> 1.0 or ~> 2.0", [hex: :decimal, repo: "hexpm", optional: true]}], "hexpm", "c5eb0cab91f094599f94d55bc63409236a8ec69a21a67814529e8d5f6cc90b3b"},
   "lazy_html": {:hex, :lazy_html, "0.1.10", "ffe42a0b4e70859cf21a33e12a251e0c76c1dff76391609bd56702a0ef5bc429", [:make, :mix], [{:cc_precompiler, "~> 0.1", [hex: :cc_precompiler, repo: "hexpm", optional: false]}, {:elixir_make, "~> 0.9.0", [hex: :elixir_make, repo: "hexpm", optional: false]}, {:fine, "~> 0.1.0", [hex: :fine, repo: "hexpm", optional: false]}], "hexpm", "50f67e5faa09d45a99c1ddf3fac004f051997877dc8974c5797bb5ccd8e27058"},
-  "makeup": {:hex, :makeup, "1.2.1", "e90ac1c65589ef354378def3ba19d401e739ee7ee06fb47f94c687016e3713d1", [:mix], [{:nimble_parsec, "~> 1.4", [hex: :nimble_parsec, repo: "hexpm", optional: false]}], "hexpm", "d36484867b0bae0fea568d10131197a4c2e47056a6fbe84922bf6ba71c8d17ce"},
+  "makeup": {:hex, :makeup, "1.2.2", "882d46dc0905e9ff7abf2aab61a7e6b3dcc555533977d8a23b06019e6c89ac94", [:mix], [{:nimble_parsec, "~> 1.4", [hex: :nimble_parsec, repo: "hexpm", optional: false]}], "hexpm", "9a1a24e5b343b8ae16abea0822c10a6f75da27af7fa802ada5251f7579bfccfa"},
   "makeup_elixir": {:hex, :makeup_elixir, "1.0.1", "e928a4f984e795e41e3abd27bfc09f51db16ab8ba1aebdba2b3a575437efafc2", [:mix], [{:makeup, "~> 1.0", [hex: :makeup, repo: "hexpm", optional: false]}, {:nimble_parsec, "~> 1.2.3 or ~> 1.3", [hex: :nimble_parsec, repo: "hexpm", optional: false]}], "hexpm", "7284900d412a3e5cfd97fdaed4f5ed389b8f2b4cb49efc0eb3bd10e2febf9507"},
   "makeup_erlang": {:hex, :makeup_erlang, "1.0.3", "4252d5d4098da7415c390e847c814bad3764c94a814a0b4245176215615e1035", [:mix], [{:makeup, "~> 1.0", [hex: :makeup, repo: "hexpm", optional: false]}], "hexpm", "953297c02582a33411ac6208f2c6e55f0e870df7f80da724ed613f10e6706afd"},
+  "mdex_native": {:hex, :mdex_native, "0.2.4", "a74b9d799d3fc487b1f97b70ee9b04108c7af0514920d56828e173d19312c2a9", [:mix], [{:rustler, "~> 0.32", [hex: :rustler, repo: "hexpm", optional: true]}, {:rustler_precompiled, "~> 0.7", [hex: :rustler_precompiled, repo: "hexpm", optional: false]}], "hexpm", "d71185c43c5209c6939f4b65f903f71c892512c93ea6843171227855d2d976f5"},
   "microprints": {:git, "https://gitea.apps.sustainabledelivery.com/QWAN/microprints-phoenix.git", "29ef59ff6eb41853b6f91872d8fffdfba4d85a62", [branch: "main"]},
   "mime": {:hex, :mime, "2.0.7", "b8d739037be7cd402aee1ba0306edfdef982687ee7e9859bee6198c1e7e2f128", [:mix], [], "hexpm", "6171188e399ee16023ffc5b76ce445eb6d9672e2e241d2df6050f3c771e80ccd"},
   "mint": {:hex, :mint, "1.7.1", "113fdb2b2f3b59e47c7955971854641c61f378549d73e829e1768de90fc1abf1", [:mix], [{:castore, "~> 0.1.0 or ~> 1.0", [hex: :castore, repo: "hexpm", optional: true]}, {:hpax, "~> 0.1.1 or ~> 0.2.0 or ~> 1.0", [hex: :hpax, repo: "hexpm", optional: false]}], "hexpm", "fceba0a4d0f24301ddee3024ae116df1c3f4bb7a563a731f45fdfeb9d39a231b"},
   "nimble_options": {:hex, :nimble_options, "1.1.1", "e3a492d54d85fc3fd7c5baf411d9d2852922f66e69476317787a7b2bb000a61b", [:mix], [], "hexpm", "821b2470ca9442c4b6984882fe9bb0389371b8ddec4d45a9504f00a66f650b44"},
   "nimble_parsec": {:hex, :nimble_parsec, "1.4.2", "8efba0122db06df95bfaa78f791344a89352ba04baedd3849593bfce4d0dc1c6", [:mix], [], "hexpm", "4b21398942dda052b403bbe1da991ccd03a053668d147d53fb8c4e0efe09c973"},
   "nimble_pool": {:hex, :nimble_pool, "1.1.0", "bf9c29fbdcba3564a8b800d1eeb5a3c58f36e1e11d7b7fb2e084a643f645f06b", [:mix], [], "hexpm", "af2e4e6b34197db81f7aad230c1118eac993acc0dae6bc83bac0126d4ae0813a"},
-  "nimble_publisher": {:hex, :nimble_publisher, "1.1.1", "3ea4d4cfca45b11a5377bce7608367a9ddd7e717a9098161d8439eca23e239aa", [:mix], [{:earmark, "~> 1.4", [hex: :earmark, repo: "hexpm", optional: false]}, {:makeup, "~> 1.0", [hex: :makeup, repo: "hexpm", optional: false]}], "hexpm", "d67e15bddf07e8c60f75849008b78ea8c6b2b4ae8e3f882ccf0a22d57bd42ed0"},
+  "nimble_publisher": {:hex, :nimble_publisher, "2.0.0", "f4fc100949ccdf1831094ff303b79f27c6f04b2ead829409426ee0d9ed3aa55b", [:mix], [{:makeup, "~> 1.0", [hex: :makeup, repo: "hexpm", optional: true]}, {:mdex_native, "~> 0.1", [hex: :mdex_native, repo: "hexpm", optional: false]}], "hexpm", "88997f74b763c24a15d20a90d7cd4ef1fd01172a2b4651e54d8021a44659f2c8"},
   "phoenix": {:hex, :phoenix, "1.8.5", "919db335247e6d4891764dc3063415b0d2457641c5f9b3751b5df03d8e20bbcf", [:mix], [{:bandit, "~> 1.0", [hex: :bandit, repo: "hexpm", optional: true]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:phoenix_pubsub, "~> 2.1", [hex: :phoenix_pubsub, repo: "hexpm", optional: false]}, {:phoenix_template, "~> 1.0", [hex: :phoenix_template, repo: "hexpm", optional: false]}, {:phoenix_view, "~> 2.0", [hex: :phoenix_view, repo: "hexpm", optional: true]}, {:plug, "~> 1.14", [hex: :plug, repo: "hexpm", optional: false]}, {:plug_cowboy, "~> 2.7", [hex: :plug_cowboy, repo: "hexpm", optional: true]}, {:plug_crypto, "~> 1.2 or ~> 2.0", [hex: :plug_crypto, repo: "hexpm", optional: false]}, {:telemetry, "~> 0.4 or ~> 1.0", [hex: :telemetry, repo: "hexpm", optional: false]}, {:websock_adapter, "~> 0.5.3", [hex: :websock_adapter, repo: "hexpm", optional: false]}], "hexpm", "83b2bb125127e02e9f475c8e3e92736325b5b01b0b9b05407bcb4083b7a32485"},
   "phoenix_ecto": {:hex, :phoenix_ecto, "4.7.0", "75c4b9dfb3efdc42aec2bd5f8bccd978aca0651dbcbc7a3f362ea5d9d43153c6", [:mix], [{:ecto, "~> 3.5", [hex: :ecto, repo: "hexpm", optional: false]}, {:phoenix_html, "~> 2.14.2 or ~> 3.0 or ~> 4.1", [hex: :phoenix_html, repo: "hexpm", optional: true]}, {:plug, "~> 1.9", [hex: :plug, repo: "hexpm", optional: false]}, {:postgrex, "~> 0.16 or ~> 1.0", [hex: :postgrex, repo: "hexpm", optional: true]}], "hexpm", "1d75011e4254cb4ddf823e81823a9629559a1be93b4321a6a5f11a5306fbf4cc"},
   "phoenix_html": {:hex, :phoenix_html, "4.3.0", "d3577a5df4b6954cd7890c84d955c470b5310bb49647f0a114a6eeecc850f7ad", [:mix], [], "hexpm", "3eaa290a78bab0f075f791a46a981bbe769d94bc776869f4f3063a14f30497ad"},
@@ -47,6 +48,8 @@
   "postgrex": {:hex, :postgrex, "0.22.0", "fb027b58b6eab1f6de5396a2abcdaaeb168f9ed4eccbb594e6ac393b02078cbd", [:mix], [{:db_connection, "~> 2.9", [hex: :db_connection, repo: "hexpm", optional: false]}, {:decimal, "~> 1.5 or ~> 2.0", [hex: :decimal, repo: "hexpm", optional: false]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:table, "~> 0.1.0", [hex: :table, repo: "hexpm", optional: true]}], "hexpm", "a68c4261e299597909e03e6f8ff5a13876f5caadaddd0d23af0d0a61afcc5d84"},
   "ranch": {:hex, :ranch, "2.2.0", "25528f82bc8d7c6152c57666ca99ec716510fe0925cb188172f41ce93117b1b0", [:make, :rebar3], [], "hexpm", "fa0b99a1780c80218a4197a59ea8d3bdae32fbff7e88527d7d8a4787eff4f8e7"},
   "req": {:hex, :req, "0.5.17", "0096ddd5b0ed6f576a03dde4b158a0c727215b15d2795e59e0916c6971066ede", [:mix], [{:brotli, "~> 0.3.1", [hex: :brotli, repo: "hexpm", optional: true]}, {:ezstd, "~> 1.0", [hex: :ezstd, repo: "hexpm", optional: true]}, {:finch, "~> 0.17", [hex: :finch, repo: "hexpm", optional: false]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: false]}, {:mime, "~> 2.0.6 or ~> 2.1", [hex: :mime, repo: "hexpm", optional: false]}, {:nimble_csv, "~> 1.0", [hex: :nimble_csv, repo: "hexpm", optional: true]}, {:plug, "~> 1.0", [hex: :plug, repo: "hexpm", optional: true]}], "hexpm", "0b8bc6ffdfebbc07968e59d3ff96d52f2202d0536f10fef4dc11dc02a2a43e39"},
+  "rustler": {:hex, :rustler, "0.38.0", "7a8906998ff0d28e3021c0a73264abcda719bda344b2e58307c6805b0f87c9b4", [:mix], [{:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: false]}], "hexpm", "704c03c1bf66be12b031c5a389347b91c81c5cb819a24b068b0de36fe4a5652a"},
+  "rustler_precompiled": {:hex, :rustler_precompiled, "0.9.0", "3a052eda09f3d2436364645cc1f13279cf95db310eb0c17b0d8f25484b233aa0", [:mix], [{:rustler, "~> 0.23", [hex: :rustler, repo: "hexpm", optional: true]}], "hexpm", "471d97315bd3bf7b64623418b3693eedd8e47de3d1cb79a0ac8f9da7d770d94c"},
   "swoosh": {:hex, :swoosh, "1.23.0", "a1b7f41705357ffb06457d177e734bf378022901ce53889a68bcc59d10a23c27", [:mix], [{:bandit, ">= 1.0.0", [hex: :bandit, repo: "hexpm", optional: true]}, {:cowboy, "~> 1.1 or ~> 2.4", [hex: :cowboy, repo: "hexpm", optional: true]}, {:ex_aws, "~> 2.1", [hex: :ex_aws, repo: "hexpm", optional: true]}, {:finch, "~> 0.6", [hex: :finch, repo: "hexpm", optional: true]}, {:gen_smtp, "~> 0.13 or ~> 1.0", [hex: :gen_smtp, repo: "hexpm", optional: true]}, {:hackney, "~> 1.9", [hex: :hackney, repo: "hexpm", optional: true]}, {:idna, "~> 6.0", [hex: :idna, repo: "hexpm", optional: false]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: false]}, {:mail, "~> 0.2", [hex: :mail, repo: "hexpm", optional: true]}, {:mime, "~> 1.1 or ~> 2.0", [hex: :mime, repo: "hexpm", optional: false]}, {:mua, "~> 0.2.3", [hex: :mua, repo: "hexpm", optional: true]}, {:multipart, "~> 0.4", [hex: :multipart, repo: "hexpm", optional: true]}, {:plug, "~> 1.9", [hex: :plug, repo: "hexpm", optional: true]}, {:plug_cowboy, ">= 1.0.0", [hex: :plug_cowboy, repo: "hexpm", optional: true]}, {:req, "~> 0.5.10 or ~> 0.6 or ~> 1.0", [hex: :req, repo: "hexpm", optional: true]}, {:telemetry, "~> 0.4.2 or ~> 1.0", [hex: :telemetry, repo: "hexpm", optional: false]}], "hexpm", "97aaf04481ce8a351e2d15a3907778bdf3b1ea071cfff3eb8728b65943c77f6d"},
   "tailwind": {:hex, :tailwind, "0.4.1", "e7bcc222fe96a1e55f948e76d13dd84a1a7653fb051d2a167135db3b4b08d3e9", [:mix], [], "hexpm", "6249d4f9819052911120dbdbe9e532e6bd64ea23476056adb7f730aa25c220d1"},
   "telemetry": {:hex, :telemetry, "1.4.1", "ab6de178e2b29b58e8256b92b382ea3f590a47152ca3651ea857a6cae05ac423", [:rebar3], [], "hexpm", "2172e05a27531d3d31dd9782841065c50dd5c3c7699d95266b2edd54c2dafa1c"},

app/playwright.docker.config.ts

@@ -0,0 +1,42 @@
+import { defineConfig, devices } from "@playwright/test";
+
+// Docker Chrome Playwright configuration.
+// Connects to a remote browserless/chrome container via CDP.
+//
+// Usage:
+//   1. Start the Chrome container:
+//      docker compose -f docker-compose.chrome.yml up -d
+//
+//   2. Run tests:
+//      npx playwright test --config=playwright.docker.config.ts
+
+const CDP_URL = process.env.PLAYWRIGHT_CDP_URL || "http://localhost:3000";
+
+export default defineConfig({
+  testDir: "./test/e2e",
+  fullyParallel: true,
+  forbidOnly: !!process.env.CI,
+  retries: process.env.CI ? 2 : 0,
+  workers: process.env.CI ? 1 : undefined,
+  reporter: "list",
+
+  use: {
+    baseURL: process.env.PLAYWRIGHT_BASE_URL || "http://localhost:8056",
+    trace: "on-first-retry",
+    headless: process.env.PLAYWRIGHT_HEADLESS !== "false",
+  },
+
+  // Connect to remote Chrome via CDP instead of launching locally.
+  // browserless/chrome exposes CDP at port 3000.
+  projects: [
+    {
+      name: "docker-chrome",
+      use: {
+        ...devices["Desktop Chrome"],
+        launchOptions: {
+          // Not used for remote connection, but placeholder for clarity
+        },
+      },
+    },
+  ],
+});

app/priv/blog/engineering/2026/03-20-llm-simple-play.md

@@ -9,4 +9,10 @@
 
 I had started on a "Write your own coding agent" exercise. Four iterations in, actually. And then I found [Tiny Agents]( https://tinyagents.dev/lesson/agent-loop), a set of interactive exercises that let you experience how agents work, from a simple chat request, through a tool, more tools etc. It has a live graph, that visualises of the flow of data and actions.
 
-It is good fun to play with, it starts simple and builds up. It lets you inspect the messages between the 'agent' loop code and the large language model server (which is just HTTP and some JSON).
+It is good fun to play with, it starts simple and builds up. It lets you inspect the messages between the 'agent' loop code and the large language model server (which is just HTTP and som![](app/priv/static/images/blog/2026/agent-nearby_20260701_220759.png)e JSON).
+![]/images/blog/2026/Screen![](app/priv/static/images/blog/2026/agent-nearby_20260701_220849.png)shot 2026-06-30 at 22.42.49.png)
+
+![agent nearby](/images/blog/2026/agent-nearby.png)
+![](app/priv/static/images/blog/2026/agent-nearby_20260701_220606.png)
+
+

app/priv/blog/engineering/2026/05-08-ai-zombies.md

@@ -3,7 +3,7 @@
   author: "Willem van den Ende",
   tags: ~w(AI Reflection),
   description: "In which the writer reflects on believing AI is conscious",
-  published: false
+  published: true
 }
 ---
 

app/priv/blog/engineering/2026/05-14-generate-an-init-script-to-get-your-team-up-and-running.md

@@ -64,9 +64,9 @@ According to the agent:
 
 It ends with a summary showing how to start the server (port 8056), demo credentials, and handy make commands.                                                                                                                                                  
 
-The snippet below is from my performance widget. Token generation is not super fast, but all 32 turns ran while attending Chris Parsons’ webinar. 2.5 minutes for a script that ’just works’ is good enough for me.
+The snippet below is from my performance widget. Token generation is not super fast, but all 32 turns ran while attending Chris Parsons' webinar. 2.5 minutes for a script that _just works_; is good enough for me.
 
-📊 Performance: llama.cpp/Qwen3.6-35B-A3B-MXFP4<sub>MOE.gguf</sub>                                                                                                                                                                                                     
+📊 Performance: llama.cpp/Qwen3.6-35B-A3B-MXFP4-MOE.gguf                                                                                                                                                                                                     
   Prefill: 28,376 tokens @ 5253.8 tok/s
   Generation: 5,699 tokens @ 38.8 tok/s
   Combined: 34,075 tokens @ 223.5 tok/s (2.5m total)

app/priv/blog/engineering/2026/06-20-enabling-a-local-model-to-explain-images-in-pidev.md

@@ -0,0 +1,143 @@
+%{
+  title: "How to let a local model interpret images in Pi.dev with llama.cpp",
+  author: "Willem van den Ende",
+  tags: ~w(),
+  description: "QWEN 3.6 models are multi modal, but getting that to work requires an additional file and configuration in llama.cpp and enabling images in the Pi.dev models configuration.",
+  published: true
+}
+---
+
+I have used visual language models occasionally, but since I switched from Claude Code to [Pi](https://pi.dev) I had not gotten around to setting it up. Jon Jagger mentioned he had just tried it out in a programming session with Claude Code, and then I decided that maybe I shoult take a bit of time to figure it out. It was not that difficult, sort of in the category: "Why did I not do that sooner?". It is quite handy to be able to draw a state diagram and use that as a starting point to draw out a workflow. 
+
+In this case, we were discussing giving developers feedback on how they are running the TDD cycle in CyberDojo (e.g. many 'red' cycles may mean the step is too big), and I was also interested in making a deterministic extension for Pi to slow down coding agents and people, and make sure that the *Refactoring* step actually happens. The state diagram was a good starting point, it got more complicated when building a Pi extension. More about that in a next post.
+
+QWEN 3.6 models are multi modal, but getting that to work requires an additional file and configuration in llama.cpp and enabling images in the Pi.dev models configuration.
+
+In addition to the configuration I described in [My local agentic dev setup two months ago](/blog/engineering/my-local-agentic-dev-setup-today), I had to download  an 'mmproj' file and specify it in my llama.cpp run script. And then it was vision capable. I put the mmproj file in the directory with my scripts, as the name is somewhat generic, and I do not yet know if it is the same for other models, or specific for this one.
+
+There are some more changes to the script since the last time, most notable `--spec-default` for 'speculative decoding' which gave a nice speed bump.
+
+``` bash
+#!/usr/bin/env bash
+set -euo pipefail
+ROOT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+LLAMA_DIR="${ROOT_DIR}/llama.cpp"
+
+# GGUF_DIR="$(llm gguf models-dir)"
+GGUF_DIR="/Users/willem/Library/Application Support/io.datasette.llm/gguf/models/"
+MAIN="${GGUF_DIR}Qwen3.6-35B-A3B-MXFP4_MOE.gguf"
+
+ls "${MAIN}"
+
+exec "${LLAMA_DIR}/build/bin/llama-server" \
+  -m "$MAIN" \
+  --mmproj unsloth/Qwen3.6-35B-A3B-GGUF/mmproj-F16.gguf \
+  --spec-default \
+  -c 262144 \
+  --temp 0.6 --top-k 20 --top-p 0.95 --repeat-penalty 1.0 \
+  --presence-penalty 0.0 \
+  --chat-template-kwargs '{"preserve_thinking": true}' \
+  --parallel 1 \
+  --jinja \
+  --host 0.0.0.0 --port 8000
+```
+
+For Pi.dev, I needed to add "image" to the part of `models.json` that has the model configuration:
+
+``` json
+      "models": [
+        {
+          "id": "Qwen3.6-35B-A3B-MXFP4_MOE.gguf",
+          "name": "Qwen3.6-35B",
+          "reasoning": true,
+          "input": [
+              "text", "image"
+          ],
+          "compat": {
+            "thinkingFormat": "qwen-chat-template"
+          },
+          "contextWindow": 262144,
+          "maxTokens": 32768,
+          "cost": {
+            "input": 0,
+            "output": 0,
+            "cacheRead": 0,
+            "cacheWrite": 0
+          }
+         }
+       ]
+```
+
+That was all the configuration changes. Two lines and a copy.
+
+I then fed a state diagram of the red-green-refactor cycle that Jon Jagger made, by tab-completing the filename in the prompt, and the model figured out it was a state diagram (this was, admittedly also in the name of the file). It also found out the states and the transitions - much faster than trying to type it out. The red green refactor cycle from tdd was recognised. TDD was in the name of the file, but the connection with red-green-refactor was not. the only thing slightly off is 'rip' instead of *ship*. Which leads to some more fun interpretations further down.
+
+The results I found surprisingly good, as Jon sketched this during a conversation, with no intent to convert it later. Here is the photo, you can see the shadow of my phone.
+
+![Hand drawn state diagram, transcribed below in 'Inline session transcript' as tables and part mermaid diagram.](/images/blog/2026/tdd-state-diagram-john-jagger.jpeg)
+
+![what inline image location should be](../../../static/images/blog/2026/tdd-state-diagram-john-jagger.jpeg)
+
+Below you can see the part of the session where QWEN interpreted the image. I asked after that to make a mermaid diagram. The mermaid syntax was broken, so either a larger or more cohesive model might be needed, or feedback from running `mmdc` - the mermaid command line.
+
+# Inline session transcript
+
+ I have chosen a vision capable model now
+ Great! Now I should be able to see the image. Let me read it again:
+ read tdd-state-diagram-john-jagger.jpeg
+
+Now I can see it! This is a TDD State Diagram drawn on a yellow sticky note. Here's the breakdown:
+
+## States
+
+ | State            | Description                                              |
+ |------------------|----------------------------------------------------------|
+ | **RED**          | The "fail first" state — write a failing test            |
+ | **GREEN**        | The "make it pass" state — minimal code to pass the test |
+ | **●** (terminal) | Accept/exit state — done, ship it                        |
+
+## Transitions
+
+ | From → To                         | Label                      | Meaning                                                      |
+ |-----------------------------------|----------------------------|--------------------------------------------------------------|
+ | **RED** → **RED** (self-loop)     | *"improve the diagnostic"* | Refine the failing test / understand what's wrong            |
+ | **RED** → **GREEN**               | *"pass"*                   | Write minimal code to make the test pass                     |
+ | **GREEN** → **RED**               | *"change"*                 | Refactor or add new requirements (break the test on purpose) |
+ | **GREEN** → **GREEN** (self-loop) | *"relax"*                  | Refactor while tests stay green                              |
+ | **GREEN** → **●** (terminal)      | *"rip"*                    | Ship it / done (rip the test away)                           |
+
+## Flow
+
+ 1. Start in **RED** — write a failing test
+ 2. **Improve the diagnostic** (self-loop) — debug the failure
+ 3. Make it **pass** → move to **GREEN**
+ 4. **Change** the requirements → back to **RED**
+ 5. **Relax** (refactor) while staying **GREEN**
+ 6. When done, **rip** → terminal state
+
+ A classic, hand-drawn representation of the Red-Green-Refactor cycle!
+
+## Mermaid Source
+
+ ```mermaid
+ ---
+ title: TDD State Diagram — John Jagger
+ ---
+ stateDiagram
+     [*] --> RED
+
+     RED --> RED : improve the diagnostic
+     RED --> GREEN : pass
+     GREEN --> RED : change
+     GREEN --> GREEN : relax
+     GREEN --> [*] : rip
+ ```
+                                                                                                                                                                                                                                 
+1. Start in RED — write a failing test                                                                                                                                                                                          
+2. Improve the diagnostic (self-loop) — debug the failure
+3. Make it pass → move to GREEN
+4. Change the requirements → back to RED
+5. Relax (refactor) while staying GREEN
+6. When done, rip → terminal state
+
+ 

app/priv/blog/engineering/2026/06-26-an-example-would-be-handy-right-now.html

@@ -0,0 +1,108 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+
+<head>
+<title>06-26-an-example-would-be-handy-right-now.html</title>
+<meta http-equiv="Content-Type" content="application/xhtml+xml;charset=utf-8"/>
+<link rel="stylesheet" type="text/css" media="all" href="https://cdn.jsdelivr.net/npm/github-markdown-css/github-markdown.min.css"  />
+<link rel="stylesheet" type="text/css" media="all" href="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/styles/github.min.css"  /><meta name='viewport' content='width=device-width, initial-scale=1, shrink-to-fit=no'><style> body { box-sizing: border-box; max-width: 740px; width: 100%; margin: 40px auto; padding: 0 10px; } </style><script id='MathJax-script' async src='https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js'></script><script src='https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/highlight.min.js'></script><script>document.addEventListener('DOMContentLoaded', () => { document.body.classList.add('markdown-body'); document.querySelectorAll('pre[lang] > code').forEach((code) => { code.classList.add(code.parentElement.lang); }); document.querySelectorAll('pre > code').forEach((code) => { hljs.highlightBlock(code); }); });</script>
+</head>
+
+<body>
+
+<h2 id="section">}</h2>
+<p>Would I recommend Emacs as a writing environment? I don’t know. It
+works for me, mostly thanks to org-roam. And after 5 years of <em>thou
+shalt not lose weeks of configuring Emacs</em>, I am occasionally making
+small tweaks.</p>
+<p>Admittedly, these tweaks sometimes are things that <em>should just
+work out of the box (TM)</em>. For instance, I can drag and drop an
+image (on my mac, at least) in an org-mode file, and then I get to
+choose how the image should be linked to the document. And then I can
+see it.</p>
+<p>But <em>of course</em> I mean <em>for some reason</em> this does not
+work in markdown-mode. Luckily <a
+href="https://oxal.org/blog/powerful-emacs-hacks-paste-images-markdown/">someone
+else solved this problem before me.</a>. And found that markdown mode is
+extensible in how it looks for files.</p>
+<p>But what does this have to do with shaving yaks, you wonder? Well, I
+was annoyed that I could not drag and drop images, displaying images was
+something the author figured out first, and used as part of a solution
+in dropping images.</p>
+<p>I have been muddling through, and was reminded I have that problem
+too. But then I was stuck. I hate thinking about paths on my computer.
+And for some silly reason, I made this blog in the same way as Jekyll
+and other static site generators - the images are nowhere near the blog
+posts. I should fix that, but not on a hot friday when I’m recovering
+from successful, but intensive, new work.</p>
+<p><a
+href="https://oxal.org/blog/powerful-emacs-hacks-image-markdown/">This
+post helpfully explains how to find the right function, and what to
+do</a>. And I have a link to an image <a
+href="https://willemvandenende.com/blog/engineering/enabling-a-local-model-to-explain-images-in-pidev">in
+my previous post</a> that will of course not show in
+<code>markdown-mode</code>. Staring at the screen for a while, it hit
+me.</p>
+<p>## An example would be handy right about now</p>
+<p>So I copied the image link, had a look at my directory structure,
+enabled images (yes, that is disabled by default. I guess a
+distraction-free writing environment requires the purity of no man-made
+images). And then still saw nothing, because I forgot the
+<code>static</code> part of the path. But this was quick iteration, no
+code or tests were harmed in the making of this example:</p>
+<pre><code>![Hand drawn state diagram, transcribed below in &#39;Inline session transcript&#39; as tables and part mermaid diagram.](/images/blog/2026/tdd-state-diagram-john-jagger.jpeg)
+
+![what inline image location should be](../../../static/images/blog/2026/tdd-state-diagram-john-jagger.jpeg)</code></pre>
+<p>Now I can go back to the joy of copy-paste-modifying the code from
+the blogpost with my very own path.</p>
+<h2 id="a-test-would-be-handy-right-about-now">A test would be handy
+right about now</h2>
+<p>I figured I could hack this path <em>only</em> for my blog, and use a
+local configuration. After copy-pasting the code, it was time, for,
+<em>le sigh</em> <em>modify</em>. I could let my animatronic rubber duck
+do it, but I have decided to better understand my emacs mods, so doing
+it by hand today.</p>
+<p>There is a <code>substring</code> call that I don’t need - my example
+shows that blog post and images are both under <code>priv</code>. So I
+need a bunch of <code>..</code> or be clever and use the git project
+root. Since my example with <code>..</code> works, we’ll make it work
+and then maybe make it right.</p>
+<p>But I don’t often write tests. And there was an error in it, so going
+straight to an emacs lisp file was too big a step.</p>
+<h2 id="taking-a-step-back-literate-programming-to-the-rescue">Taking a
+step back, literate programming to the rescue</h2>
+<p>In org mode I can have my function and a call for an example in a
+code block, and see the error right there. I had a ‘wrong number of
+arguments’ somewhere. But I can’t understand the
+<code>ert-deftest</code> error message.</p>
+<h2 id="another-step-back">Another step back</h2>
+<p>Running the function in an org-mode code block worked. the function
+doesn’t. I needed my rubber duck. Thank you dear reader.</p>
+<p>I don’t know why emacs’ <code>ert-deftest</code> test framework needs
+so many keystrokes. I need to evaluate the buffer (the place where you
+edit files) and then run the test runner separately. Org-mode worked but
+also this is not where the code should end up.</p>
+<p>The example code in the blogpost used <code>message</code>, so I
+added that to my emacs lisp file. Now I can evaluate the buffer with a
+changed function, and see the output (in the ‘messages’ buffer, and in
+the status line below)</p>
+<figure>
+<img src="/images/blog/2026/tdd-state-diagram-john-jagger.jpeg"
+alt="Hand drawn state diagram, transcribed below in ‘Inline session transcript’ as tables and part mermaid diagram." />
+<figcaption aria-hidden="true">Hand drawn state diagram, transcribed
+below in ‘Inline session transcript’ as tables and part mermaid
+diagram.</figcaption>
+</figure>
+<figure>
+<img
+src="../../../static/images/blog/2026/tdd-state-diagram-john-jagger.jpeg"
+alt="what inline image location should be" />
+<figcaption aria-hidden="true">what inline image location should
+be</figcaption>
+</figure>
+
+</body>
+</html>

app/priv/blog/engineering/2026/06-26-an-example-would-be-handy-right-now.md

@@ -0,0 +1,100 @@
+%{
+  title: "An example would be handy right about now - how to shave yaks with great efficiency .",
+  author: "Willem van den Ende",
+  tags: ~w(Emacs Examples),
+  description: "Brian Marick once distributed stickers with 'An example would be handy right about now'. This is also handy in cases where writing a test is not directly obvious",
+  published: true
+}
+---
+
+# TLDR;
+
+I write these blogposts in markdown. My editor does not show images, because the paths in the site are different than in the filesystem. My editor is moldable, but I only mold if I need to. I don't want to turn into "I am using tech x to write my blog" and blog about nothing but the tech I use for blogging. Since I am [writing more posts](https://xkcd.com/741/), not being able to easily work with images was starting to get to the point where investing a bit of time in working with images better was worth it.
+
+Originally I wanted to be able to drag images into my editor and get them in the right place for the blog. And then, by reading, I realised that correctly placed images for my blog were not showing when I was editing. So I fixed that first, following someone else's learning path.
+
+Fixing this involved staring at the wall, and then realising that an example would be handy. And it was. Even without a unit test.
+
+# How it began
+
+Would I recommend Emacs as a writing environment? I don't know. It works for me, mostly thanks to org-roam. And after 5 years of _thou shalt not lose weeks of configuring Emacs_, I am occasionally making small tweaks.
+
+Admittedly, these tweaks sometimes are things that _should just work out of the box (TM)_. For instance, I can drag and drop an image (on my mac, at least) in an org-mode file, and then I get to choose how the image should be linked to the document. And then I can see it.
+
+But  _of course_ I mean _for some reason_ this does not work in markdown-mode. Luckily [someone else solved this problem before me.](https://oxal.org/blog/powerful-emacs-hacks-paste-images-markdown/). And found that markdown mode is extensible in how it looks for files.
+
+But what does this have to do with shaving yaks, you wonder? Well, I was annoyed that I could not drag and drop images, displaying images was something the author figured out first, and used as part of a solution in dropping images.
+
+I have been muddling through, and was reminded I have that problem too. But then I was stuck. I hate thinking about paths on my computer. And for some silly reason, I made this blog in the same way as Jekyll and other static site generators - the images are nowhere near the blog posts. I should fix that, but not on a hot friday when I'm recovering from successful, but intensive, new work.
+
+[This post helpfully explains how to find the right function, and what to do](https://oxal.org/blog/powerful-emacs-hacks-image-markdown/). And I have a link to an image [in my previous post](https://willemvandenende.com/blog/engineering/enabling-a-local-model-to-explain-images-in-pidev) that will of course not show in `markdown-mode`. Staring at the screen for a while, it hit me.
+
+# An example would be handy right about now
+----
+
+[Brian Marick](http://www.exampler.com/about/) handed out stickers saying "An example would be handy right about now". I can read posts all day long, but modifying someones' (generated) code is probably going to end badly, without checking the output before and after.
+
+
+So I copied the image link, had a look at my directory structure, enabled images (yes, that is disabled by default. I guess a distraction-free writing environment requires the purity of no man-made images). And then still saw nothing, because I forgot the `static` part of the path. But this was quick iteration, no code or tests were harmed in the making of this example:
+
+```
+![Hand drawn state diagram, transcribed below in 'Inline session transcript' as tables and part mermaid diagram.](/images/blog/2026/tdd-state-diagram-john-jagger.jpeg)
+
+![what inline image location should be](../../../static/images/blog/2026/tdd-state-diagram-john-jagger.jpeg)
+```
+
+Now I can go back to the joy of copy-paste-modifying the code from the blogpost with my very own path.
+
+# A test would be handy right about now
+
+I figured I could hack this path _only_ for my blog, and use a local configuration. After copy-pasting the code, it was time, for, _le sigh_ _modify_. I could let my animatronic rubber duck do it, but I have decided to better understand my emacs mods, so doing it by hand today.
+
+There is a `substring` call that I don't need - my example shows that blog post and images are both under `priv`. So I need a bunch of `..` or be clever and use the git project root. Since my example with `..` works, we'll make it work and then maybe make it right.
+
+But I don't often write tests. And there was an error in it, so going straight to an emacs lisp file was too big a step.
+
+# Taking a step back, literate programming to the rescue?
+
+In org mode I can have my function and a call for an example in a code block, and see the error right there. I had a 'wrong number of arguments' somewhere. But I can't understand the `ert-deftest` error message. 
+
+Another step back
+==
+
+Running the function in an org-mode code block worked. the function doesn't. I needed my rubber duck. Thank you dear reader. 
+
+I don't know why emacs' `ert-deftest` test framework needs so many keystrokes. I need to evaluate the buffer (the place where you edit files) and then run the test runner separately. Org-mode worked but also this is not where the code should end up.
+
+The example code in the blogpost used `message`, so I added that to my emacs lisp file. Now I can evaluate the buffer with a changed function, and see the output (in the 'messages' buffer, and in the status line below)
+
+For testing in Emacs, I put the actual image in this blogpost, until I could see it. I like this TDD state diagram, and am evolving it as I spike on 
+
+![Hand drawn state diagram, transcribed below in 'Inline session transcript' as tables and part mermaid diagram.](/images/blog/2026/tdd-state-diagram-john-jagger.jpeg)
+
+
+# And then it does not integrate
+
+The last part is monkey patching the long function that markdown-mode uses to generate the image.
+the monkey patched functoin enables the 'hook' in another place, but the hook does not get called.
+
+I am now at the point where I am putting print statements in to see what happens. Print is known as `message` in emacs. And the rubber duck of writing does its thing - after taking a break.
+
+I put the hook definition inside a callback that gets run when the mode loads. Which of course it does not. More `modify` needed after `copy-paste`.
+
+# It works. Will it load with my blog repository?
+
+If I do this by hand, yes. When I add a file named  [dir-locals.el](https://wiki.migueldeoleiros.com/notes/20250117203949-local_emacs_configuration_per_directory) I can redefine global variables per mode. The file itself is a list of modes, and settings for each mode. It does not allow for defining new functions.
+
+That is annoying. With [Pi.dev](Pi.dev) it is nice that I can start [moldable development](https://medium.com/feenk/rewilding-software-engineering-900ca95ebc8c) right in my current project, and only extract to my machine or a published repository once I am a bit further and ready to generalise. I have an ugly hack in a file. I could move this ugly hack to my personal emacs repository, put the image prefix in a `.dir-locals.el` and at least it would automatically load. On my machine. I would like this to go with the blog source, so I can see images wherever I edit. I find it annoying to work on another machine and have to go and find  I do not have something.
+
+
+# And that is why I write blog posts like this
+
+Some of my blogposts seem to help other people, which was the stated aim, and it is nice to see that it works. The other one is to pay it forward, I managed to improve my blog writing workflow thanks to someone else's blogpost and am paying it forward. The pay-off after a few weeks seem to be that it is easier for me to find things back in my blog than on my machine(s). I have used my [instructions for setting up Pi.dev on a VPS](https://willemvandenende.com/blog/engineering/how-to-get-started-with-the-pi-coding-agent-on-a-vps) to remember how to set up open router on one of my machines, for instance.
+
+[Backing up your work to the internet](https://lkml.iu.edu/hypermail/linux/kernel/9607.2/0292.html) is great. I hope you enjoyed this yak shaving adventure. 
+
+The rabbit hole of emacs is deep, but removing friction from my workflows is not that onerous. And I needed to tinker with a small bit of code to recover from developing a more conceptual talk and a new workshop. 
+
+# Where is the code?
+
+I forgot about that the first time around. For now it lives in [init.el](https://gitea.apps.sustainabledelivery.com/mostalive/firehose/src/branch/main/init.el) in the firehose repository. I want it to load when I open a markdown file in the repository. So it works on my other machines, and in the unlikely event that someone else uses firehose for their blog and uses Emacs to write posts, they should have the code to enjoy images too.

app/priv/blog/engineering/2026/07-03-removing-a-special-cause-of-variation-in-small-steps.md

@@ -0,0 +1,29 @@
+%{
+  title: "Removing a special cause of variation in small steps",
+  author: "Willem van den Ende",
+  tags: ~w(Emacs AI Pi.dev ),
+  description: "Next annoying variation in my blog writing workflow is adding images to a post. I wanted to add drag and drop. I let a coding agent generate something that almost worked, and then did the finishing touches by hand, simplifying the UX and code as I went.",
+  published: true
+}
+---
+
+The next annoying variation in my blog writing workflow is adding images to a post. I wanted to add drag and drop. I let a coding agent generate something that almost worked, and then did the finishing touches by hand, simplifying the UX and code as I went, and learning more about writing tests and debugging in Emacs Lisp as I went.
+
+Adding images is something I want to do in the flow, while looking at images. Thinking about where to store them is _accidental friction_ during the writing and edting process.
+
+In [the previous post](/blog/engineering/an-example-would-be-handy-right-now) I made images visible (to me) while editing blog posts. Adding said images was still as annoying as it was in other static sites I write in. Including the QWAN slides repository. Images are not next to blog posts. I repeated that mistake here when creating Firehose. Fixing that is a bigger step. I wanted a small step, and even when images are next to blog posts, I still have to go into the terminal and copy files around. Often I want to add a screenshot, so I find the screenshot, then remember (aka look up) where images are stored, ~cp~ the image in the right place, and then make the link in markdown.
+
+![Screenshot of Emacs, with a dropped image in a blog post in the left pane.](/images/blog/2026/drag-drop-image-emacs-markdown.png)
+_Screenshot of working environment. Blog post with dropped image on the left, printed debug messages at the bottom, commit history on the right_.
+
+
+I used [Pi.dev](https//pi.dev) to rummage through the scrapheap of Emacs lisp code on my machine. Programming by similarity is something LLMs can do. Since I found out recently that I can drop an image on an org-mode file and link it ("Attaching" org-mode calls that), I wanted the same in markdown. So I asked how that could work, and then had a function generated and wired into ~markdown-mode~ through a 'hook'. It almost worked, but not quite.
+
+DeepseekV4-flash had generated a function with the usual LLM 'fallbacks'. What if the image does not exist? what if the directory does not exist?
+
+I applied the usual 'fail fast' principle and deleted the fallbacks, replacing some of them with a call to ~error~.  I am upskilling in Emacs Lisp as I go - I found a call to ~error~, looked up what it does: it throws an exception. I also wrote some tests, like in the previous blog post. More to get going. But as usual, it helped me simplify. The act of writing a test forces me to be very precise in what I want.
+
+The generated code was, like much 'normal' Emacs Lisp from libraries very tied to the UI. I extracted a function to determine if something was an image. This was written as two variable assignments. Having worked with Haskell and Clojure, I would write code like that sometimes, and then extract to a function or a pipe later, once I understood the dependencies between the steps better. Having been on the road for the last week and now teaching others to work with coding agents in small steps, I am moving from _knowing what good looks like_ to _knowing what good feels like_. Intuition, judgement, guided by (bad ;-)) experience.
+
+I won't bore you with the details of my code here. Suffice it to say, I have one excuse less to not publish posts. Screenshots are easily made, now they are also easy to publish. A small step etc.
+

app/priv/blog/engineering/2026/07-07-moralistic-programming.md

@@ -0,0 +1,51 @@
+%{
+  title: "Replace Moralistic Programming with Situational Awareness",
+  author: "Willem van den Ende",
+  tags: ~w(craft situational-awareness),
+  description: "I don't like what I now call Moralistic Programming. 'You are not a good developer if <you don't use my pet favourite practice>'. I see some of that resurfacing in discussions around coding agents. I value Situational Awareness over best practices and fingerpointing..",
+  published: true
+}
+---
+
+I prefer to start where I am, or where we are, and figure things out from there. That requires Situational Awareness, being able to make sense, together, of what we are facing, where we want to go and what we have at our disposal.
+
+This is contextual. Which is annoying, because it makes communicating online about our lived experience difficult when there are new-ish tools (like coding agents with LLMs) are available. What works in one context for one team, may not work for another, for reasons that may become clear in hindsight, or not.
+
+One of the things I didn't like around the early Software Craft movement (especially the american instatiation of it) was what I now call "moralistic programming". "You are not a good developer if <you don't use my pet favourite practice>". 
+
+I'm seeing some of the same tendencies that were around in the early software craft movement repeated in agentic engineering. 
+Instead of "you're not a professional software developer if you don't write tests" we have "you're not a professional software developer if you write code by hand".
+
+I enjoy both writing tests and wrangling (and developing) coding agents, and am always looking for better ways. When I briefly had a job in 1999, in the job interview Danny Greefhorst, and the late Gert Florijn, who would become my mentor, asked what I thought about Object Orientation. I remember saying something like "I like it, and use it, until something better comes along". They hired me anyway.
+
+I like to put "knobs to 11" and figure out the extremes. So that I know where the limits of my tools and my thinking are. Preferably together with other people. 
+
+This brief post is the adaptation of a comment on [a LinkedIn post by Machiel Keizer-Groeneveld](https://www.linkedin.com/posts/machielkeizergroeneveld_llms-are-confident-and-that-trips-me-up-share-7478794175946309632-HIOY/) 
+
+Machiel:
+
+>Because nothing is categorically solved, we don't need new words for software development, AI does not 'change everything' even though we are discovering where and how LLMs can assist our software dev practice. The downsides are also showing themselves clearly: LLMs have the wrong built-in intent, they either lack domain knowledge or context rot ignores it, causality is an obvious weakness, they do not evolve their understanding, ask too few questions, they are too confident and apt design requires real intelligence, not plausibility at scale.
+
+>LLM or not, we need software that is reliable, transparent, extensible and capturing domain intent
+
+As ever, we are finding better ways of delivering value (often, but not necessarily, with software) by doing it, and helping others do it.
+
+Looking for something in my notes, I found John Cutler quoting Cat Hicks:
+
+>What would it look like if we could ask, "how do I make this the absolute best environment for complex problem-solving" instead of "how do I take away all these annoying hard problems." The stuff we want to accomplish in the world is hard. But can be joyful to accomplish.
+
+Further reading
+---
+
+Gojko Adzic recent post on how to use [Commanders' Intent](https://www.votito.com/methods/commanders-intent-statement/?tag=li2608) for feature development.
+
+I like to combine Commanders Intent with Backbriefing, which is well described in the late Stephen Bungay's [The Art of Action](https://www.hachette.co.uk/titles/stephen-bungay/the-art-of-action/9781529376968/) 
+
+Afterword
+----
+
+I haven't written about this, but I have once shipped a system with very few tests (and no, this was not written in an "if it compiles it works" language, but PHP). It wasn't the optimal way to do it, but we managed to deliver value faster in other ways that were visible and achievable for the team. Focus and zero-defects worked without tests, but slower. Automating other manual work shrunk the release cycle more than tests would have - they would have added value after that, but then the project was over. Did I miss tests? Yes. Did I tell anyone about it? Well, maybe Rob and Marc at [QWAN](https://www.qwan.eu). And I told you now. 
+
+Everyone I worked with wanted to achieve a good outcome, and that is what counts. We can always find better ways.
+
+

app/priv/blog/engineering/2026/07-13-synthetic-tdd.md

@@ -0,0 +1,16 @@
+%{
+  title: "Synthetic TDD",
+  author: "Willem van den Ende",
+  tags: ~w(Vocabulary AI TDD),
+  description: "Synthetic Test Driven Development is when you have a coding agent generate the tests and the code, and maybe also do the refactor step with an agent.",
+  published: true
+}
+---
+
+I'm starting small posts under the vocabulary tag, to tease out concepts that fall out of other posts, but would be too much of an aside there. This one line could go under "Jargon", to be fair. These may evolve to larger post. I am going to try and at least leave you with a question in each :-).
+
+*Synthetic Test Driven Development* is when you have a coding agent generate the tests and the code, and also do the refactor step(s) with an agent.".
+
+When considering _Synthetic TDD_ it is worth considering what benefits you get from writing tests first as an activity, in a very short cycle, and what value you get from having tests as an artifact.
+
+

app/priv/blog/engineering/2026/07-16-at-coding-agent-skill-to-guide-editing-in-place.md

@@ -0,0 +1,253 @@
+%{
+  title: "At coding agent skill to guide editing in-place",
+  author: "Willem van den Ende",
+  tags: ~w(AI coding-agent baby-steps),
+  description: "With an @<agent> instruction in a file, you can use your regular coding agent on small parts of your code, without modifiying your editor / IDE.",
+  published: false
+}
+---
+
+TLDR
+===
+
+I made an agent skill that let's me one of Aider's favourite tricks: naming the agent in the code with `@aider extract the code below into a method <foo>`, so you don't have to go back and forth between a chat window and the code as much.
+
+Aider is a coding agent that precedes claude code. It didn't have tool calls, but did have very well defined mini-flows like this.
+
+I remember Aider picking this up on save, and executing immediately. This skill is a bit cruder, I run the command `skill:at-pi` and then it searches in recently changed files for lines annotated with `@pi` or `@Pi`.
+
+The main benefit of an @<agent> instruction in a file, is that you can use any coding agent and any editor / IDE. I am not a fan of 'spicy autocomplete' that just starts generating text while I am trying to do some wishful thinking.
+
+A skill like this isn't that hard to make. One prompt, and some iteration to make it work for me. Full skill is included at the bottom of this post. Read through it, and make your own. Curisous what you'll come up with.
+
+
+Backstory
+===
+I am slowly making WeReview 2.0 production ready. It was mostly done with [Synthetic TDD](/blog/engineering/synthetic-tdd) so far. I was blown away over a year ago when I managed to do a rewrite of 80% of WeReview in 5 days calendar time, during a school holiday. WeReview is an opinionated session review system that helps focused conferences create programs fast with little fuss. This was one of those 'blown away' moments.
+
+I have in places explicitly driven the design, like making flexible forms with the help of an Allium Spec as a separate system. Answering questions about "where are we" and "how did that flow work again?", "what do we still need to do" is sometimes more work than I like. So I have decided to generate documents showing the flow from one screen to the next as a side effect of running integration tests. This was inspired by a Matteo Vaccari's talk on TDD and AI, in which he demonstrated his customer focused tests that are not necessarily end to end, inspired by Ward Cunningham's Fit. That reminded my of Ward Cunningham's Swim system, that he made for the Eclipse Foundation. There is a paper about it that I will include in a follow up post.
+
+My users use the application through screens, I can model the domain as much as I want, but that is what they interact with. I have cheaply made end to end tests, but they are slow and fiddly, and give me a 'moment in time'. I can render videos, but those are also not easy to follow for the key stakeholders. So a document describing steps in the flow, maybe with side steps as in Ward Cunninghams' work felt like a good idea, and reading his paper backwards it can be done in small steps.
+
+Doing that took extending tests to output HTML in the right places. For this Pi + Qwen worked quite well, in the get it Run sense. Get it right, less so. I had some ideas on extracting a DSL, broke them down into tasks. When I do that, I tend to over-engineer. My coding agent less so, but once it worked, I had 400 lines of code for a test that was just spanning three screens. 
+
+
+
+Refactoring by hand and by Agent
+----
+
+This took 1.6 minutes, which is not particularly fast. But I was doing other things. There is refactoring tooling for Elixir, but it is not that easy to setup, I am in the process of doing it. I have paid attention to the extract setup refactoring more closely and will do the next one by hand, probably. I have done some extract functions by hand to keep a feel for Elixir, and also because it sometimes takes less time to just do it than to explain it.
+
+Aside: when the coding agent reports the number of tests
+----
+
+Also note, that as Pi / Qwen reported success, that not all the tests have been run (there are 998 tests in total, this is an umbrella project with `make test` at the root)
+
+> - ✅ All 739 tests pass
+> - ✅ Clean compilation (no warnings)
+> - ✅ Committed as 2e2086d
+
+The rubber duck in the blog post is strong. All the tests are run, but in three rounds, as this is a small mono-repo. I am attempting to keep some things that are not specific for the domain, like flexible forms, separate, without spinning them off in to separate repos. The coding agent picked up on the last run, which has 739 tests without mentioning the other ones. 
+
+I was tempted to blame the agent for not running all tests, but they are part of a post-commit hook, so they get run deterministically, no matter what.
+
+About the skill
+====
+
+It is probably overkill to use `git status --porcelain` a search through all files might work as well, or better. `rg` is not working in my agents' sandbox for some reason, I need to figure this out still. It is also specific to elixir in places. Also not sure if prioritization is necesary. I put it in, because when I see multiple things that need work in a piece of code, I want to annotate before I forget (this is analogous to putting test lists in code, but for refactorings too).
+
+I had expected to get this to work in one prompt, but maybe my perfectionism got the better of me, once again. I thought do do this with sub-agents in one go (looking at the skill) and getting the context picked up besides my one line instruction, was interesting. See the *Context Resolution* section below. 
+
+Note that none of the `@pi` instructions will make it into the commit history, if you work one instruction at a time. Luckily the skill has an example:
+
+```elixir
+# @Pi: move to Swimex.Report
+defp extract_fragment(full_html, selector) do
+```
+
+That already needed  a re-prompt, because I had specified 'pi' in the instruction to create the skill, and used 'Pi' when trying it out. Moving a function to another module is simple, but annoying: 
+
+- Copy function over to new module.
+- Import function in old module
+- Make sure it is referenced correctly by all call sites
+- Delete original function
+
+The At Pi skill in full
+=====
+
+```
+---
+name: at-pi
+description: Finds @pi comments in staged/unstaged changed files, presents them for prioritization, then executes each via a sub-agent (pi -p) with context from relevant imports. Use when you want to batch-execute developer instructions left as @pi annotations across changed files.
+---
+```
+
+# @pi Skill
+
+Scans changed git files for `@pi` annotated instructions, prioritizes them with the user, then executes each sequentially via a sub-agent with contextual file information.
+
+## Step 1: Discover Changed Files
+
+Run:
+```bash
+git status --porcelain | awk 'NR>0 {print $2}'
+```
+
+This returns staged + unstaged + untracked files (one path per line).
+
+Filter to code files you care about: `.ex`, `.exs`, `.heex`, `.js`, `.ts`, `.py`, `.rb`, etc.
+
+## Step 2: Scan for @pi Comments
+
+For each changed file, scan for `@pi` annotations. Two formats are supported:
+
+### Single-line
+```elixir
+# @pi fix the email validation to also reject nil
+def validate_email(email), do: ...
+```
+Instruction = everything after `@pi ` on that same line.
+
+### Multi-line (block comment)
+```elixir
+# @pi
+# Fix the email validation logic here.
+# It should handle: nil, empty string, and invalid format.
+# See WereviewWeb.EmailValidator for reference patterns.
+def validate_email(email), do: ...
+```
+Instruction = everything after `@pi` on the tag line (may be empty), plus all continuation lines that start with `# ` (or `// ` for JS/TS) until a blank line, end of file, or a non-annotation comment line.
+
+Strip the leading `# `, `// `, or `; ` markers and join into one instruction string.
+
+### Parsing approach
+Use `grep -ni '@pi' <file>` to find lines with `@pi` (case-insensitive — catches `@Pi`, `@PI`, `@pi`, etc.), then read surrounding context to capture multi-line blocks.
+
+### Context resolution (important)
+When a `@pi` comment appears immediately **above** a function definition, struct, module, or code block, the instruction likely refers to **that code**. Read that code to identify its name, arity, and purpose. Infer this relationship and carry it into the sub-agent prompt.
+
+For example:
+```elixir
+# @Pi: move to Swimex.Report
+defp extract_fragment(full_html, selector) do
+```
+The intent is: move `extract_fragment/2` into the Swimex.Report module. The sub-agent must understand **what** is being referred to, not just the bare instruction text.
+
+## Step 3: Build Instruction List
+
+For each `@pi` comment found, build a structured entry:
+
+```
+[N] FILE:PATH:LINE  "instruction text"
+```
+
+Where `[N]` is the discovery order index (1-based).
+
+Example output:
+```
+Found 3 @pi annotations in changed files:
+
+[1] wereview/apps/wereview/test/support/swimex_report.ex:82
+    "move the output_dir logic here to use the WEREREVIEW_TEST_REPORT_DIR env var"
+
+[2] wereview/lib/wereview_web/email_validator.ex:15
+    "add regex validation for international domain names"
+
+[3] wereview/apps/wereview_core/lib/wereview/tenants.ex:44
+    "handle the case where tenant slug already exists — return {:error, :duplicate_slug}"
+```
+
+## Step 4: Prioritize with User
+
+For each instruction, **resolve its intent** before presenting:
+
+1. If the `@pi` comment is immediately above a code block (function/struct/module), identify that code and describe what will happen.
+2. Present a clear action statement, not just the raw instruction text.
+
+Example output:
+```
+Found 3 @pi annotations in changed files:
+
+[1] wereview/apps/wereview/test/support/swimex_report.ex:82
+    "move the output_dir logic here to use the WEREREVIEW_TEST_REPORT_DIR env var"
+
+[2] wereview/lib/wereview_web/email_validator.ex:15
+    "add regex validation for international domain names"
+
+[3] wereview/apps/wereview/test/wereview_web/live/session_submit_live_test.exs:7
+    → The function extract_fragment/2 will be moved to Swimex.Report
+    (raw instruction: "todo move to Swimex.Report")
+```
+
+Ask the user to reorder by specifying a sequence. For example:
+
+> Execute in this order: 3, 1, 2 (skip 2)
+
+Or just press Enter to execute in discovery order. The user can skip any by omitting it.
+
+## Step 5: Discover Relevant Context Files
+
+For each instruction you are about to execute:
+
+1. Look at the file containing the `@pi` comment
+2. Extract import/require/use/include statements from that file to find relevant neighbors
+3. For Elixir (`.ex` / `.exs`):
+   - `import X` — module being imported
+   - `require X` — module being required
+   - `use X` — module being used with callbacks
+4. Resolve module names to actual file paths in the project
+5. Read those files so you know what's available
+
+Example for Elixir:
+```elixir
+# From wereview/lib/wereview_web/email_validator.ex
+import WereviewWeb.EmailHelpers    → wereview/lib/wereview_web/email_helpers.ex
+use WereviewCore.Validation         → wereview/apps/wereview_core/lib/validation.ex
+```
+
+## Step 6: Execute via Sub-Agent (Sequential)
+
+For each instruction in the prioritized order:
+
+1. **Build the sub-agent prompt**: Combine the original `@pi` instruction with context about nearby relevant files. Include:
+   - The **resolved intent** (what code/block the annotation refers to, e.g., "move function `extract_fragment/2`")
+   - The raw instruction text
+   - The file path and line number of the annotation
+   - A brief summary of what the relevant imported/required files provide (if you read them)
+   - Any other contextual info you already know about the codebase
+
+2. **Spawn the sub-agent**:
+   ```bash
+   pi -p "<enriched prompt>"
+   ```
+
+3. The sub-agent will modify files in place. You do NOT re-read or re-apply changes yourself — trust the sub-agent to make its changes.
+
+## Step 7: Show Changes and Ask Confirmation
+
+After all instructions are executed:
+
+1. Run `git diff` to show all uncommitted changes
+2. Present the diff summary to the user:
+   ```
+   Changes after @pi execution:
+   
+   modified: wereview/apps/wereview/test/support/swimex_report.ex
+     - removed unused @output_dir (already handled internally)
+     + added email validation logic
+   
+   modified: wereview/lib/wereview_web/email_validator.ex
+     + international domain regex support
+   
+   Commit these changes? (y/n)
+   ```
+
+3. If user says `y`: run `git add -A && git commit -m "Execute @pi annotations"`
+4. If user says `n`: leave changes uncommitted for manual review
+
+## Error Handling
+
+- If a file cannot be read, skip it and note the error
+- If no `@pi` comments are found in changed files, report: "No @pi annotations found in changed files."
+- If `git status` fails (not in a git repo), stop and inform the user
+- If the user cancels mid-execution, show partial results so far and exit

app/priv/blog/engineering/2026/07-18-does-ai-assistance-support-tiny-open-source-projects.md

@@ -0,0 +1,105 @@
+%{
+  title: "Does AI assistance support tiny open source projects?",
+  author: "Willem van den Ende",
+  tags: ~w(pi.dev OpenSource deterministic),
+  description: "I am making small contributions to tiny open source projects I have just started using, where I would let it be before coding agents.",
+  published: true
+}
+---
+
+Many larger open source projects are struggling with floods of AI assisted contributions. The FT has a great piece about this by Sam Learner  [Who cleans up after the vibe coding party?](https://www.ft.com/content/cec8df9e-b43b-4cd1-8feb-c07e804e8d33). But miniscule open source projects may fare better. I am now contributing to tiny open source projects while just trying them out.
+
+In the before times, I would often move on or maybe ask a question when I had trouble installing a tool I was trying out. Say it had security issues, or something didn’t work quite right on first try. I might fix it locally and have a play. But by the time I had finished doing the work, I would have no more energy to be social and make pull requests.
+
+Especially if I need to fix more than one thing, and the author might not want to accept both. I am very much a trunk based development person, so I prefer to commit a stream of commits to main. But working asynchronously with people I don’t know, more communication is required to make my changes make sense to the other party.
+
+Example - DeepClause today
+----
+
+I am playing with [the DeepClause command line interface](https://github.com/deepclause/deepclause-sdk) , and had to run `npm audit fix` after installing. After fixing that, building it failed. So I opened [Pi](/blog/engineering/tag/pi.dev) and fixed it. 10 minutes work, two candidate Pull Requests (PR). One `main` branch with two commits.
+
+As mentioned above, it is not something I do often. When working in client projects, the teams I work in can usually choose to stay out of the PR review circus and either just push to main, or pay lip service to the PR process.
+
+Making two pull requests in one go
+---
+
+So how do I make two pull requests out of it? I ask [my assistant](/blog/engineering/tag/Pi.dev), learning something in the process: 
+
+> Now I have two commits. what if I wanted to make a Pull Request on github for each commit separately?
+
+It then explained how to find the changed commits (this I knew, but saved me typing), and made the branches. If you look at the last `$`, cutting two branches is a one liner for [the LLM](/blog/engineering/tag/pi.dev)
+
+```
+    1. Find your base commit (the one before both new commits):
+
+    $ cd /Users/willem/dev/spikes/llm/deepclause-sdk && git log --oneline -5
+    
+    a305d5b fix: add missing FS type declaration for Emscripten filesystem interface
+    8edcaad fix esbuild and other vulnerabilities
+    8aa9234 v0.86
+    3f51edf v0.85
+    ecd708c v0.83
+    
+    Took 0.0s
+    
+    
+    Thinking...
+    
+    You have two commits on main:
+    
+      a305d5b fix: add missing FS type declaration
+      8edcaad fix esbuild and other vulnerabilities
+      8aa9234 v0.86  ← base
+    
+    To make separate PRs, create a branch from main before each commit, push to GitHub, and open PRs targeting main.
+    
+    
+    $ cd /Users/willem/dev/spikes/llm/deepclause-sdk && git branch pr/vulnerability-fix 8edcaad && git branch pr/fs-type-fix a305d5b
+```
+
+It then provided instructions, conveniently not knowing that I can not push to ’origin’ but have to fork it on github first. But that is ok.
+
+> 
+> 
+> Here are the steps:
+> 
+> 1.  Push the branches to GitHub
+> 
+> \`\`\`bash
+>   git push origin pr/vulnerability-fix
+>   git push origin pr/fs-type-fix
+> \`\`\`
+> 
+> 1.  Open the PRs in your browser
+> 
+> \`\`\`bash
+> 
+> gh pr create –base main –head pr/vulnerability-fix –title “fix: esbuild and other vulnerabilities” –body “Updates esbuild and other dependencies to fix vulnerabilities.”
+> 
+>   gh pr create –base main –head pr/fs-type-fix –title "fix: add missing FS type declaration for Emscripten filesystem interface" –body "Defines FS type alias with methods used by swipl-wasm. Fixes TS2304: Cannot find name
+> 'FS'."
+> \`\`\`
+> 
+> If you don’t have the gh CLI installed, open these URLs in your browser instead:
+> 
+> -   PR 1: <https://github.com/deepclause/deepclause-sdk/compare/main...pr/vulnerability-fix>
+> -   PR 2: <https://github.com/deepclause/deepclause-sdk/compare/main...pr/fs-type-fix>
+
+Now I can get my agent to solve the actual problem I had after just ~npm install~ing it.
+
+Not making the same mistake twice
+----
+
+It did take me two projects to know to ask the question. I had a similar thing with [pi-browser](https://github.com/larsderidder/pi-browser), where the dependencies were out of date, and the extension was showing as `src` on loading, which confused me no end - I thought the extension had not loaded. 
+
+So I pushed the dependencies update, waiting for it to be accepted, which happened within a day or so, and then forgot to push the next commit. So this time I paused, asked my agent and pushed to Pull Requests. Although it is mighty tempting to &rsquo;just prompt my own fork&rsquo; into existing, the &rsquo;just&rsquo; is doing a lot of heavy lifting there. And from the looks of it, a lot of thought and tinkering has gone into this project over the last year. 
+
+So while I do enjoy prompting, I value collaboration more.
+
+Do you contribute more now?
+
+
+Further reading
+---
+
+I wrote about extracting knowledge and tools from repeating patterns in [Stochastig to Deterministic](https://www.qwan.eu/2025/12/11/stochastic-to-deterministic.html). I find DeepClause interesting, because it uses Symbolic AI  (Prolog) to extract e.g. agentic loops into deterministic code. So instead of having an LLM control repetition, we can have code do the looping, e.g. over a number of tasks. Prolog supports _backtracking_, trying a number of times and falling back out of the box, and [DeepClause](https://github.com/deepclause/deepclause-sdk) uses that to reset the context for the LLM and try again.

app/priv/blog/engineering/2026/07-27-swim-the-test.md

@@ -0,0 +1,116 @@
+%{
+  title: "Swim the Test",
+  author: "Willem van den Ende",
+  tags: ~w(ATDD ComprehensionMaxxing CollaborationMaxxing),
+  description: "Every application has some kind of workflow. Understanding larger workflows, making them cohesive and understandable to users and developers is non-trivial. I re-discovered Ward Cunningham's Swim the Test approach, this is the Further Reading section of future posts.",
+  published: true
+}
+---
+
+TLDR;
+----
+Every application has some kind of workflow. Understanding larger workflows, making them cohesive and understandable to users and developers is non-trivial. I re-discovered Ward Cunningham's Swim the Test approach, this is the Further Reading section of future posts.
+
+[Jon Uddell's 2008 post about Ward Cunninghams' implementation of Brian Marick's 'Visible Workings'] https://blog.jonudell.net/2008/03/04/ward-cunninghams-visible-workings/ is a succinct introduction . connecting the Visible Workings pattern to the implementation made for a workflow system on behalf of the Eclipse Foundation. 
+
+[The "Swim" System for User-Oriented Presentation for Test-Case results](https://wiki.eclipse.org/images/2/20/Swim_System_PNSQC_2007_Paper.pdf). Plain spoken Paper by Ward Cunningham, Bjorn Freeman-Benson and Karl Matthias.
+
+> Perhaps the highest compliment we received was when one of our customers (SC) said that she
+> easily understood how everything worked because it "uses her words" in the interface panels and
+> documentation.
+
+Why this post?
+====
+
+Refactoring integration tests towards *Swim the Test* turns out to be easier than to write about it. And was not as hard as I thought - it can be done in baby steps. I keep both losing the literature references, and at the same time finding more or them. So getting them out of the way should help me post a 'how' post more easily.
+
+Swim the test
+====
+
+> Finally you can *swim the test*. Here the steps and results are laid out in a
+> table. Time advances as you move down the rows, and there’s a column for every
+actor in the workflow.
+
+!["Change personal address" Sequence diagram. 'Start' at the left, 'big2' and 'emo' column. big2 did some actions, and this results in 'User address changed'. Followed by some 'variations' (the swim paper in the linked post explains this). The 'emo' column has one 'emo address changed' box. Screenshot by Jon Udell](https://i0.wp.com/jonudell.net/img/visibleworking3.png?w=656)
+Screenshot by Jon Udell.
+[Jon Uddell's post]( https://blog.jonudell.net/2008/03/04/ward-cunninghams-visible-workings/) is a succinct introduction . connecting the Visible Workings pattern to the implementation made for a workflow system on behalf of the Eclipse Foundation. 
+
+
+The "Swim" paper
+====
+
+I learnt about the Swim system when Ward Cunningham ran a session about it at the first Agile Open Northwest (2006 or 2007 I think - this is a blog post, I may do the research later or it doesn't ship..)
+
+[The "Swim" System for User-Oriented Presentation for Test-Case results](https://wiki.eclipse.org/images/2/20/Swim_System_PNSQC_2007_Paper.pdf) by Ward Cunningham
+Bjorn Freeman-Benson and Karl Matthias
+
+I only found this paper existed now that I went looking for it. It also explained (when you read it back to front) on how to get started. The workflow with swimlanes looks very sophisticated. It mentiones `run.php` further down, which is 'just' one flow with some screenshots. 
+
+The reason I was attracted to domain modelling (long before Eric Evans' 2003 DDD book) was this:
+
+> Perhaps the highest compliment we received was when one of our customers (SC) said that she
+> easily understood how everything worked because it "uses her words" in the interface panels and
+> documentation.
+
+Simplicity is achieved when there is nothing left to take away. Compare this to DDD's "Ubiquitous Language". The scare quotes are intentional. As a non-native speaker I had to look up Ubiquitous. Compare this with the paragraph above. I appreciate many of the user-focused things that come out of the DDD community, like Event Storming, but ask yourself, if a patterns introduce barriers to outsiders, or if it removes them (and when introducing barriers, is the trade-off worth it?).
+
+>At the same time,
+> our abstractions are detailed enough to be believed because we are running the real code in our
+> simulations instead of bubbles and arrows diagrams. We respect the user's expertise without
+> dumbing down our system or forcing them to use our terminology.
+
+
+A large application is built in many small steps
+=====
+
+This looks like a lot of work, and I haven't integrated this in an application. Yet. Reworking existing integration tests to output dialogs as HTML for each step was not _that_ much work, and the rewards are instantaneous: multi-step workflows now become glanceable. And as they get longer, I can make small improvements to improve glanceability. 
+
+I am trying to draw in the users as well, let's see how this goes.
+
+Further, further, Reading
+====
+
+This is meta - a Further Reading section in a further reading post ;-).
+
+A harness for behaviour
+----
+
+I was reminded of the swim system by this talk of Matteo Vaccari on youtube which focuses on tests that are understandable by the stakeholders.
+[A Harness for Behaviour: Ensuring Ai-generated Code Does What We Want - TDD in the Age of AI ](https://www.youtube.com/watch?v=3tdmoj35HG0)
+ He referenced Fit and focuses on writing tests that work as a communication medium between users, stakeholders and developers. He uses an external DSL in YAML. I am not against YAML, but someoone's remark last year that all new programming languages appear to be YAML gives me pause, whenever I see it. The main thing is when it works it works. Context is key. (not further reading: I ended up with an internal DSL and screenshots in small steps as a medium - the users don't need to be able to write tests, yet, communication about what we are building and how it works is key. In small steps - I don't believe good UX comes from large batches). [LinkedIn post on Matteo's account](https://www.linkedin.com/posts/matteovaccari_the-video-of-my-presentation-at-platmosphere-share-7478330775579586560-vSoX) in case you want to comment.
+
+Matteo blogged about this earlier:
+[Acceptance tests for AI Assisted development](https://matteo.vaccari.name/posts/acceptance-tests-for-ai-assisted-development/) on "grey box testing". Refers to [Approved Fixtures Pattern](https://lexler.github.io/augmented-coding-patterns/patterns/approved-scenarios/) and is also worth reading on its' own.
+
+Visible Workings
+---
+
+[Visible Workings]( https://web.archive.org/web/20110202132102/http://visibleworkings.com) on archive.org, as the original site is no longer active. I like the notion of "Tinkerable Software".
+
+>Explanatory software goes hand in hand with tinkerable software because the dedicated amateur will need explanations to do the tinkering well. 
+
+
+"View Source"
+----
+
+A comment in one of Jon Udell's posts about 'View Source' reminded me of the work of [Sue Smith](https://www.sue.codes/)  My timebox is up, she has a great blog in which is she writes about building tools in an IDE to make software development accessible to newcomers. I remember her writing about how to replicate the 'view source' experience of early web 2.0, where you could find out how a web front-end worked by 'just' viewing the source.
+
+[What comes after view source?](https://www.sue.codes/blog/afterviewsource/)
+
+[Being intentional about friction](https://www.sue.codes/blog/whatfriction/) is more tangential, and inspiring. Some comment about the link to the tests in an application on one of Jon Udell's 'swim' posts may be related. That link to the tests inside an application dialog may be seen as friction, but also, as Sue puts it:
+
+> Removing friction does not necessarily empower people
+
+and
+
+>  Being able to choose which details are worth paying attention to is the trick.
+
+Happy reading and watching
+====
+
+Thank you for making it to the end. I hope this inspires you to do more reading, watching, and more importantly, building.
+
+As [Steve Freeman put it just now](https://mastodonapp.uk/@sf105/116991301858959311):
+
+> ward and Bjorn’s “swimlanes” work for the Eclipse foundation was an inspiration. It’s a crime against software that it was left derelict.
+

app/priv/blog/engineering/2026/07-28-learning-to-swim-test.md

@@ -0,0 +1,149 @@
+%{
+  title: "Learning to Swim test",
+  author: "Willem van den Ende",
+  tags: ~w(ATDD ComprehensionMaxxing CollaborationMaxxing SyntheticTDD Refactoring),
+  description: "The faster you can build, the more pressing communication with others and understanding together becomes. You can build software to promote understanding and collaboration, but where do you start? I found a foothold in the 'swim tests' paper and existing integration tests.",
+  published: false
+}
+---
+
+I often find it easier to do and build stuff than to write about it. Getting over the 'further reading' section in [swim the test](https://willemvandenende.com/blog/engineering/swim-the-test) appears to have freed me up to write more.
+
+I wrote with the LinkedIn comment announcing that post:
+
+> The faster you can build, the more pressing communication with others and understanding together becomes. 
+
+A view of a foothold
+====
+
+Reading the "Swim System" paper, it is clear that you can build software to promote understanding and collaboration, but where do you start? I found a foothold in the existing integration tests, and a discussion on page 14 and 15 of the [Swim Systems paper](https://wiki.eclipse.org/images/2/20/Swim_System_PNSQC_2007_Paper.pdf).
+
+![Screenshots. A dialog with test annotations on the left, a sequence diagram with test results on the right](/images/blog/2026/swim-asterisk-dialog.png)
+
+The left part of the screenshot, a dialog with some steps, was something I could build. There is a description of how they abstracted the report creation so one source produces multiple targets, e.g. the dialog on the left and the swimlane view on the right. That is also something that can be factored out later, starting with a point solution.
+
+I eventually read the whole paper front to back after skimming it and pondering it over. I also remember what Ward Cunningham mentioned when he presented this work: that tools like Fit(Nesse) and this are contextual, and these are something to be made in context, not off-the-shelf tools. So I read this paper, contrasted it with Matteo Vaccari's work, and my own experience in stakeholder and user-focused tests, and what we needed for the application I am working on.
+
+What do we want?
+====
+
+From the swim systems paper
+---
+
+I liked: 
+
+- application dialogs as a way to explain the system
+- backlinks to the tests from the dialogs in the actual application
+- display of errors inline
+- The swimlanes, and the way events are used
+- Standard flows and variations on them, implemented and inspectable simply
+
+I think the paper predates the Event Sourcing hype, seeing the past-tense framed things in the swimlanes 
+
+What I missed from the paper, and can now see after starting to build:
+
+- Failing tests also displayed in the report (see the red "Trouble can't find <x>" sections on the right)
+
+![Screenshots. Passed example on the left - title is a green bar. Failed example on the right, red heading and two 'trouble' bars. A clock and timestamp indicate when the tests were run.](/images/blog/2026/swim-asterisk-example.png)
+
+What I wanted to do differently:
+
+Some actions are abstract enough, eg. _login 'developer1'_ others are too UI focused for what I need. The order in which fields are filled in is often not important. Or so I thought, when writing this I have written some tests where one action makes another one (im)possible. So most of the time a whole dialog can be worked through by data, using the Test Data Builder pattern to allow for differences. 
+
+I have a test setup out of the box (Phoenix Liveview Test) that works well enough, and I guessed (correctly) that it would have primitives to export HTML for the reports as well.
+
+So to start with, I decided to produce reports, and leave reporting on unmet expectations to regular assertions in the existing test framework. 
+
+From Matteo Vaccari's ATDD and AI talk
+----
+
+Matteo presented an external DSL. I liked the idea of a DSL, and decided to start with an internal DSL first. Elixir has good support for this, and I could drive this by extracting helpers from existing tests and making the scenarios longer so there  are more steps in the workflow.
+
+Some of the lines in Matteo's DSL I found a bit HTTP specific on seeing it, but then found that my tests made by [Synthetic TDD](/blog/engineering/synthetic-tdd) also suffered from this. At one point a response is parsed for an identifier that is used in subsequent tests. 
+
+See below in working in small steps on how I am dealing with that.
+
+From my own failures
+----
+
+- being able to see the whole and have confidence it fits together coherently
+- testing as a feedback mechanism was secondary, strangely enough
+
+Having the screens, step by step, gave me confidence where I was, and made it easy to identify the next step. It did turn out to have value as a technical feedback mechanism earlier than expected. I had worked bottom up for part of a feature, and added the next step in a flow once the parts were done. Some bits to integrate them were missing, as evidenced by the new step. Good encourgement to work acceptance test driven the next time.
+
+
+On being able to have confidence in coherence
+---
+
+The swim systems paper appealed to me, because I have trouble keeping an overview of workflows with multiple steps. This was always a challenge working in the XP way, as we very quickly can create a well-tested app with complicated flows. Keeping the whole coherent and "ready to mind" is hard. "Ready to hand" with good unit tests became very cheap, but seeing the forest and the trees was sometimes difficult.
+
+This became worse with LLM generated systems. When I can create a prototype out of thin air in a couple of hours, with hundreds of tests, and several screens and can let a coding agent produce the demos (see previous posts) it feels great. But when someone else is interested and asks me how it fits together, that becomes a lot harder. 
+
+I was hesitant to take some of my visual collaboration tools to market, and I did not understand why. After building the first steps of workflow tests I do understand. It may look like a collaboration tool is about the sticky notes, but the magic is in the collaboration rules that are encoded in things like how groups are structured, how invitations work, what the unit of a 'tenant' is in a SaaS applications, who gets to (dis)invite who, how, when? Or in moderation: who invited this _Person_ and why?
+
+It is great brainstorm-building a mobile first product outcomes focused board, but then adding teams and seeing bits of flow missing is annoying. These flows are necessary for any collaborative application, visual or not, and they are different, because the combination of peoples' roles and assumptions are unique for each application.
+
+So I wanted, just for myself, to see as much of the flow as possible. End-to-End tests through browsers are now very cheap to make (I can make dozens in a day), but maintaining and running them is not. Especially when I am working on my laptop with a coding agent. Having sandboxed the agent, accessing a browser is not trivial.
+
+The unit and integration tests I have so far do give me confidence that most things work, but not that the whole application flows hang together as I want. This was triggered by a stakeholder asking: "Where are we with <tool> 2.0?" . (more about <tool> later. previous blog posts drafts failed on digressions). 
+
+Every application has workflows. They may not appear to be core, but they shape collaboration, so they are.
+
+
+Working in small steps, AI augmented where useful
+=====
+
+I had an integration test that could serve as a starting point. But the workflow only had two steps. Several things are taken care of beforehand, analogous to the `login(''developer1')` in the Swim Systems paper. At least it was a good place to start, so the process was roughly:
+
+1. Find out how to write pages and dialogs (a part of the page) as html
+2. Decide how to collect these as the test progresses
+3. Turn the collected parts into a report
+4. Refactor the existing test towards a DSL
+5. Add more steps
+6. Go to 4.
+
+For 1. I found a forum post, and I already had some [Synthetic](/blog/engineering/2026/07-13-synthetic-tdd.md) tests. This was also a good opportunity to re-read [the documentation](https://phoenix-live-view.hexdocs.pm/Phoenix.LiveViewTest.html). Rendering pages, components, selecting elements and getting the text back is all built in, so all we  need to do is wrap it in a page and save the parts. I did consider writing the reports out as markdown, with html snippets at some point. When rendering html to a pdf, the page breaks happen in the middle of screenshots sometimes. But the PDF already lacks the styling.
+
+I initially iterated with [Pi](/blog/engineering/tag/pi.dev) on how to collect tests. I had a fancy idea of collecting the various dialogs in a process (well supported e.g. by Elixir GenServers), then thought of doing it the unix way (write out dialogs, than `cat` them all together), and ended up collecting step outputs in a list, and rendering the list at the end. This did require re-ordering the test a bit: the `assert` has to come at the end, after creating the report.
+
+My assumption was that a model could generate more steps, after refactoring towards a simple flow of steps. The generated tests had some noise in parsing outputs to determine inputs for the next steps. Finding the right extractions was a bit of work, and at the same time gave me a better understanding of what I wanted.
+
+Away from the desk, away from the screen?
+----
+
+I was mostly away from my desk last week. After getting three steps working, in small steps, refactoring by hand (my local model had some trouble moving things around in to files, and I needed to learn more about how to organise tests and support code in a Phoenix Liveview project ), the basic flow is now at five steps. Pi with Deepseek v4 flash did most of that, with me doing 'yes' prompts from my phone. 
+
+![Screenshot of Pi session - featuring 'insufficient credits'](/static/images/blog/2026/pidev-step5-generated.png)
+
+This insufficient credits message hasn't happened to me in a while. I deposited 25 USD in may last year on OpenRouter. Since then I mostly used Claude Code or local models. Being away from my desk means running Pi on a server, with deepseek. I spent about 10$ in the last month, preparing a keynote and TDD with AI workshops for Philips (hit me up if you are interested too, at QWAN we are responsibly extending our offerings, now that we have a better understanding of how to augment teams, and improve the outcomes and quality using coding agents). So probably about 1 or 2 $ on workshop preparation and 8 for the testing support and bringing a vibe TDD'ed app to production.
+
+It is nice to be able to make progress while having friends over. I have learned to not multi-task too much, and when a question is too big to answer on my phone, I will just percolate on it. Good designs come from working on that - you have to be seen working for creativity to happen, and from stepping away from the screen and coming back with a fresh perspective.
+
+
+Show me the reports
+====
+
+TODO add validation failure report, and full flow so far.
+
+Reworking is easier than writing
+====
+
+Reworking and refactoring existing user-focusing integration tests towards this turns out to be easier than writing about it. A number of ideas collide, and I had trouble keeping track of the references. So the first blogpost about this was the "further reading" section.
+
+And here as well, Programming as theory building works. I built towards the principles above, learnt a few things, got some value out early, and now have an idea of the next steps. 
+
+
+
+Further Reading
+----
+[Swim the test](https://willemvandenende.com/blog/engineering/swim-the-test) has more of the literature background, including the Sim Systems paper and what I mentioned about Matteo Vaccari.
+
+The Swim Systems paper is well worth reading, it is as good as any of my favourite software engineering papers from the 1970s (but 30 years more recent).
+
+Felienne on Programming as Theory Building
+
+Refactoring to Patterns
+
+John Nolan on explaining what happened after the fact
+
+Machiel Groeneveld on wanting the reasoning

app/priv/blog/engineering/2026/07-30-retort.md

@@ -0,0 +1,25 @@
+%{
+  title: "Retort",
+  author: "Willem van den Ende",
+  tags: ~w(Synthetic TDD pi.dev coding-agents evals ),
+  description: "At first I was bemused by Retort, Adrian Cockroft's whole stack coding agent evaluation tool. It is growing on me, and might be useful as a starting point for custom evals.",
+  published: true
+}
+---
+
+I was bemused by Adrian Cockrofts' [Retort](https://github.com/adrianco/retort) - it looks like Claude Code mostly independently running evals on coding agent x model x target language combinations. The most recent report however, matches my anecdata. I have started on something like Retort earlier this year, but much smaller - custom tiny agent, a couple of small language models and about 10 programming languages with a number of small tasks (extract method, find code smells in a file etc). I parked it, because it looked like that would be significant work to turn into something explainable to more people. So it is great to see Retort blossoming.
+
+The main takeaway for me from the latest one is that the number of turns taken by the agent seems to be a good predictor for speed of task completion, and Qwen 35B, that I use a lot, does as well as the better frontier models on this task (and better than some of the worse frontier models). My hypothesis (hope?) that a decent harness with a smaller model would perform well on incremental tasks seems to pan out.
+
+Reading the readme of retort, the factors are free to label and create. It produces a number of synthetic 'blogs'. The [optimal blog](https://github.com/adrianco/retort/blob/main/optimal-blog.md) I find interesting, bedcause it compares anthropic frontier models with one model I use regularly (Qwen3.6-35B-A3B) and one that I have used successfully for legacy code analysis (Qwen3-Coder-Next 80B ). 
+
+Not all outcomes match my experience, Qwen3.6-35B-A3B does well enough with Elixir production code, although it struggles with macros and moving functions across modules. That, admittedly, is something more LLMs struggle with. Explaining that often takes more time than doing it by hand. 
+
+It would be interesting to see the same benchmarks with Deepseek V4 Flash, widely used on somewhat larger machines (128GB VRAM, or less VRAM + more RAM combinations) and cheap on Openrouter (I haven't gone over a dollar yet for a day of intensive use), and Qwen 3.6 27B (much slower in tokens per second on my Macbook pro M3 Max, but seems to get more complex tasks done than 35B. I tried it yesterday on a Docker deploy that 35B struggled with, and it fixed the two issues I had independently. Feedback loops do work, as long as the model is up to the task ).
+
+Reading through the _optimal_ blog I found the source of my bemusement. Retort also does some BDD / TDD / ATDD and 'neutral' (no tests?) comparisons. I believe these are all [Synthetic TDD](https://willemvandenende.com/blog/engineering/synthetic-tdd). I have used coding agents (mainly Claude Code up to april) extensively to generate tests, recently with the help of Allium. Without tests coding agents go off the rails quickly. And I am lazy, as a good programmer should be, so I like having tests generated and providing feedback loops. But synthetic tests do have limitations. They carry an LLMs interpretation of your intent, and may not drive the design.
+
+It may be that design doesn't matter everywhere equally. I am now working on some code where it does, and explaining myself in code (with some assistance) is faster and more precise than talking to an LLM.
+
+I am not sure how that kind of intent could fit in a benchmark like Retort.  What do you believe? Does intent and design in tests matter? If so, where and when? 
+

app/priv/blog/engineering/2026/08-12-developing-with-open-weights-models-only-three-months-in.md

@@ -0,0 +1,38 @@
+%{
+  title: "Developing with open weights models only, three months in",
+  author: "Willem van den Ende",
+  tags: ~w(pi.dev open-weights ),
+  description: "It is a bit over three months ago that my linkedin post about cancelling my Claude Max subscription went viral. Time for an update. The first six weeks were uneventful, then I started missing some things from before, and yesterday I closed the loop.",
+  published: true
+}
+---
+
+I blogged about [My local agentic development setup](/blog/engineering/my-local-agentic-dev-setup-today) the day after my post about cancelling my Claude Max subscription and going all in on local models went viral.
+
+I am still using the same flexible harness - [Pi.dev](/blog/engineering/tag/pi.dev), with surprisingly few extensions (apart from yesterday, see below for prime-agent). I had expected to add web-search, but even my local models have a lot of knowledge, know how to use tools and look up urls from documentation. Enough to start building [Swim the test](/blog/engineering/swim-the-test), which is quite niche, into an existing system. I occasionally paste a hand-searched link into the prompt and that is enough.
+
+The first six weeks were uneventful. I didn't need to create large prototypes in a day like before, that helped. I was busy preparing larger sessions (a coding dojo with 70 participants and 10 facilitators for a UK client, and a keynote about AI and TDD and a workshops on AI with TDD for Philips Image Guided Therapy).  So mostly smaller things, and sometimes making small in-the-loop changes to existing code.
+
+Then in a conversation with Chris Matts he mentioned he sketches UI on a piece of paper and then lets one of the hosted solutions (Figma or ChatGPT) create a screen out of it. I wasn't set up to do that. After that I have set up [image recognition in Pi.dev](/blog/engineering/enabling-a-local-model-to-explain-images-in-pidev). Surprisingly good. I haven't used it to generate screens, but could make that with some extensions.
+
+In July I went back to working on a larger piece of software, and improvements to local inference engines were coming in thick and fast. I can now run Qwen3.6 27B, their dense model, at conversational speed, and my previous go to, their 35B mixture of experts model, runs a lot faster as well. For smaller, me-in-the-loop changes with tests, the 35B model works quite well. For trickier things, or larger independent runs, where the coding agent runs through a list of tasks and executes them in sub-agents one by one, the 27B model performs better. Slower per token, faster to outcome.
+
+With [mtplx](https://github.com/youssofal/mtplx) instead of LLamaCPP I can now run the dense Qwen3.6 27B at conversational speed (was below 20 tokens per second, now often 30 at the start of a conversation). This means I can run more complex development tasks locally. If it slows down later, I'll go do something else, as long as it can finish the job independently. 
+
+As an example, it managed to find something properly obscure that Deepseek v4 flash also could find, but the 35B model could not. I am keeping that private as a benchmark. Before this, none of the MLX (mac accellerated) inference engines could handle long context (for me). Mtplx does that - speed does not matter if you can't get a good outcome.
+
+MTPLX is also a proper consumer solution. It comes with a GUI to select models and see how it is running. It will figure out the best parameters to run a model with by running a benchmark on your machine after downloading a model, and comes with pre-selected models and quantizations. The screenshot below was after installing a smaller variation of the qwen27B model. Before this I had never seen any of them do more than 20 tokens per second. Around 30 is good enough for a conversation for me.
+
+The screenshot below was taken when I installed a smaller version of the Qwen 27B model. It shows a few sessions tested on my laptop, and which one was found to be fastest, for me. 
+
+![Mtplx installation screenshot](/images/blog/2026/mtplx-install.png)
+
+I still have LLamaCPP, but mtplx does well enough at the moment. I would us LLamaCPP when I want to run multiple smaller models on my mac simultaneously - mtplx so far only runs one model at a time. No problem for 35B and 27B as more than one does not really fit in 64GB (V)RaM.
+
+Since the school holidays were starting and I am away from my desk more often, I revived my [remote environment in a virtual machine](/blog/engineering/how-to-get-started-with-the-pi-coding-agent-on-a-vps), so  I could develop on my phone. I had used DeepSeek V4 Flash in part when preparing exercises. This model can be locally on slightly more VRAM than I have.I use openrouter for it. This has worked very well for adding features to existing code, doing longer running implementation sessions etc. It is cheaper to host than Qwen 3.6 27B apparently.
+
+On Friday I spent a day with prime-agent. This is a ready-to-use Recursive Language Model adaptation of Pi. This runs instances of Pi on subtasks, and creates memories of things that could have been done better. It appears to do long running tasks without a ticket system like yaks, beads or a markdown file well enough. It is an example of not attaching new ways of working to old flows (ticket systems, version control). There may be better ways to discover. RLM appears to be one of them. I am doing `new session` less often, longer contexts seem to work well enough (although slower). As the memory built up, starting 'fresh' also is fast enough also is fast enough
+
+[Prime-agent](https://github.com/PrimeIntellect-ai/prime-agent) means I can do what I did with claude code before, developing larger prototypes with tests in a conversation. But now with smaller open weights models. The 0731 release of deepseek-v4-flash appears to be strong. Prime-agent with feels more coherent than claude code in april. After three months of not doing larger prototypes, and developing all the things I had thought of before, I now have some new ideas. The harness is at least important as the model, and experiments in harness development are ongoing by many people.
+
+

app/priv/blog/release-notes/2026/07-08-v0-2-0.md

@@ -0,0 +1,16 @@
+%{
+  title: "v0.2.0 — RSS Subscribe Links",
+  author: "Willem van den Ende",
+  tags: ~w(release),
+  description: "RSS feed subscribe links with classic waveguide icons across blog pages, post pages, and site footer."
+}
+---
+
+RSS feeds have always been available at `/api/blog/engineering/feed.xml` and `/api/blog/releases/feed.xml`, but they were never advertised. This release adds subscribe links throughout the site.
+
+## What's new
+
+- RSS `<link>` tags in `<head>` on all blog pages for browser/feed reader auto-discovery
+- Orange RSS icon next to blog title on index pages
+- RSS icon on each post page
+- Subscribe section in the footer with links to both feeds

app/priv/repo/seeds.exs

@@ -11,11 +11,29 @@
 # and so on) as they will fail if something goes wrong.
 
 if Mix.env() == :dev do
+  import Ecto.Query
   alias Firehose.Accounts
 
-  # Create demo user if not already present
-  unless Accounts.get_user_by_email("demo@example.com") do
+  # Get or create demo user
+  user = Accounts.get_user_by_email("demo@example.com")
+
+  unless user do
     {:ok, user} = Accounts.register_user(%{email: "demo@example.com"})
+  end
+
+  # Ensure user is confirmed to allow password login and avoid magic link conflicts
+  if is_nil(user.confirmed_at) do
+    Firehose.Repo.update_all(
+      from(u in Accounts.User, where: u.email == ^"demo@example.com"),
+      set: [confirmed_at: DateTime.utc_now()]
+    )
+
+    # Reload user after confirmation
+    user = Accounts.get_user_by_email("demo@example.com")
+  end
+
+  # Set password if not already set
+  unless user.hashed_password do
     {:ok, {_user, _tokens}} = Accounts.update_user_password(user, %{password: "password123!"})
   end
 end

app/test/firehose_web/controllers/page_controller_test.exs

@@ -1,9 +1,32 @@
 defmodule FirehoseWeb.PageControllerTest do
   use FirehoseWeb.ConnCase
 
-  test "GET /", %{conn: conn} do
+  describe "GET /" do
+    test "renders the homepage", %{conn: conn} do
       body = conn |> get(~p"/") |> html_response(200)
       assert body =~ "Drinking from the firehose"
       assert body =~ "Willem van den Ende"
     end
+
+    test "shows navigation links", %{conn: conn} do
+      body = conn |> get(~p"/") |> html_response(200)
+      assert body =~ ~s|/blog/engineering|
+      assert body =~ ~s|/blog/releases|
+      assert body =~ ~s|/contact|
+    end
+
+    test "does not show dashboard link when unauthenticated", %{conn: conn} do
+      body = conn |> get(~p"/") |> html_response(200)
+      refute body =~ ~s|/editor/dashboard|
+    end
+  end
+
+  describe "GET / when authenticated" do
+    setup :register_and_log_in_user
+
+    test "shows dashboard link in navigation", %{conn: conn} do
+      body = conn |> get(~p"/") |> html_response(200)
+      assert body =~ ~s|/editor/dashboard|
+    end
+  end
 end

app/test/firehose_web/live/editor_dashboard_live_test.exs

@@ -86,5 +86,15 @@ defmodule FirehoseWeb.EditorDashboardLiveTest do
       {:ok, _view, html} = live(conn, ~p"/editor/dashboard")
       refute html =~ "Live Post"
     end
+
+    test "renders with app layout including menu", %{conn: conn} do
+      {:ok, _view, html} = live(conn, ~p"/editor/dashboard")
+      # Verify the app layout is applied by checking for menu elements
+      assert html =~ "Willem's firehose"
+      assert html =~ "Blog"
+      assert html =~ "Releases"
+      assert html =~ "Contact"
+      assert html =~ "Dashboard" # This should be in the menu
+    end
   end
 end

app/test/firehose_web/live/microprints_live_test.exs

@@ -1,5 +1,9 @@
+alias FirehoseWeb.MicroprintsLive
+
 defmodule FirehoseWeb.MicroprintsLiveTest do
-  use ExUnit.Case, async: true
+  use FirehoseWeb.ConnCase, async: true
+
+  import Phoenix.LiveViewTest
 
   describe "scan_source_files/0" do
     test "returns exactly 2 files" do
@@ -64,4 +68,137 @@ defmodule FirehoseWeb.MicroprintsLiveTest do
       assert is_list(blogex_files)
     end
   end
+
+  describe "expanded_path and highlighted_path coupling" do
+    test "expanding file A and highlighting a line in file B should collapse file A", %{
+      conn: conn
+    } do
+      files = MicroprintsLive.scan_source_files()
+      assert length(files) >= 2, "Need at least 2 files to test coupling"
+
+      [file_a, file_b | _] = files
+
+      {:ok, view, _html} = live(conn, ~p"/microprints")
+
+      # Expand file A
+      view
+      |> element("button[phx-value-path=\"#{file_a}\"]", "Expand")
+      |> render_click()
+
+      # Verify file A shows "Collapse" button (it's expanded)
+      html = render(view)
+      assert html =~ ~s(phx-value-path="#{file_a}")
+      assert html =~ "Collapse"
+
+      # Highlight a line in file B by dispatching the highlight_line event
+      # (microprint renders multiple rect segments per line, element() can't pick one)
+      render_click(view, "highlight_line", %{"line" => "1", "path" => file_b})
+
+      # file A should be collapsed when highlighting a different file
+      html = render(view)
+
+      refute html =~ "Collapse",
+             "file A should be collapsed after highlighting a different file, but the Collapse button is still visible (expanded_path is uncoupled from highlighted_path)"
+    end
+
+    test "switching expand from file A to file B shows each file's own source content", %{
+      conn: conn
+    } do
+      files = MicroprintsLive.scan_source_files()
+      assert length(files) >= 2, "Need at least 2 files to test source switching"
+
+      [file_a, file_b | _] = files
+
+      {:ok, view, _html} = live(conn, ~p"/microprints")
+
+      # Expand file A
+      view
+      |> element("button[phx-value-path=\"#{file_a}\"]", "Expand")
+      |> render_click()
+
+      # Capture file A's source content from the rendered HTML
+      html_a = render(view)
+      # Each .ex file starts with "defmodule", grab the first defmodule line as unique content
+      assert html_a =~ "defmodule",
+             "File A source should be visible when expanded"
+
+      # Expand file B (should auto-collapse A)
+      view
+      |> element("button[phx-value-path=\"#{file_b}\"]", "Expand")
+      |> render_click()
+
+      # Capture file B's source content
+      html_b = render(view)
+
+      # The two source viewers must show different content
+      refute html_a == html_b,
+             "Source content should differ when switching between files"
+
+      # File A's button should now say "Expand" (collapsed)
+      refute html_b =~ ~r(phx-value-path="#{Regex.escape(file_a)}"[^>]*>\s*Collapse\s*</),
+             "file A should be collapsed after switching expand to file B"
+
+      # File B's button should say "Collapse" (expanded)
+      assert html_b =~ ~r(phx-value-path="#{Regex.escape(file_b)}"[^>]*>\s*Collapse\s*</),
+             "file B should show Collapse button when expanded"
+    end
+  end
+
+  describe "app layout with menu" do
+    test "renders the microprints page", %{conn: conn} do
+      {:ok, _view, html} = live(conn, ~p"/microprints")
+      assert html =~ "Microprints"
+    end
+
+    test "renders with page content and legend", %{conn: conn} do
+      {:ok, _view, html} = live(conn, ~p"/microprints")
+      # Verify the page renders expected content (render/1 returns LV inner HTML only)
+      assert html =~ "Visual fingerprints of source code files"
+      assert html =~ "Function"
+      assert html =~ "Module"
+      assert html =~ "Keyword"
+    end
+  end
+
+  describe "URL state persistence" do
+    test "expanded path is restored from query param on mount", %{conn: conn} do
+      files = MicroprintsLive.scan_source_files()
+      file_a = List.first(files)
+
+      {:ok, view, _html} = live(conn, ~p"/microprints?expanded=#{file_a}")
+
+      html = render(view)
+
+      assert html =~ "Collapse",
+             "Expanded file should show Collapse button when restored from URL param"
+
+      assert html =~ ~s(phx-value-path="#{file_a}")
+    end
+
+    test "unknown expanded path in URL is ignored gracefully", %{conn: conn} do
+      {:ok, view, _html} = live(conn, ~p"/microprints?expanded=nonexistent.ex")
+
+      html = render(view)
+
+      refute html =~ "Collapse",
+             "Nonexistent expanded path should not show Collapse"
+    end
+
+    test "expand updates URL with expanded param", %{conn: conn} do
+      files = MicroprintsLive.scan_source_files()
+      file_a = List.first(files)
+
+      {:ok, view, _html} = live(conn, ~p"/microprints")
+
+      view
+      |> element("button[phx-value-path=\"#{file_a}\"]", "Expand")
+      |> render_click()
+
+      # URL should contain expanded param after clicking Expand
+      html = render(view)
+
+      assert html =~ "Collapse",
+             "File should remain expanded after push_patch updates URL"
+    end
+  end
 end

app/test/firehose_web/live/source_viewer_test.exs

@@ -0,0 +1,102 @@
+defmodule FirehoseWeb.SourceViewerTest do
+  use FirehoseWeb.ConnCase, async: true
+
+  import Phoenix.LiveViewTest
+
+  alias FirehoseWeb.MicroprintsLive
+
+  defp expand_file(view, path) do
+    view
+    |> element("button[phx-value-path=\"#{path}\"]", "Expand")
+    |> render_click()
+  end
+
+  defp click_microprint_rect(view, path, line) do
+    render_click(view, "highlight_line", %{"line" => Integer.to_string(line), "path" => path})
+  end
+
+  describe "line elements" do
+    test "render with unique ids when file is expanded", %{conn: conn} do
+      files = MicroprintsLive.scan_source_files()
+      file = List.first(files)
+
+      {:ok, view, _html} = live(conn, ~p"/microprints")
+      expand_file(view, file)
+
+      assert has_element?(view, "#line-1"),
+             "Line 1 should exist in the source viewer"
+
+      assert has_element?(view, "#line-2"),
+             "Line 2 should exist in the source viewer"
+
+      assert has_element?(view, "#line-3"),
+             "Line 3 should exist in the source viewer"
+    end
+  end
+
+  describe "highlight class" do
+    test "is added to line on microprint click", %{conn: conn} do
+      files = MicroprintsLive.scan_source_files()
+      file = List.first(files)
+
+      {:ok, view, _html} = live(conn, ~p"/microprints")
+      expand_file(view, file)
+
+      click_microprint_rect(view, file, 1)
+
+      assert has_element?(view, "#line-1.sv-line-highlighted"),
+             "Line 1 should have the highlighted class after click"
+    end
+
+    test "is removed on re-clicking the same line", %{conn: conn} do
+      files = MicroprintsLive.scan_source_files()
+      file = List.first(files)
+
+      {:ok, view, _html} = live(conn, ~p"/microprints")
+      expand_file(view, file)
+
+      click_microprint_rect(view, file, 1)
+
+      assert has_element?(view, "#line-1.sv-line-highlighted"),
+             "Line 1 should be highlighted after first click"
+
+      click_microprint_rect(view, file, 1)
+
+      refute has_element?(view, "#line-1.sv-line-highlighted"),
+             "Line 1 should no longer be highlighted after second click"
+    end
+
+    test "persists when expand is restored from URL params", %{conn: conn} do
+      files = MicroprintsLive.scan_source_files()
+      file = List.first(files)
+
+      {:ok, view, _html} =
+        live(conn, ~p"/microprints?expanded=#{file}&line=1&highlighted=#{file}")
+
+      assert has_element?(view, "#line-1.sv-line-highlighted"),
+             "Line 1 should be highlighted when restored from URL params"
+    end
+  end
+
+  describe "different file highlighting" do
+    test "collapses file A and removes its source viewer when highlighting file B", %{conn: conn} do
+      files = MicroprintsLive.scan_source_files()
+      assert length(files) >= 2, "Need at least 2 files to test different-file highlighting"
+
+      [file_a, file_b | _] = files
+
+      {:ok, view, _html} = live(conn, ~p"/microprints")
+
+      expand_file(view, file_a)
+      click_microprint_rect(view, file_a, 1)
+
+      assert has_element?(view, "#line-1.sv-line-highlighted"),
+             "Line 1 in file A should be highlighted before switching"
+
+      click_microprint_rect(view, file_b, 2)
+
+      refute has_element?(view, "#line-1"),
+             "File A source viewer should be gone after highlighting a different file"
+    end
+  end
+end

blogex/lib/blogex/blog.ex

@@ -153,7 +153,9 @@ defmodule Blogex.Blog do
   def _validate_links(posts, blog_id) do
     Enum.each(posts, fn post ->
       case Blogex.LinkValidator.validate_body(post.body, blog_id, post_id: post.id) do
-        :ok -> :ok
+        :ok ->
+          :ok
+
         {:error, errors} ->
           raise Blogex.LinkError,
             blog: blog_id,

blogex/lib/blogex/link_validator.ex

@@ -174,7 +174,6 @@ defmodule Blogex.LinkValidator do
     end
   end
 
-
   # --- Private helpers ---
 
   @doc false

blogex/mix.exs

@@ -29,7 +29,7 @@ defmodule Blogex.MixProject do
 
   defp deps do
     [
-      {:nimble_publisher, "~> 1.1"},
+      {:nimble_publisher, "~> 2.0"},
       {:makeup_elixir, ">= 0.0.0"},
       {:makeup_erlang, ">= 0.0.0"},
       {:phoenix, "~> 1.7"},
@@ -37,7 +37,8 @@ defmodule Blogex.MixProject do
       {:phoenix_live_view, "~> 1.0"},
       {:jason, "~> 1.4"},
       {:plug, "~> 1.15"},
-      {:ex_doc, "~> 0.34", only: :dev, runtime: false}
+      {:ex_doc, "~> 0.34", only: :dev, runtime: false},
+      {:rustler, "~> 0.38.0", optional: true}
     ]
   end
 

blogex/mix.lock

@@ -3,12 +3,13 @@
   "earmark_parser": {:hex, :earmark_parser, "1.4.44", "f20830dd6b5c77afe2b063777ddbbff09f9759396500cdbe7523efd58d7a339c", [:mix], [], "hexpm", "4778ac752b4701a5599215f7030989c989ffdc4f6df457c5f36938cc2d2a2750"},
   "ex_doc": {:hex, :ex_doc, "0.40.1", "67542e4b6dde74811cfd580e2c0149b78010fd13001fda7cfeb2b2c2ffb1344d", [:mix], [{:earmark_parser, "~> 1.4.44", [hex: :earmark_parser, repo: "hexpm", optional: false]}, {:makeup_c, ">= 0.1.0", [hex: :makeup_c, repo: "hexpm", optional: true]}, {:makeup_elixir, "~> 0.14 or ~> 1.0", [hex: :makeup_elixir, repo: "hexpm", optional: false]}, {:makeup_erlang, "~> 0.1 or ~> 1.0", [hex: :makeup_erlang, repo: "hexpm", optional: false]}, {:makeup_html, ">= 0.1.0", [hex: :makeup_html, repo: "hexpm", optional: true]}], "hexpm", "bcef0e2d360d93ac19f01a85d58f91752d930c0a30e2681145feea6bd3516e00"},
   "jason": {:hex, :jason, "1.4.4", "b9226785a9aa77b6857ca22832cffa5d5011a667207eb2a0ad56adb5db443b8a", [:mix], [{:decimal, "~> 1.0 or ~> 2.0", [hex: :decimal, repo: "hexpm", optional: true]}], "hexpm", "c5eb0cab91f094599f94d55bc63409236a8ec69a21a67814529e8d5f6cc90b3b"},
-  "makeup": {:hex, :makeup, "1.2.1", "e90ac1c65589ef354378def3ba19d401e739ee7ee06fb47f94c687016e3713d1", [:mix], [{:nimble_parsec, "~> 1.4", [hex: :nimble_parsec, repo: "hexpm", optional: false]}], "hexpm", "d36484867b0bae0fea568d10131197a4c2e47056a6fbe84922bf6ba71c8d17ce"},
+  "makeup": {:hex, :makeup, "1.2.2", "882d46dc0905e9ff7abf2aab61a7e6b3dcc555533977d8a23b06019e6c89ac94", [:mix], [{:nimble_parsec, "~> 1.4", [hex: :nimble_parsec, repo: "hexpm", optional: false]}], "hexpm", "9a1a24e5b343b8ae16abea0822c10a6f75da27af7fa802ada5251f7579bfccfa"},
   "makeup_elixir": {:hex, :makeup_elixir, "1.0.1", "e928a4f984e795e41e3abd27bfc09f51db16ab8ba1aebdba2b3a575437efafc2", [:mix], [{:makeup, "~> 1.0", [hex: :makeup, repo: "hexpm", optional: false]}, {:nimble_parsec, "~> 1.2.3 or ~> 1.3", [hex: :nimble_parsec, repo: "hexpm", optional: false]}], "hexpm", "7284900d412a3e5cfd97fdaed4f5ed389b8f2b4cb49efc0eb3bd10e2febf9507"},
   "makeup_erlang": {:hex, :makeup_erlang, "1.0.3", "4252d5d4098da7415c390e847c814bad3764c94a814a0b4245176215615e1035", [:mix], [{:makeup, "~> 1.0", [hex: :makeup, repo: "hexpm", optional: false]}], "hexpm", "953297c02582a33411ac6208f2c6e55f0e870df7f80da724ed613f10e6706afd"},
+  "mdex_native": {:hex, :mdex_native, "0.2.4", "a74b9d799d3fc487b1f97b70ee9b04108c7af0514920d56828e173d19312c2a9", [:mix], [{:rustler, "~> 0.32", [hex: :rustler, repo: "hexpm", optional: true]}, {:rustler_precompiled, "~> 0.7", [hex: :rustler_precompiled, repo: "hexpm", optional: false]}], "hexpm", "d71185c43c5209c6939f4b65f903f71c892512c93ea6843171227855d2d976f5"},
   "mime": {:hex, :mime, "2.0.7", "b8d739037be7cd402aee1ba0306edfdef982687ee7e9859bee6198c1e7e2f128", [:mix], [], "hexpm", "6171188e399ee16023ffc5b76ce445eb6d9672e2e241d2df6050f3c771e80ccd"},
   "nimble_parsec": {:hex, :nimble_parsec, "1.4.2", "8efba0122db06df95bfaa78f791344a89352ba04baedd3849593bfce4d0dc1c6", [:mix], [], "hexpm", "4b21398942dda052b403bbe1da991ccd03a053668d147d53fb8c4e0efe09c973"},
-  "nimble_publisher": {:hex, :nimble_publisher, "1.1.1", "3ea4d4cfca45b11a5377bce7608367a9ddd7e717a9098161d8439eca23e239aa", [:mix], [{:earmark, "~> 1.4", [hex: :earmark, repo: "hexpm", optional: false]}, {:makeup, "~> 1.0", [hex: :makeup, repo: "hexpm", optional: false]}], "hexpm", "d67e15bddf07e8c60f75849008b78ea8c6b2b4ae8e3f882ccf0a22d57bd42ed0"},
+  "nimble_publisher": {:hex, :nimble_publisher, "2.0.0", "f4fc100949ccdf1831094ff303b79f27c6f04b2ead829409426ee0d9ed3aa55b", [:mix], [{:makeup, "~> 1.0", [hex: :makeup, repo: "hexpm", optional: true]}, {:mdex_native, "~> 0.1", [hex: :mdex_native, repo: "hexpm", optional: false]}], "hexpm", "88997f74b763c24a15d20a90d7cd4ef1fd01172a2b4651e54d8021a44659f2c8"},
   "phoenix": {:hex, :phoenix, "1.8.5", "919db335247e6d4891764dc3063415b0d2457641c5f9b3751b5df03d8e20bbcf", [:mix], [{:bandit, "~> 1.0", [hex: :bandit, repo: "hexpm", optional: true]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:phoenix_pubsub, "~> 2.1", [hex: :phoenix_pubsub, repo: "hexpm", optional: false]}, {:phoenix_template, "~> 1.0", [hex: :phoenix_template, repo: "hexpm", optional: false]}, {:phoenix_view, "~> 2.0", [hex: :phoenix_view, repo: "hexpm", optional: true]}, {:plug, "~> 1.14", [hex: :plug, repo: "hexpm", optional: false]}, {:plug_cowboy, "~> 2.7", [hex: :plug_cowboy, repo: "hexpm", optional: true]}, {:plug_crypto, "~> 1.2 or ~> 2.0", [hex: :plug_crypto, repo: "hexpm", optional: false]}, {:telemetry, "~> 0.4 or ~> 1.0", [hex: :telemetry, repo: "hexpm", optional: false]}, {:websock_adapter, "~> 0.5.3", [hex: :websock_adapter, repo: "hexpm", optional: false]}], "hexpm", "83b2bb125127e02e9f475c8e3e92736325b5b01b0b9b05407bcb4083b7a32485"},
   "phoenix_html": {:hex, :phoenix_html, "4.3.0", "d3577a5df4b6954cd7890c84d955c470b5310bb49647f0a114a6eeecc850f7ad", [:mix], [], "hexpm", "3eaa290a78bab0f075f791a46a981bbe769d94bc776869f4f3063a14f30497ad"},
   "phoenix_live_view": {:hex, :phoenix_live_view, "1.1.27", "9afcab28b0c82afdc51044e661bcd5b8de53d242593d34c964a37710b40a42af", [:mix], [{:igniter, ">= 0.6.16 and < 1.0.0-0", [hex: :igniter, repo: "hexpm", optional: true]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:lazy_html, "~> 0.1.0", [hex: :lazy_html, repo: "hexpm", optional: true]}, {:phoenix, "~> 1.6.15 or ~> 1.7.0 or ~> 1.8.0-rc", [hex: :phoenix, repo: "hexpm", optional: false]}, {:phoenix_html, "~> 3.3 or ~> 4.0", [hex: :phoenix_html, repo: "hexpm", optional: false]}, {:phoenix_template, "~> 1.0", [hex: :phoenix_template, repo: "hexpm", optional: false]}, {:phoenix_view, "~> 2.0", [hex: :phoenix_view, repo: "hexpm", optional: true]}, {:plug, "~> 1.15", [hex: :plug, repo: "hexpm", optional: false]}, {:telemetry, "~> 0.4.2 or ~> 1.0", [hex: :telemetry, repo: "hexpm", optional: false]}], "hexpm", "415735d0b2c612c9104108b35654e977626a0cb346711e1e4f1ed16e3c827ede"},
@@ -16,6 +17,8 @@
   "phoenix_template": {:hex, :phoenix_template, "1.0.4", "e2092c132f3b5e5b2d49c96695342eb36d0ed514c5b252a77048d5969330d639", [:mix], [{:phoenix_html, "~> 2.14.2 or ~> 3.0 or ~> 4.0", [hex: :phoenix_html, repo: "hexpm", optional: true]}], "hexpm", "2c0c81f0e5c6753faf5cca2f229c9709919aba34fab866d3bc05060c9c444206"},
   "plug": {:hex, :plug, "1.19.1", "09bac17ae7a001a68ae393658aa23c7e38782be5c5c00c80be82901262c394c0", [:mix], [{:mime, "~> 1.0 or ~> 2.0", [hex: :mime, repo: "hexpm", optional: false]}, {:plug_crypto, "~> 1.1.1 or ~> 1.2 or ~> 2.0", [hex: :plug_crypto, repo: "hexpm", optional: false]}, {:telemetry, "~> 0.4.3 or ~> 1.0", [hex: :telemetry, repo: "hexpm", optional: false]}], "hexpm", "560a0017a8f6d5d30146916862aaf9300b7280063651dd7e532b8be168511e62"},
   "plug_crypto": {:hex, :plug_crypto, "2.1.1", "19bda8184399cb24afa10be734f84a16ea0a2bc65054e23a62bb10f06bc89491", [:mix], [], "hexpm", "6470bce6ffe41c8bd497612ffde1a7e4af67f36a15eea5f921af71cf3e11247c"},
+  "rustler": {:hex, :rustler, "0.38.0", "7a8906998ff0d28e3021c0a73264abcda719bda344b2e58307c6805b0f87c9b4", [:mix], [{:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: false]}], "hexpm", "704c03c1bf66be12b031c5a389347b91c81c5cb819a24b068b0de36fe4a5652a"},
+  "rustler_precompiled": {:hex, :rustler_precompiled, "0.9.0", "3a052eda09f3d2436364645cc1f13279cf95db310eb0c17b0d8f25484b233aa0", [:mix], [{:rustler, "~> 0.23", [hex: :rustler, repo: "hexpm", optional: true]}], "hexpm", "471d97315bd3bf7b64623418b3693eedd8e47de3d1cb79a0ac8f9da7d770d94c"},
   "telemetry": {:hex, :telemetry, "1.4.1", "ab6de178e2b29b58e8256b92b382ea3f590a47152ca3651ea857a6cae05ac423", [:rebar3], [], "hexpm", "2172e05a27531d3d31dd9782841065c50dd5c3c7699d95266b2edd54c2dafa1c"},
   "websock": {:hex, :websock, "0.5.3", "2f69a6ebe810328555b6fe5c831a851f485e303a7c8ce6c5f675abeb20ebdadc", [:mix], [], "hexpm", "6105453d7fac22c712ad66fab1d45abdf049868f253cf719b625151460b8b453"},
   "websock_adapter": {:hex, :websock_adapter, "0.5.9", "43dc3ba6d89ef5dec5b1d0a39698436a1e856d000d84bf31a3149862b01a287f", [:mix], [{:bandit, ">= 0.6.0", [hex: :bandit, repo: "hexpm", optional: true]}, {:plug, "~> 1.14", [hex: :plug, repo: "hexpm", optional: false]}, {:plug_cowboy, "~> 2.6", [hex: :plug_cowboy, repo: "hexpm", optional: true]}, {:websock, "~> 0.5", [hex: :websock, repo: "hexpm", optional: false]}], "hexpm", "5534d5c9adad3c18a0f58a9371220d75a803bf0b9a3d87e6fe072faaeed76a08"},

init.el

@@ -0,0 +1,72 @@
+; This file is GPL licensed, same as Emacs
+
+
+; callback to rewrite image pat so emacs can show images inside blog post drafts.
+(defun firehose/markdown-translate-image-path (path)
+  "Translate /media/... image links to ../media/... relative to buffer."
+  (message (concat "markdown translate image path called on " path))
+  
+  (if (string-prefix-p "/images" path)
+      (concat "../../../static" path)))
+  
+
+; test
+(message (firehose/markdown-translate-image-path "/images/bla"))
+
+; monkey patch function to fix our filename
+(defun markdown-display-inline-images ()
+  "Add inline image overlays to image links in the buffer.
+This can be toggled with `markdown-toggle-inline-images'
+or \\[markdown-toggle-inline-images]."
+  (interactive)
+  (message "monkeypatched function called")
+  (unless (display-images-p)
+    (error "Cannot show images"))
+  (save-excursion
+    (save-restriction
+      (widen)
+      (goto-char (point-min))
+      (while (re-search-forward markdown-regex-link-inline nil t)
+        (let* ((start (match-beginning 0))
+               (imagep (match-beginning 1))
+               (end (match-end 0))
+               (file (funcall markdown-translate-filename-function (match-string-no-properties 6))))
+          (when (and imagep
+                     (not (zerop (length file))))
+            (unless (file-exists-p file)
+              (let* ((download-file (funcall markdown-translate-filename-function file))
+                     (valid-url (ignore-errors
+                                  (member (downcase (url-type (url-generic-parse-url download-file)))
+                                          markdown-remote-image-protocols))))
+                (if (and markdown-display-remote-images valid-url)
+                    (setq file (markdown--get-remote-image download-file))
+                  (when (not valid-url)
+                    ;; strip query parameter
+                    (setq file (replace-regexp-in-string "?.+\\'" "" file))
+                    (unless (file-exists-p file)
+                      (setq file (url-unhex-string file)))))))
+            (when (file-exists-p file)
+              (let* ((abspath (if (file-name-absolute-p file)
+                                  file
+                                (concat default-directory file)))
+                     (image
+                      (cond ((and markdown-max-image-size
+                                  (image-type-available-p 'imagemagick))
+                             (create-image
+                              abspath 'imagemagick nil
+                              :max-width (car markdown-max-image-size)
+                              :max-height (cdr markdown-max-image-size)))
+                            (markdown-max-image-size
+                             (create-image abspath nil nil
+                                           :max-width (car markdown-max-image-size)
+                                           :max-height (cdr markdown-max-image-size)))
+                            (t (create-image abspath)))))
+                (when image
+                  (let ((ov (make-overlay start end)))
+                    (overlay-put ov 'display image)
+                    (overlay-put ov 'face 'default)
+                    (push ov markdown-inline-image-overlays)))))))))))
+
+; register hook
+(setq markdown-translate-filename-function
+                        #'firehose/markdown-translate-image-path)

investigation/context.md

@@ -0,0 +1,77 @@
+# Codebase Context for Investigation
+
+## Project Structure
+- **app/** - Phoenix LiveView application with blogs, user auth, editor dashboard
+- **blogex/** - Multi-blog engine library (Blogex) with NimblePublisher-based markdown posts
+
+## Key Modules
+
+### Blog Config (app/lib/firehose/blogs/)
+- `Firehose.EngineeringBlog` - blog_id: :engineering, base_path: "/blog/engineering"
+- `Firehose.ReleaseNotes` - blog_id: :release_notes, base_path: "/blog/releases"
+
+### Blog Post System (blogex/lib/blogex/)
+- `Blogex.Post` - struct with fields: id, title, author, body, description, date, blog, image, tags, published
+- `Post.visibility(post)` returns :draft (published=false), :scheduled (future date), :live
+- `Post.days_until_live(post)` returns days until scheduled post goes live
+- Posts are compiled at build-time from markdown files in priv/blog/
+
+### Blog Module (blogex/lib/blogex/blog.ex)
+- `Blogex.Blog` - macro that uses NimblePublisher
+- `all_posts()` - returns published, non-future-dated posts (drafts excluded in prod)
+- `unfiltered_posts()` - returns ALL posts including drafts and future-dated
+- `recent_posts(n)` - returns n most recent published posts
+- `paginate(page, per_page)` - pagination support
+
+### Registry (blogex/lib/blogex/registry.ex)
+- `Blogex.Registry.all_posts()` - all published posts across blogs
+- `Blogex.Registry.all_posts_unfiltered()` - all posts including drafts/scheduled
+- `Blogex.Registry.get_blog!(blog_id)` - get blog module by atom
+
+### Router (app/lib/firehose_web/router.ex)
+- GET / - PageController.home (homepage with recent posts)
+- GET /blog/:blog_id - BlogController.index (blog listing)
+- GET /blog/:blog_id/:slug - BlogController.show (single post)
+- GET /blog/:blog_id/tag/:tag - BlogController.tag (posts by tag)
+- GET /api/blog/engineering - Blogex.Router (serves HTML+JSON+RSS)
+- GET /api/blog/releases - Blogex.Router (serves HTML+JSON+RSS)
+- LiveView: GET /editor/dashboard - EditorDashboardLive (authenticated)
+- LiveView: GET /microprints - MicroprintsLive
+
+### Blogex Router (blogex/lib/blogex/router.ex)
+- Serves at /api/blog/{engineering,releases}
+- GET /feed.xml - RSS 2.0 feed
+- GET /atom.xml - Atom feed
+- These are mounted under /api/blog/* so feeds are at /api/blog/engineering/feed.xml
+
+### Blog Controller (app/lib/firehose_web/controllers/blog_controller.ex)
+- Renders blog index, show, and tag pages using Phoenix templates with Blogex.Components
+- Uses the Phoenix layout (app.html.heex) with full UI
+
+### Editor Dashboard (app/lib/firehose_web/live/editor_dashboard_live.ex)
+- Authenticated LiveView at /editor/dashboard
+- Shows Drafts and Scheduled posts tabs
+- Uses Blogex.Registry.all_posts_unfiltered()
+- Has a tab switcher between drafts and scheduled
+- Each post shows title, author, date, status
+
+### Layout/UI (app/lib/firehose_web/components/layouts/app.html.heex)
+- Navbar with links to: Home, Blog, Releases, QWAN (external), Contact, theme toggle
+- No RSS icon/link visible in nav
+- No link to Editor Dashboard in nav (only accessible via direct URL)
+
+### Homepage (app/lib/firehose_web/controllers/page_html/home.html.heex)
+- Shows intro text and recent posts grid (6 most recent across both blogs)
+
+### Email/Mailer
+- `Firehose.Mailer` uses Swoosh with gen_smtp adapter
+- `Firehose.Accounts` has user registration, login, password change
+- `Firehose.Accounts.UserNotifier` for email notifications
+- No subscription/newsletter functionality exists
+
+### Mix Dependencies
+- phoenix_live_view ~> 1.1.0
+- swoosh ~> 1.16 (email library)
+- gen_smtp ~> 1.0 (SMTP adapter)
+- ecto_sql ~> 3.13, postgrex
+- blogex (path dependency, local)

investigation/question-1-drafts-scheduled-list.md

@@ -0,0 +1,153 @@
+# Question 1: "Is there a way to see all drafts and scheduled posts in a list?"
+
+## Answer Summary
+
+Yes — an editor dashboard exists at `/editor/dashboard` showing all drafts and scheduled posts, but it is **not linked from the navigation**. Only users who know the URL can access it.
+
+Public routes (index, homepage, tag pages) never show drafts/scheduled in production. However, authenticated users can view individual draft/scheduled posts **by direct URL** if they know the slug — the show template detects visibility and shows a status banner.
+
+---
+
+## 1. Existing Views/Routes for Drafts & Scheduled Posts
+
+### Editor Dashboard (LiveView) — `/editor/dashboard`
+
+- **File:** `app/lib/firehose_web/live/editor_dashboard_live.ex`
+- **Route:** `live "/editor/dashboard", EditorDashboardLive` (router.ex line 87)
+- **Auth:** Requires authenticated user (`:require_authenticated_user` pipe, line 84)
+- **Data source:** `Blogex.Registry.all_posts_unfiltered()` — returns ALL posts regardless of published/date
+- **Features:**
+  - Two tabs: Drafts (published=false) and Scheduled (future date)
+  - Count badges per tab
+  - Shows title, author, date, status badge, and days-until-live for scheduled posts
+  - Links each post to its public URL
+
+### BlogController.show — individual draft/scheduled post viewing
+
+- **File:** `app/lib/firehose_web/controllers/blog_controller.ex`
+- **Route:** `GET /blog/:blog_id/:slug` (router.ex line 38)
+- **Auth:** No auth middleware — but show template only shows status banners when authenticated
+- **Data source:** `blog.get_post!()` (line 22) uses `unfiltered_posts()` — returns ANY post by slug, including drafts/scheduled
+- **Show template** (`app/lib/firehose_web/controllers/blog_html/show.html.heex`, lines 6-22):
+  - Shows a draft banner (amber) only when `@authenticated` and visibility is `:draft`
+  - Shows a scheduled banner (blue) only when `@authenticated` and visibility is `:scheduled`
+
+### BlogController.index / tag — do NOT show drafts/scheduled
+
+- Uses `blog.paginate()` / `blog.posts_by_tag()` which call `all_posts()` — filtered in production
+- See section 3 for details
+
+---
+
+## 2. Is the Editor Dashboard linked from the main navigation?
+
+**No.** The navbar in `app/lib/firehose_web/components/layouts/app.html.heex` (lines 1-23) contains:
+
+| Link | Target |
+|------|--------|
+| Blog | `/blog/engineering` |
+| Releases | `/blog/releases` |
+| QWAN | `https://qwan.eu` (external) |
+| Contact | `/contact` |
+| Theme toggle | inline JS |
+
+There are **no user/authentication-related links at all** — no login, logout, settings, or dashboard link. The layout does not reference `@current_scope` or any authenticated-user assigns.
+
+---
+
+## 3. Do any public routes show draft or scheduled posts?
+
+| Route | Uses | Shows drafts/scheduled? |
+|-------|------|------------------------|
+| `GET /` (homepage) | `recent_posts(3)` → `all_posts()` | ❌ No (filtered) |
+| `GET /blog/:blog_id` (index) | `paginate()` → `all_posts()` | ❌ No (filtered) |
+| `GET /blog/:blog_id/tag/:tag` | `posts_by_tag()` → `all_posts()` | ❌ No (filtered) |
+| `GET /blog/:blog_id/:slug` (show) | `get_post!()` → `unfiltered_posts()` | ✅ Yes — any authenticated user can view via direct URL, with status banner |
+
+### Filtering logic (in `Blogex.Blog`, `app/lib/firehose/blog/blog.ex` lines 85-90):
+
+```elixir
+def all_posts do
+  today = Date.utc_today()
+  if Blogex.show_drafts?() do
+    Enum.filter(@posts, &(not Date.after?(&1.date, today)))
+  else
+    Enum.filter(@posts, &(&1.published and not Date.after?(&1.date, today)))
+  end
+end
+```
+
+- **Dev mode** (`config/config.exs` line 78): `show_drafts: true` — includes drafts (published=false) but excludes future-dated (scheduled)
+- **Prod mode** (`config/prod.exs` line 17): `show_drafts: false` — only live posts visible
+
+**Important gap:** `all_posts()` in dev includes drafts but NOT scheduled. The editor dashboard (`all_posts_unfiltered()`) handles both.
+
+### Show template control flow (show.html.heex lines 4-22):
+
+```heex
+<%= if @authenticated and @visibility == :draft do %>
+  <div>Draft — not published</div>
+<% end %>
+
+<%= if @authenticated and @visibility == :scheduled do %>
+  <div>This post is scheduled for ...</div>
+<% end %>
+```
+
+The `@authenticated` flag comes from `conn.assigns[:current_scope]` (BlogController line 33):
+```elixir
+authenticated: !!(conn.assigns[:current_scope] && conn.assigns.current_scope.user)
+```
+
+---
+
+## 4. What would need to change to add a link to the editor dashboard in the main nav?
+
+### Single-file change: `app/lib/firehose_web/components/layouts/app.html.heex`
+
+The app layout receives `@current_scope` from the `fetch_current_scope_for_user` plug in the browser pipeline (router.ex line 16). Currently it doesn't use it.
+
+**Required addition:** A conditional link inside the `<ul class="flex flex-row ...">` that shows only when `@current_scope` has a user:
+
+```heex
+<%= if @current_scope && @current_scope.user do %>
+  <li>
+    <a href="/editor/dashboard" class="btn btn-ghost btn-sm">Dashboard</a>
+  </li>
+<% end %>
+```
+
+No router changes needed — the route and LiveView already exist with proper authentication guards.
+
+**Optionally**, also add login/logout links for unauthenticated users, so they know how to reach the dashboard.
+
+---
+
+## 5. What would be the simplest way to make drafts/scheduled visible to editors?
+
+### Recommendation: Link the existing dashboard in the nav
+
+The EditorDashboardLive at `/editor/dashboard` is fully functional — it shows all drafts and scheduled posts with proper sorting and status badges. The **only** missing piece is discoverability.
+
+**Simplest change:**
+1. Add a conditional "Dashboard" link to `app.html.heex` (as described in #4 above) — **~3 lines of code**
+2. Optionally add login/logout links so users can authenticate
+
+**Why this is sufficient:**
+- The dashboard is already built and tested
+- It respects authentication (only shows for logged-in users)
+- It covers both drafts **and** scheduled (unlike dev-mode `all_posts()` which only covers drafts)
+- Posts link to their public URLs for preview
+
+### Alternative considered: Add drafts/scheduled to public blog index
+
+This would be more invasive — it would require:
+- Changing `BlogController.index` to check for authentication and use `unfiltered_posts()` when authenticated
+- Adding an auth plug to the blog routes (currently no auth pipeline there)
+- Modifying templates to show status badges
+
+This approach would leak draft titles to unauthenticated users if not done carefully, and is more complex than simply linking the existing dashboard.
+
+### Live post preview (already exists)
+
+Authenticated users can already view individual draft/scheduled posts by direct URL (`/blog/engineering/some-draft-slug`) with a status banner — `BlogController.show` uses `get_post!()` which returns unfiltered posts. The show template checks `@authenticated` to display the draft/scheduled banner.

investigation/question-2-rss-prominence.md

@@ -0,0 +1,225 @@
+# Question 2: How can we make RSS feeds more obvious to viewers?
+
+## 1. Where are the RSS/Atom feeds currently served?
+
+**Application router** (`app/lib/firehose_web/router.ex`, lines 39-41):
+
+```elixir
+scope "/api/blog" do
+  forward "/engineering", Blogex.Router, blog: Firehose.EngineeringBlog
+  forward "/releases", Blogex.Router, blog: Firehose.ReleaseNotes
+end
+```
+
+The Blogex.Router is mounted under `/api/blog/{engineering,releases}`. This means feeds are at:
+
+| Feed | URL |
+|------|-----|
+| Engineering RSS | `/api/blog/engineering/feed.xml` |
+| Engineering Atom | `/api/blog/engineering/atom.xml` |
+| Release Notes RSS | `/api/blog/releases/feed.xml` |
+| Release Notes Atom | `/api/blog/releases/atom.xml` |
+
+**Blogex.Router** (`blogex/lib/blogex/router.ex`, lines 27-61) handles:
+
+- `GET /feed.xml` (line 27) — RSS 2.0 via `Blogex.Feed.rss/2`
+- `GET /atom.xml` (line 39) — Atom feed via `Blogex.Feed.atom/2`
+
+The feeds are **not mounted under the human-facing `/blog/{id}/` paths** but under `/api/blog/{id}/`. This is suboptimal for usability — users browsing at `/blog/engineering` won't find a feed at `/blog/engineering/feed.xml`.
+
+**Feed generation** (`blogex/lib/blogex/feed.ex`):
+
+- `Blogex.Feed.rss/2` generates RSS 2.0 with proper XML, using `all_posts()`, respecting a `:limit` option (default 20).
+- `Blogex.Feed.atom/2` generates Atom feed with same post data.
+- Both include a self-referencing `<atom:link>` in RSS / `<link rel="self">` in Atom (for feed reader validation).
+- Blog/author info is read from the blog module's `title/0`, `description/0`, `base_path/0` functions.
+
+---
+
+## 2. Is there any RSS icon or link in the current UI?
+
+**No. There are zero references to RSS/Atom/feed in any template.**
+
+| Location | File | Line(s) | Has RSS link? |
+|----------|------|---------|---------------|
+| Navigation bar | `app/lib/firehose_web/components/layouts/app.html.heex` | 1-32 | **No** |
+| Homepage | `app/lib/firehose_web/controllers/page_html/home.html.heex` | 1-38 | **No** |
+| Blog index | `app/lib/firehose_web/controllers/blog_html/index.html.heex` | 1-9 | **No** |
+| Blog post show | `app/lib/firehose_web/controllers/blog_html/show.html.heex` | 1-23 | **No** |
+| Blog tag page | `app/lib/firehose_web/controllers/blog_html/tag.html.heex` | 1-10 | **No** |
+| HTML `<head>` | `app/lib/firehose_web/components/layouts/root.html.heex` | 1-40 | **No** |
+
+Confirmed by codebase grep — `grep -rn "feed\|rss\|atom" app/lib/firehose_web/` returned only comments and false matches (e.g. `"feed"` in error handling, not RSS).
+
+---
+
+## 3. Best places to add RSS feed links
+
+### (A) HTML `<head>` — Autodiscovery (highest priority)
+
+**File:** `app/lib/firehose_web/components/layouts/root.html.heex`
+
+Two `<link>` tags per blog for RSS autodiscovery (feed readers use these to auto-detect feeds):
+
+```html
+<link rel="alternate" type="application/rss+xml" title="Engineering Blog" href="/api/blog/engineering/feed.xml" />
+<link rel="alternate" type="application/atom+xml" title="Engineering Blog (Atom)" href="/api/blog/engineering/atom.xml" />
+<link rel="alternate" type="application/rss+xml" title="Release Notes" href="/api/blog/releases/feed.xml" />
+<link rel="alternate" type="application/atom+xml" title="Release Notes (Atom)" href="/api/blog/releases/atom.xml" />
+```
+
+**Challenge:** The root layout (`root.html.heex`) is shared across all pages (hompage, about, contact, blog pages). Hardcoding both blogs' feeds works, but ideally only the currently-relevant blog's feed links appear on blog-specific pages. Since the app router uses a single root layout, you'd need to pass the blog context from the controller into the layout assigns, or use `@content_for`/`put_layout` approaches.
+
+**Option A1 (simple):** Hardcode both feeds in `<head>` unconditionally. Acceptable because:
+- The site only has two blogs with stable URLs.
+- Readers can subscribe to either.
+- Zero configuration needed.
+
+**Option A2 (precise):** Add blog-specific metadata to the assigns in `BlogController` (lines 14-28, 31-46) and pass it to the layout via `@content_for`, similar to how `meta_tags` are already handled (line 20: `FirehoseWeb.Layouts.put_content_for(:meta_tags, meta)`). This would require adding a new `@content_for` slot for feed links.
+
+### (B) Blog index pages (app/lib/firehose_web/controllers/blog_html/index.html.heex)
+
+Add an RSS icon next to the blog title in the `<header>` section (line 4):
+
+```
+<h1 class="text-3xl font-bold font-display">{@blog_title}</h1>
+```
+
+Change to include a small RSS icon link pointing at the appropriate feed URL. The `@base_path` assign is already available (set in `BlogController.index/2`, line 24). We can derive the feed URL as `/api/blog/engineering/feed.xml` when `@base_path` is `/blog/engineering`, but there's no direct mapping. A helper mapping function would be needed, or a `@blog_id` assign should be added to the controller.
+
+**Option B1:** Add a `blog_id` assign to the controller, then in the template do:
+
+```elixir
+<a href={"/api/blog/#{@blog_id}/feed.xml"} class="..." title="RSS feed">
+  <.rss_icon />
+</a>
+```
+
+**Option B2 (simpler):** Hardcode the mapping in the template or add a helper function in `BlogHTML`:
+
+```elixir
+defp feed_url("/blog/engineering"), do: "/api/blog/engineering/feed.xml"
+defp feed_url("/blog/releases"), do: "/api/blog/releases/feed.xml"
+```
+
+### (C) Blog post pages (app/lib/firehose_web/controllers/blog_html/show.html.heex)
+
+Add a subtle "Subscribe via RSS" link or icon near the "Back to posts" link (line 2). The `@base_path` and `@post` assigns are available.
+
+Best placement: inline with the "Back to posts" link at the top, or as a small badge/icon in the post metadata area (which is rendered by `Blogex.Components.post_meta/1` in `blogex/lib/blogex/components.ex`, line 76).
+
+### (D) Homepage (app/lib/firehose_web/controllers/page_html/home.html.heex)
+
+Add an RSS icon or link near the "Recent posts" heading (line 21, currently just `<h2>Recent posts</h2>`). Since the homepage shows posts from both blogs, you could:
+
+- Link to the Engineering blog feed (primary blog)
+- Or show a dropdown between the two feeds
+- Or link to both (Engineering RSS, Releases RSS)
+
+### (E) Navigation bar (app/lib/firehose_web/components/layouts/app.html.heex)
+
+More prominent placement: add an RSS icon as a nav item (after the Contact link, line 25). Could be a dropdown linking to both feeds, or just the Engineering blog feed as default. This makes RSS discoverable from any page.
+
+---
+
+## 4. HTML for RSS autodiscovery links in `<head>`
+
+The standard pattern for RSS 2.0 autodiscovery is:
+
+```html
+<link rel="alternate" type="application/rss+xml" title="Engineering Blog" href="/api/blog/engineering/feed.xml" />
+```
+
+And for Atom:
+
+```html
+<link rel="alternate" type="application/atom+xml" title="Engineering Blog (Atom)" href="/api/blog/engineering/atom.xml" />
+```
+
+For both blogs, this would be 4 `<link>` tags inserted in `root.html.heex` between the favicon links (line 9) and the `<.live_title>` component (line 10), or after line 15 (after the title).
+
+**Autodiscovery works with relative paths** (feed readers resolve them against the page URL), so using `/api/blog/engineering/feed.xml` is fine and avoids needing the full host URL.
+
+### Recommended implementation for `root.html.heex`
+
+Insert after line 14 (`</.live_title>`) and before the CSS link (line 15):
+
+```html
+<link rel="alternate" type="application/rss+xml" title="Engineering Blog" href="/api/blog/engineering/feed.xml" />
+<link rel="alternate" type="application/atom+xml" title="Engineering Blog (Atom)" href="/api/blog/engineering/atom.xml" />
+<link rel="alternate" type="application/rss+xml" title="Release Notes" href="/api/blog/releases/feed.xml" />
+<link rel="alternate" type="application/atom+xml" title="Release Notes (Atom)" href="/api/blog/releases/atom.xml" />
+```
+
+---
+
+## 5. Adding RSS subscription icons while keeping the design clean
+
+### Icon options
+
+Use an inline SVG (no additional dependencies), a commonly recognized RSS icon, approximately 16-20px, matching the current text color. The standard RSS icon is the orange/white dot-and-waves — but matching the site's monochrome theme (text color / primary color) would be more cohesive.
+
+The current design uses:
+- `text-base-content` for text
+- `text-primary` for accent links
+- Consistently uses `btn btn-ghost btn-sm` for nav links
+
+### Placement strategies (from subtle to prominent)
+
+1. **Only autodiscovery** (no visible icon) — functional for feed readers, invisible to human visitors. Minimum viable.
+
+2. **Small RSS icon in blog header** — next to the blog title on index pages. Clean and contextual.
+
+3. **Small RSS icon next to "Recent posts" on homepage** — visible on the landing page.
+
+4. **RSS icon as a nav item** — consistently visible from any page:
+   ```
+   [Blog] [Releases] [QWAN] [Contact] [📡] [theme toggle]
+   ```
+
+5. **Combination**: Autodiscovery + blog index icons + optionally a nav item.
+
+### Recommended approach (clean design)
+
+Use a small inline SVG RSS icon (matching the `text-base-content/60` muted color) placed:
+
+- **In `<head>`** for autodiscovery (always, no visual impact)
+- **In blog index header** (a small icon right-aligned next to the page title, or an inline link reading "RSS" in subtle text)
+- **Optionally in the navbar** as a subtle icon-only button
+
+### Implementation details
+
+For the blog index (`index.html.heex`), the current template at line 4:
+
+```heex
+<h1 class="text-3xl font-bold font-display">{@blog_title}</h1>
+```
+
+Could become:
+
+```heex
+<h1 class="text-3xl font-bold font-display flex items-center gap-3">
+  {@blog_title}
+  <a href={feed_url(@base_path)} class="text-base-content/40 hover:text-primary transition" title="Subscribe to RSS feed">
+    <svg class="w-5 h-5" viewBox="0 0 24 24" fill="currentColor">
+      <path d="M6.18 15.64a2.18 2.18 0 0 1 2.18 2.18C8.36 19 7.38 20 6.18 20C5 20 4 19 4 17.82a2.18 2.18 0 0 1 2.18-2.18M4 4.44A15.56 15.56 0 0 1 19.56 20h-2.83A12.73 12.73 0 0 0 4 7.27V4.44m0 5.66a9.9 9.9 0 0 1 9.9 9.9h-2.83A7.07 7.07 0 0 0 4 12.93v-2.83Z"/>
+    </svg>
+  </a>
+</h1>
+```
+
+This requires a `feed_url/1` helper. Since `base_path` maps cleanly to the API route (`/blog/engineering` → `/api/blog/engineering/feed.xml`), a simple `String.replace_prefix(@base_path, "/blog", "/api/blog") <> "/feed.xml"` would work.
+
+### Summary of implementation points
+
+| Location | File | Action |
+|----------|------|--------|
+| `<head>` | `app/lib/firehose_web/components/layouts/root.html.heex` ~ line 14 | Add 4 `<link rel="alternate">` tags |
+| Blog index | `app/lib/firehose_web/controllers/blog_html/index.html.heex` ~ line 4 | Add RSS icon next to title |
+| Blog show | `app/lib/firehose_web/controllers/blog_html/show.html.heex` ~ line 2 | Add subtle RSS link near "Back to posts" |
+| Homepage | `app/lib/firehose_web/controllers/page_html/home.html.heex` ~ line 21 | Add RSS icon near "Recent posts" heading |
+| Navbar | `app/lib/firehose_web/components/layouts/app.html.heex` ~ line 25 | Optionally add RSS icon nav item |
+| Controller | `app/lib/firehose_web/controllers/blog_controller.ex` ~ line 22 | Optionally add `blog_id` assign for feed URL mapping |
+| Helper | `app/lib/firehose_web/controllers/blog_html.ex` | Add `feed_url/1` helper function |
+
+**Note:** The current feed URLs under `/api/blog/` are slightly awkward. Consider adding the `feed.xml` and `atom.xml` routes to the main Blogex.Router *also* under the human-facing path (e.g., `/blog/engineering/feed.xml`) by mounting Blogex.Router at both paths, or by adding explicit routes. However, this would be a larger refactor — the simplest short-term approach is to use the existing `/api/blog/` URLs and just link to them prominently.

investigation/question-3-email-subscriptions.md

@@ -0,0 +1,230 @@
+# Question 3: Email Subscriptions — Investigation
+
+## 1. Does any email subscription functionality already exist?
+
+**No. Zero.** The codebase contains no newsletter, subscription, or subscriber functionality whatsoever.
+
+A grep for `newsletter`, `subscrib`, `subscriber`, `unsubscribe` across all `.ex` and `.heex` files in the project returned zero matches.
+
+## 2. What existing email infrastructure is already in place?
+
+### Mailer (Swoosh)
+
+- **File:** `app/lib/firehose/mailer.ex` (line 1-3)
+- Uses `Swoosh.Mailer`, otp_app: `:firehose`
+- Config uses `Swoosh.Adapters.Local` in dev (config.exs, line 40)
+- Config uses `Swoosh.Adapters.Test` in test (test.exs, line 24)
+- Production uses `Swoosh.Adapters.SMTP` via env vars (runtime.exs, lines 54-65)
+
+### UserNotifier (existing pattern for transactional emails)
+
+- **File:** `app/lib/firehose/accounts/user_notifier.ex`
+- Has two notification functions:
+  - `deliver_update_email_instructions/2` (line 41)
+  - `deliver_login_instructions/2` (line 53) — which dispatches to either `deliver_confirmation_instructions` or `deliver_magic_link_instructions`
+- Internal `deliver/4` helper (line 19) constructs a `Swoosh.Email`, calls `Mailer.deliver/1`
+- Uses `SENDER_NAME` and `SMTP_FROM_EMAIL` env vars (lines 12-13)
+- Only sends plain-text emails (no HTML templates)
+
+### Accounts Context
+
+- **File:** `app/lib/firehose/accounts.ex`
+- Has `deliver_user_update_email_instructions/3` and `deliver_login_instructions/2`
+- Uses `UserToken.build_email_token/2` for token generation (hashed tokens stored in DB)
+- Token expiry: 15 minutes for magic links, 7 days for email change
+
+### Production SMTP config (runtime.exs, lines 46-64)
+
+Uses env vars:
+- `SMTP_HOST`, `SMTP_PORT`, `SMTP_USERNAME`, `SMTP_PASSWORD`, `SMTP_SSL`, `SMTP_TLS`
+
+### No Oban or background job system
+
+- **mix.exs** has no Oban dependency
+- No GenServer for background email sending
+- `app/lib/firehose/application.ex` — no Oban or job queue in the supervision tree
+- Current mailer calls are synchronous (not ideal for bulk sending)
+
+## 3. What database tables exist?
+
+Only one migration exists:
+
+**File:** `app/priv/repo/migrations/20260401201722_create_users_auth_tables.exs`
+
+Two tables:
+- `users` — id, email (citext, unique), hashed_password, confirmed_at, timestamps
+- `users_tokens` — id, user_id (FK), token (binary), context (string), sent_to (string), authenticated_at (utc_datetime), inserted_at (timestamps, no updated_at)
+
+**No subscriber table, no subscription table, no newsletter table exists.**
+
+## 4. What would a minimal email subscription feature need?
+
+### 4.1 Database Model
+
+**New table: `subscribers`**
+
+| Column | Type | Purpose |
+|--------|------|---------|
+| id | bigserial | PK |
+| email | citext, unique, not null | Subscriber email |
+| confirmed_at | utc_datetime, nullable | Set when double opt-in confirmed |
+| unsubscribed_at | utc_datetime, nullable | Set when unsubscribed |
+| token | binary, nullable | Confirmation token (hashed) |
+| token_inserted_at | utc_datetime, nullable | When token was created |
+| inserted_at | utc_datetime | Timestamps |
+| updated_at | utc_datetime | Timestamps |
+
+The `confirmed_at` field is the canonical way to know if a subscription is active (following the same pattern as `users.confirmed_at`).
+
+### 4.2 Migration
+
+Would create the `subscribers` table with:
+- `citext` extension already exists (from the users migration, line 4)
+- Unique index on email
+- Index on `confirmed_at` for querying active subscribers
+
+### 4.3 Subscription Form
+
+**Where to place it:**
+- Homepage (`app/lib/firehose_web/controllers/page_html/home.html.heex`) — add a "Subscribe to newsletter" section
+- Blog index page (`app/lib/firehose_web/controllers/blog_controller.ex`) — could also have a subscription form
+- Footer of the layout (`app/lib/firehose_web/components/layouts/app.html.heex`) — persistent subscription form
+
+**Form would POST to a new SubscriptionController** (or use a LiveView component).
+
+### 4.4 Confirmation Email Flow (Double Opt-In)
+
+1. User enters email on subscription form
+2. Server creates subscriber record with `confirmed_at: nil`, generates a hashed confirmation token
+3. Server sends confirmation email with a link like `GET /newsletter/confirm/:token`
+4. User clicks link → `confirmed_at` is set → subscription is active
+5. User can unsubscribe via `GET /newsletter/unsubscribe/:token` (or a link in each email)
+
+**Pattern to follow:** The existing `UserToken` + `UserNotifier` pattern in `app/lib/firehose/accounts/user_token.ex` shows how tokens are built, hashed, stored, and verified. The subscriber confirmation flow would be simpler — no need for the full `context` system, just a single-purpose token.
+
+### 4.5 Sending New Posts to Subscribers
+
+**Options (in order of complexity):**
+
+1. **Simple GenServer** — Polls for new published posts every N minutes, sends to confirmed subscribers. No external dependency, but no retry/backoff.
+2. **Oban** — Background job queue. Add `{:oban, "~> 2.18"}` to mix.exs. Schedule a recurring job (via Oban.Cron) to check for new posts and enqueue delivery jobs. Provides retries, observability, and proper error handling.
+3. **Manual trigger** — When a post is published (from the editor dashboard), fan out to subscribers. Requires hooking into the post-publishing flow.
+
+**Recommendation:** The GenServer approach is simpler, but Oban is more robust. The current codebase has no background job system, so either would be an addition.
+
+**How to know which posts are new:** The Blogex system compiles posts at build-time from markdown files, so there's no "published_at" event. A polling approach would need to track which posts have already been sent (e.g., a `sent_posts` table tracking `post_id` + `sent_at`).
+
+### 4.6 Unsubscribe Mechanism
+
+- Each email would include a link like `https://example.com/newsletter/unsubscribe?token=<token>`
+- The token is a hashed version of the subscriber's ID or a dedicated unsubscribe token
+- Clicking the link sets `unsubscribed_at` and the subscriber is excluded from all future sends
+- No login required — one-click unsubscribe
+
+### 4.7 New Files Needed
+
+| File | Purpose |
+|------|---------|
+| `app/lib/firehose/newsletter/subscriber.ex` | Ecto schema for `subscribers` table |
+| `app/lib/firehose/newsletter.ex` | Context module (CRUD, subscribe, confirm, unsubscribe) |
+| `app/lib/firehose/newsletter/notifier.ex` | Email sending (confirmation, new post) |
+| `app/priv/repo/migrations/*_create_subscribers.exs` | Migration |
+| `app/lib/firehose_web/controllers/newsletter_controller.ex` | Handle confirm/unsubscribe links |
+| OR `app/lib/firehose_web/live/newsletter_live.ex` | LiveView component for subscription form |
+| `app/lib/firehose/newsletter/sender.ex` | GenServer or Oban worker for sending to subscribers |
+
+## 5. Roughly how complex is this? Estimate the scope.
+
+### Complexity: Medium (roughly 2-3 days of focused work)
+
+**Breakdown by layer:**
+
+| Layer | Effort | Details |
+|-------|--------|---------|
+| DB schema + migration | 1-2 hours | Simple table, following existing patterns |
+| Ecto schema + context | 2-3 hours | CRUD, changeset validations, subscribe/confirm/unsubscribe |
+| Confirmation email flow | 2-3 hours | Token generation, email sending, link handling |
+| Subscription form UI | 2-3 hours | Form on homepage, validation, success/error states |
+| Unsubscribe mechanism | 1-2 hours | Token-based one-click unsubscribe |
+| Email sending to subscribers | 4-6 hours | The bulk of the work — polling mechanism, tracking sent posts, formatting emails |
+| Tests | 3-4 hours | Following existing test patterns in `accounts_test.exs` |
+| **Total** | **~15-22 hours** | |
+
+**Risk factors:**
+- The blog posts are compiled at build-time, so there's no "post published" event to hook into. A polling mechanism or a manual "send to subscribers" button in the editor dashboard would be needed.
+- No background job system exists — either Oban needs to be added (additional dependency, migration) or a simpler GenServer approach is used.
+- Sending bulk emails from a single-threaded GenServer could block. Oban would handle this properly with concurrent workers.
+
+**Simpler alternative (MVP):** A "Subscribe to newsletter" form that stores emails, with a manual CSV export workflow. No automated sending. This would be ~half the effort but would not be a real solution.
+
+## 6. Existing patterns to follow
+
+### User Auth Token Pattern (for confirmation tokens)
+
+**File:** `app/lib/firehose/accounts/user_token.ex`
+
+The `UserToken` module shows:
+- Tokens are generated with `:crypto.strong_rand_bytes(32)` (line 58)
+- Tokens are hashed with `:crypto.hash(:sha256, token)` before storage (line 79)
+- Raw tokens are Base64-url-encoded for URLs (line 80)
+- Verification decodes, re-hashes, and queries the database (lines 97-112)
+- Context system distinguishes token types (e.g., "session", "login", "change:email")
+
+For subscriber confirmation, we could either:
+- Reuse `users_tokens` table with a new context like `"subscribe_confirm"`
+- Create a simpler token field directly on the `subscribers` table
+
+The simpler approach (token field on `subscribers` table) is recommended to avoid coupling to the auth system.
+
+### User Notifier Pattern (for email sending)
+
+**File:** `app/lib/firehose/accounts/user_notifier.ex`
+
+The `deliver/4` function (line 19) constructs a `Swoosh.Email`:
+```elixir
+defp deliver(recipient, subject, body) do
+  email = new() |> to(recipient) |> from(sender()) |> subject(subject) |> text_body(body)
+  with {:ok, _metadata} <- Mailer.deliver(email), do: {:ok, email}
+end
+```
+
+A newsletter notifier would follow this pattern exactly, possibly adding HTML body support.
+
+### Accounts Context Pattern (for CRUD operations)
+
+**File:** `app/lib/firehose/accounts.ex`
+
+The `Accounts` context module shows the standard pattern:
+- `Repo.get_by/3` for lookups
+- `changeset` + `Repo.insert/1` for creation
+- `Repo.transact/1` for transactional operations
+- `Repo.update/1` for updates
+- Function naming convention: `subscribe/1`, `confirm_subscriber/1`, `unsubscribe/1`
+
+### Scope Pattern (for authorization)
+
+**File:** `app/lib/firehose/accounts/scope.ex`
+
+For newsletter subscriptions, scopes aren't directly relevant (subscribers are anonymous). But the pattern shows how struct-based contexts are used.
+
+### Migration Pattern
+
+**File:** `app/priv/repo/migrations/20260401201722_create_users_auth_tables.exs`
+
+The migration shows:
+- `execute "CREATE EXTENSION IF NOT EXISTS citext", ""` (line 4) — already exists
+- `create table(:users)` with `timestamps(type: :utc_datetime)` (line 6)
+- `create unique_index(:users, [:email])` (line 11)
+
+### Test Fixture Pattern
+
+**File:** `app/test/support/fixtures/accounts_fixtures.ex`
+
+Shows the fixture pattern:
+- `unique_user_email/0` — generates unique emails using `System.unique_integer()`
+- `valid_user_attributes/1` — merges defaults with overrides
+- `user_fixture/1` — creates a real DB record
+
+## Summary
+
+**Email subscriptions do not exist in any form.** The infrastructure is there (Swoosh mailer, SMTP config, email sending patterns), but the feature is a clean-slate addition. The heaviest part would be the automated sending of new posts to subscribers, which requires either adding Oban or building a polling GenServer, and solving the "which posts are new" problem since posts are compiled at build-time rather than published at runtime.

scripts/new-post.sh

@@ -43,6 +43,3 @@ EOF
 
 echo "Created: $file"
 
-if [[ -n "${EDITOR:-}" ]] && [[ -t 1 ]]; then
-    exec "$EDITOR" "$file"
-fi