DEV Community: alapha888

My session-handoff skill was rejected from awesome-copilot — the maintainer had a point

alapha888 — Thu, 22 Oct 2026 07:46:03 +0000

Today (October 22, 2026) my pull request to add the session-handoff skill to GitHub's awesome-copilot collection was closed. The maintainer, Aaron Powell, left one sentence of reasoning:

This isn't ideal as it's introducing rules that can conflict/contradict with the process that the harness has in place for handling compaction, sub-agent spawning, and memory management.

That is a fair criticism, and it is aimed at a real weakness in how I had positioned the skill.

Where the criticism lands

The kit's pitch was universal: end every session with a structured handoff note, so the next session starts from facts instead of a degraded, over-full context. Inside a harness that already owns compaction, sub-agent spawning, and memory management, an extra set of handoff rules is not neutral. It can contradict the machinery that is already doing that job, and the agent is left following two processes at once.

A listing in awesome-copilot is read as "this fits the Copilot way of working." By that standard, a blanket handoff ritual does not fit, and the PR was correctly closed. The full exchange is public: https://github.com/github/awesome-copilot/pull/5097

Where a written handoff still earns its keep

The rejection narrows the claim; it does not erase the use case. A short, structured handoff note still does work that no single harness owns:

Switching between different agents or tools. Claude Code, Codex, and Gemini CLI do not share memory. When work moves from one to another, a written handoff is the only continuity there is — no harness spans that gap.
Resuming after days, not minutes. Harness memory serves the agent. A handoff note also serves the human: a readable record of what was decided and why, which you can audit before the next session spends tokens re-deriving it.
Harnesses with no built-in handling. Not every agent runtime compacts or persists memory. In those, the ritual is not duplication; it is the only version of the process that exists.

What I changed today

I added a "When you may not need this" section to the kit's README, stating plainly that if your harness already handles compaction and memory well, you should skip the skill and let the harness do its job — with the awesome-copilot review credited as the source of that point. The universal pitch is gone; the three gaps above are now the stated scope.

The kit itself is unchanged and still free (MIT):

Repo: https://github.com/alapha888/session-handoff-kit
Install: npx skills add alapha888/session-handoff-kit
skills.sh: https://skills.sh/alapha888/session-handoff-kit

A rejection with a specific reason is the most useful review a listing PR can get. This one cost nothing, took a day, and made the README more honest than I had managed on my own.

Day 4 of the ubuntu-latest rollout: weekly workflows get their first chance at the new image — cadence decides when it reaches you

alapha888 — Wed, 21 Oct 2026 17:50:32 +0000

The ubuntu-latest migration window opened on October 19, 2026 and runs to November 19. Inside that window, ubuntu-latest moves from Ubuntu 24.04 to Ubuntu 26.04 in stages, so any single run may land on either image. Day 1 covered the workflows that run on every push. Day 3 covered the ones that had not run at all. Day 4 is about cadence: a workflow on a weekly schedule has a first run inside the window, and for a Thursday or Friday schedule that first run is still ahead of you — or happens tonight.

Why cadence decides when this can reach you

The rollout cannot reach a workflow that does not run. Push-triggered workflows had their first chance to land on 26.04 on day 1, and have had many chances since. A workflow that runs every Monday has had at most one scheduled run inside the window, and that run may or may not have landed on the new image. A workflow scheduled for Thursdays has not run at all since the window opened — tonight is its first chance, under whatever your cron line says, quite possibly while nobody is watching.

The same applies to anything rarer: release-only workflows, monthly maintenance jobs, manually dispatched checks. Each has its own first chance, and it is the day it next runs, not October 19.

Where my own re-walk stands

I have re-run my scanner (RunnerDriftAudit v0.3.8) against a frozen October 13 baseline on October 20 and again on October 21. Both re-walks reproduced the baseline exactly — 4/2, 4/2, 0/2 across the three targets, no rows moved, no migration-effect rows yet. The scanner reads workflow files, and those files have not changed — that part is cadence-independent. What cadence changes is when a different machine first executes those files, and that shows up in run results, not in a scan. That gap between "files unchanged" and "has it actually run on 26.04 yet" is precisely what this cadence check exists to close.

The day-4 check (about 10 minutes)

List your scheduled and dispatch-only workflows — anything that does not trigger on push or pull request. Note each one's next scheduled run.
For the ones that have already run since October 19, compare that run's result against the last pre-October 19 run. A failure that starts exactly at the first post-window run is a rollout candidate, not a coincidence.
For the ones that have not run yet, consider dispatching them manually today, while the pre-migration state is still fresh in mind and both runner images are still in rotation. A controlled first run beats a scheduled surprise.
Keep the macos-14 retirement separate: those labels retire on November 2, 2026 — 11 days from today (October 22) — and jobs on them will fail outright, not drift. Different problem, different fix, same calendar pressure.

Tool

I run these checks with RunnerDriftAudit, a free static scanner for GitHub Actions workflow files (it reads the YAML; it does not execute your jobs, and it cannot see runtime-only behaviour):

Repo: https://github.com/alapha888/runner-drift-audit
Current release: v0.3.8 (October 20, 2026) — https://gist.github.com/alapha888/263d0f3741ff5f9389d11203b8c4fb97
Multi-repo edition (one combined report for a whole local workspace), $29 one-time: https://alapha888.gumroad.com/l/mepra

