hrih.si | Notes

Check a draft for AI tells, in the browser or from the command line

Hatim Rih — Tue, 03 Nov 2026 00:00:00 GMT

I edit every draft for this site against a list of the habits readers associate with AI writing: contrast framing, “-ing” tails, lists of three, flat rhythm, dashes. The list now runs in two places.

The AI tells checker is the quick one. Paste a draft, and it marks the lines in the text and explains each pattern beside it. It runs in your browser, so nothing is uploaded.

For files, or for an agent, the same rules live in my copywriter skill as a Python script with no dependencies:

python scripts/check_copy.py draft.md

On the checker’s own example, a launch post written with the habits on purpose, the report includes:

  Findings: 23 (rewrite 15, cap 4, watch 4)
    L3    REWRITE  contrast framing: "It's not just a calendar — it's"
    L3    REWRITE  stock phrase: "In today's"
    L5    REWRITE  '-ing' tail: ", ensuring"
    L5    REWRITE  self-answered question: "The result? Calmer weeks."

Each finding has a line, a level and a hint. Strip and rewrite findings get fixed every time; cap and watch findings only matter when they repeat or cluster. The script gives no score and no verdict, on purpose: a flagged line can be right in context.

If you have a sample of your own writing, compare the draft with it:

python scripts/check_copy.py draft.md --voice sample.md

The report adds a table of sentence length, punctuation and person per 100 words for both texts and marks the rows that differ by more than 60%. Your sample also raises the dash allowance to one and a half times your own rate, so a writer who uses dashes isn’t flagged for them.

In Claude Code, the skill runs the script on its own drafts. To install it:

/plugin marketplace add R-Hatim/hrih-skills
/plugin install copywriter@hrih-skills

Every pattern, with a before and after, is in Signs of AI writing.

Check a saved patch by its changed lines, not its context

Hatim Rih — Tue, 03 Nov 2026 00:00:00 GMT

To check that some files still hold exactly the changes in a saved patch, compare only the added and removed lines, from the patch and from git diff. Leave the context out. It belongs to whoever touched the file last, and a commit that moves it shouldn’t stop your check:

FILES="src/layouts/Base.astro src/lib/content.ts scripts/og-images.mjs scripts/content-paths.mjs src/styles/global.css"
git diff -- $FILES | grep -E '^[+-]' | grep -vE '^(\+\+\+|---) ' > /tmp/now.txt
grep -E '^[+-]' ai-tells-shared.patch | grep -vE '^(\+\+\+|---) ' > /tmp/saved.txt
cmp /tmp/now.txt /tmp/saved.txt

The first grep keeps the lines that start with + or -: the changes, plus each file’s two header lines. The second drops the headers, --- a/… and +++ b/…. cmp exits 0 when the two lists match and names the first difference when they don’t, and diff /tmp/saved.txt /tmp/now.txt shows all of it.

Why the stricter check would have failed

On 30 October, the AI tells checker for hrih.si sat uncommitted in the site’s checkout, waiting for a release job on 3 November. It shared five files with other work. So the job’s first step checked those five against ai-tells-shared.patch, to be sure they held this work’s changes and nobody else’s.

The same evening I committed a change to the note pages’ sidebar. It replaced the two CSS rules right above the checker’s two lines in global.css. The checker’s lines didn’t change, but its patch now named context that was gone:

$ git apply --check -R ai-tells-shared.patch
error: patch failed: src/styles/global.css:161
error: src/styles/global.css: patch does not apply

The job would have stopped on Tuesday morning over lines it never touched, although its 37 changed lines were the same as before. The patch was regenerated that night and the check switched to the changed lines. On 3 November it passed on the same 37 lines.

What it still catches

It still stops the release when someone else edits one of those files without committing, because their lines show up in git diff and not in the patch. It also stops when anyone changes the work’s own lines without regenerating the patch. Commits by others to the same files no longer stop it, since they become part of what git diff compares against.

It doesn’t tell you whether the patch would still apply. When you need that, regenerate the patch from the tree with git diff -- $FILES > ai-tells-shared.patch, or apply it with git apply --3way, which falls back on a three-way merge when the context has moved.

The header filter also drops a changed line whose own text starts with -- or ++ . A removed SQL comment, -- old, reads --- old in the diff. CSS and TypeScript never hit it. For SQL, match the headers by their full form instead, with grep -vE '^(\+\+\+|---) (a/|b/|/dev/null)'.

"No space left on device" during docker build: what to prune and what to keep

Hatim Rih — Tue, 03 Nov 2026 00:00:00 GMT

Run docker system df to see what’s using the space, then docker builder prune -f. It removes only build cache that nothing uses and leaves images, containers and volumes alone. On 31 October, a docker compose build for Rubric’s pipeline filled its VM’s disk to 100%, and that one command freed 1.44 GB and brought it back to 84%.

