¬ just serendipity 🍀

markdown: nested code fences

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 17 Aug 2026 01:27:47 +0200

♠ Problem statement: a code block that quotes a markdown file swallows the first closing fence it meets, which is the inner one.

The ADRs and LLMs post quotes a README.md that itself contains a fenced template. Written naively:

```markdown
# README

Use this template:

```markdown
# ADR-NNNN: Title
```

That was the template.
```

The CommonMark spec says who wins:

The content of the code block consists of all subsequent lines, until a closing code fence of the same type as the code block began with (backticks or tildes), and with at least as many backticks or tildes as the opening code fence.

Three backticks close three backticks, so the template’s closing fence terminates the outer block. Everything after it leaks into the page:

<div class="codeblock" data-lang="markdown">
  <!-- header -->
<p>That was the template.</p>
<div class="codeblock">
   <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-plaintext" data-lang="plaintext"></code></pre></div>
</div>

Two code blocks and a stray paragraph, where one code block was meant.

The fix is a longer outer fence — four backticks, or more:

````markdown
# README

Use this template:

```markdown
# ADR-NNNN: Title
```

That was the template.
````

Two details make this worth writing down.

The damage is quiet. On the real file the outer fence was shell, so Hugo rendered a plausible block that had merely lost its last line. Comparing the rendered code block before and after the fix:

-lang: shell
+lang: markdown
 …What becomes easier or more difficult to do because of this change?