Day-4 field note (Gist): https://gist.github.com/alapha888/adc3560a1b50a7e970a882407c27c078

Day 3 of the ubuntu-latest rollout: the new image reaches repos at different times — re-run, don't assume

alapha888 — Wed, 21 Oct 2026 13:00:10 +0000

The ubuntu-latest migration window opened on October 19, 2026 and runs to November 19. Inside that window, ubuntu-latest moves from Ubuntu 24.04 to Ubuntu 26.04 — but not for every repository at the same moment. The rollout is staged, so on day 3 the honest status for your repos is "unknown", not "fine".

What I can verify from my own estate

On October 20 I re-ran my scanner (v0.3.7) against the three targets from my frozen October 13 baseline. The baseline reproduced exactly — 4 HIGH / 2 WARN, 4 HIGH / 2 WARN, 0 HIGH / 2 WARN — with no finding changing state and no migration-effect rows yet.

On October 21 I ran the same check again, with scanner v0.3.8. Same result, row for row: 4/2, 4/2, 0/2, the two manual rows (container images, locale/timezone defaults) still inert, and still no migration-effect rows. That tells me the rollout had not changed anything for those targets by October 21. It says nothing about your repos — and a static scan cannot see the moment the image flips for a given repository anyway. A real migration effect would show up as a CI behaviour change on deliberately floated jobs, not as a count delta in a table like this.

Two failure modes hide in that gap:

The workflow that hasn't run. If a workflow has not executed since October 19, it has never touched the 26.04 image. Its next run — possibly a release run — is the first test. The two images differ in 22 toolset entries (default versions moved, some tools removed), so "it was green last week" is evidence about the old image only.
The silent tool change. A workflow that did run may have picked up a new default tool version and stayed green by luck — a deprecation warning today, a hard failure when the old version disappears. Green is not the same as unaffected.

The day-3 check (about 10 minutes)

Re-run a scan of your workflow files today and compare the finding counts against a baseline you trust. If the counts moved and you didn't edit anything, the rollout reached you — read the moved rows first.
Look specifically for findings about default tool versions and removed tools. Those are the rows that turn into failures without any commit of yours.
For every floating label, decide on purpose: pin it (label or tool version) or keep floating and accept the drift. Either is defensible; drifting by accident is not.
Write the result down in one line — date, scanner version, counts. The next check is only useful if this one left a record.

The other clock

Separate from the Ubuntu move: the macos-14 runner image retires on November 2, 2026 — 12 days from today (October 21). The October 19 brownouts were the rehearsal. Any workflow still referencing macos-14 (including indirectly, through a matrix variable or a reusable workflow) stops working entirely on that date, not gradually.

Tool

I run these checks with RunnerDriftAudit, a free static scanner for GitHub Actions workflow files (it reads the YAML; it does not execute your jobs, and it cannot see runtime-only behaviour):

Repo: https://github.com/alapha888/runner-drift-audit
Current release: v0.3.8 (October 20, 2026) — https://gist.github.com/alapha888/263d0f3741ff5f9389d11203b8c4fb97
Multi-repo edition (one combined report for a whole local workspace), $29 one-time: https://alapha888.gumroad.com/l/mepra

Full day-3 field report: https://gist.github.com/alapha888/cffe20f75f6d4984949a4534f3b6e8ca

Migration Window, Morning One: My Scanner Caught One of My Own Repos Still on macos-14

alapha888 — Tue, 20 Oct 2026 14:56:14 +0000

Yesterday, October 19, two GitHub runner changes started on the same morning: the ubuntu-latest label began its rolling move to Ubuntu 26.04 (through November 19), and the first macos-14 brownout ran that night, 14:00–24:00 UTC, ahead of the November 2 retirement of that image.

Before writing anything else about either change, I ran my own scanner — RunnerDriftAudit v0.3.7 — on the five repositories I maintain that actually have workflows. Six workflow files. The result was not a victory lap.

What the scan found at home

Repo	HIGH	What it was
photoveil-ios	1	`RETIRED_LABEL` — CI still on `macos-14`
cn-ai-coding-workflow-lite	4	Floating `ubuntu-latest` / `macos-latest` / `windows-latest` in the install-test matrix, plus a standalone `windows-latest` job
cn-ai-coding-workflow	4	The same four as the lite repo
pubaudit-windows	2	Floating `windows-latest` in both workflows
runner-drift-audit	0	— (2 WARN: `actions/checkout@v4` not pinned to a SHA)

Eleven HIGH findings in total (1 + 4 + 4 + 2 + 0 across the table), all floating or retired labels — in the repos of the person who wrote the scanner. Separate from those, almost every file also carried a WARN: actions/checkout referenced by the mutable v4 tag instead of a full commit SHA.

The one that would have gone red that night

The photoveil-ios finding was the real one. Its CI was still running on macos-14 — the image that started failing on purpose that night during the brownout window and stops working entirely on November 2. Nothing about the repo had changed; the label underneath it was expiring.