See where the space went

docker system df lists images, containers, local volumes and build cache, each with what it calls reclaimable. That day the build cache was 4.6 GB, 1.44 GB of it reclaimable. Here’s the same VM today:

$ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          5         2         4.721GB   3.263GB (69%)
Containers      2         2         116.7MB   0B (0%)
Local Volumes   2         0         621.7MB   621.7MB (100%)
Build Cache     19        0         3.179GB   0B

Reclaimable means no container uses it right now. It doesn’t mean nothing needs it.

The safe one

docker builder prune -f

By default it deletes only dangling build cache, the layers no image refers to any more. -f skips the confirmation. With -a, it deletes all unused build cache, including the layers your next build would have reused, so that build runs npm ci and every step after it again.

The two that delete what the next run needs

Rubric’s jobs are one-shot containers, started by docker compose run --rm and removed when they finish. Between runs no container exists, so Docker counts everything they use as reclaimable.

docker image prune -a deletes every image no container uses, and between runs that includes the pipeline’s own image, the one the next scheduled job starts from.

docker volume prune -a deletes every named volume no container uses. Plain docker volume prune has only removed anonymous volumes since Docker 23. The pipeline keeps a checkout and a login in two named volumes, the 621.7 MB above at 100% reclaimable, and between runs no container holds them. Its database is a bind mount, ./data, which no prune touches. docker system prune leaves volumes alone unless you add --volumes, and even then it takes only anonymous ones.

Make rebuilds cheaper

Order the Dockerfile so a code change reuses the dependency layer:

COPY package.json package-lock.json ./
RUN npm ci --ignore-scripts --no-audit --no-fund
COPY src ./src

A change under src/ only rebuilds the layers from COPY src on, and npm ci comes from the cache, the same cache that builder prune -a throws away.

The real fix on this VM was the disk: the root volume was 19 GB on a 40 GB disk, and growing it gave builds 21 GB of room.

Reuse node_modules in a git worktree on Windows, and remove it safely

Hatim Rih — Tue, 03 Nov 2026 00:00:00 GMT

Create the worktree, give it the main checkout’s packages through a directory junction, and delete that junction before you remove the worktree. With the junction still in place, git worktree remove deleted the packages it pointed to when I tested it, and exited 0.

I needed a second worktree on 31 October. hrih.si’s main checkout had to stay exactly as it was until a release job ran on 3 November, because that job compared it with a saved patch. The llms.txt endpoint had to be built and tested in the meantime, so it went into a worktree on a branch of its own.

Create it

In PowerShell, from the main checkout:

git worktree add -b llms-txt ..\hrih-site-llms main
New-Item -ItemType Junction -Path ..\hrih-site-llms\node_modules -Target (Resolve-Path .\node_modules)

The worktree shares the repository’s history and gets its own files and branch. The junction makes its node_modules the very folder the main checkout uses, so npm run build and the tests run there straight away. A junction needs neither administrator rights nor Developer Mode, unlike a symbolic link.

Everything that writes into node_modules now writes into the main checkout’s copy. Astro and Vite keep their caches there, so both checkouts share them, and an npm install in the worktree would change the main checkout’s packages too.

Remove the junction first

In a test repository with the same layout, and node_modules git-ignored as usual, I removed a worktree five ways and checked whether a file in the linked packages survived:

How	Exit code	Packages survive
`git worktree remove`, junction in place	0	no
`git worktree remove --force`, junction in place	0	no
`[System.IO.Directory]::Delete(junction, $false)`, then `git worktree remove`	0	yes
`Remove-Item` on the junction	0	yes
`Remove-Item -Recurse -Force` on the junction	0	yes

That was Git for Windows 2.33.1 and PowerShell 7.4. Git didn’t even ask for --force: an ignored folder doesn’t count as a change, so the worktree looked clean, and git deleted its whole tree, through the junction. Git for Windows 2.54.0, from April 2026, stops at junctions instead, and leaves the junction and the worktree folder on disk. Removing the junction first gives the same clean result on any version.

So remove the link, then the worktree:

[System.IO.Directory]::Delete((Resolve-Path ..\hrih-site-llms\node_modules).Path, $false)
git worktree remove ..\hrih-site-llms
git branch -d llms-txt

Directory.Delete with $false removes the junction and never recurses, in PowerShell 7 and in Windows PowerShell 5.1 alike. PowerShell 7’s Remove-Item also detaches a junction without touching its target, even with -Recurse, but I haven’t tested 5.1’s. Give Directory.Delete a full path, as Resolve-Path does here. .NET resolves a relative path against the process’s working directory, and that isn’t always PowerShell’s current location. git branch -d only deletes a branch that’s been merged.

