¬ just serendipity 🍀

ssh: pipe SQL through doas with base64

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 29 Aug 2026 02:44:43 +0200

♠ Problem statement: nested shell quotes made a remote PostgreSQL update harder to run than the update itself.

The target is an Alpine Linux host. Its Miniflux configuration contains the database connection string, so psql must run after sourcing /etc/miniflux.conf through doas.

An inline command quickly becomes a quoting puzzle. SQL contains single quotes, Unicode, and sometimes apostrophes. The local shell also expands unquoted characters before ssh sends anything to the server.

I wrote SQL to a temporary file, encoded it locally, and sent only base64 over SSH:

% base64 /tmp/miniflux-flags.sql | tr -d '\n' | \
  ssh knol 'doas sh -c '\''
    . /etc/miniflux.conf
    base64 -d | psql "$DATABASE_URL" -X -v ON_ERROR_STOP=1
  '\''

Remote shell receives a simple command. base64 -d reconstructs SQL on the server. psql reads it from standard input. ON_ERROR_STOP=1 makes a SQL error stop the command instead of continuing to later statements.

The file contained real, guarded updates:

BEGIN;
UPDATE feeds SET title = title || ' 🇺🇸'
WHERE id = 1394 AND title = 'furbo.org: Craig Hockenberry'
RETURNING id, title;
UPDATE feeds SET title = title || ' 🇨🇦'
WHERE id = 1406 AND title = 'Ansuz: Matthew Skala'
RETURNING id, title;
UPDATE feeds SET title = title || ' 🇬🇧'
WHERE id = 1411 AND title = 'Ian Jackson'
RETURNING id, title;
-- eight more exact-title guards
COMMIT;

The remote output stayed useful:

BEGIN
 id  |              title
-----+---------------------------------
1394 | furbo.org: Craig Hockenberry 🇺🇸
(1 row)
UPDATE 1
...
UPDATE 1
COMMIT

A second query verified every ID after commit:

 id  |              title
-----+---------------------------------
1394 | furbo.org: Craig Hockenberry 🇺🇸
1406 | Ansuz: Matthew Skala 🇨🇦
1411 | Ian Jackson 🇬🇧
1444 | Matthew Garrett: mjg59 🇬🇧
1459 | Cloudscaling by Randy Bias 🇺🇸
1460 | Marcin Juszkiewicz 🇵🇱
1464 | Liss is More by Casey Liss 🇺🇸
1472 | Jerod Santo 🇺🇸
1482 | Matthias Kirschner 🇩🇪
1545 | Charles Leifer 🇺🇸
(10 rows)

Base64 does not encrypt anything. It only moves one opaque payload through several shells. That is enough to keep local parsing away from SQL.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #dev #linux #ssh

blog: calendar view

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 29 Aug 2026 02:12:41 +0200

♠ Problem statement: my blog archive was useful, but did not show its posting pattern over time.

I liked Jim Nielsen’s calendar view, so I added one too. List remains better for finding a post. The new calendar is for seeing when I published.

The calendar and list use one filter. Coding, recipes, and RSS-only posts stay out of both:

{{- $pages := where .pages "Site.Language.Lang" .lang -}}
{{- $pages = where $pages "Kind" "page" -}}
{{- $pages = where $pages "Params.rss_only" "!=" true -}}
{{- $excludeCategories := slice "coding" "recipes" -}}
{{- $pages = where $pages "Params.categories" "intersect" $excludeCategories | symdiff $pages -}}
{{- return $pages -}}

I group posts by ISO date. A day gets a blue dot. A day with a bestof post gets a yellow star. Clicking it shows every post from that date:

{{- $postsByDate := newScratch }}
{{- range $pages }}
  {{- $key := .Date.Format "2006-01-02" }}
  {{- $dayPages := $postsByDate.Get $key | default (slice) }}
  {{- $postsByDate.Set $key ($dayPages | append .) }}
{{- end }}

<details class="calendar-day calendar-day--has-post">
  <summary>
    <span class="calendar-day--post{{ if $featured }} calendar-day--featured{{ end }}">
      {{ if $featured }}<span class="calendar-day--featured-icon">★</span>{{ end }}
    </span>
  </summary>
  <div class="calendar-popover">
    {{- range $dayPages }}
    <a href="{{ .Permalink }}">
      <span>{{ if in .Params.tags "bestof" }}★ {{ end }}{{ .Title }}</span>
    </a>
    {{- end }}
  </div>
</details>

It has English, Portuguese, and Italian month labels. The marker target is 24 pixels tall, and mobile uses two month columns:

.calendar-day--has-post summary {
  width: 100%;
  min-height: 24px;
}

