Bloggify on ¬ just serendipity 🍀

offboarding: export your own work before the laptop is wiped

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 30 Sep 2026 11:02:24 +0200

♠ Problem statement: what is worth taking home on the last day at work, without taking the company’s code or data?

The line I drew: my work history, my own words, my contacts, my notes. Not source code, not runbooks, not customer data. Everything else the company keeps. Metadata about my contributions is mine to remember; the artifacts are theirs.

I pointed an AI harness at the connectors I already had (GitHub, Jira, Confluence, Gmail, Drive, Calendar, Slack, the HR directory) and asked it to build an inventory. It landed in one folder:

% eza -T -L1 ~/Downloads/offboarding
offboarding
├── README.md
├── resume-highlights.md
├── merged-prs.csv
├── jira-done.jsonl
├── jira-epics.md
├── contacts.csv
├── gmail-index.md
├── emails/
├── drive-index.md
├── drive-files/
├── confluence/
├── calendar-summary.md
├── slack-export.md
├── github-insights.md
├── chrome-bookmarks-work-profile.html
└── claude-memory/

The GitHub part is pure API, no clone. Merged PRs, paginated once:

% gh api graphql --paginate -f query='query($c: String) { viewer {
    pullRequests(first: 100, states: MERGED, after: $c) {
      pageInfo { hasNextPage endCursor }
      nodes { mergedAt repository { nameWithOwner } title additions deletions }
    } } }' --jq '.data.viewer.pullRequests.nodes[]' | jq -s . > merged_prs.json
% jq -r '.[].mergedAt[:4]' merged_prs.json | sort | uniq -c
 892 2024
1160 2025
1436 2026

Titles, dates, and line counts only. That is enough to write a resume bullet later; the diffs stay behind. Same idea for Jira (assignee = currentUser() AND statusCategory = Done) and for Confluence (creator = currentUser()).

Two things were clearly mine and would have been lost: the “working with me” email from week one, and a first-day checklist I mailed to myself. Both went into emails/ verbatim. The Slack kudos channel got the same treatment, because nobody will write a reference from memory two years from now.

The README in the folder lists what was deliberately not exported: source code, PR descriptions, runbook bodies, performance reviews. ∎

— § —

Reply via email

#bloggify #dev #git

JIRA: backfill tickets from merged pull requests

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 29 Sep 2026 11:21:17 +0200

♠ Problem statement: how can I catch up JIRA when pull requests have already (been) merged without tickets?

I wrote a local /backfill-jira skill for my AI harnesses. It compares recent merged PRs with existing issues before it creates anything. This is its structure; internal projects, repositories, queries, and field IDs are omitted:

% rg -n '^### Phase' ~/.claude/skills/backfill-jira/SKILL.md
31:### Phase A — gather + reconcile (read-only)
72:### Phase B — create the backfill tickets
125:### Phase C — confirm

The unit of work is a theme, not a PR. Several PRs can implement one change; one PR can also be routine enough to need no ticket. The skill checks PR references and matching issue summaries before declaring a gap. Existing backlog issues count as coverage.

The report rule in the skill is explicit:

4. **Report.** Print a table of every PR → (existing ticket | NEW theme-N | skipped-routine) and a
   separate list of the gap themes to create. The counts must reconcile: covered + new + skipped =
   total PRs. Don't let "get every PR to a theme" pressure you into merging unrelated skipped PRs
   into a theme just to shrink the skipped list.

Phase B creates one ticket for each uncovered theme, marks work as complete, and reads the status back. It also checks the sprint assignment after writing it. Neither a successful create response nor an attempted status change is proof that the final fields stuck.

The skill deliberately leaves routine work alone:

- Don't create per-PR tickets by default — one ticket per theme keeps signal high. **Never create a
  "grab bag" / "catch-all" / "hygiene" ticket that lumps together unrelated PRs** just to get to
  zero gaps — each ticket must describe one coherent, describable piece of work. If a PR is
  genuinely routine and not worth tracking on its own (a version bump, a dependency bump, a typo
  fix) and doesn't fit an existing theme, leave it **uncovered**: list it in the report as *skipped
  (routine, no ticket)* rather than inventing a ticket to absorb it.

A second pass over the same window checks whether the new tickets now cover the gaps. Zero new gaps matters more than zero skipped PRs. ∎

— § —

Reply via email

#bloggify #dev #git

typst: reusable polylux slides with section navigation

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 28 Sep 2026 23:58:53 +0200

♠ Previously.

Problem statement: how can I reuse a Typst slide layout without rebuilding its section navigation every time?

Here is the complete Polylux template. Put these three files in one directory. theme.typ owns the Metropolis-inspired layout and Frankfurt-style navigation: section names above one dot per content slide. Its state records the section counts and active slide. new-section creates a divider without a dot; slide adds a dot; untracked-slide is for title or closing pages.

// =============================================================================
// Metropolis theme + Frankfurt-style navigation bar with mini-frame dots
// =============================================================================
// Visual style: Metropolis (navy blue, light blue accent, clean typography)
// Navigation:   Frankfurt (section names + circle dots for slide progress)
// =============================================================================

#import "@preview/polylux:0.4.0": *
#let _polylux-slide = slide

// ---------------------------------------------------------------------------
// Colors — Navy blue palette
// ---------------------------------------------------------------------------
#let dark-teal = rgb("#1a2744")    // navy blue (primary dark)
#let bright = rgb("#4a90d9")       // accent / emphasis (medium blue)
#let brighter = rgb("#a8c4e0")     // muted light blue
#let bg = white.darken(2%)
#let fg = dark-teal

// ---------------------------------------------------------------------------
// Navigation state — tracks slides per section for mini-frame dots
// ---------------------------------------------------------------------------
#let _nav-sections = state("nav-sections", ())       // [{name, count}, ...]
#let _nav-current-sec = state("nav-current-sec", -1)  // index into sections
#let _nav-current-frame = state("nav-current-frame", 0)

#let _begin-section(name) = {
  _nav-sections.update(secs => {
    secs.push((name: name, count: 0))
    secs
  })
  _nav-current-sec.update(i => i + 1)
  _nav-current-frame.update(_ => 0)
}

#let _count-frame() = {
  context {
    let sec-idx = _nav-current-sec.get()
    if sec-idx >= 0 {
      _nav-current-frame.update(f => f + 1)
      _nav-sections.update(secs => {
        if sec-idx < secs.len() {
          secs.at(sec-idx).count += 1
        }
        secs
      })
    }
  }
}