For llms.txt, the junction came out on 31 October, right after the commit on the branch, and the worktree on 3 November, once the branch was merged. The main checkout’s packages were intact both times.

Why your LLM summaries credit other people's posts to your site

Hatim Rih — Tue, 03 Nov 2026 00:00:00 GMT

Take your publication’s name out of the summary prompt, tell the model never to mention it, and give it the story’s site and author. Rubric’s two summary prompts said each summary was written “for Hrih News”, the name its pipeline still goes by, and 65 of the 1,027 summaries in the editions of 24 to 31 October named it. I took the name out on 31 October, and none of the 209 summaries since has used it.

What the model wrote

The usual openings were “Hrih News covers Doozy, an AI agent that answers questions in Slack threads…” and “Hrih News reports on Timestral…”. Three say outright that someone else’s post was on Hrih News. “A post on Hrih News describes a plan to use nixpkgs’ dependency chain as a blueprint for formally verifying…” is about a post on theorem.dev, and posts on brunborg.com and vhamolya.com got the same opening on 30 October. Every edition had some, between 4 and 12 a day.

On Rubric, a summary’s first sentence is also the story page’s meta description, so a wrong credit can end up in search results.

The line that did it

The summaries for stories ranked 21 and below come from this system prompt. The change, in the sentences that matter:

- You write a one-paragraph summary, at most 50 words, of one story for Hrih News, a daily edition for people who build technology products and companies.
+ You write a one-paragraph summary, at most 50 words, of one story for a daily tech edition read by people who build technology products and companies.
+ Never mention the edition or say the story appeared in it; when the source matters, name its publisher or author.

The prompt for the top 20 opened the same way and got the same two changes, the second as one more rule in its list.

The model only knew one publication

The two prompts behaved very differently, and the user messages show why. The top 20 get the source:

`Title: ${item.title}\nSite: ${siteName(item)}${item.author ? `\nAuthor: ${item.author}` : ""}\nURL: ${item.canonical_url}\n\n${body}`

The shorter summaries get the title and the text, nothing else:

`Title: ${it.title}\n\n${truncateToTokens(text ?? "", maxTokens).text || "(no text available)"}`

Of the 65, one was in the top 20 (of 160 summaries) and 64 below it (of 867). With no site or author to go on, the only publication the model had seen was the one in its instructions, so it used that. “For Hrih News” said who the summary was for, and the model read it as where the story came from.

After the change

Editions	Summaries	Naming the edition
24 to 31 October	1,027	65
1 November	59	0
2 November	43	0
3 November	107	0

The change only reaches new summaries, so the 65 already published still say it. And the shorter summaries still don’t get a site or an author, so they can’t name the publisher unless the text does. Passing both, as the top 20’s call does, would close that gap too.

Serve llms.txt from an Astro endpoint, built from your posts

Hatim Rih — Tue, 03 Nov 2026 00:00:00 GMT

Add an endpoint at src/pages/llms.txt.ts that builds the file from your content collections, with the same filter as your RSS feed. Astro writes it as a static llms.txt at build time, a post shows up there the day it’s published and never while it’s a draft, and nobody edits the file by hand. This is hrih.si’s, shortened:

import type {APIRoute} from 'astro';
import {getCollection} from 'astro:content';
import {writingUrl, noteUrl, listedNotes} from '../lib/content';

const line = (title: string, url: string, text: string) => `- [${title}](${url}): ${text}`;

export const GET: APIRoute = async ({site}) => {
  const abs = (path: string) => new URL(path, site).href;
  const posts = (await getCollection('writing', ({data}) => !data.draft && !data.sample))
    .sort((a, b) => b.data.date.valueOf() - a.data.date.valueOf());
  const notes = await listedNotes();
  const text = [
    '# hrih.si', '',
    '> Hatim Rih builds software and writes about AI and the work of programming.', '',
    '## Articles', ...posts.map(post => line(post.data.title, abs(writingUrl(post)), post.data.description)), '',
    '## Notes', ...notes.map(note => line(note.data.title, abs(noteUrl(note)), note.data.description)), '',
    '## Optional', line('Feed', abs('/rss.xml'), 'every essay and article in full, newest first'), '',
  ].join('\n');
  return new Response(text, {headers: {'Content-Type': 'text/plain; charset=utf-8'}});
};

The shape comes from llmstxt.org: a title, a one-line summary as a quote, then sections of links with a short description each. A section called Optional holds what a tool can skip when it’s short of room. The full file also has essays and articles under separate headings, the projects, and an About section.

Reuse the feed’s filter