+```

And markdownlint was happy the whole time:

% prek run markdownlint --files content/posts/2026-01-11-adrs-and-llms.md
markdownlint-cli2........................................................Passed

Rule of thumb: count the backticks of the innermost block, then add one for every level above it.

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #coding #dev #meta

microSD card: wiping before selling

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 16 Aug 2026 15:20:10 +0200

♠ Problem statement: I want to sell a 32 GB microSD card, previously used to boot a Raspberry Pi.

% diskutil list disk4
/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *32.0 GB    disk4
   1:             Windows_FAT_32 BOOT                    268.4 MB   disk4s1
   2:                      Linux                         31.7 GB    disk4s2

For that, I would like to securely wipe it. dd is my preferred tool to do so.

% diskutil unmountDisk /dev/disk4
Unmount of all volumes on disk4 was successful
% sudo dd if=/dev/zero of=/dev/rdisk4 bs=4m
dd: invalid number: '4m'

That is GNU dd from coreutils (installed via homebrew) shadowing the BSD one in PATH. BSD dd takes bs=4m, GNU dd takes 4M. It’s hard to standardize and agree upon something so simple, eh?

/dev/rdisk4 rather than /dev/disk4 because the raw node skips the buffer cache and thus it is several times faster:

% sudo dd if=/dev/zero of=/dev/rdisk4 bs=4M status=progress
dd: error writing '/dev/rdisk4': Input/output error
7633+0 records in
7632+0 records out
32010928128 bytes (32 GB, 30 GiB) copied, 3550.08 s, 9.0 MB/s

The Input/output error is the happy ending: dd ran off the end of the device. 32010928128 bytes is precisely what diskutil info reported for the disk size, so every addressable byte got a zero.

The process took ~59min at ~9.0 MB/s.

Then we’ll partition it again so that the buyer’s camera or laptop will properly recognize it:

% diskutil eraseDisk FAT32 SDCARD MBRFormat /dev/disk4
Started erase on disk4
Creating the partition map
Formatting disk4s1 as MS-DOS (FAT32) with name SDCARD
512 bytes per physical sector
/dev/rdisk4s1: 62488736 sectors in 1952773 FAT32 clusters (16384 bytes/cluster)
Finished erase on disk4
% diskutil list disk4
/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *32.0 GB    disk4
   1:                 DOS_FAT_32 SDCARD                  32.0 GB    disk4s1

Now we can finally post it for sale.

— § —

Reply via email

#dev #macos #privacy #security

homebrew: cask drift after an in-app update

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 16 Aug 2026 14:11:17 +0200

♠ Previously.

Problem statement: every brew upgrade died on a cask whose app had upgraded itself years ago.

% brew upgrade
==> Upgrading 1 outdated package:
1password 7.9.2 -> 8.12.33
==> Upgrading 1password
  7.9.2 -> 8.12.33
Error: 1password: It seems the App source '/Applications/1Password 7.app' is not there.
==> Purging files for version 8.12.33 of Cask 1password

That path stopped existing when 1Password 8 renamed its bundle from 1Password 7.app to 1Password.app. The app had updated itself in place, behind Homebrew’s back:

% defaults read /Applications/1Password.app/Contents/Info.plist CFBundleShortVersionString
8.12.30
% brew list --cask --versions 1password
1password 7.9.2

Two disagreeing sources of truth. --adopt looked like the obvious cure, and wasn’t — the stale receipt still routes into the upgrade code path, which still looks for the v7 bundle:

% brew install --cask --adopt 1password
==> Upgrading 1password
  7.9.2 -> 8.12.33
Error: 1password: It seems the App source '/Applications/1Password 7.app' is not there.

The receipt is the whole problem, so look at what it actually holds:

% find /opt/homebrew/Caskroom/1password -maxdepth 2
/opt/homebrew/Caskroom/1password
/opt/homebrew/Caskroom/1password/.metadata
/opt/homebrew/Caskroom/1password/.metadata/config.json
/opt/homebrew/Caskroom/1password/.metadata/7.9.2
/opt/homebrew/Caskroom/1password/7.9.2
% ls -A /opt/homebrew/Caskroom/1password/7.9.2/
% du -sh /opt/homebrew/Caskroom/1password
8.0K	/opt/homebrew/Caskroom/1password

Eight kilobytes of bookkeeping and an empty version directory. Nothing in there is the application. Delete it, then reinstall over the app that is really on disk:

% rm -rf /opt/homebrew/Caskroom/1password
% brew install --cask --force 1password
==> Fetching downloads for: 1password
✔︎ Cask 1password (8.12.33)
Warning: It seems there is already an App at '/Applications/1Password.app'; overwriting.
==> Installing Cask 1password
==> Removing App '/Applications/1Password.app'
==> Moving App '1Password.app' to '/Applications/1Password.app'
🍺  1password was successfully installed!

Both sides agree again:

% defaults read /Applications/1Password.app/Contents/Info.plist CFBundleShortVersionString
8.12.33
% brew list --cask --versions 1password
1password 8.12.33
% brew outdated --cask | grep 1password

Quitting the app first is mandatory, and this one ignored two polite osascript requests before a plain kill took:

% osascript -e 'quit app "1Password"'
% pgrep -x 1Password
740
% kill 740

The general shape: a cask whose app ships its own updater will drift, and Homebrew only notices when the vendor also renames the bundle. --adopt is for an app Homebrew never tracked; for an app it tracked wrongly, the receipt has to go first.

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #coding #dev #macos

new tag: bloggify

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 16 Aug 2026 13:50:00 +0200

♠ Previously.

Problem statement: some readers may not want AI-assisted posts in their feed reader, even with my edits. I support making it easier for people to opt out from such posts. They should be able to filter them out without unsubscribing from the whole blog.

Every post the /bloggify skill drafts already carries a footer disclosing it. What was missing was a machine-readable signal, not just a line at the bottom a feed reader can’t act on. So I grepped for the marker and tagged every post that has it:

% grep -rl "Drafted with \[\`/bloggify\`\]" content/posts/ | wc -l
27

% git show 79018e8cf1 -- content/posts/2026-06-09-bloggify.md
diff --git content/posts/2026-06-09-bloggify.md content/posts/2026-06-09-bloggify.md
index b0a5a8ee86..9d15d656fd 100644
--- content/posts/2026-06-09-bloggify.md
+++ content/posts/2026-06-09-bloggify.md
@@ -3,6 +3,7 @@ title: "bloggify"
 date: 2026-06-09T16:50:11+02:00
 tags:
   - ai
+  - bloggify
   - claude
   - dev
   - meta

Every post’s tags: list ends up in the RSS <item> as a <category> element, one per tag (see layouts/_default/rss.xml). So bloggify is now a regular, filterable category in the feed, same as any other tag.

For those of you who use Miniflux, filtering it out is the same trick from blocking an entry matching a URL and the global blocklist, except on the EntryTag field instead of EntryURL or EntryTitle:

EntryTag=(?i)^bloggify$

Added as a global block rule in miniflux, and every future /bloggify-drafted post never reaches the inbox. /tags/bloggify/ on the blog itself works too, for anyone who’d rather subscribe to the opposite: only the AI-assisted posts.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #dev #meta

pi: prompt before dangerous commands

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 16 Aug 2026 13:28:44 +0200

♠ Previously.

Problem statement: my Pi extension blocked dangerous shell commands outright, even when I had already preserved the state they could destroy.

The guard parses every bash tool call with tree-sitter, catching commands such as rm -rf, terraform destroy, and destructive Git operations. Today it did exactly what I had asked:

% git -C "$(brew --repo thiagowfx/pancake)" reset --hard origin/master
git reset --hard is blocked - discards changes irreversibly

Blocking remains the right default, but an interactive session can ask me. Pi extensions can intercept the tool_call event and open a confirmation dialog through ctx.ui.

The change in dangerous-command-guard/guard.ts:

-  pi.on("tool_call", async (event) => {
+  pi.on("tool_call", async (event, ctx) => {
     if (event.toolName !== "bash") return;

     const command = event.input.command;
     if (typeof command !== "string") return;

     const blocked = await findBlockedCommand(command);
-    if (blocked) return { block: true, reason: blocked.reason };
+    if (!blocked) return;
+    if (!ctx.hasUI) return { block: true, reason: blocked.reason };
+
+    const allowed = await ctx.ui.confirm(
+      "Allow dangerous command?",
+      `${blocked.command}\n\n${blocked.reason}`,
+    );
+    if (!allowed) return { block: true, reason: "Blocked by user" };
   });

Interactive Pi now pauses for approval. Print and JSON modes have no UI, so they still fail closed. Safe commands never prompt.

The tests exercise all three decisions:

✔ extension prompts before dangerous bash tool calls (0.66225ms)
ℹ tests 48
ℹ pass 48
ℹ fail 0

Same guardrails, with an escape hatch operated by a human rather than a model.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #security

pi: am I sandboxed?

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 15 Aug 2026 00:56:29 +0200

♠ Problem statement: asking a coding agent whether it runs in a sandbox returns a confident answer derived from its system prompt, not from the machine it is actually running on.

I asked Pi exactly that. The reply was assured:

No — pi itself doesn’t sandbox tool execution. When I run bash, edit, or write, they execute directly on your machine with your user’s permissions, in the current working directory (/Users/thiago.perrotta/.pi). […] But there’s no OS-level sandbox (no container, no seccomp, no filesystem jail).

It’s plausible, well-formatted, and…wrong!. One typo-ridden command was enough to break the illusion:

% ls ~/worksppace
ls: cannot access '/home/hostuser/worksppace': No such file or directory

~ is not /Users/thiago.perrotta. The follow-up probe:

% pwd; uname -a; whoami; cat /etc/os-release
/Users/thiago.perrotta/.pi
Linux lima-rancher-desktop 6.18.37-0-virt #1-Alpine SMP PREEMPT_DYNAMIC 2026-06-29 10:52:25 aarch64 GNU/Linux
hostuser
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

A macOS-shaped pwd inside an aarch64 Debian container, on an Alpine Lima VM, under Rancher Desktop. Containerception.

And the giveaway at the filesystem root:

% ls -la / | head -5
total 68
drwxr-xr-x   1 root root 4096 Aug 15 00:54 .
drwxr-xr-x   1 root root 4096 Aug 15 00:54 ..
-rwxr-xr-x   1 root root    0 Aug 15 00:54 .dockerenv
drwxr-xr-x   3 root root 4096 Aug 15 00:54 Users

/.dockerenv, plus a /Users bind mount recreating just enough of the host path for the system prompt’s cwd to resolve.

The model was not lying; it had no way to know. Its self-description comes from tokens someone else wrote, while the ground truth sits one uname away. The useful lesson is that agent introspection is a documentation lookup, not a measurement — for anything security-relevant, make it run the command.

The sandbox was cco.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #security

git: cd from worktree to main checkout

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 12 Aug 2026 17:22:01 +0200

♠ Previously.

Problem statement: make my cdg shortcut jump from a linked Git worktree back to the main checkout when already at the worktree root.

The shortcut originally stopped at the current checkout’s root:

alias cdg='cd "$(git root)"'

I wanted two consecutive calls from a worktree subdirectory to behave like the following:

worktree/subdirectory
        ↓ cdg
worktree (at the root)
        ↓ cdg
main checkout (at the root)

An alias cannot succinctly express the necessary conditional behavior, whereas an external script cannot change its parent shell’s working directory. A shell function can:

cdg() {
	# This file is sourced by bash and zsh, both of which support local.
	# shellcheck disable=SC3043
	local line main_is_bare main_worktree root worktrees

	root=$(git rev-parse --path-format=absolute --show-toplevel) || return

	if [ "$(pwd -P)" != "$root" ]; then
		cd "$root" || return
		return
	fi

	worktrees=$(git worktree list --porcelain) || return
	main_worktree=
	main_is_bare=false
	while IFS= read -r line; do
		case "$line" in
			worktree\ *) main_worktree=${line#worktree } ;;
			bare) main_is_bare=true ;;
			'') break ;;
		esac
	done <<-EOF
	$worktrees
	EOF

	if [ "$main_is_bare" = false ] && [ -n "$main_worktree" ] && [ "$main_worktree" != "$root" ]; then
		cd "$main_worktree" || return
	fi
}

The first entry from git worktree list --porcelain is the main checkout. At its root, cdg remains a no-op. If that entry is a bare repository, it also stays put instead of entering the Git directory.

— § —

Reply via email

#coding #dev #git

★ cmux: search all windows

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 12 Aug 2026 11:41:09 +0200

♠ Problem statement: given a cmux session with a dozen¹ workspaces, how can you quickly find the one you’re looking for?

Keyboard shortcut (macOS): Cmd + ⌥ + F. Source.

There’s also a system tray icon for cmux with a Search All Windows... menu item.

How did I look this up? Via Kagi Search. My query was cmux search shorcut?.

The question mark (?)² at the end triggers the quick answer feature, including links to sources:

Kagi’s Quick Answer quickly produces a summary of the results across the pages returned and provides references to the pages that are used. This functionality allows you to quickly consume the desired information from the search while giving you the pointers to dive deeper into the information if desired.

Whenever I know exactly the shape of the problem that I want to look up and solve, and whenever it is byte-sized enough, I often resort to this approach; it is very efficient.

In the ~~old~~ pre-LLM days, I would instead scour Stack Overflow or the upstream documentations.

In the early LLM days, I would ask ChatGPT or Duck, but I’d be limited to the training cut-off of the underlying model.

“““This should not happen”””. We’re poor humans with poor attention spans. Managing more than 4-7 workspaces at once is counter-productive due to context switching tax. One should not end up in this situation in the first place. ↩︎
The friction of adding the question mark is important and deliberate, it is what enables the decision to get a digest of ~~slop~~ LLM results. I quite dislike the approach of other search engines, unconditionally shoving questionable AI results on everyone’s face. ↩︎

— § —

Reply via email

#ai #bestof #dev

hwatch

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 11 Aug 2026 01:29:14 +0200

♠ hwatch:

hwatch: alternative watch command with history, diff view, JSONL logging, and change hooks. since 2018.

Or, even better, from its man page hwatch(1):

hwatch is like watch command, repeatedly executes a command and displays its output. However, the output results can be scrolled and displayed. In addition, the difference of the execution result is recorded with the time stamp, and it can be checked later. When checking, it is also possible to display the diff with the previous difference together.

This is the first project I’ve ever stumbled upon that (i) is written in Rust, and (ii) doesn’t brag about being written in Rust. Am I having a dream? Not kidding, there’s not a single mention of Rust in its README.md.

As usual, it is available via your favorite package manager.

I particularly like:

that records the result of command execution, can display it history and diffs […]

A simple way to test it:

% hwatch git status

Then make a silly change like:

% touch foo

It behaves just like vanilla watch(1):

watch runs command repeatedly, displaying its output and errors (the first screenful). This allows you to watch the program output change over time. By default, command is run every 2 seconds and watch will run until interrupted. A header informs of the start and running time of command as well as its exit code.

…plus a few goodies such as history tracking.

h opens a pop-up with in-app keyboard shortcuts¹.

--aftercommand (hook) is also interesting:

% hwatch --aftercommand '/usr/bin/afplay /System/Library/Sounds/Glass.aiff' git st

…makes a chime sound upon each diff².

A poor man’s stopwatch:

% hwatch --aftercommand '/usr/bin/afplay /System/Library/Sounds/Glass.aiff' --interval 1 date

Why not ?? :( ↩︎
There’s also a native --beep option but it did not work in my terminal. ↩︎

— § —

Reply via email

#dev

homebrew: replace deprecated and orphaned packages

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 10 Aug 2026 15:10:42 +0200

♠ Problem statement: brew doctor found one deprecated cask and one installed keg whose formula had disappeared.

tflint #

Warning: Some installed casks are deprecated or disabled.
You should find replacements for the following casks:
flameshot

Warning: Some installed kegs have no formulae!
You should find replacements for the following formulae:
  tflint

Homebrew/core removed TFLint after its executable became subject to both MPL 2.0 and BUSL 1.1. Upstream now maintains terraform-linters/tap as a cask, so migrate the old formula instead of merely reinstalling it:

% brew uninstall tflint
Uninstalling /opt/homebrew/Cellar/tflint/0.61.0... (8 files, 51.8MB)

% brew install terraform-linters/tap/tflint
==> Tapping terraform-linters/tap
Tapped 1 cask (15 files, 14.7KB).
==> Installing Cask tflint
==> Linking Binary 'tflint' to '/opt/homebrew/bin/tflint'
🍺  tflint was successfully installed!

% tflint --version
TFLint version 0.64.0
+ ruleset.terraform (0.15.0-bundled)

Flameshot → Shottr #

The Flameshot cask was deprecated because it does not pass macOS Gatekeeper checks. I replaced it with Shottr:

% brew uninstall --cask flameshot
==> Uninstalling Cask flameshot
==> Removing App '/Applications/flameshot.app'
==> Purging files for version 14.0.0,14.0 of Cask flameshot

% brew install --cask shottr
==> Installing Cask shottr
==> Moving App 'Shottr.app' to '/Applications/Shottr.app'
🍺  shottr was successfully installed!

The corresponding Brewfile change keeps the migration reproducible:

+tap "terraform-linters/tap"

-brew "tflint"

-cask "flameshot"
+cask "shottr"
+cask "tflint"

Both offending entries are now gone:

% brew doctor 2>&1 | grep -E 'flameshot|tflint|deprecated|no formulae'

% brew list --cask | grep -E '^(flameshot|shottr|tflint)$'
shottr
tflint

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #coding #dev #macos

homebrew: turn go install into a formula

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 10 Aug 2026 14:58:29 +0200

♠ Previously.

Problem statement: meat only documents a go install command, but I want Homebrew to manage it¹.

The existing installation lived under $GOPATH:

% go install meat.dev/cmd/meat@latest
% which meat
/Users/thiago.perrotta/go/bin/meat

There are no tags or releases. @latest currently resolves to a Go pseudo-version:

% go list -m -json meat.dev@latest
{
        "Path": "meat.dev",
        "Version": "v0.0.0-20260803201634-f39f41dfe7b5",
        "Query": "latest",
        "Time": "2026-08-03T20:16:34Z",
        "Dir": "/Users/thiago.perrotta/go/pkg/mod/meat.dev@v0.0.0-20260803201634-f39f41dfe7b5",
        "GoMod": "/Users/thiago.perrotta/go/pkg/mod/cache/download/meat.dev/@v/v0.0.0-20260803201634-f39f41dfe7b5.mod",
        "GoVersion": "1.24.13"
}

The pseudo-version gives us commit f39f41dfe7b5; the module’s vanity import page points at github.com/boldsoftware/meat. Hash its source archive:

% curl -LfsS https://github.com/boldsoftware/meat/archive/f39f41dfe7b5.tar.gz -o /tmp/meat.tar.gz
% shasum -a 256 /tmp/meat.tar.gz
faf4831aa3fa866168191b21414698f407f1d473c1572e4cc3942e2c595db6bd  /tmp/meat.tar.gz

We can do better. Let’s create a homebrew package for it. Formula/meat.rb:

class Meat < Formula
  desc "Abridge code diffs into reading diffs"
  homepage "https://meat.dev"
  url "https://github.com/boldsoftware/meat/archive/f39f41dfe7b5b37a12b35fdfbaecc7e779855bd3.tar.gz"
  version "0.0.0-20260803201634-f39f41dfe7b5"
  sha256 "faf4831aa3fa866168191b21414698f407f1d473c1572e4cc3942e2c595db6bd"
  license "Apache-2.0"
  head "https://github.com/boldsoftware/meat.git", branch: "main"

  depends_on "go" => :build

  def install
    system "go", "build", *std_go_args, "./cmd/meat"
  end

  test do
    assert_match "abridge a diff", shell_output("#{bin}/meat --help 2>&1")
  end
end

std_go_args builds the requested package into Homebrew’s bin directory. No manual GOBIN or linker flags needed.

Replace the old binary and let Homebrew take over:

% rm ~/go/bin/meat
% brew install thiagowfx/taps/meat
==> Installing meat from thiagowfx/taps
==> go build ./cmd/meat
🍺  /opt/homebrew/Cellar/meat/0.0.0-20260803201634-f39f41dfe7b5: 6 files, 6.6MB, built in 2 seconds

% which meat
/opt/homebrew/bin/meat
% brew list --versions meat
meat 0.0.0-20260803201634-f39f41dfe7b5

Same binary, now owned by the package manager.

We can trivially uninstall it on-demand:

brew uninstall meat

In 2026 there’s no excuse to ship software with go install. It feels sloppy, unless it’s a prototype or an experimental project. Creating a package is trivial, even without LLMs. ↩︎

— § —

Reply via email

#coding #dev #macos

terraform: fileset does not respect gitignore

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 07 Aug 2026 11:27:13 +0200

♠ Problem statement: a terraform project planned clean locally (terraform plan), but CI insisted on a diff. Every apply fixed it for one side and broke it for the other, back-and-forth.

The culprit was a null_resource that rebuilds an AWS Lambda for a NodeJS app bundle whenever its sources change, keyed on a hash of the whole directory:

resource "null_resource" "lambda_build" {
  triggers = {
    dir_sha = sha256(join("", [for f in sort(fileset("${path.module}/lambda", "**")) : "${f}:${filesha256("${path.module}/lambda/${f}")}"]))
  }

  provisioner "local-exec" {
    command = "cd ${path.module}/lambda && npm ci && npm run build"
  }
}

fileset() walks the filesystem. It has no idea .gitignore exists. So node_modules/ and dist/, present locally after a build, but absent in a fresh CI checkout, creates the discrepancy.

A minimal reproduction test case, with node_modules/ and dist/ gitignored:

% git ls-files lambda | wc -l
2
% echo 'sha256(join("", [for f in sort(fileset("./lambda", "**")) : "${f}:${filesha256("./lambda/${f}")}"]))' | terraform console
"a0af67e204ae2b73a7452d0c2755be1f665b377b5d49e7cc520bd31607adb832"

Then with npm ci && npm run build:

% find lambda -type f | wc -l
4
% git status --porcelain | wc -l
0
% echo 'sha256(join("", [for f in sort(fileset("./lambda", "**")) : "${f}:${filesha256("./lambda/${f}")}"]))' | terraform console
"728a40d04abc2b8292d57465d1f037f833a67d4cc0607a6c64cef487292d9be6"

Git says nothing changed; Terraform says everything did (ugh!).

That’s the issue. CI plans one value, my laptop plans the other, and each apply sets up the next one to “detect drift” again.

Nothing in AWS had changed. The deployed artifact was byte-identical the whole time; only the build trigger churned.

The fix is to hash the build inputs, not the build directory:

dir_sha = sha256(join("", [for f in sort(setunion(
  fileset("${path.module}/lambda", "src/**"),
  ["package.json", "package-lock.json"],
)) : "${f}:${filesha256("${path.module}/lambda/${f}")}"]))

Same value on both sides, and still sensitive to anything that actually matters:

% # dirty tree, after npm ci
"a0af67e204ae2b73a7452d0c2755be1f665b377b5d49e7cc520bd31607adb832"
% # pristine `git archive` checkout
"a0af67e204ae2b73a7452d0c2755be1f665b377b5d49e7cc520bd31607adb832"
% # after editing lambda/src/handler.ts (hypotetically)
"53ef69e287a65f9785cf05985942a5c62a8175348c91c7d9c83039bfc31b8714"

terraform console is the right tool here — it evaluates an expression against the real filesystem without an apply, so both variants can be diffed against a pristine git archive tree and a working one before committing anything.

The general shape: any fileset() over a directory that also holds build artifacts, virtualenvs, or vendored dependencies is environment-dependent, and will read as permanent drift for exactly as long as nobody looks closely.

🤖 Drafted with /bloggify.

— § —

Reply via email

#aws #bloggify #coding #dev #git #terraform

↗ Reply to: The Wisdom Paradox - Sketchplanations

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 07 Aug 2026 10:42:27 +0200

Wisdom is a strange thing.

The Wisdom Paradox is this: when we realise we are less wise than we thought, we become wiser.

[…]

Good judgment comes from experience, and experience comes from bad judgment.

The naivety of youth is a lovely thing. As a teenager, you can be sure that the grown-ups are doing it all wrong, and the path to better is obvious. Then, as an adult, it somehow seems more difficult than before.

Some 20 years ago I became familiar with this principle, and it’s beautiful.

There’s no greater feeling of satisfaction than learning and overcoming your own ignorance.

— § —

Reply via email

#pkm #serenity %commentary

atuin: hooks for LLM agent shell history

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 06 Aug 2026 13:21:31 +0200

♠ Today I learned: Atuin ships hooks that capture commands executed by AI LLM coding agents into the same shell history as mine.

As of today there are hooks for Claude Code, OpenAI Codex and Pi.

% atuin hook --help
Manage AI-agent shell hooks

Usage: atuin hook
       atuin hook <COMMAND>

Commands:
  install  Install hooks for an AI agent to capture commands in atuin history
  help     Print this message or the help of the given subcommand(s)

install --help doesn’t list which agents are supported, but a bogus one does (or simply look at their web documentation):

% atuin hook install invalid-agent
Error: unknown agent: invalid-agent. Supported agents: claude-code, codex, pi

Installing the hook for pi is straightforward:

% atuin hook install pi
pi extension: installed atuin extension

Atuin extension installed for pi. Extension: ~/.pi/agent/extensions/atuin.ts
Reload pi with `/reload` or restart pi.

It drops a small extension that wraps every bash tool call with atuin history start --author pi / history end:

const historyId = await startHistory(pi, ctx.cwd, command);
if (historyId) pending.set(event.toolCallId, historyId);

// ...

await endHistory(pi, ctx.cwd, historyId, exitCodeFromResult(event.result, event.isError));

Commands run by the agent land in the same database as everything typed by hand (by me!); there’s no separate table, just an --author tag:

% atuin search --help | grep -A2 author
      --author <AUTHOR>
          Filter by author. Supports $all-user (non-agents), $all-agent, or literal names.

% atuin search --author pi
% atuin search --author '$all-user'

One shared history to rule them all.

— § —

Reply via email

#ai #claude #coding #dev #pi

dual-review: address review findings automatically

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 05 Aug 2026 14:01:30 +0200

♠ Previously.

My dual-review skill runs two independent LLM reviewers over a commit / diff / PR, validates every finding against the code, and hands back one action plan — Blockers, Important, Suggestions.

Recently I added a flag argument that closes the loop:

 argument-hint: "[branch|staged|all] [--pr NUMBER] [--post]"
+argument-hint: "[branch|staged|all] [--pr NUMBER] [--post] [--address]"

 - `--post`: post final action plan to target pull request after showing it; never post otherwise
+- `--address`: after showing (and, if requested, posting) the action plan, fix Blockers and Important findings directly in the reviewed tree; never fix Suggestions without explicit confirmation

+## 7. Address Findings (only with `--address`)
+
+Skip this section entirely unless `--address` was requested.
+
+1. Work in the same tree that was reviewed (existing worktree or user's checkout for `staged`/`all`); never create a second copy of the changes.
+2. Address every Blocker and every Important finding. For Suggestions, ask the user which (if any) to apply; default to none.
+3. For each finding: re-read the exact `file:line` locations, apply the `Fix:` recommendation, and fix every sibling location listed under that finding, not just the first instance.
+4. If a finding is ambiguous, requires a design decision, or the recommended fix turns out to be wrong once you're in the code, stop and ask the user instead of guessing.
+5. After edits, rerun any locally available checks that cover the change (tests, linters, type-checks) before treating a finding as resolved.
+6. Stage only the files touched while addressing findings. Commit with a message describing which findings were fixed (e.g. `address dual-review findings`), listing them briefly in the body.
+7. If scope was `branch`/`--pr`, push to the branch. If the action plan was posted (`--post`), leave a short follow-up comment noting the findings were addressed and pushed; do not repost the full plan.
+8. Report: which findings were fixed, which were skipped and why, and which need user input.

The important line is the second one: Suggestions never get auto-applied, only Blockers and Important.

/dual-review --post --address now reviews, posts the plan, fixes what’s fixable, and pushes.

Why two review(er)s instead of one? Because LLMs are non-deterministic.

Why not more than two review(er)s then? Tokens ($$$) and time. It’s a balance.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #claude #coding #dev #meta

pi: remove redundant github MCP

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 03 Aug 2026 18:47:51 +0200

♠ Previously.

I’ve finally removed the GitHub MCP server from my Pi configuration, after piloting it for a while with pi-mcp-adapter.

GitHub already has a mature CLI (gh) installed and authenticated:

% gh --version
gh version 2.97.0 (2026-07-31)
https://github.com/cli/cli/releases/tag/v2.97.0

% gh auth status
github.com
  ✓ Logged in to github.com account thiagowfx (keyring)
  - Active account: true
  - Git operations protocol: ssh

gh handles pull requests, issues, workflows, and releases directly. Anything else remains available through gh api, including GraphQL. The MCP server added another interface without adding capability.

 {
   "mcpServers": {
-    "github": {
-      "auth": "bearer",
-      "bearerToken": "!gh auth token",
-      "url": "https://api.githubcopilot.com/mcp"
-    },
     "slack-mcp": {

MCP remains useful for APIs without a better (or any) CLI, but it should be avoided wherever possible.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #dev #pi

DNS: negative cache behind a local resolver

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 31 Jul 2026 14:02:20 +0200

♠ Problem statement: a newly created Route 53 record resolved through public DNS, but ~~Chrome~~ Brave and macOS still returned DNS_PROBE_POSSIBLE.

It smells like a DNS caching issue.

Flushing mDNSResponder did nothing though.

The system resolver was Tailscale’s local DNS proxy, so I asked that resolver rather than trusting dig’s default path:

% dig +time=3 +tries=1 @100.100.100.100 kargo.tools.example-corp.net A +noall +answer +authority +comments
; <<>> DiG 9.10.6 <<>> +time=3 +tries=1 @100.100.100.100 kargo.tools.example-corp.net A +noall +answer +authority +comments
; (1 server found)
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13683
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
tools.example-corp.net. 225 IN SOA ns-1609.awsdns-09.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Route 53’s authoritative nameserver and several public resolvers already had it:

% for resolver in 1.1.1.1 1.1.1.2 8.8.8.8; do
    printf '%-16s ' "$resolver"
    dig +time=2 +tries=1 +short @"$resolver" kargo.tools.example-corp.net A | paste -sd, -
  done
1.1.1.1          192.0.2.11,198.51.100.50,203.0.113.95
1.1.1.2          192.0.2.11,203.0.113.95,198.51.100.50
8.8.8.8          203.0.113.95,198.51.100.50,192.0.2.11

% dig +short @ns-1609.awsdns-09.co.uk kargo.tools.example-corp.net A
192.0.2.11
203.0.113.95
198.51.100.50

Tailscale had cached the previous NXDOMAIN response for a couple of minutes. Its cache is not macOS’s cache; restarting mDNSResponder cannot clear it. Waiting out that TTL fixed the web browser lookup.

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #dev #macos

pi: with free models

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 31 Jul 2026 01:04:23 +0200

OpenRouter #

Today I signed up for OpenRouter.

The Unified Interface For LLMs

Better prices, better uptime, no subscriptions.

Its main selling point is a single LLM API endpoint to rule them all, without lock-in to a specific provider or model.

Upon signing up you’ll get an API Key: sk-or-v1-..., which you’ll save to your password manager. You use one, right?!

The next step is to wire the key to a harness. At this point it’s no surprise I’ve been investing in pi, though OpenCode remains a decent contender.

In pi, run /login, select “Sign in with an API key”, select OpenRouter and then input the key.

Then select a /model. A good starting point is openrouter/free:

The simplest way to get free inference. openrouter/free is a router that selects free models at random from the models available on OpenRouter. The router smartly filters for models that support features needed for your request such as image understanding, tool calling, structured outputs and more.

It’s slow. But it’s free!

Now, interestingly:

User: which model are you?

Assistant: We need to answer user’s question: “which model are you?” According to instructions, we must respond in caveman style? The user asks which model. The system says we are an expert coding assistant within pi. The answer likely: “Opus”. But we need to follow Caveman mode: terse, no filler. So respond something like “Opus model”. Possibly just “Opus”. Let’s output as a plain message. Use normal verbosity for code, but this is not code. So just answer succinctly.

Opus model.

{
    "defaultModel": "openrouter/free",
    "defaultProvider": "openrouter"
}

What if you don’t want OpenRouter?

OpenCode #

Well, there’s OpenCode’s big pickle:

Big Pickle is a stealth model that’s free on OpenCode for a limited time. The team is using this time to collect feedback and improve the model.

% pi -e npm:opencode-pi --provider opencode-cli --model opencode/big-pickle

User: which model are you?

Assistant: big-pickle

— § —

Reply via email

#ai #dev #pi

git: repair unreachable object corruption

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 29 Jul 2026 22:16:46 +0200

♠ Problem statement: git fsck failed in a linked worktree, even though every branch and reflog remained intact.

The initial diagnosis was noisy: missing blobs, hundreds of dangling objects, and an invalid commit graph:

missing blob 97f9a2ed29f84e47848244c2d2626b2536a33c55
error: Could not read 003fb43a3aa361b52f2ab3f27bdabcb9b5137103
failed to parse commit 003fb43a3aa361b52f2ab3f27bdabcb9b5137103 from object database for commit-graph

Worktrees have their own administrative directory but share an object database:

% git rev-parse --git-dir
.git/worktrees/thiagowfx-prm-revenue-tagging
% git rev-parse --git-common-dir
.git

I checked every missing blob against objects reachable from refs and reflogs. None were reachable. Before removing them, I backed up objects, commit graphs, and index:

% common=$(git rev-parse --git-common-dir)
% backup="$common/repair-backup-20260729221124"
% mkdir -p "$backup"
% cp "$(git rev-parse --git-path index)" "$backup/worktree-index"
% ditto "$common/objects" "$backup/objects-before-gc"
% mv "$common/objects/info/commit-graphs" "$backup/commit-graphs"

The index also had an invalid cache-tree entry. Rebuilding it from HEAD preserves working-tree files; comparing its old entries found no staged changes:

% git read-tree HEAD
% GIT_INDEX_FILE="$backup/worktree-index" git ls-files --stage > /tmp/index-before-repair
% join -t $'\t' -v 1 \
    <(awk '{print $4 "\t" $1}' /tmp/index-before-repair | sort) \
    <(git ls-files --stage | awk '{print $4 "\t" $1}' | sort)
% # no output

Then Git could discard unreachable corrupt objects and rebuild its graph:

% git gc --prune=now
% git fsck --full --strict
% echo $?
0
% git fsck --full --no-reflogs --strict >/tmp/fsck
% echo $?
0

The backup remains under .git/repair-backup-20260729221124. fsck is clean; recovery material remains available.

It’s very weird to experience this kind of error. We’re not used to it.

The one trick to remember from this post is git fsck.

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #coding #dev #git

obsidian: logseq-compatible tasks

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 29 Jul 2026 14:34:39 +0200

♠ Previously.

Problem statement: preserve Logseq’s task syntax while opening the same markdown files in Obsidian.

My migration script originally converted every task into Obsidian’s checkbox syntax:

- TODO buy milk     ->  - [ ] buy milk
- DOING ...         ->  - [/] ...
- DONE ...          ->  - [x] ...

Obsidian itself does not recognize the left-hand side as tasks. The TODOseq community plug-in does:

- TODO buy milk
- DOING ...
- DONE ...

It keeps the file unchanged, adds clickable task states and a task list to Obsidian, and remains compatible with Logseq.

Before granting a community plug-in write access to my vault, I inspected the current release with the LLM™:

% git clone --depth=1 https://github.com/scross01/obsidian-todoseq.git /tmp/obsidian-todoseq-audit
Cloning into '/tmp/obsidian-todoseq-audit'...
% cd /tmp/obsidian-todoseq-audit
% git rev-parse --short HEAD
4ba5e81
% jq '{id, version, minAppVersion, description}' manifest.json
{
  "id": "todoseq",
  "version": "0.18.1",
  "minAppVersion": "1.11.0",
  "description": "Lightweight keyword-based task tracker using Logseq style keywords."
}

A source scan found no network requests, telemetry, process execution, or dynamic code evaluation¹.

It does read and modify notes through Obsidian’s vault API, as expected:

% rg -n 'vault\.(read|modify)' src/services/editor-controller.ts | head -4
1130:        const currentContent = await this.plugin.app.vault.read(todayNote);
1135:        await this.plugin.app.vault.modify(todayNote, newContent);
1283:        const todayContent = await this.plugin.app.vault.read(todayNote);
1286:        await this.plugin.app.vault.modify(todayNote, newTodayContent);

Low risk, and no task-format conversion needed.

This should make it easier for me to adapt my LogSeq muscle memory to Obsidian, even if at the cost of enabling community plug-ins.

🤖 Drafted with /bloggify.

Hope is not a strategy. ↩︎

— § —

Reply via email

#bloggify #dev #pkm #security

pi: change directories mid-session

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 29 Jul 2026 14:13:03 +0200

♠ Today I learned: pi 0.82.1 cannot change its working directory mid-session.

The interactive shell syntax looks tempting, but ! and !! run commands in a child process. cd ends with that process; Pi keeps the session’s original cwd. There is no built-in /cd either:

% pi --version
0.82.1
% docs="$(brew --prefix pi-coding-agent)/libexec/lib/node_modules/@earendil-works/pi-coding-agent/docs"
% rg -n 'ctx\.(newSession|switchSession|changeCwd|switchCwd)' "$docs/extensions.md"
1109:### ctx.newSession(options?)
1117:const result = await ctx.newSession({
1187:### ctx.switchSession(sessionPath, options?)
1192:const result = await ctx.switchSession("/path/to/session.jsonl", {
1220:      await ctx.switchSession(choice, {
1247:    await ctx.newSession({
1262:    await ctx.newSession({
% rg -n '^\| `/[^|]+`' "$docs/usage.md" | tail -5
56:| `/share` | Upload as private GitHub gist with shareable HTML link |
57:| `/reload` | Reload keybindings, extensions, skills, prompts, themes, and context files |
58:| `/hotkeys` | Show all keyboard shortcuts |
59:| `/changelog` | Display version history |
60:| `/quit` | Quit pi |

This has been requested several times upstream:

% for n in 2102 2992 3921 4423 6997; do
    gh issue view "$n" --repo earendil-works/pi \
      --json number,title,state,stateReason \
      --jq '[.number, .title, .state, .stateReason] | @tsv'
  done
2102	Allow extensions to change cwd at runtime	CLOSED	COMPLETED
2992	Allow session CWD to be changed	CLOSED	COMPLETED
3921	Feature request: ExtensionCommandContext.changeCwd() for lightweight cwd switching	CLOSED	NOT_PLANNED
4423	Add command API to switch cwd	CLOSED	COMPLETED
6997	Windows Bash inside Pi not working properly	CLOSED	NOT_PLANNED

The exact /cd proposal lives in #3921. The maintainer responses on #2102, #2992, and #4423 capture the trade-off:

#2102 @badlogic: use case makes sense, however, it can be done by overriding the built-in tools to support cwd changes.
#2992 @badlogic: setting a new cwd in a session is not great, as a bunch of things need to be rewired. currently unsupported.
#4423 @badlogic: this is part of the big refactor work and will be available in the new extension api.

That last API still is not exposed in 0.82.1. Changing cwd means rebuilding tools, project settings, extensions, skills, context files, autocomplete, footer state, and session storage—not merely calling process.chdir().

For now, the boring path is the supported one:

/quit
% cd ~/Workspace/perrotta.dev
% pi

Session cwd is a runtime boundary. Oh well.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi

drskill: lint claude skills

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 28 Jul 2026 19:09:34 +0200

♠ I found drskill through Drew Breunig’s post about managing an agent’s loadout.

Problem statement: lint skills bundled in a Claude Code plugin with drskill.

Running it through uvx is easy enough:

% uvx drskill scan --detailed
drskill scan — 3 harnesses (10 more empty), 9 skills
...
0 errors, 5 warnings (5 new) · token counts are approximate

But none of this repository’s 11 skills appeared. The known limitation explains why:

Claude Code skills bundled inside plugins are not scanned yet.

I projected the plugin’s skill directory into the plain .claude/skills layout that drskill understands via Justfile:

# Check skills with drskill
doctor:
    #!/usr/bin/env bash
    set -euo pipefail
    tmp=$(mktemp -d)
    trap 'trash "$tmp"' EXIT
    mkdir -p "$tmp/project/.claude/skills" "$tmp/home"
    for skill in "$PWD"/plugins/thiagowfx/skills/*; do
      ln -s "$skill" "$tmp/project/.claude/skills/$(basename "$skill")"
    done
    uv_cache=$(uv cache dir)
    cd "$tmp/project"
    HOME="$tmp/home" UV_CACHE_DIR="$uv_cache" uvx drskill scan --ci --harness claude-code

The temporary HOME excludes unrelated global skills. Reusing uv’s cache avoids redownloading drskill there. --ci makes warnings fail the recipe.

The first isolated scan found four warnings:

drskill scan — 1 harness, 11 skills

WARNINGS
  [e91d] new frontmatter-angle-brackets: 'bloggify' ...
  [a551] new frontmatter-angle-brackets: 'gha' ...
  [6335] new frontmatter-angle-brackets: 'new-apkbuild' ...
  [206e] new missing-activation: 2 skills never say when to use them ...

0 errors, 4 warnings (4 new) · token counts are approximate
exit=2

The fixes were small: remove angle brackets from argument-hint values and add explicit activation conditions to catchup and handoff:

-argument-hint: "<url>"
+argument-hint: "url"

-description: Create portable handoff document for another agent or harness to continue current work.
+description: Create a portable handoff document for another agent or harness to continue current work. Use when the user asks for a handoff, continuation brief, or context transfer.

Now the repository has its own linter:

% just doctor
drskill scan — 1 harness, 11 skills

No findings.
0 errors, 0 warnings · token counts are approximate

Restoring <url> temporarily made just doctor exit 2 again, so future warnings will break the check. I should add it to CI at some point.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #claude #coding #dev

pi: block dangerous commands syntax-aware

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 28 Jul 2026 10:57:06 +0200

♠ Problem statement: block destructive shell commands issued by pi without resorting to grepping shell source with regular expressions.

My first guard was a direct port of an older hook in Claude Code:

const BLOCKED_COMMANDS: ReadonlyArray<{ pattern: RegExp; reason: string }> = [
  { pattern: /terraform\s+apply/, reason: "terraform apply is blocked - use terraform plan first" },
  { pattern: /terraform\s+destroy/, reason: "terraform destroy is blocked for safety" },
  { pattern: /git\s+reset\s+.*--hard/, reason: "git reset --hard is blocked - discards changes irreversibly" },
];

const blocked = BLOCKED_COMMANDS.find(({ pattern }) => pattern.test(command));

This matched harmless strings such as echo 'terraform destroy', while shell quoting, wrappers, substitutions, and reordered options kept opening holes. Regexes aren’t robust in this context.

Enter ASTs! Shell source could leverage a shell parser.

I switched the extension to the Bash grammar from tree-sitter-bash, loaded through the WASM Tree-sitter runtime:

await Parser.init();
const languagePath = require.resolve("tree-sitter-bash/tree-sitter-bash.wasm");
const language = await Language.load(languagePath);
return new Parser().setLanguage(language);

Tree sitter is an amazing parser.

The policy now works on executable names and arguments:

if (executable === "rm") {
  const recursive = staticArguments.some(
    (argument) => argument === "--recursive" || hasShortOption(argument, "r") || hasShortOption(argument, "R"),
  );
  const force = staticArguments.some(
    (argument) => argument === "--force" || hasShortOption(argument, "f"),
  );
  if (recursive && force) return { command, reason: "rm -rf is blocked for safety" };
}

The AST walker also follows command substitutions, heredocs, bash -c, eval, find -exec, xargs, and common wrappers. Comments and quoted data remain data. Malformed syntax and dynamic guarded arguments fail closed.

ℹ tests 48
ℹ suites 0
ℹ pass 48
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0

Local extensions do not get npm dependencies installed by Pi. I kept index.ts dependency-free: on first load it checks for the parser files, runs a pinned installation when needed, then imports the real guard.

const result = await pi.exec("npm", ["ci", "--ignore-scripts"], {
  cwd: extensionDirectory,
  timeout: 120_000,
});

const { default: dangerousCommandGuard } = await import("./guard.ts");
await dangerousCommandGuard(pi);

Finally, testing the real tool call:

% rm -rf /tmp/foo
rm -rf is blocked for safety
% test -f /tmp/foo/marker && cat /tmp/foo/marker
guard-test

The guard blocked the command; /tmp/foo/marker survived.

The source lives in my dotfiles.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #security

pi: asynchronous exit summaries

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 27 Jul 2026 18:18:38 +0200

♠ Problem statement: ctrl+d in pi took several seconds to quit.

The culprit was pi-memory’s session_shutdown handler. It sent one last LLM request to summarize the session, wrote its answer to the daily log, then ran qmd update. Pi awaits all shutdown handlers, correctly, so quitting waited for everything:

pi.on("session_shutdown", async (event, ctx) => {
  const result = await generateExitSummary(ctx);
  fs.writeFileSync(filePath, entry, "utf-8");
  await runQmdUpdateNow();
});

Making that promise fire-and-forget would not work: Pi exits immediately after shutdown, and either the in-flight request keeps Node alive or gets killed before it can write anything.

Instead, I made the shutdown path write a durable job, synchronously:

const job: ExitSummaryJob = {
  version: 1,
  id: randomUUID(),
  createdAt: new Date().toISOString(),
  date: todayStr(),
  reason,
  sessionId: shortSessionId(ctx.sessionManager.getSessionId()),
  conversationText: truncated.text,
  truncated: truncated.truncated,
  totalChars: truncated.totalChars,
};

const jobPath = path.join(
  EXIT_SUMMARY_JOBS_DIR,
  `${job.createdAt.replace(/[:.]/g, "-")}-${job.id}.json`,
);
fs.writeFileSync(jobPath, `${JSON.stringify(job)}\n`, { encoding: "utf-8", flag: "wx" });

The next interactive session starts an unref’ed worker. It atomically renames one job to claim it, generates summary with active model, writes it back to original day’s daily log, and deletes job. Failed jobs return to queue. A stale claimed job retries after ten minutes.

I kept upstream package intact by replacing it with a local package, effectively forking it:

% pi remove npm:pi-memory
Removed npm:pi-memory
% pi install ~/.pi/agent/local/pi-memory-async
Installed /Users/thiago.perrotta/.pi/agent/local/pi-memory-async
% pi list
User packages:
  local/pi-memory-async
    /Users/thiago.perrotta/.pi/agent/local/pi-memory-async

Jobs live in ~/.pi/agent/memory/exit-summary-jobs/. ctrl+d only writes one JSON file now; summary happens during next session, without blocking exits.

Source code: pi-memory-async.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #pkm

pi: update pinned npm packages

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 27 Jul 2026 14:28:59 +0200

♠ Problem statement: pin pi npm packages without giving up convenient updates.

My settings.json used to leave some package versions unpinned, until now:

     "npm:@heyhuynhgiabuu/pi-diff@0.7.6",
-    "npm:@tifan/pi-recap",
-    "npm:@tmustier/pi-tab-status",
-    "npm:@tintinweb/pi-subagents"
+    "npm:@tifan/pi-recap@0.4.4",
+    "npm:@tmustier/pi-tab-status@0.1.4",
+    "npm:@tintinweb/pi-subagents@0.14.3"

Exact versions make package installation reproducible (& safer), but Pi then does not automatically pull newer packages.

To tackle that, I added a just update-pi recipe that asks npm for each package’s current latest version and writes back an exact pin:

[doc('Update pinned Pi npm packages')]
[group('update')]
update-pi:
    #!/usr/bin/env bash
    set -euo pipefail

    settings="pi/.pi/agent/settings.json"
    updates="{}"
    while IFS= read -r spec; do
        if [[ "$spec" =~ ^npm:((@[^/]+/[^@]+)|([^@]+))(@[^@]+)?$ ]]; then
            package="${BASH_REMATCH[1]}"
        else
            echo "Invalid npm package spec: $spec" >&2
            exit 1
        fi

        latest="$(npm view "$package@latest" version)"
        pinned="npm:$package@$latest"
        updates="$(jq -cn \
            --argjson updates "$updates" \
            --arg spec "$spec" \
            --arg pinned "$pinned" \
            '$updates + {($spec): $pinned}')"
        echo "✓ $pinned"
    done < <(jq -r '.packages[] | select(type == "string" and startswith("npm:"))' "$settings")

    updated_settings="$(jq --argjson updates "$updates" \
        '.packages |= map($updates[.] // .)' "$settings")"
    printf '%s\n' "$updated_settings" > "$settings"

It handles every npm: entry, including scoped packages:

% just update-pi
✓ npm:@heyhuynhgiabuu/pi-diff@0.7.6
✓ npm:@heyhuynhgiabuu/pi-pretty@0.6.20
✓ npm:@tifan/pi-recap@0.4.4
✓ npm:@tmustier/pi-tab-status@0.1.4
✓ npm:@tintinweb/pi-subagents@0.14.3

The aggregate just update recipe invokes it alongside submodule, prek hook, and vendored-file updates.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #security

Anki: archive a deck

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 27 Jul 2026 10:49:00 +0200

♠ Previously.

The Anki official docs do not provide explicit instructions about the archival of decks that are no longer needed.

Archiving is better than deleting because you never know when you may need a deck again.

One way to archive a deck is to simply export it as a backup and save it elsewhere. But then you collection becomes scattered. I’d really like to manage all my decks in a single place.

So I came up with a simple workaround.

First, create an Archive:: subdeck. A subdeck creates a parent-child relationship which, for our purposes, bundles all archived decks within an umbrella parent. It’s visually easier to manage and organize, effectively hiding archived decks from the deck list view.

Second, move the desired deck(s) within Archive::.

Third, one by one, open the cards/notes list (“Browse”) of a deck, select all cards/notes (Cmd-A), then suspend them all (Cmd-J or right click, “Toggle suspend”).

Side effect: cards/notes from the deck will no longer show up for review. At the same time, your past progress is kept, should you ever want to unarchive them.

— § —

Reply via email

#dev #pkm

pi: test drive an extension

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 26 Jul 2026 01:24:35 +0200

♠ Problem statement: using pi, install an extension (package) as an one-off, without persisting it, for the sake of test-driving it, akin to pre-commit try-repo.

Solution:

% pi --help
[...]
--extension, -e <path> Load an extension file (can be used multiple times)
[...]

For example:

% pi -e npm:@tmustier/pi-usage-extension

added 1 package, and audited 2 packages in 1s

found 0 vulnerabilities

…then I can run /usage in that session.

— § —

Reply via email

#ai #dev #pi

obsidian: type * for a bullet point, not ** bold

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 24 Jul 2026 10:04:46 +0200

♠ Problem statement: in Obsidian, out-of-the-box, typing * at the start of a new line emits *|* (an empty bold pair, cursor in the middle) instead of starting a bullet point.

The culprit is Settings → Editor → Auto pair Markdown syntax. With it on, every * auto-inserts its closing *, so a * followed by a space never gets the chance to become a list marker. In fact, we get a bullet point followed by a plain *, which we then have to delete.

To turn this setting off: set Settings → Editor → Auto pair Markdown syntax to off.

Now: * followed by a space at the start of a line converts it to a bullet¹, exactly like - does.

Surely inserting bullet points in Obsidian is a muscle memory artifact from migrating from LogSeq. ↩︎

— § —

Reply via email

#dev #pkm

pi: /btw side-chat

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 22 Jul 2026 14:07:54 +0200

♠ Previously.

Problem statement: mid-task, I want to ask the LLM agent a quick tangential question — “will this change cause downtime?” — without polluting the main agent thread.

Claude Code has /btw¹ for exactly this. pi doesn’t, but patriceckhart/pi-btw does, as an extension. It opens a side-chat overlay: the LLM gets to see the full main thread context and answers, but nothing is written back to the conversation history.

The upstream extension imports the pre-fork @mariozechner/* package names, which are now deprecated. As such, I use earendil-works/pi. Rather than trust a diff I hadn’t read, I reimplemented it against the current API, and cross-checked against the bundled examples/extensions/summarize.ts (the canonical example for calling the model from an extension):

import { complete } from "@earendil-works/pi-ai/compat";
import type { ExtensionAPI, SessionEntry } from "@earendil-works/pi-coding-agent";
import { convertToLlm, getMarkdownTheme } from "@earendil-works/pi-coding-agent";

// ...inside the /btw command handler, once at entry:
const branch = ctx.sessionManager.getBranch();
const mainMessages = branch
  .filter((entry): entry is SessionEntry & { type: "message" } => entry.type === "message")
  .map((entry) => entry.message);
const mainLlmMessages = convertToLlm(mainMessages);   // frozen snapshot
const systemPrompt = ctx.getSystemPrompt();

// ...per question, the side-chat calls the model directly:
const response = await complete(
  ctx.model!,
  { systemPrompt, messages: [...mainLlmMessages, ...btwLlmMessages] },
  { apiKey: auth.apiKey, headers: auth.headers, env: auth.env, signal },
);

The key move is what’s missing: the handler never calls pi.sendMessage() or appends anything. It reads the branch once, talks to the model in an ctx.ui.custom() overlay, and returns. The main session is untouched, so the next real prompt doesn’t pay for any of it.

Added to ~/.pi/agent/extensions/btw.ts.

🤖 Drafted with /bloggify.

I am no longer using Arch, btw (sad!) ↩︎

— § —

Reply via email

#ai #bloggify #coding #dev #pi

pi: auto-retry stalled requests

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 22 Jul 2026 13:45:41 +0200

♠ Previously.

Problem statement: sometimes a prompt in pi just hangs, as if the network dropped. It never recovers on its own — I have to hit Esc and re-prompt.

It’s 2026, this symptom should be self-recoverable.

Pi already has agent-level retry on transient errors (retry.enabled defaults to true). The catch is when it fires: a stalled connection isn’t an error until the HTTP idle timeout trips, and that defaults to five minutes:

httpIdleTimeoutMs | number | 300000 | HTTP header/body idle timeout in milliseconds […] Set to 0 to disable.

So pi would have eventually recovered. I was just quitting long before the five-minute clock ran out. Who has patience to wait for 5 minutes?!

:∴ Lower the idle timeout to O(seconds) instead:

{
  "httpIdleTimeoutMs": 30000,
  "retry": {
    "enabled": true,
    "maxRetries": 5,
    "baseDelayMs": 2000
  }
}

Dropped into ~/.pi/agent/settings.json, documented in docs/settings.md. Now a stall errors out after 30s and pi retries automatically with exponential backoff (2s, 4s, 8s…), up to five attempts. There’s no need for Esc nor re-prompting.

The idle timer resets on every byte received, so long thinking or a slow stream won’t trip it — only a genuinely dead connection will. Restart pi for the change to take effect.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi

pi: cycle models backward with ctrl+n

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 22 Jul 2026 13:23:53 +0200

♠ Previously.

Problem statement: pi binds ctrl+p to app.model.cycleForward¹ by default, but has no default binding to cycle backward other than shift+ctrl+p, which is arguably difficult to remember.

Every keybinding in pi is namespaced and overridable via ~/.pi/agent/keybindings.json, documented in docs/keybindings.md:

{
  "app.model.cycleBackward": [
    "shift+ctrl+p",
    "ctrl+n"
  ]
}

ctrl+n is also the default for app.session.toggleNamedFilter, but that only fires inside the session picker, not while a model selector or the main editor has focus.

Run /reload in pi to pick up the keybinding addition without restarting the session.

∴ ctrl+p/ctrl+n now cycle models forward/backward, matching the readline (emacs!) history bindings I already have muscle memory for.

🤖 Drafted with /bloggify.

It cycles through models selected in /scoped-models. ↩︎

— § —

Reply via email

#ai #bloggify #coding #dev #pi

pi: caveman mode

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 22 Jul 2026 12:14:47 +0200

♠ Previously, previously.

Problem statement: adopt caveman in pi.

Pi isn’t one of the 30+ agents caveman auto-detects. The install matrix (INSTALL.md) lists agent detection rules one by one — claude, cursor, windsurf, opencode, openclaw, etc — and pi isn’t in it. Running the one-liner installer here would just skip everything silently. Booo!

Rather than run someone else’s curl | bash against an agent it wasn’t built for, “““I””” reimplemented the terse-speak part natively, since pi already ships the two primitives needed: skills and extensions.

A skill for /skill:caveman documentation, and an extension that rewrites the system prompt on every turn via pi.on("before_agent_start", (event) => ...):

const INSTRUCTIONS = `Caveman mode: on. Respond terse. Drop articles (a/an/the), filler (just/really/basically), pleasantries, hedging. Fragments OK. Short synonyms. Technical terms exact. Pattern: [thing] [action] [reason]. [next step]. Example — not: "Sure! I'd be happy to help you with that." yes: "Bug in auth middleware. Fix:"
Boundaries, always: code blocks, commit messages, and PR descriptions stay normal full verbosity, never compressed. Drop caveman style for security warnings, irreversible/destructive actions, or when the user seems confused — resume caveman after.`;

export default function (pi: ExtensionAPI) {
  let on = true; // auto-on by default, every session

  const applyStatus = (ctx: { ui: { setStatus: (k: string, v?: string) => void } }) => {
    ctx.ui.setStatus("caveman", on ? "[caveman]" : undefined);
  };

  pi.on("session_start", async (_event, ctx) => applyStatus(ctx));

  pi.on("before_agent_start", (event) => {
    if (!on) return;
    return { systemPrompt: `${event.systemPrompt}\n\n${INSTRUCTIONS}` };
  });

  pi.registerCommand("caveman", {
    description: "Toggle caveman terse-response mode: on|off (default: on)",
    handler: async (args, ctx) => {
      const arg = args.trim().toLowerCase();
      if (arg === "off" || arg === "stop" || arg === "normal") on = false;
      else if (arg === "on" || arg === "") on = true;
      else return ctx.ui.notify(`Unknown arg "${arg}". Use: on | off`, "error");
      applyStatus(ctx);
      ctx.ui.notify(on ? "Caveman mode on." : "Caveman mode off.", "info");
    },
  });
}

before_agent_start fires on every prompt, before the agent loop starts, so the instructions are re-appended each turn instead of relying on one message that could get pruned from context. Dropped in ~/.pi/agent/extensions/caveman.ts, auto-discovered, no /reload needed after the first load.

Unlike the Claude Code plugin, I skipped lite/full/ultra/wenyan — I called that bloat back in June, and I’m not adding it to my own version either. On or off is enough.

The result, unprompted:

user: caveman on or off now?

assistant: Caveman: on.

user: how to turn it off?

assistant: /caveman off

I also skipped the parts that don’t have a pi equivalent: the statusline savings counter, /caveman-stats, the caveman-shrink MCP proxy that rewrites tool descriptions (a proxy that rewrites what an agent sees is exactly the kind of thing worth reading before installing). The 40-line extension above covers what I actually wanted.

One rule baked into both the skill and the extension: code, commits, and PRs stay full verbosity, never compressed.

This experience was an eye-opener for me to realize how bloated the upstream caveman project became.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi

★ logseq → obsidian

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 20 Jul 2026 18:26:33 +0200

♠ Previously.

Problem statement: LogSeq v2 is moving its graph format from markdown files to a sqlite database:

This is not OK for my workflow.

The whole point of adopting LogSeq was, just like Obsidian, the promise of managing my notes in plain markdown files.

Even though this migration is supposed to improve the performance of the app, it ends up breaking a fundamental reason why I decided to use it in the first place.

Furthermore, the Second Brain app of my choice is supposed to be boring. It is a big deal to wake up one day and find that I can no longer open my notes graph with the new version of the app. This is a no-go.

Well, classic LogSeq (dubbed “Logseq OG”) will be kept around, but I can only assume that from this point on it will become poorly maintained — it will never get the same amount of resources and attention as the new version.

Also, even if I really wanted to use the new version, it turns out it does not work on mobile (iOS), which is a dealbreaker, therefore I would be forced to stay stuck with OG for a while. Heck, the iOS app hasn’t been updated in 2y anyway, and it shows.

There will be no hard feelings, this is a peaceful breakup; I enjoyed LogSeq, it’s simpler and more streamlined than Obsidian; as such, I will keep recommending it to most people.

That said, I’ve always been pondering whether to switch back to Obsidian. There’s no doubt that Obsidian is more actively maintained and better suited for Gen AI / LLM workflows these days (see Obsidian CLI for starters).

Why did I switch to LogSeq from Obsidian in the first place? Because Obsidian was too much for me. It was more complicated (in terms of its feature set) than warranted for my purposes. It offered more than I needed. That’s not necessarily a bad thing. It’s like saying (hypothetically) “I prefer nano instead of vim”, or that I prefer to live in a studio apartment than in a 3-bedroom house.

Obsidian won’t let me down in terms of changing its file format: file over app is one of their core promises:

File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read. Use tools that give you this freedom.

File over app is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their data.

This is very important. My Second Brain app must not lock me in. LogSeq, upon the switch to a sqlite database, breaks this invariant. I want — I need — boring markdown files. Do not break the beauty and simplicity of this setup.

Migration #

LogSeq and Obsidian are similar but not identical.

In order to bridge the gap, a small python script (drafted by Claude Fable 5, reviewed by me) walked the existing LogSeq Graph and wrote to a fresh Obsidian Vault, leaving the source untouched, should I decide to roll back.

These are some mappings (LogSeq → Obsidian):

journals/2024_03_04.md         ->  journals/2024-03-04.md
pages/Foo___Bar.md             ->  Foo/Bar.md          (namespaces)
- TODO buy milk                ->  - [ ] buy milk
- DOING ...                    ->  - [/] ...
- DONE ...                     ->  - [x] ...
[[Feb 9th, 2026]]              ->  [[2026-02-09]]
((67ea7dba-3200-...))          ->  [[2025-03-31#^67ea7dba]]
{{embed ((67ea7dba-3200-...))}} -> ![[2025-03-31#^67ea7dba]]
{{video https://...}}          ->  plain URL
id:: 67ea7dba-3200-...         ->  ^67ea7dba block anchor (when referenced)
collapsed:: true, :LOGBOOK:    ->  dropped

Plus one line of config so that the LogSeq journals become Obsidian daily notes:

{
    "folder": "journals",
    "format": "YYYY-MM-DD"
}

…and then I spent some time trying to dumb down Obsidian, disabling core plug-ins I do not need at this time. There’s no need for community plug-ins for now (if ever).

So far, I only migrated my corp (work) notes. I’ll need to migrate my personal PKM as well, but I am happy to simply pilot this migration at work first, so that I don’t get to regret twice.

The migration script:

#!/usr/bin/env python3
"""Migrate LogSeq graph -> Obsidian vault. Source is never modified."""
import re
import shutil
from pathlib import Path

SRC = Path("/Users/thiago.perrotta/Library/Mobile Documents/iCloud~com~logseq~logseq/{redacted}")
DST = Path("/Users/thiago.perrotta/Library/Mobile Documents/iCloud~md~obsidian/{redacted}")

UUID = r"[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
MONTHS = {m: i + 1 for i, m in enumerate(
    ["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"])}

MARKER_MAP = {
    "TODO": "[ ]", "LATER": "[ ]", "WAITING": "[ ]",
    "DOING": "[/]", "NOW": "[/]", "IN-PROGRESS": "[/]",
    "DONE": "[x]",
    "CANCELED": "[-]", "CANCELLED": "[-]",
}


def journal_name(stem: str) -> str:
    return stem.replace("_", "-")


def dest_rel(src_file: Path) -> Path:
    """Map a source md file to its vault-relative destination path."""
    if src_file.parent.name == "journals":
        return Path("journals") / (journal_name(src_file.stem) + ".md")
    # namespace pages: A___B.md -> A/B.md; everything else under pages/
    parts = src_file.stem.split("___")
    return Path(*parts[:-1]) / (parts[-1] + ".md") if len(parts) > 1 else Path("pages") / src_file.name


def page_ref(src_file: Path) -> str:
    """Wiki-link target for a source file (what goes inside [[...]])."""
    if src_file.parent.name == "journals":
        return journal_name(src_file.stem)
    return "/".join(src_file.stem.split("___"))


def collect_ids():
    """uuid -> (link target, anchor) for every id:: definition; also which uuids are referenced."""
    defined, referenced = {}, set()
    for f in sorted(SRC.glob("pages/*.md")) + sorted(SRC.glob("journals/*.md")):
        text = f.read_text(encoding="utf-8")
        for m in re.finditer(rf"^\s*id:: ({UUID})\s*$", text, re.M):
            defined[m.group(1)] = (page_ref(f), m.group(1)[:8])
        for m in re.finditer(rf"\(\(({UUID})\)\)", text):
            referenced.add(m.group(1))
    return defined, referenced


def convert(text: str, defined, referenced) -> str:
    lines = text.split("\n")
    out = []
    in_fence = False
    in_logbook = False

    def resolve_ref(m):
        uuid = m.group(1)
        if uuid in defined:
            target, anchor = defined[uuid]
            return f"[[{target}#^{anchor}]]"
        return m.group(0)

    def resolve_embed(m):
        uuid = m.group(1)
        if uuid in defined:
            target, anchor = defined[uuid]
            return f"![[{target}#^{anchor}]]"
        return m.group(0)

    def date_link(m):
        mon, day, year = m.group(1), int(m.group(2)), int(m.group(4))
        return f"[[{year:04d}-{MONTHS[mon]:02d}-{day:02d}]]"

    pending_merge_indent = None  # indent of an empty bullet awaiting its continuation line

    for line in lines:
        stripped = line.strip()

        # merge continuation text into a bullet whose first line was a property
        if pending_merge_indent is not None:
            m = re.match(rf"^{re.escape(pending_merge_indent)}\s\s?(\S.*)$", line)
            pending_merge_indent = None
            if m and out:
                out[-1] = out[-1] + m.group(1)
                continue

        # LogSeq opens fences on bullet lines ("- ```lang"), closes with bare "```"
        if re.match(r"^\s*(?:[-*+]\s+)?```", line):
            in_fence = not in_fence
            out.append(line)
            continue
        if in_fence:
            out.append(line)
            continue

        # LOGBOOK drawers
        if stripped == ":LOGBOOK:":
            in_logbook = True
            continue
        if in_logbook:
            if stripped == ":END:":
                in_logbook = False
            continue

        # bullet-form property lines: block whose first line is the property itself
        # ("- collapsed:: true" with real content on the continuation line below)
        m = re.match(rf"^(\s*)- (collapsed:: (?:true|false)|logseq\.order-list-type:: number|id:: ({UUID}))\s*$", line)
        if m:
            indent = m.group(1)
            uuid = m.group(3)
            if uuid and uuid in referenced:
                out.append(f"{indent}- ^{uuid[:8]}")
            else:
                out.append(f"{indent}- ")
                pending_merge_indent = indent
            continue

        # property lines
        m = re.match(rf"^\s*id:: ({UUID})\s*$", line)
        if m:
            uuid = m.group(1)
            if uuid in referenced and out:
                # anchor goes at end of the block's first line
                for i in range(len(out) - 1, -1, -1):
                    if out[i].strip():
                        out[i] = out[i].rstrip() + f" ^{uuid[:8]}"
                        break
            continue
        if re.match(r"^\s*collapsed:: (true|false)\s*$", line):
            continue
        if re.match(r"^\s*logseq\.order-list-type:: number\s*$", line):
            # convert the previous bullet line to a numbered item; number it by
            # walking back past deeper lines to the previous same-indent sibling
            for i in range(len(out) - 1, -1, -1):
                bm = re.match(r"^(\s*)- (.*)$", out[i])
                if bm:
                    indent = bm.group(1)
                    n = 1
                    for j in range(i - 1, -1, -1):
                        if not out[j].strip():
                            continue
                        lead = out[j][: len(out[j]) - len(out[j].lstrip())]
                        if len(lead) > len(indent):
                            continue  # child or continuation line
                        if lead == indent:
                            nm = re.match(rf"^{re.escape(indent)}(\d+)\. ", out[j])
                            n = int(nm.group(1)) + 1 if nm else 1
                        break
                    out[i] = f"{indent}{n}. {bm.group(2)}"
                    break
            continue

        # task markers on bullet lines (not headings)
        line = re.sub(
            r"^(\s*)- (TODO|LATER|WAITING|DOING|NOW|IN-PROGRESS|DONE|CANCELED|CANCELLED)\s+",
            lambda m: f"{m.group(1)}- {MARKER_MAP[m.group(2)]} ",
            line,
        )

        # drop LogSeq priority markers
        line = re.sub(r"\[#[A-C]\]\s*", "", line)

        # embeds and block refs
        line = re.sub(rf"\{{\{{embed \(\(({UUID})\)\)\}}\}}", resolve_embed, line)
        line = re.sub(r"\{\{embed \[\[([^]]+)\]\]\}\}", r"![[\1]]", line)
        line = re.sub(rf"\(\(({UUID})\)\)", resolve_ref, line)
        line = re.sub(r"\{\{video ([^}]+)\}\}", r"\1", line)

        # date links: [[Feb 9th, 2026]] -> [[2026-02-09]]
        line = re.sub(
            r"\[\[(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) (\d{1,2})(st|nd|rd|th), (\d{4})\]\]",
            date_link, line)

        # asset paths
        line = line.replace("](../assets/", "](assets/")

        out.append(line)

    result = "\n".join(out)
    if result.strip() == "-":  # LogSeq empty-page placeholder
        result = ""
    return result