// ---------------------------------------------------------------------------
// Navigation header — section names + mini-frame circles
// ---------------------------------------------------------------------------
#let _nav-header() = context {
  let all-secs = _nav-sections.final()
  let curr-sec = _nav-current-sec.get()
  let curr-frame = _nav-current-frame.get()

  if all-secs.len() == 0 { return }

  set text(fill: white, size: 0.5em, weight: "bold")

  let n = all-secs.len()

  // Row 1: Section names
  let names-row = all-secs.enumerate().map(((i, sec)) => {
    let is-current = i == curr-sec
    let is-past = i < curr-sec
    let name-color = if is-current { white } else if is-past { white.darken(10%) } else { white.darken(35%) }
    align(center, text(fill: name-color, sec.name))
  })

  // Row 2: Mini-frame dots (aligned under each section name)
  let dots-row = all-secs.enumerate().map(((i, sec)) => {
    let is-current = i == curr-sec
    let is-past = i < curr-sec

    let dots = range(sec.count).map(j => {
      let frame-num = j + 1
      let dot-fill = if is-past {
        white.darken(10%)
      } else if is-current and frame-num < curr-frame {
        white.darken(5%)
      } else if is-current and frame-num == curr-frame {
        bright
      } else {
        none
      }
      let dot-stroke = if dot-fill == none { 0.6pt + white.darken(30%) } else { none }
      let fill = if dot-fill == none { dark-teal } else { dot-fill }
      box(circle(radius: 2.5pt, fill: fill, stroke: dot-stroke))
    })
    align(center, dots.join(h(2.5pt)))
  })

  // Combine into a two-row grid
  block(width: 100%, fill: dark-teal, inset: (x: 0.6em, y: 0.3em),
    grid(
      columns: (1fr,) * n,
      row-gutter: 0.25em,
      ..names-row,
      ..dots-row,
    )
  )
}

// ---------------------------------------------------------------------------
// Slide title header (Metropolis style — below nav bar)
// ---------------------------------------------------------------------------
#let _title-header = toolbox.next-heading(h => {
  show: toolbox.full-width-block.with(fill: dark-teal, inset: (x: 1em, y: 0.6em))
  set align(horizon)
  set text(fill: bg, size: 1em)
  strong(h)
})

// ---------------------------------------------------------------------------
// Footer — Metropolis style
// ---------------------------------------------------------------------------
#let _the-footer(content) = {
  set text(size: 0.7em)
  show: pad.with(0.5em)
  set align(bottom)
  context text(fill: fg.lighten(40%), content)
  h(1fr)
  toolbox.slide-number
}

// ---------------------------------------------------------------------------
// Progress bar — Metropolis style (blue)
// ---------------------------------------------------------------------------
#let progress-bar = toolbox.progress-ratio(ratio => {
  set grid.cell(inset: (y: 0.03em))
  grid(
    columns: (ratio * 100%, 1fr),
    grid.cell(fill: bright)[],
    grid.cell(fill: brighter)[],
  )
})

// ---------------------------------------------------------------------------
// Public API: slide (tracked), new-section, focus, alert, note, divider
// ---------------------------------------------------------------------------

/// Content slide — automatically tracked in the navigation bar.
/// Use `= Title` as the first line for the slide title.
#let slide(body) = {
  _count-frame()
  _polylux-slide(body)
}

/// Section divider slide — registers a new section and shows a title card.
/// Not counted in mini-frame dots.
#let new-section(name) = {
  _begin-section(name)
  _polylux-slide({
    set page(header: none, footer: none)
    toolbox.register-section(name)
    show: pad.with(20%)
    set text(size: 1.5em, fill: fg)
    name
    progress-bar
  })
}

/// Focus slide — inverted colors for key messages.
#let focus(body) = context {
  set page(header: none, footer: none, fill: dark-teal, margin: 2em)
  set text(fill: bg, size: 1.5em)
  set align(center + horizon)
  body
}

/// Untracked slide — for title, closing, etc. No navigation counting.
#let untracked-slide(body) = _polylux-slide(body)

/// Blue divider line
#let divider = line(length: 100%, stroke: 0.1em + bright)

/// Alert text (blue bold)
#let alert(body) = text(fill: bright, weight: "bold", body)

/// Two-column layout helper — e.g. diagram left, bullets right
#let side-by-side(left, right, ratio: 1fr) = {
  grid(
    columns: (ratio, 1fr),
    gutter: 1em,
    left, right,
  )
}

/// Captioned image from assets directory
#let fig(path, caption: none, width: 80%) = {
  align(center,
    figure(
      image("assets/" + path, width: width),
      caption: if caption != none { text(size: 0.75em, caption) },
    )
  )
}

/// Speaker notes — pass `--input notes=false` to hide
#let note(body) = {
  let hidden = sys.inputs.at("notes", default: "true") == "false"
  if not hidden {
    place(bottom + left, dx: 0pt, dy: 0.8em)[
      #block(
        width: 100%,
        inset: 6pt,
        fill: rgb("#fef9c3").transparentize(20%),
        radius: 4pt,
        text(size: 10pt, style: "italic", fill: fg, body),
      )
    ]
  }
}

// ---------------------------------------------------------------------------
// Theme setup — call as:  #show: theme.setup.with(...)
// ---------------------------------------------------------------------------
#let setup(
  footer: none,
  navbar: true,
  text-font: "Avenir Next",
  math-font: "Avenir Next",
  code-font: "IBM Plex Mono",
  text-size: 22pt,
  body,
) = {
  set page(
    paper: "presentation-16-9",
    fill: bg,
    margin: (top: if navbar { 4.5em } else { 3em }, left: 1.2em, right: 1.2em, bottom: 1.8em),
    header: {
      set align(top)
      if navbar { toolbox.full-width-block[#_nav-header()] }
      _title-header
    },
    footer: _the-footer(footer),
  )

  set text(
    font: text-font,
    size: text-size,
    fill: fg,
  )
  set strong(delta: 100)
  show math.equation: set text(font: math-font)
  show raw: set text(font: code-font)
  show raw.where(block: true): it => block(
    width: 100%,
    fill: luma(240),
    inset: 10pt,
    radius: 3pt,
    stroke: 0.5pt + luma(200),
    it,
  )
  set align(horizon)
  set list(spacing: 1.4em)
  set enum(spacing: 1.4em)
  show emph: it => text(fill: bright, it.body)
  show heading.where(level: 1): _ => none

  body
}

#import "theme.typ"
#import theme: slide, untracked-slide, new-section, alert, note

#show: theme.setup.with(
  footer: [Slide template],
  text-font: "Libertinus Serif",
  code-font: "DejaVu Sans Mono",
  text-size: 22pt,
)

#untracked-slide[
  #set page(header: none, footer: none)
  #set align(center + horizon)
  #text(size: 1.5em, weight: "bold")[Slide template]
]

#new-section[First section]

#slide[
  = First slide

  A #alert[highlight] and a speaker note.

  #note[This note is absent from the audience PDF.]
]

#slide[
  = Second slide

  The navigation bar counts this slide within the first section.
]

#new-section[Second section]

#slide[
  = Third slide

  The section changes, and the dot count starts again.
]

watch:
    typst watch --input notes=true slides.typ

all: build audience

build:
    typst compile --input notes=true slides.typ

alias speaker := build

audience:
    typst compile --input notes=false slides.typ slides-audience.pdf