@media (max-width: 600px) {
  .calendar-months {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

% git show --stat --oneline 9c1db78581
9c1db78581 calendar
11 files changed, 388 insertions(+), 33 deletions(-)

% hugo --environment production
                   │  EN  │ PT  │ IT
───────────────────┼──────┼─────┼────
 Pages             │ 2968 │ 225 │ 21
Total in 8080 ms

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #dev #meta

★ miniflux: add country flags to all feeds 🌐

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 28 Aug 2026 01:20:26 +0200

♠ Problem statement: given my miniflux server with hundreds of RSS feed subscriptions, add emoji country flags to each feed title, representing their country of origin and/or the country they’re associated with¹.

For example:

Before: Not Just Serendipity by Thiago Perrotta
After: Not Just Serendipity by Thiago Perrotta 🇧🇷🇨🇦

Some feeds may be identified with multiple flags. The distinction is purposely loose.

I started to do this tagging process manually, throughout several weeks, until I exhausted the ones I knew about.

The next natural step, in 2026, is to resort to Gen AI to finish the heavy lifting, now that the initial pattern has been established.

With my OpenAI Codex subscription and pi, I prompted away:

User: List all prompts I ran in this session, bulleted list:

Thinking: Listing all user prompt messages

“Are you able to connect to my miniflux database in knol? (ssh knol) Creds are in /etc/miniflux.conf in knol.”

“Note that Alpine Linux uses doas, not sudo.”

“Are you able to find my list of subscriptions / feeds? There should be 687 of these.”

“Observe that some feed titles have flags in them.”

“I want to add a flag for the origin of each blog. Source a few feeds lacking flags and suggest which flags to add.”

“LGTM.”

“Source 10–15 more blogs.”

“LGTM.”

“Write a blog post about this work using /bloggify.”

“List all prompts I ran in this session, bulleted list.”

Here are a few interesting bits produced by the agent. Note that I run the coding harness (pi) from my laptop, not from my server. As such, all commands that interact with the server do so via ssh. This is good enough for my purposes.

Count all feeds:

% ssh knol 'doas sh -c '\''. /etc/miniflux.conf; psql "$DATABASE_URL" -X -Atqc "SELECT count(*) FROM feeds"'\'''
687

Some titles already followed the convention:

780|37signals jobs 🇩🇰🇺🇸
818|A cup of coffee by Quentin JOLY 🇫🇷
1366|AI Engineer Guide 🇮🇳
562|Adam Gordon Bell: Cascade Of Insights 🇨🇦
916|Adam Johnson 🇬🇧

A pair of Unicode regional indicators forms a flag. Export the titles and count those pairs:

% ssh knol 'doas sh -c '\''. /etc/miniflux.conf; psql "$DATABASE_URL" -X -q -c \
  "COPY (SELECT id, title FROM feeds ORDER BY title) TO STDOUT WITH CSV"'\''' | \
  python3 -c 'import csv,sys,re; rows=list(csv.reader(sys.stdin)); p=re.compile(r"[\U0001F1E6-\U0001F1FF]{2}"); found=[(i,t,p.findall(t)) for i,t in rows if p.search(t)]; print(f"feeds_with_flags={len(found)} flags={sum(len(x[2]) for x in found)}")'
feeds_with_flags=148 flags=158

I did not infer origin from a name, domain, language, or current residence. Each addition needed an explicit source. For example, Jeremy Keith says “I’m from Ireland originally”, Andre Garzia says he is originally from Brazil, and Christian Rebischke describes himself as being from Germany.

The title itself is the metadata. Exact old-title guards made each update idempotent and prevented an accidental edit to a renamed feed:

BEGIN;
UPDATE feeds
SET title = 'Christian Rebischke: shibumi 🇩🇪'
WHERE id = 207 AND title = 'Christian Rebischke: shibumi';
UPDATE feeds
SET title = 'Adactio: Journal by Jeremy Keith 🇮🇪'
WHERE id = 1106 AND title = 'Adactio: Journal by Jeremy Keith';
UPDATE feeds
SET title = 'Adactio: Articles by Jeremy Keith 🇮🇪'
WHERE id = 1107 AND title = 'Adactio: Articles by Jeremy Keith';
UPDATE feeds
SET title = 'Andre Alves Garzia 🇧🇷'
WHERE id = 1481 AND title = 'Andre Alves Garzia';
COMMIT;

BEGIN
UPDATE 1
UPDATE 1
UPDATE 1
UPDATE 1
COMMIT

A second sourced batch added 12 more titles. Compound origins stay compound:

430|Burak Karakan: ps 🇩🇪🇹🇷
1022|Amjad Masad 🇯🇴🇺🇸
1076|Christopher Olah 🇨🇦
1100|Cognitive Medium by Michael Nielsen 🇦🇺🇺🇸
1174|Andrej Karpathy 🇸🇰🇨🇦
1489|Jeff Geerling 🇺🇸

The same audit now reports:

total=687
feeds_with_flags=164
flags=178
without_flags=523

Only 523 to go.

This is a practical excuse to tokenmaxx, eh?!

Web searches are done with pi-web-search. ∎

Why? Purely as a matter of context, and for an extra dose of serendipity via diversity. For example, it’s often exciting to me to read posts from other Canadians, for no particular reason. ↩︎

— § —

Reply via email

#bestof #dev #selfhosted

claude code: /goal

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 26 Aug 2026 17:45:34 +0200

♠ Problem statement: a coding agent stops when it thinks it is done, not when the thing is actually done.

/goal sets a condition that outlives the turn. The docs call it a wrapper around a session-scoped, prompt-based Stop hook: every time the agent tries to end its turn, an evaluator checks the condition and pushes back if it does not hold.

/goal argocd, prometheus and external secrets should all be healthy and synced in cluster #26

I set that mid-session while debugging a cluster where three Argo CD apps were stuck. What followed was the useful part. The agent wrapped up with a tidy summary and two pull requests, and got this back:

Stop hook feedback:
[argocd, prometheus and external secrets should all be healthy and synced in cluster #26]:
PRs #3064 and #3062 have been opened but not yet merged. The latest status check
in the transcript confirms external-secrets = 'OutOfSync', argocd = 'OutOfSync',
prometheus = 'Unknown' — none are both 'healthy and synced'.

Opening a PR is not the same as the apps being green, and the evaluator reads the transcript rather than the closing paragraph. It fired three times. Each time the summary was plausible and each time the condition was still false.

/goal with no arguments shows the condition, elapsed time, turn count, token spend, and the evaluator’s last reason. /goal clear ends it.

The failure mode it fixes is specific: an agent that declares victory one step early. It does not make the agent smarter — mine still burned several turns on wrong theories, and I had to redirect it more than once. It only refuses to let “I opened a PR” stand in for “the apps are green”.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#ai #argocd #bloggify #claude #dev #kubernetes

Continuity

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 25 Aug 2026 15:40:59 +0200

♠ A serendipitous discovery: macOS continuity.

Picture this:

I am using my corp Macbook Pro, whilst my personal Macbook Air happens to be close by. Both of their lids are open.

In my corp Macbook, for some reason, I decided to move the mouse cursor to the edge of the laptop screen, using the trackpad.

And then, just like magic, the mouse cursor in my personal Macbook starts to move around.

And then I open up a terminal and start to type, from my corp Macbook, and somehow characters start to appear in my personal Macbook.

Remote trackpad + keyboard control. This is amazing!

This post was created in my personal Macbook, typed from my corp keyboard.

Naturally, I am signed into my Apple ID in both devices. ∎

— § —

Reply via email

#dev #macos #serenity

pi: prompt template or skill?

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 25 Aug 2026 01:13:46 +0200

♠ Problem statement: I often type commit (only) what you changed in coding agent harnesses. Can I make an abbreviation out of it?

Pi turns a Markdown file in ~/.pi/agent/prompts/ into a /slash command. This one gives me /commit:

---
description: Commit files changed in this turn without pushing
---
Commit what you changed (only). DO NOT push.

% find ~/.pi/agent/prompts -maxdepth 1 -type f -print -exec sh -c 'printf "%s\n" "--- $1"; cat "$1"' _ {} \;
/Users/thiago.perrotta/.pi/agent/prompts/commit.md
--- /Users/thiago.perrotta/.pi/agent/prompts/commit.md
---
description: Commit files changed in this turn without pushing
---
Commit what you changed (only). DO NOT push.

In Pi, a prompt template is fixed prompt expansion. It is right for a short, stable request:

Prompt templates are Markdown snippets that expand into full prompts. Type /name in the editor to invoke a template, where name is the filename without .md.

A skill is a capability package. Its description is available at startup, but Pi loads its SKILL.md only when task matches or I run /skill:name. A skill can carry scripts, references, setup, and a workflow that branches on state:

Skills are self-contained capability packages that the agent loads on-demand. A skill provides specialized workflows, setup instructions, helper scripts, and reference documentation for specific tasks.

A commit flow with checks, generated files, partial staging rules, or project specific policy deserves a skill. This one is a couple of words and one constraint, so I choose to keep it simple. ∎

— § —

Reply via email

#ai #dev #pi

terrateam: plan from drift issues

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 24 Aug 2026 18:38:39 +0200

♠ Problem statement: Terrateam opens drift reports as GitHub issues, but terrateam plan only works on pull requests.

The distinction is explicit in Terrateam’s issue comment handler:

{ primary = Primary.{ number = pull_request_id; pull_request = Some _; _ }; _ };

| Gw.Issue_comment_event.Issue_comment_created _ ->
    Logs.debug (fun m -> m "%s : NOOP : ISSUE_COMMENT_CREATED" request_id);
    Prmths.Counter.inc_one (Metrics.comment_events_total "noop");
    Abbs_future_combinators.return_ok ()

Calling the repository workflow directly was not an option either. Its work token comes from the Terrateam backend.

So I kept Terrateam in charge and gave it the pull request it expects. A GitHub Actions relay checks that the source is an open Terrateam drift issue and that the commenter has repository write access. It then puts a comment-only Terraform file in each selected drift directory:

markers = [
    InputGitTreeElement(
        path=f"{directory}/terrateam_issue_relay.tf",
        mode="100644",
        type="blob",
        content=f"# Terrateam plan relay for drift issue #{issue_number}, comment {comment_id}.\n",
    )
    for directory in directories
]

That path change gives Terrateam a real dirspace without changing infrastructure. The relay opens a temporary draft PR and posts the original command on it:

pull = repo.create_pull(
    base=repo.default_branch,
    head=branch,
    title=f"Terrateam plan relay for drift issue #{issue_number}",
    body=relay_body(issue_number, comment_id, event["comment"]["html_url"]),
    draft=True,
)
pull.as_issue().create_comment(command)

Terrateam uses its normal locks, hooks, credentials, and batching. Another workflow copies its comments back to the drift issue. apply remains unsupported: an issue has no PR approval or review intent.

The live test planned the requested directory and returned the result:

## Plans :thumbsup:

## Terrateam Plan Output :thumbsup:

**Plan: 0 to add, 8 to change, 0 to destroy**

The temporary PR ended where it should:

% gh pr view 6687 --json number,state,headRefName,title
{"headRefName":"bot/terrateam-issue-relay/6663-5398113346","number":6687,"state":"CLOSED","title":"Terrateam plan relay for drift issue #6663"}

% ./ci/run_python_tests.sh ci/terrateam_issue_relay
collected 19 items
tests/test_relay.py ...................                                  [100%]
============================== 19 passed in 1.45s ==============================

A scheduled job deletes inactive relay branches after 30 hours. Terrateam still owns plan execution; the relay only translates the issue command into its existing PR protocol.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #dev #terraform #terrateam

★ Books

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 24 Aug 2026 18:28:31 +0200

♠ It’s about time: I added a books page to this blog with a sample of my favorites. ∎

— § —

Reply via email

#bestof #serenity

bloggify, revisited

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 24 Aug 2026 01:21:57 +0200

♠ Yours truly, more than two months ago:

As of today, it’s not clear to me whether this approach will stick.

Clearly this approach is here to stay: bloggify (40+ posts at the time of this writing).

I am starting to ponder whether to split /bloggify posts into an Agent Blog:

These posts are written by my agents, not by me.

We’ll see. ∎

— § —

Reply via email

#ai #bloggify #dev #serenity

pi: statusline with GitHub PR link

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

♠ Previously.

Problem statement: the @narumitw/pi-github-pr statusline entry reports much more than I care about:

PR #123: checks failing (2), changes requested, 3 comments

I want the clickable PR link and nothing else. Checks live in gh pr checks, comments live on GitHub, they are the source of truth.

There’s no knob for it in this particular pi extension. The wording is hardcoded in formatCompactStatus(), and the single option the extension takes (refreshIntervalMs) is unreachable, because pi calls the default export with pi alone. Nothing lighter exists on the registry either — everything else is a full footer replacement:

% for q in "pi-extension%20pull%20request" "pi-extension%20statusline"; do
    curl -s "https://registry.npmjs.org/-/v1/search?text=$q&size=25" |
      jq -r '.objects[].package | select(.name | test("^(@[^/]+/)?pi-")) | "\(.name) — \(.description)"'
  done | grep -iE "pull request|statusline|footer" | sort -u
@feniix/pi-statusline — Fixed two-line status footer for pi with model, thinking, context, git, token, worktree, and skill indicators
@narumitw/pi-github-pr — Pi extension that shows GitHub pull request review, checks, and comment status.
@narumitw/pi-statusline — Pi extension that replaces the footer with an information-rich statusline.
[...]

Then we’ll simply fork it away: 65 lines of local extension replace the 600+ of the extension:

export function formatPrLink(stdout: string): string | undefined {
	let pr: { number?: unknown; url?: unknown; state?: unknown };
	try {
		pr = JSON.parse(stdout);
	} catch {
		return undefined;
	}
	if (pr.state !== "OPEN") return undefined;
	if (typeof pr.number !== "number" || !Number.isFinite(pr.number)) return undefined;
	const label = `PR #${pr.number}`;
	return typeof pr.url === "string" ? osc8Link(pr.url, label) : label;
}

export default function (pi: ExtensionAPI) {
	let request = 0;

	const refresh = async (ctx: ExtensionContext) => {
		request += 1;
		const current = request;
		let status: string | undefined;
		try {
			const result = await pi.exec("gh", ["pr", "view", "--json", "number,url,state"], {
				cwd: ctx.cwd,
				signal: ctx.signal,
				timeout: GH_TIMEOUT_MS,
			});
			if (result.code === 0 && !result.killed) status = formatPrLink(result.stdout);
		} catch {
			status = undefined;
		}
		if (current === request && !ctx.signal?.aborted) ctx.ui.setStatus(STATUS_KEY, status);
	};

	pi.on("session_start", async (_event, ctx) => refresh(ctx));
	pi.on("agent_end", async (_event, ctx) => refresh(ctx));
	pi.on("session_shutdown", async (_event, ctx) => {
		request += 1;
		ctx.ui.setStatus(STATUS_KEY, undefined);
	});
}

The osc8Link() helper wraps the number in an OSC 8 hyperlink, so the entry is clickable in the terminal (Cmd + click in Ghostty, for example):

% node --experimental-strip-types -e '
const { formatPrLink } = await import("/Users/thiago.perrotta/.pi/agent/extensions/github-pr-link.ts");
const { execFileSync } = await import("node:child_process");
const out = execFileSync("gh", ["pr", "view", "14215", "-R", "cli/cli", "--json", "number,url,state"], { encoding: "utf8" });
console.log("gh stdout:", out.trim());
console.log("status:", JSON.stringify(formatPrLink(out)));
'
gh stdout: {"number":14215,"state":"OPEN","url":"https://github.com/cli/cli/pull/14215"}
status: "\u001b]8;;https://github.com/cli/cli/pull/14215\u0007PR #14215\u001b]8;;\u0007"

Dropping the counters also dropped the second network call: the package pairs every gh pr view with a GraphQL query for comment and review totals, and polls every 60 seconds on top of session start, branch changes, and agent turns. One gh pr view on session start and after each turn is enough. A branch switch lands on the next turn end anyway, because switching branches means running git checkout.

Every failure path — no PR, merged PR, missing gh, unauthenticated gh — just clears the entry:

% node --experimental-strip-types --test agent/extensions/tests/github-pr-link.test.ts
✔ formatPrLink links open PRs and hides everything else (0.601333ms)
✔ osc8Link rejects non-http schemes (0.079ms)
✔ session start shows the PR link (0.526625ms)
✔ agent end clears the entry when gh fails (0.094167ms)
✔ agent end clears the entry when gh is missing (0.093125ms)
✔ aborted turn keeps the previous entry (0.466084ms)
✔ session shutdown clears the entry (0.104292ms)
✔ a stale refresh does not overwrite a newer one (0.165791ms)
ℹ pass 8
ℹ fail 0

The whole swap:

% pi uninstall npm:@narumitw/pi-github-pr
Removing npm:@narumitw/pi-github-pr...
Removed npm:@narumitw/pi-github-pr

% git --no-pager show --stat --oneline HEAD
4dadda2 pi: replace pi-github-pr with a link-only extension
 pi/.pi/README.md                                   |   4 +-
 pi/.pi/agent/extensions/github-pr-link.ts          |  65 ++++++++++
 .../agent/extensions/tests/github-pr-link.test.ts  | 139 +++++++++++++++++++++
 pi/.pi/agent/settings.json                         |   3 +-
 4 files changed, 207 insertions(+), 4 deletions(-)

Files under ~/.pi/agent/extensions/*.ts are auto-discovered, so /reload picks it up without restarting the session.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#ai #bloggify #dev #git #pi

★ CodeBurn

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 23 Aug 2026 00:17:38 +0200

♠ Previously.

CodeBurn shows Gen AI / LLM code usage: where did all the money ~~burning tokens~~ ($$) go?

CodeBurn is a free, open-source, local-first tool that tracks AI coding token usage and cost across 41 tools and agents (Claude Code, Pi, Codex, Cursor, and more), broken down by model, project, and task.

It reads the session files already on disk. No wrapper, proxy, or API key is needed, and nothing leaves the machine (great!).

It’s a TUI.

Installation methods:

% brew install codeburn

% npx codeburn

The same data is also available via web and desktop interfaces. On macOS, menubar downloads the native app to ~/Applications and launches it:

% codeburn menubar
Resolving CodeBurn Menubar v0.9.20...
Downloading CodeBurnMenubar-v0.9.20.zip...
Verifying checksum...
Unpacking...
Verifying app bundle...
Launching CodeBurn Menubar...

  Ready. /Users/thiago.perrotta/Applications/CodeBurnMenubar.app

It shows the current spend in the menu bar. Clicking it opens local breakdowns by agent, model, and activity, plus trends, forecasts, and exports. It refreshes every 30 seconds by default and backs off on battery.

It tracks spend calculated from local sessions, not provider usage windows or reset countdowns. Codexbar does the latter.

I find that the CLI TUI is enough.

A few subcommands:

yield correlates AI sessions with nearby Git commits. It classifies the money spent as productive, reverted, abandoned, or ambiguous:

% codeburn yield -p 30days

  Analyzing yield for Last 30 Days...


Productive:   $594.85 (31%) - 117 sessions shipped to main
Reverted:       $0.00 (0%) - 0 sessions were reverted
Abandoned:    $611.66 (32%) - 377 sessions never committed
Ambiguous:    $709.10 (37%) - 220 sessions lost commits to concurrent sessions

Attribution: timestamp-window based (heuristic)

Total:       $1915.61     - 714 sessions

It’s an experimental timestamp-based heuristic, but a neat answer to “did all those tokens produce code that shipped?”

report opens the interactive dashboard for a given period, with token and cost breakdowns by tool, model, project, and task:

% codeburn report --provider pi -p month

∎

— § —

Reply via email

#ai #bestof #dev

prometheus: a 117GB WAL that could not truncate

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 22 Aug 2026 23:35:00 +0200

♠ Previously.

With the volume expanded, the next failure surfaced. The pod came up, served for 14 minutes, then hit a different wall:

% kubectl -n monitoring get pod prometheus-...-prometheus-0 -o json | \
    jq '.status.containerStatuses[] | select(.name=="prometheus") | .lastState.terminated'
{
  "reason": "OOMKilled",
  "exitCode": 137,
  "startedAt": "2026-08-22T20:35:12Z",
  "finishedAt": "2026-08-22T20:49:29Z"
}

Not disk this time — 129GB was free. The WAL was the problem:

% du -sh /prometheus/prometheus-db/wal
117.7G	/prometheus/prometheus-db/wal
% ls /prometheus/prometheus-db/wal | wc -l
1062

A healthy WAL holds about two hours. This one spanned two days, because WAL truncation happens at head compaction, and head compaction was OOMKilling before it could commit. I caught it mid-attempt once:

% ls -d /prometheus/prometheus-db/wal/checkpoint.*
/prometheus/prometheus-db/wal/checkpoint.00188884
/prometheus/prometheus-db/wal/checkpoint.00189585.tmp

That .tmp never landed. The next check, it was gone and the old checkpoint from two days earlier was still the newest one. Each cycle ingested a little more than it compacted, so the head grew, and the OOM arrived sooner. 205 restarts of no net progress.

The memory limit had no room to grow either:

      resources:
        limits:
          memory: 14Gi
        requests:
          cpu: 1
          memory: 11Gi

14Gi against a Standard_D4ps_v6 with 15.0Gi allocatable. Raising it makes the pod unschedulable.

So: delete the WAL. Thanos had already shipped every local block, which is what made this cheap:

% cat /prometheus/prometheus-db/thanos.shipper.json
{
	"version": 1,
	"uploaded": [
		"01M0NKKGWJVKD3R84S90WW9R7G",
		"01M0NMBBC2Y31KMSJRA7VSGYXA",
		"01M0NMDM1XRJ0P1MMRBKF5HDV0"
	]
}

Scaling the StatefulSet down does not work — prometheus-operator owns it and put the replica back within two minutes. The Prometheus CR is the real lever:

% kubectl -n monitoring patch prometheus prometheus-kube-prometheus-prometheus \
    --type merge -p '{"spec":{"replicas":0}}'

Then a scratch pod on the PVC, where I nearly deleted nothing at all:

% kubectl -n monitoring exec wal-cleanup -- ls /prometheus
lost+found
prometheus-db

The StatefulSet mounts that volume with a subPath. Deleting /prometheus/wal would have removed nothing, and the restart would have looked like a fix. The data is one level down:

% kubectl -n monitoring exec wal-cleanup -- \
    find /prometheus/prometheus-db/wal /prometheus/prometheus-db/chunks_head -mindepth 1 -delete
% kubectl -n monitoring exec wal-cleanup -- df -h /prometheus | tail -1
/dev/sda                250.9G      3.8G    247.1G   2% /prometheus

Replay after that:

total_replay_duration=280.16µs

Down from ten minutes. Cost: five hours of local samples, everything older still queryable through Thanos.

Two independent limits, hit in sequence: the volume, then the memory ceiling that kept compaction from ever committing. The remaining one is a limit sized at 93% of the node it runs on, and that needs a bigger node pool.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #dev #kubernetes

azure disk: resize needs the PVC patch too

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 22 Aug 2026 22:50:20 +0200

♠ Problem statement: a Prometheus pod crash-looped on a full 128GiB volume. I resized the Azure-managed disk to 256Gi in the Azure Portal (ClickOps) to no avail.

The disk really was bigger:

% az disk show -g my-cluster-k8s-nodes \
    -n pvc-86ac2c66-fb67-43c3-84b0-7209f3a23bd3 -o json | \
    jq '{diskSizeGB, diskState, provisioningState}'
{
  "diskSizeGB": 256,
  "diskState": "Attached",
  "provisioningState": "Succeeded"
}

Kubernetes disagreed though (well, it didn’t know about the resize yet):

% kubectl -n monitoring get pvc prometheus-...-prometheus-0 -o json | \
    jq '{spec: .spec.resources.requests, status: .status.capacity, alloc: .status.allocatedResources}'
{
  "spec": {"storage": "128Gi"},
  "status": {"storage": "128Gi"},
  "alloc": null
}

allocatedResources: null means no resize was ever requested. Growing the disk in Azure doesn’t tell the CSI driver anything, so nobody ran resize2fs, and the filesystem stayed exactly where it was:

% kubectl -n monitoring exec prometheus-...-prometheus-0 -c thanos-sidecar -- df -h /prometheus
Filesystem                Size      Used Available Use% Mounted on
/dev/sda                124.9G    123.0G      1.9G  98% /prometheus

The fix is to patch the PVC so the control plane catches up. disk.csi.azure.com sees the block device is already large enough, skips the Azure API call, and goes straight to the filesystem:

% kubectl -n monitoring patch pvc prometheus-...-prometheus-0 \
    -p '{"spec":{"resources":{"requests":{"storage":"256Gi"}}}}'
persistentvolumeclaim/prometheus-...-prometheus-0 patched

% kubectl -n monitoring exec prometheus-...-prometheus-0 -c thanos-sidecar -- df -h /prometheus
Filesystem                Size      Used Available Use% Mounted on
/dev/sda                250.9G    124.6G    126.4G  50% /prometheus

42MB free became 126.4GB, and the pod went 3/3 Running after 203 crashes.

The lesson: patch the PVC and then let CSI follow up.

Resizing in Azure first just creates a split state where the volume is bigger but nothing can use it.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #dev #kubernetes

anki: migrate English notes to TTS note types

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 22 Aug 2026 13:36:25 +0200

♠ Previously.

Problem statement: migrate my English 🇬🇧 deck to dedicated note types with British English text-to-speech, without adding reverse cards.

I created English Language Card 🇬🇧 with four fields (Front, Front Example, Back, and Striked) and only one card template:

{{Front}} {{tts en_GB:Front}}

{{#Front Example}}
<br>
<i>{{Front Example}}</i> {{tts en_GB:Front Example}}
{{/Front Example}}

English Grammatik Cloze 🇬🇧 uses the same TTS setup for cloze notes:

{{cloze:Text}} {{tts en_GB:Text}}

AnkiConnect could create both types, but did not expose a changeNoteType action. I closed Anki and used its own Python package instead. Before changing the collection, I exported the English deck and copied the SQLite database:

4.8M pre-english-note-type-migration-2026-08-22-13.27.44.apkg
9.9M pre-english-note-type-migration-2026-08-22-13.29.08.collection.anki2

The field and template maps did the migration in place:

col.models.change(basic, groups["Basic"], language, {0: 0, 1: 2}, {0: 0})
col.models.change(cloze, groups["Cloze"], english_cloze, {0: 0, 1: 1}, None)

I rehearsed the migration against the database copy before running it for real:

% PYTHONPATH=/Applications/Anki.app/Contents/Resources/app_packages \
  /opt/homebrew/bin/python3.13 /tmp/anki_migrate_english.py \
  ~/Library/Application\ Support/Anki2/User\ 1/collection.anki2
{
  "notes": 1089,
  "cards_before": 1096,
  "cards_after": 1089,
  "language_notes": 1086,
  "cloze_notes": 3,
  "removed_reverse_cards": 7,
  "integrity": "ok"
}

The script also checked every mapped field, retained card ID, and review-log count. After a full upload to AnkiWeb, a normal sync passed.

No reverse cards, and all English notes can now speak for themselves (pun intended!).

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#anki #bloggify #dev #pkm

hugo: tag-based post connections

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 22 Aug 2026 13:29:06 +0200

♠ Previously.

Problem statement: post connections showed only direct links, while posts with the same tags remained disconnected in the graph of this blog.

I added a second kind of edge. The pre-computation picks up to two posts with the most shared tags, breaks ties by date, and excludes direct links:

def compute_tag_related_posts(
    post: dict,
    all_posts: list[dict],
    outlinks_set: set[str],
    backlinks_set: set[str],
    limit: int = 2,
) -> list[str]:
    """Compute tag connections, excluding posts with direct links."""
    post_tags = set(post["tags"])
    if not post_tags:
        return []

    direct_ids = outlinks_set | backlinks_set
    scored = []
    for other in all_posts:
        other_id = other["id"]
        if other_id == post["id"] or other_id in direct_ids:
            continue

        shared_tags = post_tags & set(other["tags"])
        if shared_tags:
            scored.append((other_id, len(shared_tags), other["date"]))

    scored.sort(key=lambda item: (item[1], item[2], item[0]), reverse=True)
    return [item[0] for item in scored[:limit]]

Direct links remain solid and prominent. Shared-tag links use smaller arrows with dashed, muted edges:

.mini-graph .mini-graph-direct-edge {
  fill: none;
  stroke: var(--link-color);
  stroke-width: 2.25;
  stroke-opacity: 0.9;
}

.mini-graph .mini-graph-tag-edge {
  fill: none;
  stroke: var(--color-gray);
  stroke-width: 1;
  stroke-dasharray: 4 4;
  stroke-opacity: 0.65;
}

The original Anki post now gets one direct link and two tag connections:

{
  "outlinks": ["2024-12-23-anki-workflow"],
  "tag_related": [
    "2026-04-15-anki-flashcards-with-claude-code",
    "2026-04-13-anki-api-access"
  ]
}

% python3 ci/test_precompute_links.py
..
----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

There’s a limit of 2 shared tag post edges for the sake of not visually polluting the presentation.

I’ve been loving how this little blog is evolving into my beloved (public) digital garden.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #coding #dev #meta

LLM: Devise a plan

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 22 Aug 2026 13:07:58 +0200

♠ There’s no need for plan mode.

Sandboxing + prompt engineering is enough.

End your prompt with

Devise a plan

…and let the 2026 Gen AI models flow by themselves.

Here’a a sample session:

User:

some of my blog posts e.g. https://perrotta.dev/2026/07/anki-archive-a-deck/ have
"connections"

this is great, but it includes _only_ direct links

I wanted to expand connections to include a couple of posts that share tags too

They should be visually distinct from direct links (direct links should stand out better)

*Devise a plan*

Assistant:

[...]

Current Connections graph reads only backlinks and outlinks. Existing related
data mixes links, tags, categories, and title words. It cannot guarantee two
tag-based results.

 Plan:

 1. Precompute tag connections
     - Add tag_related to ci/precompute_links.py.
     - Select up to two posts with shared tags.
     - Exclude current post, backlinks, and outlinks.
     - Rank by shared-tag count, then newest date.
     - Store post IDs in data/links.json.

 2. Extend mini graph
     - Read tag_related in layouts/partials/mini-graph.html.
     - Keep incoming links on left.
     - Keep outgoing links on right.
     - Place tag connections below current post.
     - Use no arrows because tag relationships have no direction.
     - Include shared tag names in each SVG <title>.

[...]

 6. Verify
     - Add focused tests for ranking, direct-link exclusion, deduplication, and
       fewer-than-two matches.
     - Regenerate data/links.json.
     - Run hugo.
     - Inspect /2026/07/anki-archive-a-deck/ on desktop and mobile.
     - Confirm direct Anki workflow link stands out.
     - Confirm two non-direct Anki/tag posts appear as muted tag connections.
     - Confirm posts without tags or direct links still render correctly.

∎

— § —

Reply via email

#ai #dev

kargo: notify when a soak completes

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 21 Aug 2026 18:38:23 +0200

♠ Previously.

Problem statement: notify a Slack channel whenever Freight finishes soaking in an upstream Kargo Stage, without promoting it to the next environment.

A soak does not finish a process. Once requiredSoakTime elapses, Kargo simply makes the Freight available downstream. There is no soak-complete event in the Kargo event list.

Worakround: I made availability start a notification-only promotion. Relevant excerpt, with variable values omitted:

metadata:
  name: notify-remaining-gardens-ready
spec:
  requestedFreight:
    - origin:
        kind: Warehouse
        name: argocd
      sources:
        stages:
          - staging-gardens
        requiredSoakTime: 48h0m0s
  promotionTemplate:
    spec:
      steps:
        - uses: http
          config:
            method: POST
            url: https://slack.com/api/chat.postMessage
            responseContentType: application/json
            successExpression: response.status == 200 && response.body.ok == true
            failureExpression: response.status != 200 || response.body.ok != true
            body: |-
              ${{ quote({
                "channel": vars.slackChannel,
                "username": "Kargo",
                "icon_emoji": ":kargo:",
                "unfurl_links": false,
                "text": ":white_check_mark: *argocd*: chart " + chartFrom(vars.chartRepo, "argocd").Version
                  + " completed 48h of soak in staging-gardens and is ready for promotion to remaining-gardens."
                  + "\nFreight: `" + ctx.targetFreight.name + "`"
              })
              }}

…wherein remaining-gardens = prod.

Only the notification Stage auto-promotes:

promotionPolicies:
  - stageSelector:
      name: notify-remaining-gardens-ready
    autoPromotionEnabled: true

Once the HTTP step succeeds, the Freight occupies this Stage and does not send again. The real downstream Stage remains human-gated. A Slack API error fails only the notification Promotion, which can be retried.

% prek run kargo-promotion-tasks --all-files
Check Kargo PromotionTask references.....................................Passed

This uses Kargo’s generic http step as the notification transport and Kargo itself as the timer.

There’s no need to enroll into Akuity Platform ($$) just for the sake of send-message.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#argocd #bloggify #dev #kubernetes

mise: one frontend for tool versions

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 21 Aug 2026 16:55:45 +0200

♠ Previously.

Thanks to the ThoughtWorks Technology Radar I finally decided to adopt mise, so I migrated my dotfiles to use it for every programming language runtime:

rbenv (ruby)
tfenv (terraform)
nvm (nodejs)
pyenv (python)

A single bespoke declarative file to rule them all:

[tools]
go = "1.27"
node = "26.7"
python = "3.14"
ruby = "3.4"
rust = "1.97"
terraform = "1.15"
terraform-docs = "0.24.0"

Deleted ~/.rbenv (1.2 GB, three ruby builds) and ~/.config/tfenv (821 MB, eight terraform builds). Mise is using 275 MB now. That’s a nice cleanup bonus.

I should write a dedicated blog post about it if it sticks in my setup. ∎

— § —

Reply via email

#ai #coding #dev

Google notice of content restriction

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 21 Aug 2026 12:26:12 +0200

♠ From: removals@google.com

To: me

Subject: Google notice of content restriction

Hello,

Your review isn’t posted.

What happened

We received a complaint that your review is defamatory under German law. Your review is removed for now, because German courts have set a low threshold for businesses to challenge reviews as defamatory. For example, businesses can simply claim that they cannot verify that you were a customer (for example, they have no record of a transaction) and unless there is evidence to the contrary, courts may order platforms to remove the review. To show that you were a customer and reinstate your review, use the appeals option below under “What you can do next”.

Affected URL(s): {redacted}

Thiago ★ {1 star}

What you can do next

If you think your content should be re-published, we invite you to contest this removal decision by providing us with evidence of your interaction with this business at this link:

https://reportcontent.google.com/forms/dsa_appeal

In case you’re curious, it was a blank review. I did not write any text at all.

In other words, a 1-star review without any commentary is apparently deemed defamatory. What a great system.

This has happened more than once.

I can no longer recommend Google Maps as a reliable source for unbiased reviews.

It is certainly a reliable proxy for popularity, but that’s all.

Some businesses take advantage of the situation to attempt to take down bad reviews, and they’re often successful while at it. Therefore you cannot trust the leftover glamourous reviews.

I stopped using Yelp many years ago for the same reason. ∎

— § —

Reply via email

#privacy #serenity

Terminals

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 20 Aug 2026 18:04:21 +0200

♠ Today I found myself with 13 open terminals, more than half of them running Pi or Claude Code, the rest with various projects and explorations split amongst work and personal affairs.

13!!

This is not a matter of pride.

I need to take a break. ∎

— § —

Reply via email

#ai #dev #serenity

ThoughtWorks Technology Radar

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 20 Aug 2026 13:27:08 +0200

♠ TIL: The ThoughtWorks Technology Radar publishes an yearly¹ opinionated report about the technology landscape today.

It is a rich source of inspiration to identify techniques, tools, platforms and languages & frameworks to assess and/or adopt.

They also publish PDFs and keep historical editions available.

Too bad there isn’t a RSS feed though, not that I could find.

That’s what we have Kill the Newsletter for, right? ∎

Actually, biyearly (=twice a year). ↩︎

— § —

Reply via email

#dev #serenity

★ human voice

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 19 Aug 2026 16:24:06 +0200

♠ More and more I’ve been resorting to LLMs / Gen AI to file feature requests or issues/bugs in upstream repositories.

Sometimes I get completely ignored, even when I follow the project guidelines.

For example, last week I filed this issue in Pi. It got auto-closed. I know why it was auto-closed, but it’s lame, because I followed their guidelines. In spite of writing it in my own voice, it got lost in the sea of slop issues. I can’t blame the maintainers, I totally understandand and sympathize with them. Yet, it sucks for me¹.

In other words: even when I put in the effort to file an issue manually, without using an LLM, it gets mistaken for an LLM slop issue, because that’s what everybody else is doing.

Which kind of incentives does this create?

→ There’s little reason to put in the effort to write issues in my own voice.

Which is, ironically, the opposite of what the project maintainers seemingly hoped to accomplish (=to attract non-clanker contributors that file high-quality issues).

So now I am pivoting.

I’ll shamelessly create issues (or feature requests) with an LLM. I’ll review the wording first, but won’t attempt to write them in my own voice. Would it even matter? Maintainers are too busy and overwhelmed to be able to distinguish slop from human voice, which is ironical — LLMs were supposed to improve WLB, not to make it worse. Oh well.

That said, pure Gen AI is lame. So I am starting to complement with a follow-up comment in my own voice.

Today’s example: angristan/fast-resume#87:

(human voice) Disclaimer: the previous comment was created by an LLM, I reviewed its text though. I can reliably reproduce this locally. I’ve been using fr for a while now, it’s very handy. This is the only use case that is getting on my way.

Let me know if you would like help to implement/address it. Thanks!

Check out fast-resume if you haven’t yet. It’s awesome.

I think this is a good compromise. ∎

And, frankly, for them too. I no longer feel motivated to file issues for Pi, even though I’m becoming a heavy user of it. ↩︎

— § —

Reply via email

#ai #bestof #dev #serenity

★ /ship-and-burn a pull request

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 19 Aug 2026 12:02:31 +0200

♠ Problem statement: ship a simple change (or commit, or pull request: you name it), then wait for green CI, then remove its local branch and worktree (=clean up).

It’s 2026, so we’ll codify this workflow in the form of an agent skill.

I created /ship-and-burn for that.

/ship-and-burn [reviewer]

It’s very important that you picture this movie whenever you invoke this skill.

The structure is the following, composing various of my other skills:

/ship ──> pull request ──> /pr-pass ──> green ──> delete local state
                                  └──> blocked ──> keep local state

The implementation is a single SKILL.md Markdown file (naturally!):

% git show --stat --oneline 8e0eed7
8e0eed7 feat: add ship-and-burn skill

 README.md                                       |  1 +
 package.json                                    |  2 +-
 plugins/thiagowfx/.claude-plugin/plugin.json    |  2 +-
 plugins/thiagowfx/skills/ship-and-burn/SKILL.md | 67 +++++++++++++++++++++++++
 4 files changed, 70 insertions(+), 2 deletions(-)

The skill stops before cleanup whenever CI remains failed or pending 🔴.

Once checks pass 🟢, it verifies that the worktree/checkout is clean and that every local commit exists on the remote:

test -z "$(git status --porcelain)"
git merge-base --is-ancestor HEAD "origin/$branch"

For a secondary (=non-base) worktree, wt removes both the worktree and its local branch:

cd "$primary"
wt del -- --foreground "$branch"

The pull request and remote branch remain intact.

Should review comments arrive later, my gh co (or wt co for a separate worktree) alias restores the branch and worktree before I address them:

% gh co <pull-request>
% /address-pr-comments

This surely feels like living in the future!

And, when using a light harness like pi, it’s super fast! ∎

— § —

Reply via email

#ai #bestof #coding #dev #git

★ kubernetes: force-refresh a cached multi-architecture image

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 19 Aug 2026 11:22:26 +0200

♠ Previously.

Problem statement: a Kubernetes ARM64 node kept running an AMD64 image after I replaced the registry tag with a multi-architecture image via skopeo, due to image caching.

I first mirrored only the AMD64 variant into AWS ECR (note: no --all):

% skopeo sync \
  --dest-creds "AWS:$(aws ecr get-login-password --region cn-north-1)" \
  --src docker --dest docker \
  --override-os linux --override-arch amd64 \
  quay.io/argoproj/argocd:v3.5.0 \
  "$REGISTRY/quay.io/argoproj"

That image failed on the ARM64 node:

exec /usr/local/bin/argocd: exec format error

The source has four platform manifests, so I replaced the ECR tag with the full manifest list (-all¹):

% skopeo sync \
  --all \
  --dest-creds "AWS:$(aws ecr get-login-password --region cn-north-1)" \
  --src docker --dest docker \
  quay.io/argoproj/argocd:v3.5.0 \
  "$REGISTRY/quay.io/argoproj"

linux  amd64    sha256:521d6b62ecd0434c9cc6e9242a74f0e1137bb8fc0026b2c483ea88f3f17e725d
linux  arm64    sha256:8a14921f7e5dc3408111714f05bff68e337d459653c45f0aea738330d156079b
linux  s390x    sha256:28743e713eabeeaacc103d177fc0b651b564d10309839077b0381ca980055c7d
linux  ppc64le  sha256:1f9e154e0eef6df29b75948b0b54dfc8ec490c657100df11a24c34197b9beb3a

The sync is complete.

Deleting the failed pod did not help though. Its replacement still used the cached AMD64 child manifest:

pod: pod/argocd-redis-secret-init-qgnqr
node: ip-10-25-54-66.cn-north-1.compute.internal
arch: arm64
image ID: $REGISTRY/quay.io/argoproj/argocd@sha256:521d6b62ecd0434c9cc6e9242a74f0e1137bb8fc0026b2c483ea88f3f17e725d
pull policy: IfNotPresent

The Job pod template is immutable, so changing its pull policy in place (to Always) also failed. Instead, I created a temporary pod on the same node. It forced a pull and ran a harmless command that proved the selected binary can be executed:

apiVersion: v1
kind: Pod
metadata:
  name: argocd-image-refresh
  namespace: argocd
spec:
  nodeName: ip-10-0-0-42.cn-north-1.compute.internal
  restartPolicy: Never
  tolerations:
    - key: arch
      operator: Exists
      effect: NoSchedule
    - key: arch
      operator: Exists
      effect: NoExecute
  containers:
    - name: refresh
      image: $REGISTRY/quay.io/argoproj/argocd:v3.5.0
      imagePullPolicy: Always  # This is the important part!
      command: ["/usr/local/bin/argocd"]
      args: ["version", "--client"]

NAME                   READY   STATUS      RESTARTS
argocd-image-refresh   0/1     Completed   0

The node cache now pointed at the multi-architecture manifest list:

$REGISTRY/quay.io/argoproj/argocd@sha256:c298cedbaeb31532ba8d4e9904eba9e4987e067293fbd86400c5194e78f743d5

I removed the temporary pod and the failed Job pod. The Job controller created a replacement, and the ARM64 binary started normally.

% kubectl -n argocd delete pod argocd-image-refresh
% kubectl -n argocd delete pod -l job-name=argocd-redis-secret-init

🤖 Drafted with /bloggify. ∎

Why isn’t this the default?! ↩︎

— § —

Reply via email

#argocd #aws #bestof #bloggify #dev #docker #kubernetes

kargo: cool down upstream releases with a holding stage

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 19 Aug 2026 01:36:27 +0200

♠ Problem statement: wait before opening an upstream Helm chart upgrade PR, without putting a timer in the PR workflow.

In other words: implement dependency cooldowns¹ in Kargo.

A Kargo Warehouse makes newly discovered Freight immediately available to a Stage that accepts it directly:

Warehouse ──immediate──> open-upgrade-pr ──> PR

Kargo already has requiredSoakTime, but only between Stages. It cannot delay a direct Warehouse-to-Stage promotion. So add a Stage whose promotion deliberately does nothing:

apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
  name: hold-upstream-release
spec:
  requestedFreight:
    - origin:
        kind: Warehouse
        name: external-secrets-upstream
      sources:
        direct: true
  promotionTemplate:
    spec:
      steps:
        - uses: compose-output
          config:
            state: holding

The PR Stage accepts Freight from that holding Stage and starts only after the cool-off period:

spec:
  requestedFreight:
    - origin:
        kind: Warehouse
        name: external-secrets-upstream
      sources:
        stages:
          - hold-upstream-release
        requiredSoakTime: 72h0m0s
  promotionTemplate:
    # clone, update chart dependency, push, and open PR

Warehouse ──> hold-upstream-release ──72h──> open-upgrade-pr ──> PR

The holding Stage must auto-promote, as must the PR Stage after its soak. A new release replaces the current Freight in the holding Stage. If the old release did not complete 72 hours, it does not advance. This makes the hold a stability window: only a release that remains current for three days opens a PR.

Explicit Freight approval remains the escape hatch because it bypasses the soak.

🤖 Drafted with /bloggify. ∎

cooldown or cool-off? ↩︎

— § —

Reply via email

#argocd #bloggify #dev #kubernetes #security

git: intent-to-add breaks autostash

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 19 Aug 2026 01:09:07 +0200

♠ Problem statement: git pull could not autostash files added with git add -N.

I had local work and was nine commits behind origin/master:

% git pull --force
Updating 266a5af537..07e4551075
error: Entry 'ci/goodreads_to_reading.py' not uptodate. Cannot merge.
Cannot save the current worktree state
fatal: Cannot autostash

--force does not replace local worktree files. My global Git configuration makes git pull run rebase.autostash, which found an intent-to-add entry:

% git status --porcelain=v2
1 .M N... 100755 100755 100755 fcc319233ddf8e000ad2f735dbc2b0d760f467e5 fcc319233ddf8e000ad2f735dbc2b0d760f467e5 Justfile
1 .A N... 000000 000000 100755 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 ci/goodreads_to_reading.py
1 .M N... 100644 100644 100644 2787100c3968766ea3a84e7c28e28b5046d1da32 2787100c3968766ea3a84e7c28e28b5046d1da32 config/_default/config.yml
1 .A N... 000000 000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 content/reading.md
1 .A N... 000000 000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 data/reading.yaml

The .A records have an empty index object (0000000), so Git has tracked path metadata without file content to stash.

git reset removes intent-to-add entries and leaves worktree files alone:

% git reset
% git pull

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #coding #git

pi: handing off to a focused session

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

♠ Previously.

Disclaimer: This was a failed experiment. I am including it here anyway, for completeness.

Handoff #

Problem statement: move a running Pi task into a fresh, focused session without losing the way back.

I wanted Amp’s handoff workflow in Pi, so I vendored the handoff and session_query pieces of pasky/pi-amplike as a local package:

% git show --stat --oneline 77af167
77af167 Add Amp-like handoff package
 pi/.pi/README.md                                   |   2 +
 pi/.pi/agent/local/handoff-amp/LICENSE             |  21 +
 pi/.pi/agent/local/handoff-amp/README.md           |  28 ++
 .../agent/local/handoff-amp/extensions/handoff.ts  | 553 +++++++++++++++++++++
 .../local/handoff-amp/extensions/lib/mode-utils.ts | 127 +++++
 .../local/handoff-amp/extensions/session-query.ts  | 198 ++++++++
 pi/.pi/agent/local/handoff-amp/package.json        |  17 +
 .../handoff-amp/skills/session-query/SKILL.md      |  35 ++
 pi/.pi/agent/settings.json                         |   1 +
 9 files changed, 982 insertions(+)

From the editor, /handoff accepts a goal and optional mode or model:

/handoff execute phase one of the plan
/handoff -mode rush execute phase one of the plan
/handoff -model anthropic/claude-haiku-4-5 check other places that need this fix

The extension serializes the current branch, asks the model for a focused context summary, and includes the source session path in the new prompt:

// ~/.pi/agent/local/handoff-amp/extensions/handoff.ts
const currentSessionFile = ctx.sessionManager.getSessionFile();

if (currentSessionFile) {
  finalPrompt = `${goal}\n\n/skill:session-query\n\n**Parent session:** \`${currentSessionFile}\`\n\n${result}`;
}

The important part: handoff does not open a second Pi process. The command replaces the active session inside the current process:

const newSessionResult = await cmdCtx.newSession({
  parentSession: currentSessionFile,
});

When the agent invokes the handoff tool instead, Pi waits for the current turn to finish, then changes the session file:

pi.on("agent_end", (_event, ctx) => {
  if (!pendingHandoff) return;

  const { prompt, parentSession } = pendingHandoff;
  (ctx.sessionManager as any).newSession({ parentSession });
});

Handoff initiated. The session will switch after the current turn completes.

Same TUI, new active session. The old session remains saved as the parent. To return to it, open the session picker:

/resume

Or start Pi with that picker from the shell:

% pi -r

/tree is not the way back: it navigates branches inside the current session file. Handoff creates another session file, so /resume is the matching operation.

Conclusion #

Human voice: Guess what, after doing all of the above I came to the conclusion that this is a cumbersome workflow. No wonder the Amp folks seem to have reached the same conclusion:

Handoff is another one of my features that I expect to die soon.

I am ditching it.

A better workflow is to backtrack the session tree with /tree or Esc Esc.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#ai #bloggify #coding #dev #pi

ChatGPT / OpenAI / Codex plan usage

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 19 Aug 2026 00:14:25 +0200

♠ Previously.

When enrolled in an OpenAI / ChatGPT plan (e.g. Pro/Plus), you may want to figure out how much weekly usage (%) you have left.

I’m sure codex has an /usage or /cost command to do so, but what if I’m using a third-party harness like Pi or OpenCode?

Head over to https://chatgpt.com/#settings/Usage to assess your usage limits.

Usage limits normally reset every week.

You can buy API credits (and even enable auto reload) when you run out, just like how you would do with your mobile phone plan.

Alternatively: codexbar. ∎

— § —

Reply via email

#ai #dev

★ Reviewing slop pull requests

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 18 Aug 2026 00:47:17 +0200

♠ Previously.

Problem statement: review an AI-written ~~slop~~ pull request from a teammate.

We’ll use a clanker to review slop PRs.

First, I invoke the /meat skill, turning the diff into a reading guide, inspired by David Crawshaw:

/meat <PR-URL>

It does not look for defects. It captures the diff once, follows control and data flow, treats tests as specifications, and returns this shape:

One sentence with intent and observable result.

## Read in this order
- path:line — why this contract matters

## Flow
1. input
2. transformation
3. effect

## Contracts
## Tests as specs
## Omitted

That gives me the author’s system model (the “meat” of their PR) without the PR body’s narrative.

Second, /dual-review¹ tries to break that model:

/dual-review <PR-URL> [--post]

It runs two review passes with different lenses / perspectives, then validates every candidate against source and focused probes. Reviewer agreement changes investigation priority.

--post instructs the clanker to write a comment in the PR.

To recap:

/meat says what the change means and where to read it.
/dual-review checks whether contracts survive hostile input.

My default sequence for a long, plausible PR is now:

/meat <PR-URL>
/dual-review <PR-URL> --post

One tool removes narrative noise. The other removes findings without evidence. ∎

Inspired by an internal skill created by our CISO. ↩︎

— § —

Reply via email

#ai #bestof #coding #dev

pi: fork vs clone sessions

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 17 Aug 2026 16:10:31 +0200

♠ Problem statement: split a running Pi conversation / session into a second independent one whilst keeping the original.

Pi has three similarly named albeit distinct operations:

/fork
/clone
pi --fork <path|id>

/fork opens a selector for an earlier user message, copies the active path up to the message’s parent into a new session, and puts the selected prompt back in the editor. This is for changing an earlier request.

/clone copies the current active root-to-leaf path into a new session and switches the current Pi process to it. The old session file remains unchanged; retrieve it with /resume, or note its ID first and open it directly:

/session
/clone

% pi --session 019feb2b

The CLI spelling does something subtly different:

% pi --help | grep -A5 -- '--session <path'
  --session <path|id>            Use specific session file or partial UUID
  --session-id <id>              Use exact project session ID, creating it if missing
  --fork <path|id>               Fork specific session file or partial UUID into a new session
  --session-dir <dir>            Directory for session storage and lookup
  --no-session                   Don't save session (ephemeral)
  --name, -n <name>              Set session display name

pi --fork copies the complete source session file, including all branches, then opens the copy in a new Pi process. The running source process is untouched:

# current Pi
/session

# second terminal, same project
% pi --fork 019feb2b

It’s easier to do so if we add the session ID to the Pi status bar. Pi loads extensions from ~/.pi/agent/extensions/, so I have this one:

// ~/.pi/agent/extensions/session-id.ts
import type { ExtensionAPI, ExtensionContext } from "@earendil-works/pi-coding-agent";

export function updateSessionIdStatus(ctx: ExtensionContext): void {
  const sessionId = ctx.sessionManager.getSessionId();
  ctx.ui.setStatus("session-id", ctx.ui.theme.fg("dim", `sid:${sessionId}`));
}

export default function (pi: ExtensionAPI) {
  pi.on("session_start", async (_event, ctx) => updateSessionIdStatus(ctx));
}

For a linear session, pi --fork and /clone produce equivalent conversation context. Once a session has branches, /clone extracts only the active branch; pi --fork preserves the full tree.

Pi sessions are JSONL trees, so none of these operations mutate the source history. For splitting one live conversation into two live processes, use pi --fork <id>. ∎

— § —

Reply via email

#ai #coding #dev #pi

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