def main():
    defined, referenced = collect_ids()
    orphans = referenced - set(defined)
    if orphans:
        print(f"WARNING: refs without target: {orphans}")

    written = 0
    for f in sorted(SRC.glob("pages/*.md")) + sorted(SRC.glob("journals/*.md")):
        rel = dest_rel(f)
        dst = DST / rel
        dst.parent.mkdir(parents=True, exist_ok=True)
        dst.write_text(convert(f.read_text(encoding="utf-8"), defined, referenced),
                       encoding="utf-8")
        written += 1

    assets_dst = DST / "assets"
    assets_dst.mkdir(exist_ok=True)
    copied = 0
    for a in SRC.glob("assets/*"):
        if a.name == ".DS_Store":
            continue
        shutil.copy2(a, assets_dst / a.name)
        copied += 1

    print(f"wrote {written} notes, copied {copied} assets")


if __name__ == "__main__":
    main()

— § —

Reply via email

#ai #bestof #dev #pkm #serenity

Sports.app

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 20 Jul 2026 11:35:19 +0200

♠ The recently released Apple Sports app was surely a great way to keep up with the World Cup on the go.

It is very polished; it does one thing, and does it well. Simple yet effective. I do recommend it.

It’s especially handy when you’re not able to watch a match live for whatever reason.