slides.typ is a minimal deck with two sections, three tracked slides, an untracked title, and a speaker note. Change its content and fonts for a new presentation; keep the theme and build recipes.

Justfile produces two PDFs from the same source. notes=false hides speaker notes from the audience copy:

% just all
typst compile --input notes=true slides.typ
typst compile --input notes=false slides.typ slides-audience.pdf

∎

— § —

Reply via email

#bloggify #dev #meta

postgres: point-in-time restore to roll back a breaking upgrade

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 24 Sep 2026 02:11:43 +0200

♠ Problem statement: how to roll back a self-hosted app upgrade when its database migrations have no down path?

A new release of an internal tool started to enforce a license limit that the old one did not. Pinning the old image back in GitOps was not enough:

[ERROR] Migration failed - inconsistent migrations
Traceback (most recent call last):
  File "/etc/service/app/./run", line 145, in <module>
    main()
subprocess.CalledProcessError: Command '['/usr/local/bin/app', 'migrate', '--verbosity=debug']' returned non-zero exit status 1.

The old binary refused to start against the new schema. RDS automated backups were on, with 30-day retention:

% aws rds describe-db-instance-automated-backups \
    --db-instance-identifier shared-db \
    --query 'DBInstanceAutomatedBackups[].[Status,RestoreWindow.EarliestTime,RestoreWindow.LatestTime]' \
    --output table
----------------------------------------------------------------------
|                 DescribeDBInstanceAutomatedBackups                 |
+--------+-----------------------------+-----------------------------+
|  active|  2026-08-24T22:41:45+00:00  |  2026-09-23T22:41:45+00:00  |
+--------+-----------------------------+-----------------------------+

Several apps share that instance. An in-place restore would have rolled back all of their databases. RDS point-in-time restore always creates a new instance anyway:

% aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-identifier shared-db \
    --target-db-instance-identifier shared-db-restore-20260910 \
    --restore-time 2026-09-10T12:00:00Z \
    --db-instance-class db.t4g.micro \
    --no-multi-az --no-publicly-accessible --no-deletion-protection
shared-db-restore-20260910	creating

With the app scaled to zero, a throwaway pod in the cluster moved only the app’s database across:

% pg_dump -h shared-db-restore-20260910.xxx.rds.amazonaws.com \
    -d app -Fc -f /tmp/app.dump
% psql -h shared-db.xxx.rds.amazonaws.com -d postgres \
    -c "ALTER DATABASE app RENAME TO app_upgraded_bak;" \
    -c "CREATE DATABASE app OWNER app;"
% pg_restore -h shared-db.xxx.rds.amazonaws.com \
    -d app --no-owner --role=app -j 2 /tmp/app.dump

Rename, not drop: rollback stays two ALTER DATABASE statements away. With the old schema back, the pinned image started cleanly:

[INFO] Migrations to perform
[INFO] Performing migration for add-unified-comment-output-details
[INFO] Completed migration for add-unified-comment-output-details
[INFO] Migration complete
[INFO] Starting server

The cost: everything the app wrote after the restore point was gone.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#aws #bloggify #dev #kubernetes

terraform: destroy a deleted project from git history

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 17 Sep 2026 14:15:09 +0200

♠ Problem statement: how can I run terraform destroy after deleting a project from the current Git checkout?

Deleting Terraform configuration does not destroy resources from its old state. My just destroy wrapper could no longer find the project:

% just destroy g08-opencost
Resolved path: g08-opencost
Error handling -chdir option: chdir g08-opencost: no such file or directory
error: recipe `destroy` failed with exit code 1

The last usable configuration is the parent of the commit that deleted its path. I taught the recipe to find and extract that revision into a temporary directory:

-    resolved_path=$(just _resolve_and_echo "{{ module_path }}")
+    resolved_path=$(just _resolve_path "{{ module_path }}")
+    historical_checkout=""
+    cleanup() {
+        if [[ -n "$historical_checkout" ]]; then
+            rm -rf "$historical_checkout"
+        fi
+    }
+    trap cleanup EXIT
+
+    if [[ ! -d "$resolved_path" ]]; then
+        project_name="${resolved_path%/}"
+        project_name="${project_name##*/}"
+        project_path="standalone/$project_name"
+        deletion_commit=$(git log -1 --format=%H --diff-filter=D -- "$project_path")
+
+        if [[ -z "$deletion_commit" ]] || ! git cat-file -e "$deletion_commit^:$project_path" 2>/dev/null; then
+            just _error "Project not found in current checkout or Git history: {{ module_path }}"
+            exit 1
+        fi
+
+        historical_commit=$(git rev-parse "$deletion_commit^")
+        historical_checkout=$(mktemp -d)
+        git archive "$historical_commit" | tar -x -C "$historical_checkout"
+        resolved_path="$historical_checkout/$project_path"
+        just _info "Project was deleted. Using $project_path from commit ${historical_commit:0:12}."
+    fi

The normal backend initialization and destroy path can then run unchanged:

% just destroy g08-opencost
Project was deleted. Using standalone/g08-opencost from commit fb82317c0010.
Resolved path: /var/folders/yr/6sw3yylx6gjcy5jr38d6j6000000gn/T/tmp.0als997N54/standalone/g08-opencost
...
Plan: 0 to add, 0 to change, 8 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value:
Error: error asking for approval: EOF

Releasing state lock. This may take a few moments...

No automatic approval: the historical configuration only gets Terraform back to its usual confirmation prompt. ∎

— § —

Reply via email

#bloggify #dev #git #terraform

lf: edit files and enter directories with enter

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 16 Sep 2026 16:41:39 +0200

♠ Problem statement: in lf, how can <Enter> edit files without trying to edit directories?

e already opens the selected file in $EDITOR. My first keybinding mapping attempt copied its default command:

 # Edit file: 'e' (mapped out-of-the-box)
+map <enter> $$EDITOR "$f"

This worked for files, but it also sent directories to the editor, which is unwelcome.

Next up: lf’s built-in open command already has the split behavior I wanted for directories:

% lf -doc | sed -n '533,540p'
Change the current working directory to the parent directory.

open (default l and <right>)

If the current file is a directory, then change the current directory to
it, otherwise, execute the open command. A default open command is
provided to call the default system opener asynchronously with the
current file as the argument. A custom open command can be defined to

So I kept the file branch in $EDITOR and sent the directory branch back to lf’s open command:

cmd edit-or-open ${{
    if [ -d "$f" ]; then
        "$lf" -remote "send $id open"
    else
        $EDITOR "$f"
    fi
}}
map <enter> edit-or-open

This works exactly as intended!

The complete lf configuration lives in my dotfiles. ∎

— § —

Reply via email

#bloggify #dev #linux

pi: stop repeated macos keychain prompts for mcp oauth

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 08 Sep 2026 13:09:35 +0200

♠ Problem statement: why did Pi keep asking for my macOS login keychain password during MCP OAuth authentication?