The posts come through the same query as /rss.xml, and the notes through listedNotes(), the function the notes page uses. Whatever keeps a draft out of the feed keeps it out of llms.txt, and there’s no second list to forget.

Stop the release when it misses a post

Since 3 November, hrih.si’s release script reads the built file and stops if any item in either feed, or any project page in the sitemap, isn’t in it:

const llms = readFileSync('build/llms.txt', 'utf8');
const published = [
  ...['build/rss.xml', 'build/notes/rss.xml'].flatMap(file =>
    [...readFileSync(file, 'utf8').matchAll(/<item>[\s\S]*?<link>([^<]+)<\/link>/g)].map(match => match[1])),
  ...[...readFileSync('build/sitemap-0.xml', 'utf8').matchAll(/<loc>([^<]+\/projects\/[^<]+\/)<\/loc>/g)].map(match => match[1]),
];
const unlisted = published.filter(url => !llms.includes(`](${url})`));
if (!published.length || unlisted.length) throw new Error(`build/llms.txt is missing ${unlisted.join(', ')}`);

Check what AI crawlers get

robots.txt can allow everything while a firewall or a CDN rule still blocks a crawler, so ask as the crawler:

curl -s -o /dev/null -w "%{http_code} %{content_type}\n" -A "GPTBot" https://hrih.si/llms.txt
curl -s -o /dev/null -w "%{http_code} %{content_type}\n" -A "ClaudeBot" https://hrih.si/llms.txt

Both answer 200 text/plain; charset=utf-8.

What it’s worth

Google’s guide to its AI features says Search doesn’t use llms.txt, and that keeping one neither helps nor hurts. Between 18 and 31 October, Umami counted one visit to hrih.si from claude.ai, against 131 from google.com. It isn’t a traffic source. The file costs nothing to keep current, so I keep it for the assistants and agents that look for one, and Chrome’s Lighthouse checks for it in its agentic browsing audits.

Scheduled tasks in the Claude desktop app stop at a production deploy

Hatim Rih — Tue, 03 Nov 2026 00:00:00 GMT

Schedule the job up to the commit and leave the deploy to a person. A scheduled task in the Claude desktop app runs with nobody watching, and a production deploy wants someone there: in Auto mode the permission classifier blocks it, and in Manual mode the run waits at the prompt. Mine ran in Auto mode and stopped on 3 November at 08:05, one step short of publishing three pages on hrih.si, with the reason “Production Deploy”.

What the job did

ai-tells-publish was a one-time task, and its prompt held the whole release:

Check the tree: main level with origin, the shared files holding only this work’s changes, nobody else’s edits.
Switch the three pages from draft to published, draw their social cards, run the tests and the type check.
Commit the listed files and push to main.
Run bash deploy/deploy.sh.
Check the live pages, write the journal, send me a notice.

Steps 1 to 3 passed: 70 tests, no type errors, commit 2139922 pushed. Step 4 was blocked. The job stopped there and didn’t look for another way round, as its prompt said to do whenever a step failed.

Why the deploy was blocked

Each scheduled task runs in the permission mode saved with it, and this one was saved in Auto mode. In Auto mode, reads and edits in the project go ahead, and every other action passes a classifier first. Production deploys are on its default block list as a soft block, which you can lift by asking for the deploy in the conversation, or with an autoMode.allow rule in your user settings.

The task’s prompt told it to deploy and quoted my approval, and the deploy was blocked anyway. Later that morning, the same command was blocked the same way in a session I was in, until I wrote “Yes, deploy it” there.

An allow rule or Bypass mode would let the job through. For a job that ships to production with nobody watching, that removes the one check I want to keep.

The state it left behind

The worse problem was main. The commit had already switched the three pages to published, so the next deploy from any session would have shipped them, checked or not. The release went out at 08:18, from a session I was in, after the pages were checked again.

The pattern that works

Schedule everything up to the commit: the checks, the tests, the cards, the commit itself.
Push to a branch, not main, when the deploy may not follow, so main never holds work that hasn’t shipped.
End with a notice that carries the one command to run. With ntfy:

curl -fsS -H "Title: hrih.si: release ready" \
  -d "Checks passed, pushed to <branch>. Merge it, then run: bash deploy/deploy.sh" \
  "https://ntfy.sh/$NTFY_TOPIC"

The deploy is then one command in a session where you’re there to say yes.

Ubuntu Server only uses half the disk: grow the root volume with lvextend

Hatim Rih — Tue, 03 Nov 2026 00:00:00 GMT

Run sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv. It gives the root logical volume every free extent in its volume group and grows the ext4 filesystem on it in the same step, while it’s mounted, with no reboot. On the VM that runs Rubric’s pipeline, it took / from 19 GB at 84% to 38 GB at 42%.

Find the free space