If you’re able to watch a match in real time then it’s better to leave your phone in airplane mode, otherwise chances are you’ll get a goal notification from the app before you get to see it on the TV due to broadcasting delays. Wild.

— § —

Reply via email

#serenity

brew pin

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 18 Jul 2026 14:53:04 +0200

♠ TIL: brew pin.

For reasons to be elaborated in another post, I am currently prevented from upgrading LogSeq to its latest version in homebrew:

% brew outdated
[...]
logseq (0.10.14) != 2.0.1
[...]

LogSeq v2 introduces breaking changes to my workflow. I found this out the hard way. As put by Valodim in HN:

And now after several years of complete stagnation, the supposed improvement is a database format to fix their technical issues, so I can no longer keep all my data as markdown files? At a time when half the edits are done by Claude and tracked with jujustu, this is just not useful for me.

All I wanted was the original vision, but with less bugs and more quality of life features.

As such, I would like to settle in the current version for now. Pinning to the rescue!

% brew pin logseq
Warning: logseq has `auto_updates true` and may update itself outside Homebrew despite being pinned.

% brew list --pinned
logseq

% brew outdated
[...]
logseq (0.10.14) != 2.0.1 [pinned at 0.10.14]
[...]

That’s all.

To unpin it in the future:

% brew unpin logseq