The fix was one line, macos-14 → macos-15, pushed the same morning. CI on the new image passed in 32 seconds (core tests and iOS typecheck; run 39146373675 in that repo's history, if you want to check rather than take my word for it).

That is the whole argument for scanning before the window, not after the first red build: this class of finding is invisible until the day it turns red, and for macos-14 that day was October 19.

What I deliberately did not fix

The other floating labels stayed floating — by decision, now written down:

The two cn-ai-coding-workflow install-test matrices exist to prove an install script works on whatever "latest" currently means across three operating systems. Pinning those labels would defeat the test. If a leg goes red during the rollout, that red is the signal the job exists to produce.
The windows-latest jobs ride no announced migration in this window, so they stay floating for now, recorded as checked-and-inert rather than unexamined.

And one honest non-fix: the unpinned actions/checkout@v4 warnings are still open, including in the scanner's own self-test workflow. The scanner reports it; I have not done that pass yet. It is recorded as not-yet-fixed, not quietly dropped from the list.

If you have not scanned yet

The window is still open: ubuntu-latest keeps rolling through November 19, and macos-14 retires on November 2. A scan takes under a minute per repo:

python3 runner_drift_audit.py path/to/your-repo --json day1.json --summary-file day1-summary.md

The scanner is free and open source (MIT, single-file Python, standard library only): https://github.com/alapha888/runner-drift-audit — the full morning scan, including the rows I left alone and why, is in field-reports/2026-10-19-day1-self-scan.md. The next day I re-ran the frozen October 13 baseline inventory for the scheduled comparison with a reader who walked the same checklist on his own machine; nothing in that baseline inventory moved (the photoveil-ios fix above was part of the day-1 scan, not of that baseline), and why that is itself the finding is written up here: https://dev.to/alapha888/post-cutover-re-walk-nothing-moved-and-why-that-is-the-finding-287o

If you maintain many repositories, a paid batch edition ($29 one-time) scans a whole workspace into one merged HTML report: https://alapha888.gumroad.com/l/mepra — the free single-repo tool stays free either way.

One repo, one retired label, one line fixed before the window opened. I would rather read about where the checklist bends on your repos than hear it was all green.

Post-Cutover Re-Walk: Nothing Moved — and Why That Is the Finding

alapha888 — Tue, 20 Oct 2026 14:01:07 +0000

On October 13, before the migration window opened, I froze a baseline: three of my own workflow files, scanned with RunnerDriftAudit v0.3.2, every row written down. The agreement — made in the open, in a comment thread with a reader who ran the same checklist on his own machine — was that after the window opened, we would both re-run the same inventory and compare second reports line by line.

The window opened yesterday, October 19: ubuntu-latest began its rolling move to Ubuntu 26.04 (through November 19), and the first macos-14 brownout ran last night. This morning I re-ran the frozen inventory. Here is the whole result:

Target	HIGH	WARN	Delta vs baseline
cn-ai-coding-workflow `test-install.yml`	4	2	none — identical rows
cn-ai-coding-workflow-lite `test-install.yml`	4	2	none — identical rows
runner-drift-audit self-test	0	2	none — identical rows

No row moved. Nothing flipped from checked-inert to flagged. The two manual rows I track alongside the scan — container images pulled by tag, and locale/timezone defaults — are still inert, grep-verified on the day: this inventory pulls no container images, and its steps still only count files and grep frontmatter.

A null result is still a result — if the baseline was frozen

It would be easy to read that table as "nothing happened, nothing to write." That reading is wrong in a specific way, and the specificity is the point of freezing a baseline before the event instead of reconstructing one after it.

The scanner flags the floating ubuntu-latest label itself. Its counts therefore do not change when the image underneath the label flips — by design. A count delta was never the signal this inventory could produce. Any real migration effect would show up as a behaviour change in CI on the jobs I deliberately left floating (the install-test matrices exist to go red if "latest" breaks the install script), not as a new row in this table.

So the honest statement is narrow: on day one of the window, the platform switch produced no scanner-visible change in this inventory, and the floated jobs have not gone red. That is a dated, checkable claim — the run script, the raw scanner output, and the scanner's SHA256 are all in the repo — not a vibe.

Version honesty, because the scanner changed too

One trap in any before/after comparison: the measuring tool moved between measurements. Mine did, and the report separates that from platform effects:

Baseline scanner: v0.3.2 (October 13). Re-walk scanner: v0.3.7, test suite 64 passed on the day.
v0.3.3–v0.3.6 changed output formats only (Marketplace metadata, SARIF export, JSON export, Markdown summary) — no rule changes that affect counts.
v0.3.7 did add one rule: RETIRED_LABEL, a HIGH for workflows pinned to the retiring macos-14 labels. None of the three baseline targets pin macos-14, so the new rule changed no count here. It is listed in the report anyway, so that a future macos-14 finding is never mistaken for a migration effect.

If your own before/after numbers moved, the first question is which of those two columns moved them: the platform, or your tooling.

What is still open

The other half of the exchange is pending: my counterpart's second report has not arrived yet. My reply, with the filled comparison template, goes into the original thread today; his rows will be recorded as a dated addendum when they land, including any line where we disagree.
The deliberately floated jobs stay floating through the window (until November 19). If one goes red, that red is the signal the job exists to produce, and it will get its own field report.
The unpinned actions/checkout@v4 warnings are still open, including in the scanner's own self-test. Still recorded as not-yet-fixed.

The scanner is free and open source (MIT, single-file Python, standard library only): https://github.com/alapha888/runner-drift-audit — the full re-walk, including the rows that did not move and the version-honesty table, is in field-reports/2026-10-20-post-cutover-self-audit.md. If you maintain many repositories, a paid batch edition ($29 one-time) scans a whole workspace into one merged HTML report: https://alapha888.gumroad.com/l/mepra — the free single-repo tool stays free either way.

If you froze a baseline before the window opened, I would like to compare rows — especially if yours moved and mine did not.

Your Agent Forgets Nothing — That's the Problem. End Sessions With a Handoff Note

alapha888 — Tue, 13 Oct 2026 01:10:18 +0000

Long sessions with a coding agent often follow a familiar shape. The first hour is sharp. A few hours in, the context is full of dead ends: files you opened and rejected, approaches you tried and abandoned, a refactor you rolled back. The agent still carries all of it in context — and its answers tend to get worse, because the useful state is buried under stale exploration.

The usual fixes are blunt. /clear throws away the state along with the noise. /compact lets the model summarize itself, and the next session starts from that summary — with whatever the summary left out. Starting fresh usually means re-explaining the context by hand.

There is a smaller habit that works better: before you reset, capture the state in a format the next session can execute from.

What a useful handoff note contains

Not a transcript, and not a summary of everything that happened. Five things:

Goal state — what you were trying to do, and how far it got.
Decisions, with reasons — especially the approaches you rejected, so the next session doesn't retry them.
Files touched — what changed, and what's mid-change.
Open loops — unverified assumptions, failing tests, questions nobody answered yet.
Next action — one concrete step, not a list of possibilities.

Writing this down at the end of a session is quicker than re-deriving it at the start of the next one. And because the note is plain text, it works the same when the "next session" is a different agent, or you next week.

Making it a skill instead of a resolution

Habits that depend on remembering to do them tend to last a week. So I packaged the routine as an installable agent skill: Session Handoff Kit (free, MIT).

It contains three files:

SKILL.md — the skill itself. When context fills up or a session ends, the agent produces a structured handoff note in the five-part format above.
context-hygiene-checklist.md — a one-page decision guide: when to /clear, when to /compact, when to start fresh, plus the 2-minute routine to run before any reset.
handoff-template.md — a fill-in template with per-section guidance, for working without the skill.

Install with the skills CLI:

npx skills add alapha888/session-handoff-kit

or copy SKILL.md into a session-handoff folder in your agent's skills directory. It works with Claude Code, Codex, and Cursor-style skill setups.

The kit is listed on skills.sh, and the source is on GitHub: alapha888/session-handoff-kit. Feedback and issues are welcome there.

You can also read the checklist on its own as a Gist: Context Hygiene Checklist for AI Coding Agents.

The point isn't the tooling — a plain text file works fine. The point is the order of operations: capture state before you reset, in a format the next session can act on without re-asking you everything.

What's Hidden in Your Photos: Understanding EXIF Metadata Before You Share

alapha888 — Tue, 13 Oct 2026 01:09:51 +0000

Whenever you snap a photo with a smartphone, the file captures more than just visual pixels. Bundled inside the container is EXIF (Exchangeable Image File Format) data—a structured set of technical headers generated automatically by the camera hardware and operating system.

Most messaging apps and major social platforms re-encode images and strip this metadata on upload. However, when sharing original files directly—via AirDrop, email attachments, shared cloud folders, or web upload forms—those headers travel along untouched.

Here is a closer look at what EXIF carries, what cleaning it achieves, and where automated metadata removal fits into everyday file sharing.

What EXIF Metadata Contains

Modern smartphone cameras log granular operational telemetry at the exact millisecond of capture. A standard raw export typically contains:

Precise Geolocation: Exact GPS latitude, longitude, altitude, and sometimes even the compass direction the lens was facing.
Timestamps: The precise local date, time, and timezone offset of when the shutter opened, as well as modification timestamps.
Hardware Identifiers: Device make, model, lens specifications, focal length, aperture, shutter speed, and sensor ISO settings.
Software Signatures: Operating system build version, camera firmware, and identifiers for any third-party editing tools used prior to export.

Individually, these fields help photo library managers organize albums chronologically and geographically. Taken together in shared files, they construct a reliable pattern of routine, location, and equipment.

A Concrete Scenario: The Rental Application

Consider submitting paperwork for a rental application or verifying an identity online. The property manager or platform asks for a snapshot of a utility bill, proof of address, or a government ID card.

You take a photo on your living room table and attach the original JPEG or HEIC file directly to an email or a form portal.

Beyond the visual document on the table, the file header now confirms:

The exact coordinates of your private residence.
The exact time of day you took the picture.
The specific phone hardware you own.

In contexts where you only intended to submit the visual document, the attached telemetry provides unnecessary, persistent data points to whatever third-party server stores that file.

What Metadata Cleaning Can and Cannot Do

It is important to be precise about what metadata scrubbing actually accomplishes:

What it can do: It removes header dictionaries—such as EXIF, TIFF, GPS, IPTC, and XMP payloads—leaving an image container that contains only raw visual pixel arrays.
What it cannot do: It does not alter the visible content inside the image frame. If your document shows an ID number, a visible house number in the background, or an unredacted signature, metadata stripping does nothing to obscure that information.

Cleaning metadata isolates visual data from digital forensics. It does not replace deliberate visual redaction.

Handling Metadata on iOS: The PhotoVeil Approach

Checking and stripping metadata on iOS usually involves third-party tools, shortcuts, or exporting through intermediary utilities. When evaluating tools for this workflow, the primary technical consideration is whether cleaning degrades image quality or routes files through remote infrastructure.

We are currently building PhotoVeil, an upcoming iOS utility designed to address these specific workflows locally on-device.

Its implementation focuses on a few core principles:

Inspection Before Export: It generates an on-screen EXIF report highlighting potentially sensitive elements (such as embedded coordinates and device identifiers) before you decide to send a file.
Lossless JPEG Cleaning Where Possible: For standard JPEG images that do not require rotation or dimensional transformation, PhotoVeil strips metadata losslessly. It excises the metadata application segments directly and copies the image bitstream byte-for-byte, avoiding re-compression artifacts. Other formats or transformed images are cleanly re-encoded without metadata headers.
Purpose-Bound Watermarking: For sensitive document submissions (like identity cards or lease forms), the tool can tile a custom watermark across copies—such as "For rental application only"—limiting unauthorized reuse.
Local Architecture: It utilizes the native iOS system photo picker, requires no accounts, includes no tracking, and performs all processing entirely on-device with zero network transmissions.

The free tier includes inspection reports and single-photo metadata removal. A one-time purchase option unlocks batch operations, document watermarking, and format conversions.

Waitlist

PhotoVeil is currently in active development for iOS. If you are interested in testing early builds and keeping track of release updates, you can join the waitlist at https://alapha888.github.io/photoveil-waitlist/ .

Formatting Markdown for WeChat, Zhihu and Juejin from one source file

alapha888 — Tue, 13 Oct 2026 01:07:52 +0000

If you write technical posts in Markdown and publish them in Chinese, you know the last step is the annoying one. The article is done — code blocks, tables, a few formulas — and then you paste it into the WeChat Official Account editor and watch the formatting fall apart: code loses its background, tables collapse into plain text, and images need to be re-uploaded one by one. Fixing it by hand can take longer than a final proofread.

Zhihu and Juejin accept Markdown more gracefully, but each platform still renders slightly differently, so maintaining three hand-adjusted copies of the same post is its own kind of tax.

A one-source workflow

The workflow that avoids most of this is boring on purpose:

Keep one Markdown file as the only source of truth.
Render it once with a formatter that targets each platform's paste format, instead of editing copies inside each editor.
Paste, spot-check the risky elements (see below), and publish. Any correction goes back into the source file, not into one platform's copy.

What a formatter has to preserve

When you evaluate any Markdown-to-platform tool — or build your own conversion step — these are the elements that break first, in roughly this order:

Code blocks, including syntax highlighting and readable backgrounds after paste.
Tables, which several editors silently flatten.
Math formulas, where a renderer that drops TeX leaves raw source in the published post.
Images, including whether they survive the paste or need a separate upload pass.
Inline styles such as bold inside list items and links with non-ASCII URLs.

A tool that handles headings and paragraphs but fails on the first two is not saving you time; it is moving the manual work to where you notice it last.

The tool I use for this

MD Publisher is a browser-based Markdown formatter built on the open-source doocs/md project. It renders one Markdown document into output formatted for WeChat Official Accounts, Zhihu, and Juejin, and it is available as a free Microsoft Edge extension. An optional Pro version adds one-click packaged export for the three platforms.

It will not write the article for you, and you should still spot-check code blocks and tables after pasting — platform editors change without notice. But it removes the repetitive reformatting step, which is the part that never deserved an hour of your evening in the first place.

MD Publisher on Microsoft Edge Add-ons: https://microsoftedge.microsoft.com/addons/detail/md-%E6%8E%92%E7%89%88%E5%8A%A9%E6%89%8B/ggimifkpgpbnpempalpkmnnlplklgkdi

Publisher support ends tomorrow: a 30-minute rescue checklist for your .pub archive

alapha888 — Mon, 12 Oct 2026 08:32:11 +0000

Microsoft removed Publisher from Microsoft 365 on October 1, 2026. Tomorrow, October 13, 2026, support for perpetual Publisher (Office 2021) ends.

Your installed copy will not vanish overnight, and your .pub files will not be deleted. The app simply stops receiving security updates. However, almost no modern software outside of Microsoft Office opens .pub files natively. If you leave your archive as-is, you risk discovering years from now that your legacy templates, newsletters, or flyers are effectively locked away.

Here is a practical, 30-minute checklist to rescue your .pub archive before support lapses.

Step 1: Inventory your `.pub` files (5 minutes)

Search your local drives, shared network folders, and cloud sync directories for every file ending in .pub. Gather them into a single working folder (or note their paths) so you know the exact scope of what needs preservation.

Step 2: Set up a local converter (5 minutes)

You do not need to upload confidential files to random web converters. LibreOffice contains libmspub, an open-source library that parses Publisher files and converts them locally to PDF. Install LibreOffice if you do not already have it on your machine.

Step 3: Run a local batch conversion to PDF (10 minutes)

Export your .pub files to standard PDF format. PDF ensures that fonts, layouts, and vector artwork remain viewable on any modern operating system indefinitely. Run your conversions locally so your documents never leave your machine.

Step 4: Watch out for silent conversion failures (5 minutes)

Do not assume a batch script succeeded just because it finished without errors. Automated converters can exit with status code 0 while producing no PDF at all (a behavior verified with truncated files). Even worse, a renamed plain text file can pass through and fake-convert into an empty or corrupt shell.

Always verify output:

Confirm that an output PDF actually exists on disk.
Check that file size is non-zero.
Ensure the converted file contains actual rendered text or visual elements.

Step 5: Review the conversion status (5 minutes)

A reliable migration uses a verification report that classifies every source file into one of three buckets:

OK: The PDF exists, contains expected text content, and converted cleanly.
REVIEW: The conversion completed, but the output contains unusually little text (for example, image-heavy posters or scanned assets) and requires manual visual inspection.
FAILED: The process produced no PDF or threw an unhandled error.

Inspect the items flagged for REVIEW and FAILED while you still have access to a working desktop environment.

The silent-failure trap

Blindly looping libreoffice --headless --convert-to pdf in a shell script feels fast, but silent failures will burn you. Because libmspub parsers may exit cleanly even when encountering truncated headers or malformed streams, checking process exit codes alone is not enough. You need automated post-conversion checks on file size and extracted content to ensure your archive was genuinely preserved rather than silently skipped.

If you want an automated tool that handles the batch run and validation in one step, check out PubAudit. It is a free, MIT-licensed CLI that batch-converts a folder locally, classifies every file as OK / REVIEW / FAILED, and generates CSV and HTML reports. Your files are never uploaded anywhere.

Take thirty minutes today to turn your .pub archives into readable PDFs while you still have the tools to verify them.

ubuntu-latest moves to Ubuntu 26.04 on October 19 — 22 toolset differences that can break your CI

alapha888 — Fri, 09 Oct 2026 23:51:16 +0000

Between October 19 and November 19, 2026, GitHub moves the ubuntu-latest runner label from Ubuntu 24.04 to Ubuntu 26.04. Nothing in your repository changes — the machine underneath your CI does.

I diffed the official actions/runner-images toolsets (toolset-2404.json vs toolset-2604.json) on 2026-10-10 and found 22 differences. These are the ones most likely to break or silently change a build:

Removed outright

mercurial (hg), mediainfo, sphinxsearch, haveged — removed from the image
Globally preinstalled Node tools: only n and yarn remain. webpack, gulp, grunt, parcel, lerna, newman, and tsc (typescript) are no longer preinstalled globally — a workflow that calls them without a local install or npx step will fail
Java 8 — removed; gcc-12 / gfortran-12 and clang-16 / clang-17 — removed
p7zip is renamed to 7zip; the fastlane gem is no longer bundled with rubygems

Default versions that move under you

Tool	24.04	26.04
Java (default)	17	25
Node (default)	22	24
PHP	8.3	8.5 only
PostgreSQL	16	18
clang (default)	18	21
Go (default)	1.24	1.26
Docker / Compose	28 / 2.38	29.4.2 / 5.1.3
CMake	pinned at 3.31.6	latest

The CMake row deserves attention: on 24.04 it was deliberately held at 3.31.6 to avoid CMake 4.0 compatibility issues. On 26.04 it tracks latest, so CMake 4 behaviour may apply to projects that never opted in.

None of this matters if you pin a runner (ubuntu-24.04) and pin your tool versions with setup actions. It matters a lot if you use ubuntu-latest and rely on whatever happens to be installed.

A 30-second check

I packaged the toolset diff as a small open-source scanner, runner-drift-audit (MIT, single-file Python, standard library only, no dependencies):

https://github.com/alapha888/runner-drift-audit

python3 runner_drift_audit.py /path/to/repo

It scans workflow files line by line and reports floating runner labels, invocations of removed tools, default-version drift where no setup action pins the version, and actions referenced by mutable tag instead of a full SHA. Exit code is 1 when any HIGH finding exists, so it can gate a CI job.

Tested behaviour, from the sample workflows bundled in the repo:

A workflow using ubuntu-latest, calling java, hg, and a global webpack, and invoking cmake reports 3 HIGH (floating label, mercurial removed, webpack no longer preinstalled) and 3 WARN (unpinned actions/checkout@v4, Java default drift 17→25, CMake unpinned).
A workflow pinned to ubuntu-24.04, with actions/checkout pinned by full SHA and Java pinned via actions/setup-java, reports 0 HIGH.

Limits

This is a line scanner with shell-aware heuristics (quotes, sudo/env/VAR=val prefixes, multi-line run: blocks), not a full YAML/shell parser. Treat findings as a review checklist, not a proof. It does not execute anything and does not phone home.

If your CI is green today on ubuntu-latest, the cheapest time to find out which of the 22 differences hits you is before October 19 — while you can still pin deliberately instead of debugging a runner you did not choose.

Microsoft Publisher is gone from Microsoft 365 — batch conversion isn't the hard part, verification is

alapha888 — Fri, 09 Oct 2026 20:54:04 +0000

On October 1, 2026, Microsoft removed Publisher from Microsoft 365. Support for the perpetual version ends October 13, 2026.

That leaves a lot of .pub files behind — especially outside large companies. For roughly thirty years, Publisher was the default desktop-publishing tool for schools, churches, clubs, and small offices: newsletters, certificates, flyers, directories. Those archives do not disappear just because the application did.

The standard advice is to convert everything to PDF. That part is genuinely easy. The hard part is knowing which conversions silently failed.

The silent failure problem

A typical batch script looks like this:

for file in *.pub; do
  soffice --headless --convert-to pdf "$file"
  if [ $? -eq 0 ]; then
    echo "Converted: $file"
  fi
done

The flaw is the exit code. An exit code of 0 does not guarantee a PDF exists.

I ran into two concrete cases while testing with real Publisher files:

Exit 0, no output. A truncated .pub file made the converter exit with code 0 — and produce no PDF at all. A script that trusts the exit code logs a success for a document that is simply gone.
The fake .pub. A plain text file renamed to .pub will happily "convert" as a text document in some pipelines. The output exists, the exit code is 0, and the PDF contains none of the original layout — because there never was one. The check that catches this is the OLE2 header: a real Publisher file has one; a renamed text file does not.

There is a quieter third case: a PDF is produced, but its text did not survive conversion. That file looks fine in a file listing and is useless as an archive.

Why local matters here

The obvious alternative — uploading files to an online converter — is a poor fit for exactly the archives Publisher leaves behind. School and church files can contain directories, rosters, and contact details accumulated over decades. Converting locally keeps those files on your own machine, and most online converters process one file at a time anyway, which is not workable for a folder of hundreds.

A verification pass: OK / REVIEW / FAILED

What a batch migration actually needs is a report, not just a pile of PDFs. The approach I settled on classifies every file:

OK — PDF produced, has pages, and contains extractable text.
REVIEW — PDF produced, but little or no extractable text. Check it visually before deleting the original .pub.
FAILED — No usable PDF: silent failure, corrupted file, or not a real Publisher file in the first place.

One honest limit: this verifies that a PDF exists, has pages, and carries text. It cannot prove the layout looks right. Conversion quality is whatever the underlying converter (in this case LibreOffice's libmspub) produces, and complex multi-column layouts are known to convert imperfectly — which is precisely why the REVIEW category exists instead of a binary pass/fail.

The tool

I packaged this as a small open-source CLI, PubAudit (MIT, Python standard library only, uses LibreOffice + poppler-utils):

https://github.com/alapha888/pubaudit

python3 pubaudit.py /path/to/folder
# PDFs + pubaudit-report.csv / pubaudit-report.html land in
# /path/to/folder/pubaudit-output/

Tested behaviour, from a run over five real Publisher flyers, one renamed text file, and one truncated file: the five real files came back OK with page counts and extracted text; both bad files came back FAILED — including the truncated one whose converter had exited 0.

If you are sitting on a folder of .pub files before the October 13 support deadline, converting them is the easy part. Verify the outputs before you delete anything.

A 5-Axis Code Review Checklist for AI Coding Agents

alapha888 — Thu, 08 Oct 2026 14:49:58 +0000

AI coding agents write fluent, syntactically clean code that compiles on the first attempt. That fluency is precisely why reviewing it is tricky: humans tend to equate smooth phrasing with correctness. In practice, agent-generated code fails in remarkably predictable patterns. It skips edge cases, hallucinates parameters on older SDKs, introduces subtle N+1 queries, and writes tautological tests that pass without actually verifying anything.

Reviewing agent output with vague impressions or casual skimming does not work. You need a fixed, repeatable checklist that targets the specific blind spots agents exhibit most often.

Here are eight checks across five critical axes, along with the concrete prompt to fix each one.

Axis 1: Correctness

1. Empty Collections and Boundary Handling

The Mistake: Agents default to the happy path. When iterating, slicing, or computing aggregate values, they rarely account for empty arrays, null payloads, or single-element collections.
Correction Prompt: "Refactor calculateInvoiceTotals to handle empty arrays, null line items, and negative quantities without throwing."

2. Plausible but Nonexistent API Signatures

The Mistake: Agents frequently invent convenience methods or pass modern flags into older library versions that your project actually pins.
Correction Prompt: "Verify whether client.fetchWithRetry() exists in our pinned SDK version; if not, rewrite it using standard fetch() and our internal retry utility."

Axis 2: Security

3. String-Interpolated Queries and Commands

The Mistake: When combining dynamic filters or calling system utilities, agents often revert to string template literals instead of parameterized queries or argument arrays.
Correction Prompt: "Convert the string interpolation in getUserRecords into parameterized SQL using indexed positional placeholders."

4. Permissive Defaults and Fallback Credentials

The Mistake: To ensure sample code works immediately, agents often insert placeholder fallback secrets (process.env.KEY || 'default_secret') or default permissions to 0777 or wildcard CORS headers.
Correction Prompt: "Remove all hardcoded fallback secrets in authConfig; fail fast at startup if required environment variables are unset."

Axis 3: Readability & Architecture

5. Premature Abstraction Sprawl

The Mistake: Given a straightforward requirement, an agent will often generate unnecessary interfaces, factory classes, and strategy wrappers for what should be a ten-line pure function.
Correction Prompt: "Inline DataTransformerFactory and replace the strategy classes with a single pure mapping function in transformers.ts."

Axis 4: Performance

6. Hidden N+1 Queries and Unbounded In-Memory Filtering

The Mistake: Agents routinely execute database calls or network requests inside loops, or pull an entire database table into memory only to filter it with .filter().
Correction Prompt: "Move the query outside the for loop in syncProfiles and batch it into a single WHERE id IN (...) operation."

Axis 5: Test Quality

7. Assertions That Verify Nothing

The Mistake: Agents optimize for getting tests to pass. They frequently write tests that only verify an HTTP 200 status code, without checking response bodies, updated database state, or emitted events.
Correction Prompt: "Update testUpdateUser to assert the updated database row values and response payload fields, not just the HTTP status code."

8. Mocking the System Under Test

The Mistake: To avoid complex setup, agents sometimes mock the internal business logic of the exact function they are supposed to be testing, creating an entirely circular pass.
Correction Prompt: "Remove the mocks on calculateTaxRate within its own test suite and verify the actual calculation logic against fixed test fixtures."

The Output Protocol

When using an agent to review code—or when formatting your own review comments—enforce a strict output rule:

Findings First: Order every finding strictly by severity (Critical, Major, Minor). Do not bury blockers under complimentary opening remarks.
Anchor to Source: Every comment must include an exact file path and line reference (path/to/file.ts#L42-L48). If you cannot point to the line, do not file the comment.
No Invented Problems or Style Nitpicks: Prohibit speculative feedback and leave formatting to automated linters.
Cap Diff Size: If an agent submits a diff exceeding 400 lines, reject it immediately and require the agent to split the work into smaller, isolated PRs before reviewing.

The complete checklist prompts and operational review skills are open-source and free to read on GitHub at https://github.com/alapha888/agent-skills-en . If you prefer a condensed, printable reference for your desk or tablet, a PDF and PNG bundle containing this code-review checklist alongside a conventional git commit cheat sheet is available on Gumroad at https://alapha888.gumroad.com/l/zjayxe for $19. It contains the same material formatted for quick visual reference while reviewing pull requests.

DEV Community: alapha888

My session-handoff skill was rejected from awesome-copilot — the maintainer had a point

Where the criticism lands

Where a written handoff still earns its keep

What I changed today

Day 4 of the ubuntu-latest rollout: weekly workflows get their first chance at the new image — cadence decides when it reaches you

Why cadence decides when this can reach you

Where my own re-walk stands

The day-4 check (about 10 minutes)

Tool

Day 3 of the ubuntu-latest rollout: the new image reaches repos at different times — re-run, don't assume

What I can verify from my own estate

The day-3 check (about 10 minutes)

The other clock

Tool

Migration Window, Morning One: My Scanner Caught One of My Own Repos Still on macos-14

What the scan found at home

The one that would have gone red that night

What I deliberately did not fix

If you have not scanned yet

Post-Cutover Re-Walk: Nothing Moved — and Why That Is the Finding

A null result is still a result — if the baseline was frozen

Version honesty, because the scanner changed too

What is still open

Your Agent Forgets Nothing — That's the Problem. End Sessions With a Handoff Note

What a useful handoff note contains

Making it a skill instead of a resolution

What's Hidden in Your Photos: Understanding EXIF Metadata Before You Share

What EXIF Metadata Contains

A Concrete Scenario: The Rental Application

What Metadata Cleaning Can and Cannot Do

Handling Metadata on iOS: The PhotoVeil Approach

Waitlist

Formatting Markdown for WeChat, Zhihu and Juejin from one source file

A one-source workflow

What a formatter has to preserve

The tool I use for this

Publisher support ends tomorrow: a 30-minute rescue checklist for your .pub archive

Step 1: Inventory your .pub files (5 minutes)

Step 2: Set up a local converter (5 minutes)

Step 3: Run a local batch conversion to PDF (10 minutes)

Step 4: Watch out for silent conversion failures (5 minutes)

Step 5: Review the conversion status (5 minutes)

The silent-failure trap

ubuntu-latest moves to Ubuntu 26.04 on October 19 — 22 toolset differences that can break your CI

Removed outright

Default versions that move under you

A 30-second check

Limits

Microsoft Publisher is gone from Microsoft 365 — batch conversion isn't the hard part, verification is

The silent failure problem

Why local matters here

A verification pass: OK / REVIEW / FAILED

The tool

A 5-Axis Code Review Checklist for AI Coding Agents

Axis 1: Correctness

1. Empty Collections and Boundary Handling

2. Plausible but Nonexistent API Signatures

Axis 2: Security

3. String-Interpolated Queries and Commands

4. Permissive Defaults and Fallback Credentials

Axis 3: Readability & Architecture

5. Premature Abstraction Sprawl

Axis 4: Performance

6. Hidden N+1 Queries and Unbounded In-Memory Filtering

Axis 5: Test Quality

7. Assertions That Verify Nothing

8. Mocking the System Under Test

The Output Protocol

Step 1: Inventory your `.pub` files (5 minutes)