/mcp-auth grafana opened the same prompt again after I entered the correct password and selected Allow:

pi wants to use your confidential information stored in “pi-mcp-adapter.oauth” in your keychain.

pi-mcp-adapter stores OAuth credentials in the operating system credential store. Its Grafana record name is a SHA-256 hash:

% node -e 'const {createHash}=require("crypto"); console.log("sha256-" + createHash("sha256").update("grafana").digest("hex"))'
sha256-cace491b69555e8d0f77747d47ae54e31ce4cc322fe51a7bdcf64402f3676ebf

The Keychain ACL still allowed old Homebrew Node executables:

% security dump-keychain -a | rg -A18 'sha256-cace491b69555e8d0f77747d47ae54e31ce4cc322fe51a7bdcf64402f3676ebf"'
    entry 1:
        authorizations (6): decrypt derive export_clear export_wrapped mac sign
        don't-require-password
        description: pi-mcp-adapter.oauth
        applications (2):
            0: /opt/homebrew/Cellar/node/26.6.0/bin/node (status -67068)
                requirement: cdhash H"ea8d578543c9d8c21b74e26f7976cc30b60e24a5"
            1: /opt/homebrew/Cellar/node/26.5.0_1/bin/node (status -67068)
                requirement: cdhash H"4947cbedfdb054cda3708de8c0b22946c4fd98f1"

Pi now used Homebrew Node 26.8.1 with a different ad-hoc signature:

% codesign -dv --verbose=4 /opt/homebrew/Cellar/node/26.8.1/bin/node 2>&1 | rg 'Identifier|CDHash|TeamIdentifier'
Identifier=node-55554944b8d19d4157093cf1805ecde9a77d4850
CandidateCDHash sha256=cead962814af248488bb6597ee22a32fc23d00a1
CandidateCDHashFull sha256=cead962814af248488bb6597ee22a32fc23d00a1aac036bb431b750dd5120163
CDHash=cead962814af248488bb6597ee22a32fc23d00a1
TeamIdentifier=not set

The password was valid. macOS did not trust this new executable to read the old item. Selecting Allow authorized one access, so the next read prompted again.

I removed the base record and its two credential chunks, then authenticated again:

% service=pi-mcp-adapter.oauth
% base=sha256-cace491b69555e8d0f77747d47ae54e31ce4cc322fe51a7bdcf64402f3676ebf
% security dump-keychain 2>/dev/null \
    | sed -n 's/^[[:space:]]*"acct"<blob>="\([^"]*\)"/\1/p' \
    | rg "^${base}(\.chunk\.[a-f0-9]{16}\.[0-9]+)?$" \
    | while read -r account; do
        security delete-generic-password -s "$service" -a "$account"
      done
password has been deleted.
password has been deleted.
password has been deleted.

A future Homebrew Node update would change its code hash again. The official Node binary installed by Mise has a stable Developer ID requirement instead:

% codesign -dr - ~/.local/share/mise/installs/node/latest/bin/node 2>&1
designated => identifier node and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = HX7739G8FX

Installing Pi through that Node avoids tying Keychain access to one Homebrew binary hash:

% npm install -g --ignore-scripts @earendil-works/pi-coding-agent

∎

— § —

Reply via email

#bloggify #dev #macos #pi #security

pi: approve several pull requests at once

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 08 Sep 2026 12:15:25 +0200

♠ Previously.

Problem statement: how can I approve several reviewed pull requests without opening each one individually?

I pasted six pull request URLs into Pi and asked it to approve all of them. It ran the same gh command for each URL:

prs=(
  https://github.com/[redacted]/[redacted]/pull/7692
  https://github.com/[redacted]/[redacted]/pull/7695
  https://github.com/[redacted]/[redacted]/pull/7689
  https://github.com/[redacted]/[redacted]/pull/7694
  https://github.com/[redacted]/[redacted]/pull/7693
  https://github.com/[redacted]/[redacted]/pull/36196
)
status=0
for pr in "${prs[@]}"; do
  if gh pr review --approve "$pr"; then
    printf 'APPROVED %s\n' "$pr"
  else
    printf 'FAILED %s\n' "$pr" >&2
    status=1
  fi
done
exit "$status"

APPROVED https://github.com/[redacted]/[redacted]/pull/7692
APPROVED https://github.com/[redacted]/[redacted]/pull/7695
APPROVED https://github.com/[redacted]/[redacted]/pull/7689
APPROVED https://github.com/[redacted]/[redacted]/pull/7694
APPROVED https://github.com/[redacted]/[redacted]/pull/7693
APPROVED https://github.com/[redacted]/[redacted]/pull/36196

One prompt, six approvals, no repository checkouts. ∎

— § —

Reply via email

#bloggify #dev #git #pi

espanso: restart a stale daemon after upgrading

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 07 Sep 2026 15:03:27 +0200

♠ Problem statement: why did Espanso stop expanding text while its service was running?

The CLI reported a healthy service on version 2.4.1:

% espanso --version
2.4.1
% espanso status
espanso is running

The daemon log disagreed:

% rg 'espanso version:' ~/Library/Caches/espanso/espanso.log | tail -1
16:50:24 [daemon(2251)] [INFO] espanso version: 2.4.0

The app had been upgraded on September 3, but the launcher and daemon still came from August 24. Restarting the worker had not replaced either one:

% ps -p 1899,2251,92631 -o pid,lstart,command
  PID STARTED                      COMMAND
 1899 Mon Aug 24 16:50:17 2026     /Applications/Espanso.app/Contents/MacOS/espanso launcher
 2251 Mon Aug 24 16:50:23 2026     /Applications/Espanso.app/Contents/MacOS/espanso daemon
92631 Mon Sep  7 14:55:26 2026     /Applications/Espanso.app/Contents/MacOS/espanso worker --monitor-daemon --start-reason manual_restart

A full service restart replaced all three processes:

% espanso service restart
% ps -p "$(pgrep -d, -f '/Applications/Espanso.app/Contents/MacOS/espanso (launcher|daemon|worker)')" -o pid,lstart,command
  PID STARTED                      COMMAND
 3049 Mon Sep  7 15:01:47 2026     /Applications/Espanso.app/Contents/MacOS/espanso launcher
 3063 Mon Sep  7 15:01:47 2026     /Applications/Espanso.app/Contents/MacOS/espanso daemon
 3064 Mon Sep  7 15:01:47 2026     /Applications/Espanso.app/Contents/MacOS/espanso worker --monitor-daemon
% rg 'espanso version:' ~/Library/Caches/espanso/espanso.log | tail -1
15:01:47 [daemon(3063)] [INFO] espanso version: 2.4.1

Text expansion worked again.

So now I’ll need to remember to restart espanso whenever it is upgraded. ∎

— § —

Reply via email

#bloggify #dev #macos

typst: color-coded choir parts

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 03 Sep 2026 16:54:39 +0200

♠ Previously.