lsblk          # the disk, the partition LVM uses, and the volume on it
sudo vgs       # VFree: space in the volume group that no volume uses yet
df -h /        # what the filesystem has

The VM runs Ubuntu 24.04.5 LTS on a 40 GB disk. lsblk showed the partition LVM uses, sda3, at 38 GB and the root volume on it at 19 GB, and vgs had the other half under VFree. When VFree holds what you’re missing, the one command is all it takes.

If VFree is zero but lsblk shows the disk bigger than the partition, which is what you see after enlarging a VM’s virtual disk, the space is outside LVM. Grow the partition and the physical volume first (growpart comes with the cloud-guest-utils package), then run the same lvextend:

sudo growpart /dev/sda 3
sudo pvresize /dev/sda3

Grow it

sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

-l +100%FREE adds all the free extents in the volume group, so you don’t have to work out a size. -r resizes the filesystem along with the volume, so there’s no separate resize2fs. ext4 can grow while it’s mounted, and / stayed in use the whole time. Afterwards:

$ df -h /
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv   38G   15G   21G  42% /

Growing is the easy direction. Shrinking ext4 needs it unmounted, so give the root volume what it needs rather than more than you’ll use, if you plan to keep free space for another volume or for snapshots.

Why the installer left half

Ubuntu Server’s guided install with LVM sizes the root volume from the volume group: all of it under 10 GiB, 10 GiB up to 20, half of it up to 200 GiB, and 100 GiB above that. The rule is scaled_rootfs_size in the installer’s source, and the space it leaves is meant for snapshots and for growing volumes later. A 38 GB volume group gets 19. In an autoinstall file, sizing-policy: all gives the root volume everything from the start.

Nothing tells you at boot. I found out when the disk filled: on 31 October an image build took / to 100%, the second time in three days. With 21 GB free, the same build now fits.

How to give a second Bluesky account a subdomain handle

Hatim Rih — Fri, 30 Oct 2026 00:00:00 GMT

Each Bluesky handle needs a TXT record of its own: a subdomain handle like @rubric.hrih.si gets one at _atproto.rubric, because the root domain’s record does nothing for it. That’s the part that’s easy to get wrong. I run two Bluesky accounts on one domain. Mine is @hrih.si, and Rubric, my daily tech edition, posts as @rubric.hrih.si.

One TXT record per handle

Bluesky checks a domain handle by looking for a TXT record at _atproto. followed by the handle. The record holds the account’s DID, the id that stays the same when the handle changes. These are mine:

_atproto.hrih.si          TXT  "did=did:plc:dx4qyo2eyyf4wqjmygtepbbh"
_atproto.rubric.hrih.si   TXT  "did=did:plc:ow3tqck73woxcn6qo4mgk4ea"

So the subdomain’s record sits at _atproto.rubric, inside the same zone. Most DNS panels take the name relative to the domain: you type _atproto.rubric and the panel adds .hrih.si. Bluesky’s tutorial shows the same thing for a subdomain called me, whose record is _atproto.me.

There’s no wildcard to fall back on. A made-up name like _atproto.anything.hrih.si doesn’t exist, so a handle without its own record fails the DNS check. That’s also what keeps the accounts apart: each record names exactly one DID.

Getting the value

Sign in as the account that should get the handle. Open Settings, then Account, then Handle, and choose “I have my own domain”. Type the handle, and Bluesky shows the TXT record to create, with that account’s DID in it.

The value belongs to whoever is signed in. For the subdomain, that has to be the second account, not your main one.

Check before you verify

DNS changes take a while to reach every resolver, so I look the record up myself before asking Bluesky to:

nslookup -type=TXT _atproto.rubric.hrih.si 1.1.1.1
dig +short TXT _atproto.rubric.hrih.si @1.1.1.1

Once a public resolver prints the did= line, go back to the app and verify.

The HTTPS method

Bluesky also accepts the DID as a plain-text file at https://<handle>/.well-known/atproto-did, answered with a 200. Neither of my domains has that file (both answer 404). For a subdomain that is also a website, with its own build and deploys, the DNS record is simpler: it works whether or not the site is up, and no release can drop it. Bluesky’s tutorial suggests the HTTPS route for organizations that hand out many subdomains, where a record for each gets tedious.

For an account a script posts from

Rubric posts from a script. It signs in with an app password, created in the account’s settings and kept in the script’s environment, never with the account password. You can revoke an app password on its own, and the account carries on.

Run scheduled Docker jobs with systemd user timers instead of cron

Hatim Rih — Fri, 30 Oct 2026 00:00:00 GMT

Each of Rubric’s ten scheduled jobs runs as a fresh Docker container that a systemd timer starts under my user account, so it needs no root, and the container exits when the job is done. The jobs poll the sources every 30 minutes, build the edition overnight, publish it at 05:50 UTC and post about it later in the day. Since this setup went in on 28 October 2026, nothing of Rubric runs between jobs.