— § —

Reply via email

#dev #macos #pkm

★ The lifecycle of physical books

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 18 Jul 2026 14:21:02 +0200

♠ Typically:

Step 1: buy a physical book — via Amazon, bookstores, classifieds marketplaces (e.g. Craigslist in the US, Kijiji in Canada, Kleinanzeigen in Germany). Bonus points for used copies. This should take up to a week.
Step 2: read the ~~goddamn~~ book. This is arguably the hardest part, albeit the most exciting one. As Alex Kotliarskyi puts it (emphasis mine):

The 80/20 rule says that 80% value come from 20% effort. What if we apply the 80/20 rule to the first 80%?

So 80% of 80% of value come from 20% of 20% of effort. Or 64% of the value come from 4% of the effort. Apply it again and you’ll get ~51% value from ~1% effort. Which is ballpark close to “Dimidium facti, qui coepit, habet” — Well begun is half done.

Once you start, it becomes much easier to go through it, I promise.

Step 3: Find a way to get rid of the book.

There’s no shame. Have gratitude, appreciate it, and then simply move on. I don’t like to stick with physical books forever. They unnecessarily occupy space in my home.

There are various ways to do so:

Donating is the easiest. Leave books by the vestibule of your apartment building complex with a post-it note stating that it’s free¹.
Leave books in public community bookshelves or libraries.
Gift a book to a friend. Bonus points for being thoughtful.
Sell a book in a classified site. Bonus points for using the same one you got it from.