Problem statement: a plain lyrics sheet does not say who sings what. In a choir rehearsal one has to annotate every line by hand: sopranos here, everybody on the refrain.

Two files, one helper, no music engraving:

% ls
AGENTS.md  main.pdf  main.typ  template.typ

template.typ holds the styling only — page, font, headings:

#let template(doc) = {
  set page(paper: "a4", margin: (left: 2cm, right: 2cm, top: 2cm, bottom: 2cm))
  set text(font: "Libertinus Serif", size: 11pt, lang: "en")
  set heading(numbering: none)

  show heading.where(level: 1): it => {
    set text(size: 24pt, weight: "bold")
    set align(center)
    it
    v(0.5em)
  }

  doc
}

main.typ holds the content, plus a parts_line() that draws one colored square per voice above the lyrics:

#let parts_line(parts_colors, lyrics) = {
  let squares = parts_colors.map(((part, color)) => {
    box(width: 1em, height: 1em, fill: color, stroke: rgb("#000"), inset: 0pt)
  }).join(h(0.2em))

  set align(left)
  [#squares \ #lyrics]
}

#let soprano = rgb("#ffc0cb")
#let alto = rgb("#90ee90")
#let tenor = rgb("#ffffff")
#let bass = rgb("#87ceeb")
#let all = rgb("#f0f0f0")

The verse then reads almost like the score:

== Verse 1

#parts_line((("S", soprano), ("B", bass)), "Oh the weather outside is frightful,")
#parts_line((("all", all),), "And since we've no place to go.")
#parts_line((("S", soprano), ("A", alto), ("T", tenor), ("B", bass)), "Let It Snow! Let It Snow! Let It Snow!")

Two pages, a sixth of a second:

% typst --version
typst 0.15.1 (unknown commit)

% time typst compile main.typ
typst compile main.typ  0.04s user 0.07s system 63% cpu 0.169 total

Tenor is white and only visible because of the black stroke, which is a happy accident: on a photocopy it still reads as a distinct part. The "S" and "B" strings are ignored by the helper — they are there so the source stays readable without counting colors. ∎

— § —

Reply via email

#bloggify #dev

pre-commit: internal hook repos, take two

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 03 Sep 2026 14:03:03 +0200

♠ Previously.

Problem statement: an internal hook repo has to be cloned by CI and by every developer, and the credentials each side owns are not the same.

A .pre-commit-config.yaml refers to hooks by repository:

repos:
  - repo: https://github.com/<org>/pre-commit-hooks
    rev: 528e165cff8a11bc4f9f49a9b25f3249e09e4237 # frozen: v0.0.22
    hooks:
      - id: just-format

Before every run, prek clones each of those repositories into its cache. A public repo clones anonymously and nobody thinks about it again. Ours moved out of a personal account into an org-owned repo, which is INTERNAL — so the clone now needs credentials, from whoever is running.

In June I gave the runners a short-lived app token and called it done. CI went green. The next morning, a coworker could no longer commit:

$ prek run -a
error: Failed to init hooks
  caused by: Failed to initialize repo `https://github.com/<org>/pre-commit-hooks`
  caused by: Command `git full clone` exited with an error:

[status]
exit status: 128

[stderr]
fatal: could not read Username for 'https://github.com': terminal prompts disabled

Not a permissions problem: the same coworker could open and clone the repo by hand. prek clones non-interactively, and an internal repo over https:// needs a credential helper to answer. Mine had a token cached; theirs did not:

% git -c credential.helper= clone https://github.com/<org>/pre-commit-hooks
Cloning into 'pre-commit-hooks'...
fatal: could not read Username for 'https://github.com': terminal prompts disabled

SKIP= does not rescue this. The clone happens while hooks are being initialized, long before SKIP is consulted, so the whole run dies and commits with it. Three days after the migration, I reverted it everywhere:

4f74a46a Revert: ci: migrate pre-commit hooks to <org>/pre-commit-hooks
ea747ebe Revert: ci: migrate pre-commit hooks to <org>/pre-commit-hooks
4ec7e8063 Revert: ci: migrate pre-commit hooks to <org>/pre-commit-hooks

That June token was handed to git as a URL rewrite: https://github.com/ became https://x-access-token:$TOKEN@github.com/ on the runner. I had also considered git@github.com:<org>/pre-commit-hooks back then, and dropped it because runners have no SSH key. The premise was right and the conclusion was backwards — a rewrite runs in whichever direction we point it, and I had pointed it at the side that could not adapt.

So the config takes the URL that developers already have credentials for:

-  - repo: https://github.com/<org>/pre-commit-hooks
-    rev: 528e165cff8a11bc4f9f49a9b25f3249e09e4237 # frozen: v0.0.22
+  - repo: git@github.com:<org>/pre-commit-hooks
+    rev: 3030e9389488a2e4543a4d5d45d78a63bb591864 # frozen: v1.1.0

And the keyless runner rewrites that SSH prefix back to HTTPS, with the same short-lived app token as before:

- name: Authenticate git for the internal hooks repo
  env:
    TOKEN: ${{ steps.generate-token.outputs.token }}
  run: git config --global url."https://x-access-token:${TOKEN}@github.com/<org>/".insteadOf "git@github.com:<org>/"

A warm cache is what hid the bug the first time, so both paths were verified against a cold one. The developer path, cloning over SSH:

% XDG_CACHE_HOME=$(mktemp -d) prek run -a just-format
Format Justfiles.........................................................Passed

The runner path, with SSH made unusable and nothing but the rewrite in $HOME:

% export HOME=$(mktemp -d)
% printf '[url "https://x-access-token:%s@github.com/<org>/"]\n\tinsteadOf = git@github.com:<org>/\n' "$(gh auth token)" > "$HOME/.gitconfig"
% SSH_AUTH_SOCK= GIT_SSH_COMMAND=/bin/false XDG_CACHE_HOME="$HOME/.cache" prek run -a just-format
Format Justfiles.........................................................Passed

That second run also exposed where the rewrite belongs. Asking for a single hook populated the cache with every hook repo in the config:

% ls "$HOME/.cache/prek/repos" | wc -l
      13

prek initializes all of them up front, so the rewrite goes in every job that runs prek — not only the linting one. ∎

— § —

Reply via email

#bloggify #dev #git #pre-commit #ssh

starship: hyperlink github PR number

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 03 Sep 2026 14:02:52 +0200

♠ Previously.

Problem statement: the GitHub PR number in my Starship prompt was plain text.

The custom module already asked gh for the PR number and cached it with bkt:

[custom.github_pr]
command = "bkt --ttl=10m --scope=\"$(git rev-parse --show-toplevel):$(git branch --show-current)\" -- gh pr view --json number --jq '\"#\" + (.number | tostring)' 2>/dev/null"
when = "git rev-parse --is-inside-work-tree 2>/dev/null"
format = " [$output](magenta)"
ignore_timeout = true