Before that, the scheduler ran on my PC inside terminals and agent sessions, and when one closed, the scheduler went with it. The editions of 26 and 28 October were missed that way. On the VM I wanted something that starts at boot, catches up after downtime and logs every run, without a scheduler container of its own. systemd already does that.

One service template for every job

# ~/.config/systemd/user/rubric@.service
[Unit]
Description=Rubric pipeline: %i

[Service]
Type=oneshot
ExecStart=/usr/bin/flock --nonblock --conflict-exit-code 0 %t/rubric-%i.lock %h/app/deploy/vm/rubric %i
TimeoutStartSec=6h

%i is whatever follows the @, so rubric@ingest.service runs the ingest job. Type=oneshot tells systemd the job is over when the command exits. flock holds a lock in the user’s runtime directory (%t) while the job runs. A second start of the same job finds the lock taken and exits 0 straight away, so a slow edition never runs twice. TimeoutStartSec=6h is the ceiling for a run that hangs.

The wrapper it calls is a few lines of shell:

#!/bin/sh
set -eu
cd "$(dirname "$(readlink -f "$0")")/../.."
exec docker compose run --rm -T pipeline npx tsx src/cli.ts "$@"

run --rm starts a new container from the image and deletes it afterwards. -T skips the pseudo-terminal, which a timer doesn’t have.

One timer per job

# ~/.config/systemd/user/rubric-due.timer
[Unit]
Description=Rubric: the daily edition

[Timer]
OnCalendar=*-*-* 00:05:00 UTC
OnCalendar=*-*-* 05:45:00 UTC
OnCalendar=*-*-* *:10,25,40,55:00 UTC
AccuracySec=1s
Persistent=true
Unit=rubric@due.service

[Install]
WantedBy=timers.target

Each OnCalendar line adds a schedule. Persistent=true starts a run that was missed while the machine was off as soon as it’s back. A VM that was down at 05:45 still publishes. The source poll’s timer leaves it out on purpose: a missed poll isn’t worth running late, because the edition’s backfill covers that window anyway. AccuracySec defaults to a minute, and the edition’s timer sets one second.

Install as your user, with lingering

units="${XDG_CONFIG_HOME:-$HOME/.config}/systemd/user"
mkdir -p "$units"
cp deploy/vm/rubric@.service deploy/vm/rubric-*.timer "$units/"
systemctl --user daemon-reload
systemctl --user enable --now rubric-due.timer
loginctl enable-linger "$(id -un)"

The units belong to your user, so installing them needs no root. The last line is the one that’s easy to miss. Without lingering, your user’s systemd starts at login and stops at logout, and the timers stop with it. With lingering on, they start at boot and keep running with nobody logged in.

Compose and logs

The compose service sits behind a profile, so docker compose up never starts it. That way no long-running container sits next to the timers and runs a job a second time:

services:
  pipeline:
    build: .
    profiles: [jobs]

The catch is the build. A bare docker compose build then reports “No services to build” and leaves the old image in place, so name the service: docker compose build pipeline.

To see what ran and what’s next:

systemctl --user list-timers 'rubric-*'
journalctl --user -u 'rubric@*' -f
journalctl --user -u rubric@due --since today

Every job logs under its own unit name. Watch the disk when you rebuild. On 29 October an image build filled the VM’s disk to 100%, and docker builder prune got 1.16 GB back.

Use your own domain as a Mastodon handle without running a server

Hatim Rih — Fri, 30 Oct 2026 00:00:00 GMT

A static WebFinger file and two response headers let people find @rubricdaily@mastodon.social as @rubric@rubric.hrih.si, with no Mastodon server. That’s Rubric’s account, named rubricdaily because @rubric was taken on mastodon.social, and I wanted people to find it on the domain the site already has.

How Mastodon finds an account

When someone searches for @rubric@rubric.hrih.si, their server asks the domain:

GET https://rubric.hrih.si/.well-known/webfinger?resource=acct:rubric@rubric.hrih.si

The answer is a small JSON document called a JRD. Its self link points at the account’s ActivityPub actor, and its subject names the account. When the subject isn’t the handle that was asked for, Mastodon sends a second WebFinger request to the server named in the subject, and that answer has to point at the same actor. That second request is what lets a domain you own vouch for an account that lives somewhere else. Mastodon’s WebFinger docs describe both steps.

The file

The file is a copy of what mastodon.social already says about the account. Fetch it:

curl -s "https://mastodon.social/.well-known/webfinger?resource=acct:rubricdaily@mastodon.social"