And now, adding the missing alternative to my repertoire:

momox:

Schnell & einfach Gebrauchtes verkaufen Was möchtest du verkaufen? Bücher & Medien Kleidung

Momox is

a Berlin-based recommerce site for used books and media founded by Christian Wegner in 2004.

In plain English: it’s like selling a book in a classified, but without having to wait for someone to actually message you².

Scan or input its ISBN, get an estimate of how much you’ll get for it (assuming it’s in good condition), arrange a box, pack the book, ship it for free, wait, and then get paid. It’s very streamlined and easy to use.

So far, I’ve only heard of this concept in Germany. I would love to find out if it’s possible to follow suit in other countries.

Zu verschenken, as they say it auf Deutsch. In plain English, “for free” suffices. ↩︎
And eventually lowball or flake on you. ↩︎

— § —

Reply via email

#bestof #serenity

★ Project Aces OST

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 17 Jul 2026 12:52:54 +0200

♠ Project Aces (from the Ace Combat series) has one of the best videogame OSTs ever.

I am¹ finally pleased² to find their whole collection available on Spotify as of 2026. Previously, only a handful of them were available.

No more fiddling random playlists on YouTube Music!

myrepos: a wip action to find unfinished work

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 17 Jul 2026 12:23:10 +0200

♠ Previously.