An OSC 8 escape sequence can turn #78 into a terminal hyperlink. I first used ESC \ to terminate each sequence. The template produced the expected bytes, but zsh prompt expansion consumed each backslash and left an incomplete escape sequence:

missing hyperlink sequence; output=b'...\x1b]8;;https://github.com/thiagowfx/.dotfiles/pull/78\x1b#78\x1b]8;;\x1b...'

BEL terminates OSC 8 without passing a backslash through zsh:

diff --git starship/.config/starship.toml starship/.config/starship.toml
index 87e83794..739ee62f 100644
--- starship/.config/starship.toml
+++ starship/.config/starship.toml
@@ -54,7 +54,7 @@ format = " [⎇ $output]($style)"
 style = "bold yellow"

 [custom.github_pr]
-command = "bkt --ttl=10m --scope=\"$(git rev-parse --show-toplevel):$(git branch --show-current)\" -- gh pr view --json number --jq '\"#\" + (.number | tostring)' 2>/dev/null"
+command = "bkt --ttl=10m --scope=\"$(git rev-parse --show-toplevel):$(git branch --show-current)\" -- gh pr view --json number,url --template '{{printf \"\\033]8;;%s\\007#%v\\033]8;;\\007\" .url .number}}' 2>/dev/null"
 when = "git rev-parse --is-inside-work-tree 2>/dev/null"
 format = " [$output](magenta)"
 ignore_timeout = true

I tested the full Starship-to-zsh path against the branch for PR #78:

% tmp=$(mktemp -d)
% git -C "$tmp" init -q
% git -C "$tmp" remote add origin https://github.com/thiagowfx/.dotfiles.git
% git -C "$tmp" switch -q -c renovate/web-tree-sitter-0.x
% (cd "$tmp" && STARSHIP_SHELL=zsh starship prompt) |
    zsh -c 'prompt=$(cat); print -nP -- "$prompt"' |
    python3 -c 'import sys
out = sys.stdin.buffer.read()
expected = b"\x1b]8;;https://github.com/thiagowfx/.dotfiles/pull/78\x07#78\x1b]8;;\x07"
assert expected in out
print("PASS: zsh-rendered Starship prompt links #78 to PR URL")'
PASS: zsh-rendered Starship prompt links #78 to PR URL

Cmd + click on the number now opens the PR in Ghostty.

That test covered zsh only. Bash exposed a prompt alignment bug two weeks later. Text from the command line appeared at the right edge and before the prompt.

Starship did not mark the complete OSC 8 sequence as non-printing for Bash:

\[\x1b]8;;https://github.com\]/[redacted]/[redacted]/pull/7163\x07#7163\[\x1b]8;;\x07

Only ESC ] 8 ;; https://github.com was inside Readline’s \[ and \] markers. Bash counted the remaining URL as visible prompt text, so its cursor position was wrong.

I reverted the hyperlink:

 [custom.github_pr]
-command = "bkt --ttl=10m --scope=\"$(git rev-parse --show-toplevel):$(git branch --show-current)\" -- gh pr view --json number,url --template '{{printf \"\\033]8;;%s\\007#%v\\033]8;;\\007\" .url .number}}' 2>/dev/null"
+command = "bkt --ttl=10m --scope=\"$(git rev-parse --show-toplevel):$(git branch --show-current)\" -- gh pr view --json number --jq '\"#\" + (.number | tostring)' 2>/dev/null"
 when = "git rev-parse --is-inside-work-tree 2>/dev/null"
 format = " [$output](magenta)"
 ignore_timeout = true

The PR number is plain text again. The Bash prompt now stays aligned.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #dev #git

pi: enable fullscreen TUI mode

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 03 Sep 2026 13:48:57 +0200

♠ Today I learned: pi can keep its editor and footer at the bottom of the terminal with fullscreen TUI mode, similarly to Claude Code.

The regular mode leaves terminal scrollback in charge. The --tui-mode option switches to a viewport managed by Pi:

% pi --help | rg -- '--tui-mode|TUI mode'
  --tui-mode <mode>              TUI mode: regular (default) or fullscreen

For an one-off session:

% pi --tui-mode fullscreen

For a persistent default, add tuiMode to ~/.pi/agent/settings.json:

diff --git pi/.pi/agent/settings.json pi/.pi/agent/settings.json
index 7d2fee8b..57fd5094 100644
--- pi/.pi/agent/settings.json
+++ pi/.pi/agent/settings.json
@@ -41,6 +41,7 @@
   "showCacheMissNotices": true,
   "theme": "catppuccin-mocha",
   "treeFilterMode": "user-only",
+  "tuiMode": "fullscreen",
   "warnings": {
     "anthropicExtraUsage": false
   }

The transcript scrolls inside Pi. The editor, queued messages, widgets, and footer stay docked at the bottom.

The same setting is available under /settings as TUI mode. Pi 0.84.4 supports regular and fullscreen.

Fullscreen mode also owns mouse selection. Dragging with the primary mouse button copies the selected text on release by default:

{
  "fullscreenCopyOnSelect": true
}

Pi confirms the copy with a reverse-video Copied! flash in the top-right corner for one second, which is quite easy to miss. ∎

— § —

Reply via email

#bloggify #dev #pi

AgentsView vs fast-resume

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 01 Sep 2026 20:55:14 +0200

♠ Previously.

Problem statement: does AgentsView replace fast-resume, or do they solve different problems?

I installed both and compared their current releases:

% agentsview --version
agentsview v0.41.1 (commit a902515a, built 2026-08-18T13:34:56Z)
% fr --version
fr 2.11.2

fr has one job: search local agent sessions and resume one in its native agent. Search is typo-tolerant. Enter replaces fr with the original agent process and restores its working directory:

Agent stores ──► adapters ──► normalized sessions ──► Tantivy index
                                                        │
Terminal ◄──── resume handoff ◄──── TUI/search ◄────────┘

AgentsView is a persistent SQLite archive with a desktop app, local web UI, CLI, REST API, MCP server, cost reports, and session health signals. Its search surface is correspondingly larger:

% agentsview session search --help | grep -E -- '--(fts|hybrid|regex|semantic|in )'
      --fts                      Fast tokenized FTS over messages only
      --hybrid                   Hybrid semantic + full-text search (reciprocal rank fusion)
      --in string                Comma-separated sources: messages,tool_input,tool_result (default all)
      --regex                    Treat pattern as an RE2 regex
      --semantic                 Semantic (vector) search over user/assistant messages

AgentsView documents 59 session sources against fr’s 12. Resume support is the opposite: AgentsView maps nine agent types, while fr has handoff commands for all twelve, including Pi:

# fast-resume
Pi → pi --session <id>

# AgentsView resume map
claude, codex, traex, copilot, cursor, gemini, opencode, amp, kiro

The local footprint shows the difference in scope:

% du -sh /opt/homebrew/Cellar/fast-resume/2.11.2 \
    /Applications/AgentsView.app ~/.cache/fast-resume ~/.agentsview