Save the answer unchanged as .well-known/webfinger in the site’s public folder. Rubric’s is 505 bytes on one line, spread out here:

{
  "subject": "acct:rubricdaily@mastodon.social",
  "aliases": [
    "https://mastodon.social/@rubricdaily",
    "https://mastodon.social/ap/users/117518336990487890"
  ],
  "links": [
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://mastodon.social/@rubricdaily"
    },
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://mastodon.social/ap/users/117518336990487890"
    },
    {
      "rel": "http://ostatus.org/schema/1.0/subscribe",
      "template": "https://mastodon.social/authorize_interaction?uri={uri}"
    }
  ]
}

Nothing in it gets edited: the subject stays the real account, and the actor stays on mastodon.social.

The two headers

The file has no extension, so the server won’t send the right type on its own. It needs Content-Type: application/jrd+json, and Access-Control-Allow-Origin: * so that web clients on other origins can read it. In Caddy, inside the site block:

@webfinger path /.well-known/webfinger
header @webfinger Content-Type "application/jrd+json"
header @webfinger Access-Control-Allow-Origin "*"
file_server

In nginx, Rubric sets the CORS header at the server level from a map on the path, and gives the file its type in a location of its own:

map $uri $cors_origin {
    default                  "";
    /.well-known/webfinger   "*";
}

server {
    add_header Access-Control-Allow-Origin $cors_origin always;

    location = /.well-known/webfinger {
        types { }
        default_type application/jrd+json;
        try_files $uri =404;
    }
}

I left the location without an add_header of its own on purpose: nginx drops the server-level add_header lines in any location that sets one, and the CORS header would go with them.

Check both headers from outside:

curl -sI "https://rubric.hrih.si/.well-known/webfinger?resource=acct:rubric@rubric.hrih.si"

It should answer 200 with content-type: application/jrd+json and access-control-allow-origin: *.

What a static file can’t do

A static server ignores the query string, so every name at the domain gets the same answer: acct:nobody@rubric.hrih.si resolves to Rubric’s account just as acct:rubric@rubric.hrih.si does. That makes it one account per domain: if you want a second one there, you need a server that reads resource. The file also answers a request with no resource at all, where the WebFinger spec, RFC 7033, asks for a 400. Mastodon always sends one, so it hasn’t mattered.

It’s an alias, not a server. The account, its posts and its followers stay on mastodon.social, and the domain is one more way to find them.

To link the two the other way, Rubric’s footer carries the profile link with rel="me":

<a href="https://mastodon.social/@rubricdaily" rel="me">Mastodon</a>

List the site in one of the profile’s fields, and Mastodon marks that field verified once it finds the rel="me" link back.

Post to X and LinkedIn from a script without paying for the X API

Hatim Rih — Fri, 30 Oct 2026 00:00:00 GMT

Rubric posts to X and LinkedIn through Buffer’s GraphQL API on the free plan, so it never pays X’s $0.20 for a post with a link. Every day at 13:00 UTC, it picks three stories from its top twenty and posts them to my LinkedIn and my X account. The script never talks to either network: it sends one GraphQL request per post to Buffer, which holds both accounts and publishes the post at once.

Why not the networks’ own APIs

X’s API is pay-per-use. Its pricing page lists $0.015 to create a post and $0.20 to create one that contains a URL, and every post I send has a link.

LinkedIn’s self-serve API can post to your own profile, with access tokens that last 60 days. Refresh tokens are only for LinkedIn’s approved partners, so someone has to sign in again every two months. Posting as a company page needs a separate API that LinkedIn reviews.

Buffer connects both accounts through its own app, and since May 2026 it has offered a GraphQL API with personal keys on every plan. The free plan covers 3 channels, 10 scheduled posts per channel and one API key, good for 1,000 requests per channel a month. Posting once a day uses about 30.

Find the channel ids

Connect the accounts in Buffer’s app, then create a key in its API settings. Every call is a POST to https://api.buffer.com with the key as a Bearer token. Two queries list what the key can post to:

query { account { organizations { id name } } }

query ($input: ChannelsInput!) {
  channels(input: $input) { id name service type displayName }
}

The second takes {"input": {"organizationId": "<organization id>"}} as its variables. X shows up with the service name twitter. Keep the two channel ids next to the key, because the script needs nothing else.

Post

One mutation per post:

mutation ($input: CreatePostInput!) {
  createPost(input: $input) {
    __typename
    ... on PostActionSuccess { post { id } }
    ... on MutationError { message }
  }
}

with these variables:

{
  "input": {
    "channelId": "<channel id>",
    "text": "The post",
    "schedulingType": "automatic",
    "mode": "shareNow"
  }
}

mode: "shareNow" skips the queue and publishes right away. For LinkedIn, I add a link card to the input, with the page’s social image as its thumbnail:

"metadata": {
  "linkedin": {
    "linkAttachment": {
      "url": "https://rubric.hrih.si/editions/2026-10-30/",
      "title": "…",
      "description": "…",
      "thumbnail": { "url": "https://rubric.hrih.si/og/2026-10-30.png" }
    }
  }
}

On X the link goes in a reply, so the input carries a thread. The thread lists every post including the first one, which repeats the text:

"metadata": {
  "twitter": {
    "thread": [{ "text": "The post" }, { "text": "The reply, with the link" }]
  }
}

The same request from a shell:

curl -s https://api.buffer.com \
  -H "Authorization: Bearer $BUFFER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"mutation ($input: CreatePostInput!) { createPost(input: $input) { __typename ... on PostActionSuccess { post { id } } ... on MutationError { message } } }","variables":{"input":{"channelId":"<channel id>","text":"Hello from a script","schedulingType":"automatic","mode":"shareNow"}}}'

Buffer can refuse a post without the request failing. The answer then has __typename set to MutationError and a message, so check __typename as well as the errors array GraphQL uses for a bad query.

What you give up

Buffer answers with its own post id, not the post’s address on X or LinkedIn, so the script can’t link to what it just posted. You also add a company in the middle that holds your tokens. For me that beats paying per post: the first real posts went out on 28 October 2026, and Buffer took the link card and the thread exactly as shown here.

tar "Cannot open: No such file or directory" in Docker when the folder exists on your machine

Hatim Rih — Fri, 30 Oct 2026 00:00:00 GMT

tar failed in the container because the folder it writes into, data/deploy/, is git-ignored: it existed on my PC and nowhere in the container, and creating it before tar runs fixed it. On 29 October, Rubric’s edition was published at 05:50 UTC, the morning email went out with a link to it, and at 06:10 my live check reported the edition live. It wasn’t. The page answered 404 until I deployed it by hand at 09:31 UTC, and the first of the three things that went wrong was this line in the job’s log:

tar -czf ../../app/data/deploy/site-….tar.gz: Cannot open: No such file or directory

A folder that only existed on my PC

The deploy builds the site, packs it with tar -czf into data/deploy/ and uploads the archive to the server. On my PC that folder existed: it’s git-ignored, and an earlier run had created it. The day before, the jobs had moved into containers on a VM, and there the folder existed nowhere. .dockerignore keeps data out of the image, and the data volume is mounted at /data, not /app/data. tar doesn’t create the folder for the file it writes, and when that folder is missing you get exactly this error.

The fix is one line before tar, plus a test that archives into a folder that doesn’t exist yet. Simplified:

// before
await run("tar", ["-czf", relative(dir, file), "."], { cwd: dir });

// after
mkdirSync(dirname(file), { recursive: true });
await run("tar", ["-czf", relative(dir, file), "."], { cwd: dir });

A step that reported done

That error should have stopped the morning. It didn’t, because the upload sat inside the publish step, wrapped in a try/catch:

} catch (err) {
  run.log.error(`site deploy failed: ${(err as Error).message}`);
  built += " · site deploy FAILED";
}

The step logged the failure, wrote site deploy FAILED into its summary line and finished. The scheduler saw a finished step and had nothing to retry. The email went out in the same step, linking to a page that wasn’t there.

The deploy is now a stage of its own after the publish. It fails like any other stage, alerts on its first failure only, and the scheduler runs it again every quarter hour for six hours after the publish. The email waits until the upload has landed.

A check that trusted the database

This is the part worth copying. The live check asked my own database:

if (row?.status === "published") return `edition ${date} is live`;

published meant the edition was committed and pushed. It never meant a reader could open the page, and the check treated the two as one. Now it asks the site:

const res = await fetch(url, { method: "HEAD", redirect: "manual", signal: AbortSignal.timeout(20_000) });
return { live: res.status === 200, status: res.status, url };

A missing edition page answers 404 to a HEAD request just as it does to a GET, so a 200 means a reader gets the page. redirect: "manual" counts a redirect as not live, so the URL needs its trailing slash. Without it, the server answers 308.

A row that says “published” is the pipeline’s own account of what it did. Readers get the page, so the page is what gets checked, and nothing that links to the edition trusts the database alone any more. The social posts at 08:00 and 13:00 ask the page first, and while it isn’t 200 they post nothing and send me an alert.

One more race

The 06:10 check and the 08:00 posts also hit a smaller bug that morning. Two job containers pulled the same git checkout in the same second and broke each other’s fetch (“Cannot fast-forward to multiple branches”). Each pull now waits up to two minutes for a lock on the shared volume:

flock -w 120 /site/.pull.lock git -C /site pull --ff-only