Problem statement: I manage a few dozen repos via myrepos (mr), and I wanted a single command to show which ones have work in progress (“WIP”) — uncommitted changes, dirty staging area, stray branches and alike.

I want essentially a filtered version of mr ls.

So I defined my own command. A repo is not WIP when all three hold:

the default branch is checked out;
no other local branches exist;
and the working tree is fully clean.

Anything else gets flagged with a reason.

The definition:

# List repos with work in progress: not on default branch, extra local branches, or dirty tree.
# Run as `mr -m wip`: the -m (minimal) flag drops mr's per-repo "mr wip:" header and blank
# lines, leaving only the flagged repos. This cannot be defaulted per-action (mr only honors
# -m/-q as CLI flags, not via config).
wip =
 reasons=""
 cur=$(git symbolic-ref --quiet --short HEAD 2>/dev/null || echo "(detached)")
 def=$(git symbolic-ref --quiet --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')
 if [ -z "$def" ]; then if git show-ref --verify --quiet refs/heads/main; then def=main; elif git show-ref --verify --quiet refs/heads/master; then def=master; fi; fi
 if [ -n "$def" ] && [ "$cur" != "$def" ]; then reasons="$reasons branch:$cur"; fi
 n=$(git for-each-ref --format='%(refname)' refs/heads | wc -l | tr -d ' ')
 if [ "$n" -gt 1 ]; then reasons="$reasons +$((n-1))_branches"; fi
 if [ -n "$(git status --porcelain)" ]; then reasons="$reasons dirty"; fi
 if [ -n "$reasons" ]; then printf '%s [%s]\n' "$MR_REPO" "${reasons# }"; fi

Naturally, the snippet above is art from the LLM, but it accomplishes exactly what I want:

thiago.perrotta ~
% mr -m wip
mr wip: /Users/thiago.perrotta/Corp/gitops
/Users/thiago.perrotta/Corp/gitops [branch:thiagowfx/acme +1_branches]

mr wip: /Users/thiago.perrotta/Corp/terraform
/Users/thiago.perrotta/Corp/terraform [+1_branches]

mr wip: /Users/thiago.perrotta/workspace/perrotta.dev
/Users/thiago.perrotta/workspace/perrotta.dev [+3_branches dirty]

Clean repos stay silent. I get to see all repos with unfinished work, and I can see exactly why each one is dirty.

mr wip works too but it’s noisier. I need to add mr -m wip to my muscle memory¹. Without the -m flag, mr prepends a mr wip: header and a blank line for every repo, WIP or not.

-m can’t be baked into the action definition — mr only honors it as a CLI flag — so the comment above the action documents it.

Previously I’d run mr xl (an alias for git branch -vv across every repo) and eyeball the result — but that’s dozens of lines of branch tips for tens of repos, and I still have to scan for the ones that are actually behind or dirty. wip does the scanning: it only prints the repos that need attention, with the reason attached. Much more ergonomic than visually diffing a wall of green.

Runs read-only, so it’s safe to run twice.

🤖 Drafted with /bloggify.

Should I rely on this workflow more often, I could leverage Espanso or a shell alias/function to easen its recall. ↩︎

— § —

Reply via email

#bloggify #coding #dev #git

safari: (permanently) allow pop-ups for a domain

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 16 Jul 2026 14:01:29 +0200

♠ Problem statement: a site / domain needs pop-ups for OAuth / logins, but I don’t want to disable Safari’s pop-up blocker globally just to appease a couple of domains.

Safari lets one scope the exception on a per-site basis. The domain has to be open in a tab first, so that its entry shows up in the list:

Open the site in a new tab.
Click Safari → Settings → Websites → Pop-up Windows (left sidebar).
Find the domain under “Currently Open Websites” and set it to Allow.

The blocker stays on everywhere else, as it should be.

The default at the bottom (“When visiting other websites”) is the global toggle; leave it on Block and Notify so only the sites I’ve whitelisted get through.

That per-site list is the same panel that governs camera, microphone, location, and auto-play permissions.

— § —

Reply via email

#macos #privacy

claude code: replace a hand-rolled loop with /goal

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 16 Jul 2026 13:44:25 +0200

♠ Previously.

Problem statement: one of my skills, /pr-pass, was a hand-rolled loop — push, poll CI, fix a failure, re-push, repeat, bail after five iterations.

It works quite well, and it’s one of my most used skills.

That said, recently Claude Code shipped /goal (in v2.1.139), which is exactly that loop, packaging it as a primitive. So the skill was reimplementing something the harness now does natively.

In fact, most harnesses ship /goal natively these days.

We shall refactor!

/goal sets a completion condition. After each turn a fast model checks whether it holds; if not, Claude starts another turn on its own. It auto-clears once the condition is met. From the docs:

The /goal command sets a completion condition and Claude keeps working toward it without you prompting each step. After each turn, a small fast model checks whether the condition holds. If not, Claude starts another turn instead of returning control to you.

That deletes three things the old skill hand-built: the Monitor poll waiting on CI state, the “go back to Step 1” loop, and the max-5-iterations guard. The guard becomes a clause in the condition itself:

/goal every check on this PR has passed (gh pr checks shows no FAILURE
and no PENDING), or stop after 5 turns

One catch worth knowing before reaching for /goal: the evaluator (tester?) is a fresh model that only reads the transcript. It does not run gh or read files.

It does not call tools, so it can only judge what Claude has already surfaced in the conversation.

So the condition has to be something Claude’s own output demonstrates. The skill now says to paste the gh pr checks result into the reply every turn, so the evaluator has a CI state to judge against. Otherwise the goal would have never resolved thus it would have looped forever.

Another gotcha: /goal doesn’t touch permissions. Each turn’s git push still prompts unless paired it with auto mode.

The lesson generalizes past this one skill: whenever the harness grows a primitive, the custom code that predates it becomes technical debt. /loop, Stop hooks, and /goal now cover most of the “keep going until X” constructs I used previously.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #claude #coding #dev