14M     /opt/homebrew/Cellar/fast-resume/2.11.2
116M    /Applications/AgentsView.app
772K    /Users/tperrotta/.cache/fast-resume
28M     /Users/tperrotta/.agentsview

fr treats its index as a disposable cache. AgentsView keeps sessions until agentsview prune removes them. It also sends an anonymous daily liveness ping and checks for updates; fr 2.11.2 has neither mechanism.

Given the aforementioned trade-offs: I am happier with fr. KISS. ∎

— § —

Reply via email

#ai #bloggify #dev #pkm #privacy

kargo: quote numeric-looking image tags

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 01 Sep 2026 15:39:56 +0200

♠ Previously.

Problem statement: a Kargo promotion turned a valid all-digit Git SHA into scientific notation.

The Freight contained an image tag and a Helm chart version:

15abd266dc635e7b9f3fe740441a73cd3cd549e7  937844257  0.5.1

937844257 looked like a build number. It was the first nine characters of a real commit:

% git rev-parse 937844257
9378442576c62b45cba4b41d8b4eb09a763da1ad

The Stage passed the tag directly to yaml-update:

- uses: yaml-update
  config:
    path: ./gitrepo/apps/overlays/g02/sessions/patches.yaml
    updates:
      - key: 1.value.image.tag
        value: ${{ imageFrom(vars.imageRepo).Tag }}

Kargo coerces expression results that look like JSON numbers. The promotion log showed the result:

Updated ./gitrepo/apps/overlays/g02/sessions/patches.yaml

- 1.value.image.tag: 9.37844257e+08
- 3.value: ~0.5.0

The generated Git diff therefore pointed at an image tag that did not exist:

 image:
-  tag: cd3a31000
+  tag: 9.37844257e+08

Kargo provides quote() for exactly this case:

-        value: ${{ imageFrom(vars.imageRepo).Tag }}
+        value: ${{ quote(imageFrom(vars.imageRepo).Tag) }}

I changed all image-tag writes across the eight rollout Stages and checked the same condition before and after:

before fix: 20 unsafe image-tag updates
after fix: 0 unsafe image-tag updates

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

An older Kargo bug report even used an all-digit short SHA as its example. Git hashes contain hexadecimal characters, but none of those characters has to be a letter.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#argocd #bloggify #dev #git #kubernetes

external secrets: repair a CRD upgrade

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

♠ Problem statement: an External Secrets Operator upgrade left different clusters in different states, and a normal ArgoCD retry could not repair them.

The upgrade moved from ESO 0.9.20 to 2.9.0. Two CRDs rendered at about 707 KB. Client-side apply tried to store each complete manifest in an annotation capped at 262144 bytes:

metadata.annotations: Too long: may not be more than 262144 bytes

Server-side apply avoids kubectl.kubernetes.io/last-applied-configuration:

% kubectl apply --server-side --force-conflicts -f crd-secretstores.yaml

That fixed only half of the problem. The old chart configured CRD conversion through the ESO webhook. The new chart omitted the conversion block, but server-side apply does not remove a field that the desired manifest never mentions. Reads still went to a /convert endpoint that ESO 2.9.0 no longer served:

conversion webhook for external-secrets.io/v1beta1, Kind=SecretStore failed

The conversion field had to be removed before the new schema was applied:

% kubectl patch crd/secretstores.external-secrets.io --type=merge \
    -p '{"spec":{"conversion":{"strategy":"None","webhook":null}}}'
% kubectl apply --server-side --force-conflicts -f crd-secretstores.yaml

Order matters. Applying the schema first creates a window where every SecretStore read reaches the dead webhook.

One fixed sequence was still not enough. A cluster with the old controller and old CRDs was healthy. Applying the v1 CRDs before ArgoCD deployed ESO 2.9.0 would instead produce this controller error:

no matches for kind

I made the upgrade script classify live state before changing it:

case "$IMG_TAG:$V1_COUNT:$WEBHOOK_COUNT" in
  v2.9.*:3:0|2.9.*:3:0)  CLASS=DONE ;;
  v2.9.*:*|2.9.*:*)      CLASS=NEEDS-CRD-FIX ;;
  v0.9.*:0:*|0.9.*:0:*)  CLASS=NOT-STARTED ;;
  v0.9.*:*|0.9.*:*)      CLASS=MIXED ;;
  *)                      CLASS=UNKNOWN ;;
esac

DONE is a no-op. NEEDS-CRD-FIX patches conversion, renders all three CRDs from the pinned Helm chart, applies them server-side, and restarts the controller. MIXED and UNKNOWN stop instead of guessing.

NOT-STARTED also stops by default. Its separate opt-in path enables ArgoCD auto-sync, waits for the new controller to land, then asks for a second run:

$ALLOW_NOT_STARTED || die "refusing without --allow-not-started"
run kc patch app external-secrets -n argocd --type=merge \
  -p '{"spec":{"syncPolicy":{"automated":{
    "enabled":true,"prune":true,"selfHeal":true
  }}}}'
info "Then: $0 $GARDEN"

The final checks compare custom resource counts, read all three resource kinds, check every ExternalSecret, scan controller logs, and require ArgoCD to converge:

for k in clustersecretstores secretstores externalsecrets; do
  kc_ok get "$k.external-secrets.io" -A || FAIL=true
done

if (( CSS_AFTER < CSS_BEFORE || SS_AFTER < SS_BEFORE || \
      ES_AFTER < ES_BEFORE )); then
  FAIL=true
fi

APP="$(kc get app external-secrets -n argocd \
  -o "jsonpath={.status.sync.status}/{.status.health.status}")"
[[ "$APP" == "Synced/Healthy" ]] || FAIL=true

The repair became an idempotent state transition instead of a command sequence.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#argocd #bloggify #dev #kubernetes

argocd: sync windows block pruning

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

♠ Problem statement: deleting an ArgoCD Application from Git (GitOps) does not guarantee it will disappear from the cluster.

We removed an app-of-apps child from every garden it lived in and merged the PR. The parent synced clean:

phase: Succeeded
message: successfully synced (all tasks run)

An hour later, six clusters paged 🚨 with ArgoCdAppSyncUnknown. The child was still there:

sync: Unknown
health: Healthy
deletionTimestamp:
finalizers:

No deletionTimestamp, no finalizer stuck — it was never asked to delete. The controller logs said why:

level=info msg="Sync prevented by sync window" application=datastore-all
    dest-namespace=infra-services project=garden

The app was listed in an AppProject sync window:

{
  "kind": "allow",
  "schedule": "0 23 * * *",
  "duration": "1h",
  "timeZone": "America/New_York",
  "applications": ["...", "datastore-all", "..."]
}

An allow window means auto-sync — including pruning — only runs inside it. The parent app re-rendered without the child and dropped it from status.resources, but pruning a tracked resource is itself a sync operation, so ArgoCD deferred it to 23:00–00:00 New York time. Meanwhile the orphaned Application still pointed at a values file that no longer existed on HEAD:

Failed to load target state: failed to generate manifest for source 1 of 2:
    ... open apps/overlays/g28/datastore-all/values.yaml: no such file or directory

Manifest generation failure is a sync status of Unknown, which is exactly what fired the alert.

The object had no finalizer, so deleting it directly only removes the bookkeeping, not the workload it deployed:

% kubectl -n argocd delete app datastore-all

The actual infra-services resources it created are still tracked by label and get pruned once the window opens — or by hand in the meantime. ∎

— § —

Reply via email

#argocd #bloggify #dev #kubernetes

★ TV Shows

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

♠ Previously.

I added a TV shows page with a sample of my favorites, inspired by Michael Harley’s watching page and Michael Stapelberg’s series page.

The list lives in YAML. Trakt keeps my full watch history; this file stays small, alphabetical, and intentionally incomplete:

shows:
  # keep-sorted start case=no by_regex=title:\s+"?([^"]+)
  - title: 13 Reasons Why
    years: 2017–2020
    seasons: 4
    url: https://www.themoviedb.org/tv/66788-13-reasons-why
    cover: https://media.themoviedb.org/t/p/w500/nel144y4dIOdFFid6twN5mAX9Yd.jpg
  - title: 3%
    years: 2016–2020
    seasons: 4
    url: https://www.themoviedb.org/tv/68467-3
    cover: https://media.themoviedb.org/t/p/w500/uLBJSLuAQ8UqLIKZVWG3uNEXwjt.jpg
  # keep-sorted end

A custom Hugo layout turns each record into a poster card. Show details and posters come from The Movie Database:

<div class="tv-shows-grid">
  {{- range $data.shows }}
  <div class="tv-shows-item">
    <a href="{{ .url }}" title="{{ .title }} ({{ .years }})">
      <img class="tv-shows-cover" src="{{ .cover }}" alt="Poster for {{ .title }}" loading="lazy" decoding="async" referrerpolicy="no-referrer">
      <div class="tv-shows-item-title">{{ .title }}</div>
    </a>
    <div class="tv-shows-item-meta">
      {{ .years }} &middot; {{ .seasons }} {{ cond (eq .seasons 1) "season" "seasons" }}
    </div>
  </div>
  {{- end }}
</div>

The data has a JSON schema, and the page now sits next to Books in the More menu:

% git show --stat --oneline 97dc4bde16
97dc4bde16 add TV shows page
6 files changed, 305 insertions(+), 3 deletions(-)

TV show recommendations are almost always welcome. ∎

— § —

Reply via email

#bestof #bloggify #serenity

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. ∎

— § —

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

∎

— § —

Reply via email

#bloggify #dev #meta

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”. ∎

— § —

Reply via email

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

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. ∎

— § —

Reply via email

#bloggify #dev #terraform #terrateam

goodreads: a books page from a private shelf

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

♠ Previously.

Problem statement: I wanted a /books page with covers, but my Goodreads shelf is private and the API has been dead since 2020.

% curl -sS "https://www.goodreads.com/review/list_rss/7873832?shelf=read" \
    -o /tmp/rss.txt -w "%{http_code}\n"
401
% head -c 42 /tmp/rss.txt
Sorry, that person's shelf is private

The CSV export needs no auth, no key, no scraping — one click under My Books → Import/Export. It carries 1469 rows and everything worth rendering, except covers:

% head -1 ~/Downloads/goodreads_library_export.csv | tr ',' '\n' | grep -ciE "cover|image"
0

So ci/goodreads_to_books.py reads the CSV, keeps the five-star read rows, and writes data/books.yaml for Hugo to render:

% just goodreads-import
ci/goodreads_to_books.py ~/Downloads/goodreads_library_export.csv
wrote 101 books in 2 categories to ~/Workspace/perrotta.dev/data/books.yaml (101 kept their category, series, note and cover; 101 covers, 0 fetched; 63 excluded)

101 on display, 63 excluded: the 164 five-star rows, minus the textbooks and language courses nobody needs a recommendation for.

Covers come from each book’s public page — those stay readable even when the shelf is not, and the og:image points straight at the CDN:

% curl -sL "https://www.goodreads.com/book/show/22034" |
    grep -o '<meta property="og:image" content="[^"]*"'
<meta property="og:image" content="https://m.media-amazon.com/images/S/compressed.photo.goodreads.com/books/1394988109i/22034.jpg"

Which lands in the data file, one fetch per book, ever:

      - title: The Godfather
        author: Mario Puzo
        year: 1969
        rating: 5
        url: https://www.goodreads.com/book/show/22034
        cover: https://m.media-amazon.com/images/S/compressed.photo.goodreads.com/books/1394988109i/22034.jpg

That “ever” is the whole trick. Crawling 164 pages back to back gets an AWS WAF challenge — HTTP 202 with an empty body — and it sticks around for a few minutes:

  Thinking, Fast and Slow: HTTP 202, 0 bytes
  Blindness: HTTP 202, 0 bytes
  Freakonomics + Superfreakonomics: HTTP 202, 0 bytes
giving up after 5 failures in a row; run again later to fetch the remaining 43 covers

So the importer treats a cover as a cache entry rather than a build step: three seconds between requests, a save every ten covers, and a bail-out after five consecutive failures. A blocked run keeps what it got, and the next run resumes:

        book["cover"] = fetch_cover(book)
        if book["cover"]:
            fetched += 1
            failures = 0
            if fetched % COVER_SAVE_EVERY == 0:
                save()

Three runs, spaced by coffee, and every cover was in. Re-imports are now free — 0 fetched above — and idempotent, which matters because the CSV is the source of truth for titles and ratings, while the YAML owns the curation: categories, series names, notes, an excluded list for the books I don’t want on display, and an overrides list for when the shelved edition is not the one worth linking:

overrides:
  - id: "15779555"
    title: The Godfather
    url: https://www.goodreads.com/book/show/22034

That entry is the Brazilian translation of The Godfather. It is what I read, but O Poderoso Chefão is not what I would recommend.

% git --no-pager show --stat --oneline 7c8785dbb4
7c8785dbb4 books: add fiction favorites
 data/books.yaml | 348 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 348 insertions(+)

Fiction first. Non-fiction is still sitting unstaged, which is its own kind of review queue.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #dev #meta #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. ∎

— § —

Reply via email

#ai #bloggify #dev #git #pi

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. ∎

— § —

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. ∎

— § —

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!). ∎

— § —

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. ∎

— § —

Reply via email

#bloggify #coding #dev #meta

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. ∎

— § —

Reply via email

#argocd #bloggify #dev #kubernetes

★ 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

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. ∎

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

∎

— § —

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. ∎

— § —

Reply via email

#ai #bloggify #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. ∎

— § —

Reply via email

#bloggify #coding #dev #meta

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. ∎

— § —

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. ∎

— § —

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. ∎

— § —

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. ∎

— § —

Reply via email

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

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

∎

— § —

Reply via email

#bloggify #coding #dev #macos