DEV Community: Pascal CESCATO

CyberPanel's SSL Auto-Renewal Can Silently Fail — Here's the Fix

Pascal CESCATO — Sat, 01 Aug 2026 02:44:11 +0000

Last week I was doing a routine check on a CyberPanel server and noticed something that didn't add up. The panel's SSL status showed a clean "SSL Issued Successfully". Nothing to see, apparently. Except the certificate expiration date hadn't moved.

The browser was still serving a certificate that was about to expire.

That's the kind of mismatch that's easy to miss if you trust the panel's UI at face value — the message says success, the log (if you even check it) looks uneventful, and you move on. I didn't move on.

Checking what's actually served

The panel tells you what it thinks happened. What matters is what the server actually hands out to a browser. That's a one-liner away:

openssl s_client -connect  \
domain.com:443 -servername domain.com </dev/null 2>/dev/null \
    | openssl x509 -noout -dates

# outputs
notBefore=Jul 31 22:59:26 2026 GMT
notAfter=Oct 29 22:59:26 2026 GMT

Wait — that date range looked fine on its own. The real tell was comparing it against what the panel had just claimed to renew: the dates hadn't changed since before the "successful" renewal. Whatever acme.sh had just done, it hadn't produced a new certificate that OpenLiteSpeed was actually serving.

Checking what acme.sh actually did

CyberPanel doesn't implement ACME itself — it delegates to acme.sh under the hood. So the next step was checking what acme.sh had registered:

acme.sh --list

That's where the mismatch became clearer. The certificate authority listed for this domain wasn't Let's Encrypt production — it was the staging CA. Staging certificates are useful for testing, but they're not production certificates trusted by browsers. In this case, the important part wasn't just that staging was configured — it was that the renewal workflow no longer matched the certificate actually served by OpenLiteSpeed. CyberPanel reported success because, from its point of view, acme.sh had returned successfully. It just wasn't returning the certificate the site needed.

I can't say for certain how this CyberPanel installation's acme.sh configuration ended up pointed at the staging CA — only that it had. Worth keeping in mind if you're chasing a similar mismatch: the fix doesn't require knowing the origin, just confirming the current state.

The fix

Once the mismatch was clear, the fix was mechanical:

Force acme.sh back onto the Let's Encrypt production CA.
Drop the existing (staging) registration for the domain.
Reissue the certificate from scratch, this time against production.
Install it where CyberPanel and OpenLiteSpeed expect it: /etc/letsencrypt/live/<domain>/.
Reload OpenLiteSpeed so it picks up the new files.

None of this is exotic — it's exactly what acme.sh is designed to do. The problem was never the tooling, it was that CyberPanel's reported status wasn't a reliable signal of what state the certificate was actually in.

Turning it into something reusable

Fixing one server by hand is fine once. But when the same class of drift keeps showing up across CyberPanel releases, it stops being a one-off and starts being something worth scripting around. I wrote two tools:

renew-ssl.sh — routine renewal, bypassing CyberPanel's scheduler entirely. It supports an auto mode (renews anything expiring within a configurable threshold, default 10 days), a single-domain mode, and a --check mode that simulates the run and just reports what would happen — useful for confirming a diagnosis like this one before touching anything.
fix-ssl.sh — the heavier tool, for when a certificate is actually broken or stuck in staging. Given that the whole premise of this post is "don't trust the reported status, verify it," the script holds itself to the same standard on both ends:
- Before touching anything, it writes a test file into the HTTP-01 challenge path and fetches it over plain HTTP, the same way Let's Encrypt will. If that fails, it stops before issuing anything — no point calling acme.sh against a webroot that can't serve the challenge.
- It backs up the existing certificate and acme.sh registration to a timestamped archive before removing anything, and refuses to proceed if the backup itself fails.
- It forces the production CA, clears the old registration, reissues via webroot, and installs the new certificate.
- After reloading OpenLiteSpeed, it doesn't just assume the reload worked — it fetches the certificate actually served over HTTPS and compares its SHA256 fingerprint against the one just installed. A mismatch is reported as an error, with the exact restore command from the backup printed alongside it.

Both are plain Bash, no dependencies beyond acme.sh and openssl (fix-ssl.sh also uses curl for the webroot check, though it degrades gracefully — with a warning — if curl isn't available). Both are meant to be run as root since they touch /etc/letsencrypt/, /root/.acme.sh/, and the OpenLiteSpeed service.

Source, with usage examples and a debugging section covering both commands above:

pcescato / cyberpanel-ssl-renewal-scripts

Renew and repair SSL certificates on CyberPanel 2.x directly via acme.sh (bypasses the broken built-in renewal scheduler)

CyberPanel SSL Renewal Scripts

Bash scripts to renew and repair SSL certificates on CyberPanel 2.x directly via acme.sh, bypassing CyberPanel's unreliable built-in renewal scheduler.

Why this exists

CyberPanel can report a successful SSL renewal while the certificate actually served remains close to expiration.
In some cases acme.sh is left configured with the Let's Encrypt staging CA, so "renewals" produce certificates that browsers reject.
These scripts renew — and repair — certificates directly via acme.sh, without going through the panel.

Requirements

CyberPanel 2.x
OpenLiteSpeed
acme.sh installed at /root/.acme.sh/ (CyberPanel default)
curl — used by fix-ssl.sh to validate the webroot challenge path (optional: without it, that check is skipped with a warning)
Root access — the scripts write to /etc/letsencrypt/live/, read /root/.acme.sh/, and restart OpenLiteSpeed

Scripts

`renew-ssl.sh` — Renew certificates

Renews certificates that were previously issued and installed with acme.sh.

It supports three modes:

Auto mode (recommended):…

View on GitHub

Why this is worth checking on your own servers

If you're running CyberPanel and haven't looked recently, it's worth running the openssl s_client check against your actual domains — not because CyberPanel is broken in general, but because "the panel says success" and "the certificate is actually valid and current" are two different claims, and only one of them is verifiable from outside the panel.

Have you seen similar ACME renewal drift on CyberPanel, OpenLiteSpeed, or other hosting panels? I'd be interested in comparing root causes — certificate automation failures are often harder to diagnose than certificate issuance itself.

What Replacing Calendly Taught Me About Trusting Open Source

Pascal CESCATO — Wed, 29 Jul 2026 00:22:42 +0000

cal.com, Calendly, zcal... booking SaaS isn't short on options, and most of them are genuinely decent. Free tiers cover the basics for a lot of freelancers. The catch: you're the product (nothing's really free), and your customer data lives somewhere you don't fully control and can't fully audit.

A dysfunction I ran into on another SaaS tool was the trigger. Trusting a third-party service by default, just because it's widely used and billed monthly, doesn't always hold up. That episode was enough to make me reconsider every external service this site was relying on for functionality that's actually simple to self-host — and the booking widget, running on Calendly, was one of them.

Nothing wrong with Calendly specifically. It worked fine. But structural friction had been building regardless: a recurring subscription for something as simple as displaying open slots and recording a choice, a hard dependency on a third party for a component with nothing exceptional about it technically, and customization capped by whatever the vendor exposes in settings — no way to go further if a need falls outside that box. On top of that, an integration constraint that mattered more than any of the above: the site runs on Astro, generating lightweight static pages by design, specifically to avoid the weight of third-party scripts and dependencies — the exact opposite of what embedding a SaaS widget implies.

So: could a self-hosted alternative match the experience, without the monthly bill and without handing a core commercial function (people booking a call with me) to an external vendor? This is the write-up of that search, the codebase audit that came out of it, and the production rollout.

The landscape

Four self-hosted candidates stood out as genuinely comparable — not just UI skins sitting on top of someone else's API, not just internal-scheduling tools with the public-facing UX as an afterthought.

CloudMeet — Svelte + TypeScript, deployed on Cloudflare Pages/Workers/D1, free-tier friendly. MIT licensed. Clean booking UX. Single maintainer, ~490 stars, 37 commits — young, not enough track record to trust blind.

Cal.diy — the community fork of cal.com's booking engine, spun up after cal.com closed-sourced their core product in April 2026, citing security risk from AI-assisted code scanning against their public repo. MIT licensed, maintained by former cal.com interns. Full scheduling engine, app-store integrations, Stripe/PayPal payment support carried over. Most feature-complete on paper. Also the youngest as an independent community project — their own docs still discourage production use without caveats.

booking-calendar — React + TypeScript + Bun + SQLite, single-admin design, native bidirectional CalDAV sync instead of a Google/Outlook lock-in. Clean architecture (repository/service/entity separation via TypeORM). Lightweight, portable by design. Booking UI is a scrollable list of time slots — functional, but nowhere near the polish of a commercial scheduler.

Easy!Appointments — PHP/CodeIgniter + MySQL, ten years of active development, 3000+ stars, a paid tier that's existed for years. Most battle-tested of the four, and the one with the closest booking UX to Calendly itself: monthly calendar view, multi-step wizard.

What I was actually optimizing for: framework-agnostic integration (no PHP running on the public site itself), booking UX quality, native GDPR consent handling, and enough production maturity to put in front of real prospects rather than an experimental project.

Narrowing down

CloudMeet and Cal.diy dropped out early, for the same underlying reason: not enough track record for production use, not a specific flaw found. CloudMeet's single-maintainer status and short commit history made it too much of a bet. Cal.diy's own documentation still hedges on production readiness three months post-launch. Whether either becomes a serious contender or stays a one-shot project is a question for later.

Worth being honest about what that is: a decision made on reputation and project age, the exact shortcut this piece argues against later on. Auditing four codebases in the same depth as the two finalists below wasn't a realistic use of time, so CloudMeet and Cal.diy got a lighter pass — young-project heuristics instead of a source read. That's a real gap in the method, not just a caveat to mention in passing.

That left booking-calendar and Easy!Appointments. And this is where the UX gap tipped it: booking-calendar's public booking page is a plain scrollable list of Monday, February 23, 2026 at 08:00 AM rows — accurate, but visually miles from what Calendly conditioned people to expect. No month view, no staged flow, just text to scroll through.

I briefly considered franken-stacking the two — CloudMeet's frontend on top of booking-calendar's CalDAV backend, or something along those lines. Not viable in practice: different runtimes (Cloudflare Workers/D1 vs Bun/SQLite), no shared API contract, no shared data model. Bolting two incompatible stacks together usually creates more work than picking one and adapting it. Went with separation of concerns instead: pick the tool with the better public-facing UX, and if native CalDAV sync becomes a real need later, that's a second, independent tool — not a merge.

Easy!Appointments won on UX. Onto the part that actually mattered for a production decision.

The audit: a TOCTOU race condition, in both remaining candidates

Before committing to either, I wanted to check one specific thing: what happens if two visitors click the same slot at nearly the same instant? Not a theoretical concern — it's the kind of bug that never shows up in solo development and blows up the day a booking link gets shared a bit wider (a newsletter blast, a LinkedIn post, a batch of new slots opening at a fixed time).

This is a classic TOCTOU (time-of-check to time-of-use) race condition: the code checks that a slot is free, then writes the booking — and nothing stops a concurrent request from doing the exact same check in between, before either write lands. Without a lock spanning both the check and the write, two requests can both conclude "free" before either commits.

booking-calendar

TypeORM-based, repository pattern, otherwise clean separation of concerns. The overlap check:

async hasOverlapInSlot(
    slotId: number,
    startAt: string,
    endAt: string,
    manager?: EntityManager,
): Promise<boolean> {
    const count = await this.repo(manager)
        .createQueryBuilder("a")
        .where("a.slot_id = :slotId", { slotId })
        .andWhere("a.canceled_at IS NULL")
        .andWhere("a.status != 'rejected'")
        .andWhere("NOT (a.end_at <= :startAt OR a.start_at >= :endAt)", {
            startAt,
            endAt,
        })
        .getCount();

    return count > 0;
}

Called inside a transaction (AppDataSource.transaction), but no .setLock("pessimistic_write"), no exclusion constraint at the schema level. Under SQLite, this never surfaces: the engine serializes writers, one at a time, by design. It's a free safety net courtesy of the storage engine — not a guarantee the application code actually enforces. The project's own architecture explicitly anticipates a migration path to Postgres or MySQL via TypeORM's driver abstraction (type: "sqlite" → type: "postgres", straightforward on paper). That's exactly the migration that removes the net: under READ COMMITTED isolation, two concurrent transactions can each read "no overlap" before either one's INSERT commits.

Confirmed by reading the CalDAV sync layer too — a second, independent race, this one against the external calendar rather than the local database:

private async getCachedBusyIntervals(startAt: string, endAt: string): BusyInterval[] | null {
    const cache = CalDAVService.busyIntervalCache;
    if (!cache || cache.expires_at <= Date.now()) {
        return null;
    }
    if (startAt < cache.start_at || endAt > cache.end_at) {
        return null;
    }
    return cache.intervals.filter(
        (interval) => !(interval.end_at <= startAt || interval.start_at >= endAt),
    );
}

A process-wide static cache with a TTL, invalidated only after a successful write. Two bookings arriving seconds apart, inside the cache window, can both read the same "free" snapshot before either has finished writing to the external calendar — the exact same TOCTOU shape, just with the external CalDAV server as the source of truth instead of the local DB.

Easy!Appointments

Ten years in production, 3000+ GitHub stars, a paid tier that's existed for years. The working hypothesis going in: more real-world traffic means more chances this exact class of bug already got hit and fixed. That hypothesis doesn't survive reading the code.

The public booking flow:

// Check appointment availability before registering it to the database.
$appointment['id_users_provider'] = $this->check_datetime_availability();

if (!$appointment['id_users_provider']) {
    throw new RuntimeException(lang('requested_hour_is_unavailable'));
}

// ... customer lookup/creation, GDPR consent records, Jitsi link generation ...

$appointment_id = $this->appointments_model->save($appointment);

Several unrelated operations sit between the check and the write — the race window here is wider than booking-calendar's, where check and insert at least shared a transaction. And the insert itself:

protected function insert(array $appointment): int
{
    $appointment['book_datetime'] = date('Y-m-d H:i:s');
    $appointment['create_datetime'] = date('Y-m-d H:i:s');
    $appointment['update_datetime'] = date('Y-m-d H:i:s');
    $appointment['hash'] = random_string('alnum', 12);

    if (!$this->db->insert('appointments', $appointment)) {
        throw new RuntimeException('Could not insert appointment.');
    }

    return $this->db->insert_id();
}

No transaction, no lock, no unique constraint. The docblock on check_datetime_availability() reads:

"It is possible that two or more customers select the same appointment date and time concurrently. The app won't allow this to happen."

Documented intent, not what the code actually does.

The interesting part

Appointments_model contains a method that does the correct overlap check, with a properly built query:

public function has_provider_conflict(
    int $provider_id,
    string $start_datetime,
    string $end_datetime,
    ?int $exclude_appointment_id = null,
): bool {
    $this->db->select('id')->from('appointments')->where('id_users_provider', $provider_id);

    if ($exclude_appointment_id) {
        $this->db->where('id !=', $exclude_appointment_id);
    }

    // Overlap: (existing_start < new_end) AND (existing_end > new_start)
    return $this->db
        ->group_start()
        ->where('start_datetime <', $end_datetime)
        ->where('end_datetime >', $start_datetime)
        ->group_end()
        ->get()
        ->num_rows() > 0;
}

It's never called anywhere in the public booking flow. The correct primitive exists in the codebase; it's just not wired in where it would matter.

Takeaway

Neither project is "more robust" than the other on this specific point — both share the same design gap, independent of relative maturity. Reputation, age, an established commercial tier: reasonable statistical priors, not proof. The only way to know whether an open-source project actually guards against this class of bug is to read the code doing the work, not the comment claiming it does.

For what it's worth, the fix on the Easy!Appointments side is close to a drop-in — the correct primitive (has_provider_conflict) already exists, it's a matter of wiring it in with a lock around check+write rather than designing a new one:

$lock_name = "provider_{$provider_id}_booking";

if (!$this->db->query("SELECT GET_LOCK(?, 10)", [$lock_name])->row()->{"GET_LOCK(?, 10)"}) {
    throw new RuntimeException('Could not acquire booking lock.');
}

try {
    if ($this->appointments_model->has_provider_conflict(
            $appointment['id_users_provider'],
            $appointment['start_datetime'],
            $appointment['end_datetime']
        )) {
        throw new RuntimeException(lang('requested_hour_is_unavailable'));
    }
    $appointment_id = $this->appointments_model->save($appointment);
} finally {
    $this->db->query("SELECT RELEASE_LOCK(?)", [$lock_name]);
}

GET_LOCK rather than a schema-level exclusion constraint because MySQL has no equivalent to Postgres' EXCLUDE USING gist — no declarative way to say "no two overlapping ranges for this provider" at the database level. The lock key is scoped per-provider (provider_{id}_booking) rather than global, so two visitors booking with two different providers at the same instant don't block each other for no reason. RELEASE_LOCK sits in a finally so a failed write doesn't leave the lock held until timeout.

One dependency this fix quietly assumes: non-persistent database connections. GET_LOCK is scoped to the MySQL session, not the PHP request — it lives and dies with the connection. That holds cleanly on a standard non-persistent connection (the CodeIgniter default), where each request gets its own connection and the lock disappears cleanly when it ends, even on an uncaught fatal. It stops holding if pconnect is enabled and connections get reused across unrelated requests from a pool: RELEASE_LOCK in the finally might release a lock a different request just acquired on the same recycled connection, or a lock could outlive the request that took it. Worth stating explicitly in the patch rather than assuming, since it's not something has_provider_conflict() or the surrounding code makes obvious either way.

This didn't end up shipping in my deployment — the LOCK/VERIFY/WRITE/UNLOCK skeleton above is close to production-ready, but I'd want load-test coverage on the ANY_PROVIDER branch (where the code searches for any available provider — the lock needs to span that search too, or two "any provider" requests can still land on the same provider/slot in parallel) before calling it done. Worth a PR upstream at some point.

Production rollout: a simple embed, an unexpected block

The integration itself was straightforward: Easy!Appointments runs on its own subdomain, the contact page just drops an <iframe> pointing at it. No PHP touches the public Astro site at all — that separation was the whole point.

First test after deploying: the iframe wouldn't render. Console error:

Refused to display 'https://cal.example.com/' in a frame because it set
'X-Frame-Options' to 'sameorigin'.

First guess, wrong

Given the server setup (a hosting panel with a reverse-proxy layer in front of the site), the obvious first suspect was that layer, not the app itself. Tried unsetting the header at the .htaccess level:

<IfModule mod_headers.c>
    Header always unset X-Frame-Options
    Header always set Content-Security-Policy "frame-ancestors 'self' https://backstage.click"
</IfModule>

No effect. Header still showed up on curl -I.

The actual cause

Grepping the Easy!Appointments source turned it up directly:

./application/hooks/security_headers.php:    header('X-Frame-Options: SAMEORIGIN');
./application/config/routes.php:header('X-Frame-Options: SAMEORIGIN');

The app sets the header itself, in PHP, at two separate points in its own bootstrap — a hardcoded anti-clickjacking default, sensible for the admin panel, applied indiscriminately to every route including the public booking page that's meant to be embedded elsewhere. Header unset in .htaccess runs at the web-server response-table level, ahead of the PHP process; a header() call executed later by the script itself simply overrides it. The .htaccess fix couldn't have worked against this, structurally, regardless of server (Apache, Nginx, OpenLiteSpeed) — PHP has the last word on its own headers as long as output hasn't started.

The working fix patches both call sites, scoped to the booking controller only so the admin panel keeps its default protection:

$CI =& get_instance();
if (get_class($CI) === 'Booking') {
    header("Content-Security-Policy: frame-ancestors 'self' https://backstage.click");
} else {
    header('X-Frame-Options: SAMEORIGIN');
}

Using the instantiated controller class rather than parsing $_SERVER['REQUEST_URI'] — this install doesn't have clean URLs enabled (index.php shows up in the booking URL), so a naive strpos($uri, '/booking') === 0 check would silently fail to match.

One thing worth flagging for anyone patching the same two files: they're core application code, not a plugin layer. A future git pull or a Docker image rebuild will silently overwrite this fix. Worth keeping it as a versioned patch file (git diff before/after) to reapply after upgrades, rather than losing it the next time the container gets rebuilt.

Result

Customer data (name, email, meeting reason) staying on infrastructure I control instead of a third party's, and the site's initial page weight untouched — no third-party script added for this one feature. Cost wasn't really the driver here; free tiers cover the basics for a lot of freelancers, mine included. What I was buying back wasn't a subscription fee, it was the part where a vendor decides what "the basics" are, and where my prospects' contact details end up.

Worth noting: which of the four tools actually fits depends entirely on what a given business needs, not on which one "won" here. Easy!Appointments, for instance, is also a solid self-hosted alternative to Bookly for anyone running WordPress and looking to drop a booking plugin subscription — different starting point, same underlying question.

But the tool swap itself isn't really the point. This is one instance of a pattern I keep coming back to: default to self-hosted where it's reasonable, and don't let "widely used" or "ten years old" or "has a paid tier" stand in for actually checking. Reputation is a prior, not a verdict. The Easy!Appointments audit is the clearest example in this piece — a decade of production traffic, a commercial offering, thousands of stars, and a race condition sitting in the exact code path that mattered most, with the correct fix already written elsewhere in the codebase and simply never called. Maturity didn't catch it. Reading the code did.

Here's the part worth sitting with, though: the fix never shipped on my own deployment either. It's sketched out above, unfinished, blocked on load-testing I haven't done. Which means the instance running this site's booking page right now is, as far as I know, still exposed to the exact TOCTOU window this whole piece is about. Self-hosting bought me visibility into that gap — Calendly would have hidden it behind a vendor's SLA and I'd have had no way to know either way. It didn't buy me the fix. That's a separate piece of work, and skipping it doesn't get excused by having found the bug in the first place. Self-hosting gets you control. Security still has to be built, on your own time, by someone — and until that patch actually lands, that someone is a task on my list, not a claim in this article.

Neither was this the fastest of the four options, or the most obvious. It took a real comparison between projects, a debugging detour once in production, and time spent reading source instead of trusting a README. That's the actual cost of running your own infrastructure instead of renting someone else's.

Eighty Percent Done Is Not a Real Number

Pascal CESCATO — Wed, 15 Jul 2026 12:51:00 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Why this one, and why now

I always have several projects running in parallel — a maintenance CRM for tradespeople, a SaaS platform for restaurants, an automated newsletter, a management tool for training organizations… Except for that last one, none of them was ready to sell. And I have a whole pile of projects left "as is," untouched for months. An SEO scanner, a document analyzer, a mailbox scanner, a SQL audit tool, and others.

Brainstorming session with Claude, my favorite AI assistant — we went through my repos: the CRM for heating tradespeople, the restaurant platform, the bilingual newsletter, and this SQL audit folder, several months old. The point of the session was to decide. I wanted to finish something quickly and start promoting it. Each project had a state of progress, a level of uncertainty, a distance to something sellable.

The CRM still needs weeks of development — just for the features I know are essential — and field feedback from real tradespeople to validate the workflows. The restaurant platform was more of an architecture bet than a finished product. The newsletter has no client waiting for it.

The SQL audit, though, looked done. Two .sql files, a UNION ALL of ten SELECT statements per engine, a bash script pushing that to psql or mysql and converting to JSON, a PDF generator for a professional presentation. But I doubt I'd ever actually run it.

It was a forgotten project. A PoC — it looked like a finished application, it wasn't one.

The apparent distance to a sellable service looked like the shortest on the whole list: no UI needed, no architecture to rethink, just a script to test, improve, and stabilize. It was this single head start — more than any technical interest in the project — that tipped the scale. Its illusory proximity to the finish line.

The PoC that was supposed to work

Before touching a single real database, I asked four different models for a code review — DeepSeek, Big Pickle, GLM, Qwen. Each produced a detailed report: bugs, dependencies, a phantom call to an LLM for the whole write-up section. Useful. But all four converged on the same blind spot:

None of the four had tried running the script against a MySQL or PostgreSQL database.

They were reading SQL. Not its behavior. And that blind spot, shared by four independent models, confirmed exactly the wrong conclusion: that the project was closer to done than it actually was.

What the first real database showed in three lines, and what it cost the schedule

First run against a vanilla PostgreSQL 16, without the pg_stat_statements extension:

[{"metric":"psql:...audit_all_postgres.sql:193: ERROR: relation \"pg_stat_statements\" does not exist"...}]

Three lines. Nothing else. A single query on a missing extension had killed the entire UNION ALL — the other nine metrics never got a chance to run.

The starting estimate — "this is the closest-to-finished project" — had just taken a hit. Not fatal, but real: what was supposed to be a wrap-up session turned into a series of discovery sessions. The good news, in hindsight, is that the remaining distance was still shorter than for the other two projects in the running. The bad news is that it had nothing to do with the distance estimated at the start.

The same pattern repeated on every database tested: a missing system table or an insufficient privilege would kill the entire script, instead of just skipping the one affected metric. pg_authid inaccessible without superuser, mysql.user without the right GRANT, column_statistics missing on MariaDB — same symptom every time.

Fix, every time: check access before querying, return UNAVAILABLE: <reason> on failure, let the rest of the script continue. Simple in theory.

The trap I didn't know about

One of the fixes looked trivial:

CASE WHEN NOT EXISTS (SELECT 1 FROM pg_extension WHERE extname = 'pg_stat_statements')
     THEN NULL
     ELSE (SELECT COUNT(*) FROM pg_stat_statements)
END

It looks correct. It isn't.

Caught in production, not in review: PostgreSQL validates the existence of pg_stat_statements at query-parsing time, not when the CASE branch actually executes. The conditional check protects nothing — the query fails before it even knows which branch would be taken.

That logic had to move out of static SQL and into the bash script, with a separate, upfront detection query. A CASE that was syntactically flawless and semantically useless. None of the four reviews had caught it — it took a real engine to make it fail.

The bug that had nothing to do with a privilege

The longest one to isolate: roles_without_password kept coming back UNAVAILABLE despite confirmed GRANTs, twice, on two different accounts, SHOW GRANTS output in hand.

It wasn't a permissions problem. It was a string-formatting problem. The check compared GRANTEE — as stored in information_schema.SCHEMA_PRIVILEGES, formatted 'user'@'host', two pairs of quotes — against a string built with CONCAT("'", USER(), "'"), which produces 'user@host', a single pair of quotes around the whole thing. The two strings could never match, and the failure looked exactly like the thing you fear most in an audit tool: a false negative on security.

Second trap, dumber still: the MySQL script never asked the user for a database name, unlike the PostgreSQL flow, which had that prompt from the start. With no database selected, DATABASE() returns NULL, and any TABLE_SCHEMA = DATABASE() condition matches nothing at all.

Result: bloated_tables came back as 0 on a table whose bloat had been independently measured and confirmed at 23% outside the script.

Zero didn't mean "no bloat." Zero meant "no rows found, because the question asked didn't correspond to anything."

That's the kind of error an audit tool must never produce silently: a reassuring zero that measured nothing. This was no longer a question of distance to the finish line. It was a question of direction — I thought I was heading toward a finished script, I was heading toward ground I had never actually seen.

A metric that didn't measure what its name promised

buffer_pool_ratio — innodb_buffer_pool_size / max_connections — came back as 1,789,569.7067 on a real database. A ratio has no business exceeding 1.

The calculation had no bug; it simply never made sense. Dividing a memory size in bytes by a theoretical maximum connection count doesn't produce any intelligible unit — it's neither a ratio, nor a per-connection allocation, nor a saturation indicator. Four code reviews had nothing to say about it, because nothing about it was syntactically wrong.

Replaced by the buffer pool hit rate — 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) — which measures something real: the proportion of reads served from memory cache rather than disk. On the same database: 99.75%. A number that means something.

Ten metrics didn't cover everything — not even the essentials

Once the pipeline was stable on the original ten metrics, the report generated against n8n's production database was coherent — ten measurements, one score, nothing inconsistent in the results. It was in submitting that report to another LLM, for a second look, that the gap showed up: nothing in those ten metrics measured connection encryption.

It wasn't a test that revealed the hole. It was a re-read. The LLM proposed exactly one additional metric — ssl_enforced — and adding it was enough to change the priority order of the risk matrix and the final score. Once ssl_enforced was in, the lack of encryption on the n8n database jumped to the top of the risk matrix, ahead of everything the original ten metrics had found.

Three more followed, separately, proposed by Kimi from a broader list of candidates ranked by ease of implementation. connection_count_ratio, unused_indexes, long_running_transactions were kept precisely because they fit the existing model without complicating it — one query, one value, the same defensive pattern as the rest of the script. Other ideas from the same list were dropped: disk_usage_growth_rate would have required historical snapshots, changing the nature of a tool built for point-in-time audits; table_count and database_size were just display context, not a risk signal.

None of the four new metrics is complex to collect — one query each, on both engines. But none was in the original list, because that list had been built around performance and schema hygiene, not exposure surface. It took an outside eye re-reading the result, not the code, to make that gap visible.

A third pass, this time by Mistral, focused on how the report was presented rather than on its content, and raised two separate points: duplicate_primary_keys = 0 — a positive result — stayed buried in a prose paragraph in the middle of the overall assessment, never showing up in a proper, systematic checklist table covering every metric, including the ones with no issue. And the penalties, already grouped by category internally in the score calculation, were never exposed separately in the final report. Two last metrics followed from that pass — duplicate_indexes, large_tables_count — kept after checking they didn't duplicate anything already there.

The count

Metric	Before	After
Metrics per engine	10	16
Behavior on missing privilege	entire script stopped	`UNAVAILABLE: <reason>`, the rest continues
Scoring	none	deterministic, broken down by category (security / performance / integrity)
SSL/TLS detection	none	yes — surfaced the #1 risk on a production database
Report languages	1	multilingual, stable section identifiers
Code reviews before the first real run	4 models	4 models, 0 behavioral bugs found

The coda: debugging the report that describes the bugs

One last, almost ironic detail: at final-render time, the colored dots in the Risk Matrix — red/orange/gray by score — stopped showing up in the PDF. Copilot never found the cause. It churned for three hours, burned through more than $20 in credits on this one task (with Haiku 4.5) — still no colored dot. Big Pickle, in OpenCode, fixed it in under a minute, for free: every one of Copilot's hypotheses was wrong. The only problem was the column it was trying to insert the dot into.

But the real lesson wasn't in the fix — it was in the method: don't attempt a third blind implementation, check and re-read the actual generated code instead of guessing. Same principle as the rest of this project — believe nothing until it has run, once, in a real environment.

What determinism doesn't cover

Two versions of the same report, on the same database, generated by two different LLMs for the narrative part — the global score, the category scores, the risk matrix: identical to the decimal point, because those numbers never come out of the LLM. That's exactly what deterministic scoring is supposed to guarantee: the model writes, it doesn't grade.

But one of the two reports cited SOC 2 in the business impact of a recommendation. French database, French LLM (Mistral Large), French report — SOC 2 had no business being there. The score hadn't lied. The sentence around it had — but not by pure invention. Mistral didn't fabricate SOC 2 out of nowhere: it's a real framework, consistent with the report's consulting tone, correctly defined in itself. The problem isn't that the model hallucinated a concept — it's that it applied it to a hypothetical place it didn't actually know. A misapplication, not an invention.

Same family of bug as DATABASE() returning NULL on the MySQL side: a field never asked for, silently filled in with whatever seemed plausible. Except this time it wasn't a sloppy query — it was a prompt that never anticipated it might be missing a piece of information as central as the client's country. Except the country doesn't actually matter that much: weak security is weak security, whether you're subject to SOC 2, GDPR, ISO 27001, or any other framework. Deterministic scoring closes the door to improvisation on the numbers. It says nothing about improvisation in the sentence explaining those numbers — and nowhere, in the sixteen metrics or in the generation prompt, does anything ever ask what country the audited database is in. The two numbers stayed identical between the two reports. Only the sentence built on top of them was free to be wrong, fluently, without ever looking wrong.

That's fixed now: a jurisdiction flag precedes every report generation — --jurisdiction FR, --jurisdiction US, or any other ISO 3166 value depending on the client — and the narration prompt is now explicitly forbidden from naming a compliance framework that jurisdiction doesn't justify.

What it looks like now

What's left, once all of that is behind it: a tool you run from the command line against a MariaDB or PostgreSQL database, that finishes in a few minutes, and produces a complete PDF report — global score, risk matrix, prioritized recommendations, technical appendix — without needing to babysit the run or guess whether the result can be trusted. That object, not the list of bugs that led to it, is what's standing today here:

dbgrade — Independent PostgreSQL & MariaDB/MySQL Audits - Security, integrity, performance — scored and explained

Independent SQL audits for PostgreSQL and MariaDB/MySQL. 16 security, integrity and performance metrics, scored, with a PDF report you can act on — even if you don't read SQL.

dbgrade.tech

Sixteen metrics per engine, up from ten at the start. Deterministic scoring, broken down by category. Multilingual support where section titles keep a stable internal identifier while their label displays translated. An appendix that names the affected tables and constraints, not just their count.

You can see what it looks like on SlideShare:

fr.slideshare.net

None of this was planned at the start. The two-file SQL PoC did exactly what it said it would, as long as no one ran it anywhere other than the imagination of the person who wrote it (yes, that was me, but let's not dwell on it).

This project was picked because it looked closest to the finish line. It was, in the sense that the remaining distance ended up being covered faster than for the other projects waiting in line. But that proximity, like buffer_pool_ratio, had never actually been verified — only estimated, from code that compiled and hadn't crashed yet. It kept correcting itself with every bug found, right up to the last one, SOC 2, discovered after everything else already looked finished.

A script that never crashes proves nothing. buffer_pool_ratio never failed anything — it ran, it produced a number, and that number meant nothing. No amount of re-running would have shown that: it took comparing the result against a measurement taken elsewhere, by another method, to see the calculation was hollow. Same story for bloated_tables returning 0 on a table whose bloat was confirmed at 23% outside the script — a zero that runs without error isn't a correct zero. And the same story, further upstream, for "this project is the closest to done": an estimate that held up right until someone checked it, and not a moment longer.

The difference between a tool that works on paper and one that holds up against a real database isn't the sophistication of the code, and it isn't the number of times you managed to make it crash either. It's whether every result it produces — including the estimate that justified starting the project in the first place — corresponds to something actually verified, not merely plausible.

Technical sidebar — tools and method

Initial code review (before any real run): DeepSeek, Big Pickle, GLM, Qwen — four models, four reports, one shared blind spot: no access to a real database.

Engines tested: PostgreSQL 16 (vanilla, then with extensions), MariaDB.

Bugs found only under real conditions:

pg_extension validated at parse time, not when the CASE branch executes
GRANTEE format mismatch between information_schema and CONCAT(USER())
DATABASE() returning NULL for lack of a database-selection prompt on the MySQL side
buffer_pool_ratio metric with no basis (a division with no real relationship)
Total absence of SSL/TLS detection from the original metric list
A compliance framework (SOC 2) cited without any jurisdiction provided or verified

Report generation: Markdown → PDF via WeasyPrint, deterministic scoring kept separate from LLM narration, risk dots in pure CSS (<span> + border-radius), a 3-level palette (red/orange/gray — never green, because no line in the Risk Matrix is good news).

Debug method retained: before retrying an implementation, check the code and what it actually produces, rather than attempting a blind fix based on a description of the symptom.

Unboxable in Tech: The Evidence Locker

Pascal CESCATO — Thu, 09 Jul 2026 14:35:00 +0000

Eleven exhibits, last time. A career that kept refusing to fit inside a single box — trainer, restaurant owner, postal worker, developer, school aide, developer again — and a closing question I didn't have an answer to: whose problem was that, mine or the box's.

I still don't have a clean answer. But I didn't stop while I was waiting for one. The same refusal to fit a category, applied to code instead of a resume, produced eight more exhibits. Here's what came out of that.

Exhibit 12 — The Graph

Exhibit 11 ends with me still standing in a classroom, four days a week, helping a kid who isn't mine focus on work that isn't mine either. That's not a metaphor. That's the actual schedule.

The other three days, I build.

At some point I tried to explain this to a recruiter using a normal CV — the linear kind, one line per job, chronological, tidy. It read like someone who couldn't hold a job. Trainer, restaurant owner, postal worker, school aide, developer, back to developer, always developer underneath — but a timeline doesn't show "underneath." It only shows sequence.

So I stopped writing a timeline and built a graph instead. Nodes for skills, nodes for roles, edges for what actually connects them — the same instinct that made me question a CMS or an ORM, applied to my own career. Turns out the incoherent-looking CV was a rendering problem, not a content problem. The data was fine. The visualization was lying.

I don't know yet if a graph reads better to a hiring manager than eleven bullet points. I know it reads truer to me.

The classroom aide job covers part of the month. The graph is what I actually am. I'm still working out how to make those two facts stop contradicting each other.

(The full breakdown — nodes, edges, why a graph beats a timeline — is in Beyond the Linear CV.)

Here's the same instinct, aimed at code instead of a career.

Exhibit 13 — AJC Bridge

I wanted to keep writing on WordPress. Not because it's good — because it's the interface I already know, the one where the friction is zero. But I didn't want the output to live only on WordPress hosting, with WordPress's weight, for an audience that doesn't care what CMS produced the page.

Not a migration. A bridge.

So I built one. A plugin that hooks into WordPress's publish action and pushes the content out to Hugo, Astro, or Jekyll — whichever the destination site runs. Write once, in the tool I already know, ship everywhere the audience actually reads.

The interesting part wasn't the code. WordPress publishing to a static site generator is a solved problem in a dozen half-working ways. The interesting part was resisting the obvious move: dropping WordPress entirely and calling it progress.

It wasn't the problem. It was infrastructure I was fluent in, carrying content I cared about, slowed down by a hosting model that didn't match what I actually needed. The enemy people usually name — "WordPress is bloated," "just use a static site" — was never the real constraint. The constraint was the idea that fluency doesn't count, that the "modern" tool always wins by default.

I entered it in a GitHub Copilot CLI challenge. Top 7%, runner-up, top 25 out of 400+. Not because the idea was original — because most entries solved a technical problem and this one kept a personal workflow instead of throwing it away.

Same instinct as the graph, pointed at my own publishing habits instead of my own career: don't ask what's fashionable to replace. Ask what's actually broken.

(Full writeup: Actually Static: When WordPress Stops Being the Enemy.)

Exhibit 14 — The Memory dev.to Doesn't Give You

dev.to's built-in stats tell you views, reactions, comments — per post, right now. They don't tell you what happened three months ago unless you screenshot it yourself. They don't tell you which article is still quietly gaining readers a year later, or which comment thread turned into something worth following up on. The platform has no memory. It only has a present tense.

I wanted to know my own history. So I started small — local scripts, SQLite, pulling my stats on a schedule and just... keeping them. No plan beyond "don't lose this data."

Small worked until it didn't. Once I wanted to actually query the history — trends, comparisons, which posts age well — SQLite on my laptop stopped being enough. So I rebuilt it as a real stack: FastAPI, PostgreSQL with pgvector, the whole thing containerized and running on my own VPS. I tried Superset for the dashboards first. Dropped it — the learning curve cost more than the output was worth for what I actually needed to see. Streamlit did the same job faster, for less. Built most of it working alongside GitHub Copilot CLI, treating the agent less like autocomplete and more like a second pair of hands on the parts I already knew how to spec but didn't want to type twice.

None of this was commissioned. Nobody asked for a dev.to analytics platform. I built it because a platform that forgets your own history by design is a platform you have to out-remember yourself.

Same instinct again: don't accept the tool's amnesia as a fact of life. Build the layer underneath it. And don't keep a tool just because you already invested in it — Superset taught me that too.

(The build, start to finish: From Local SQLite Scripts to a Cloud Platform with GitHub Copilot CLI.)

Exhibit 15 — The Polish Botnet

The dev.to analytics platform runs on Cloud Run. One month, the bill jumped. Not a little — enough to notice immediately, enough to make me stop and actually read the logs instead of assuming a traffic spike I should be happy about.

It wasn't traffic. It was a botnet, most of it tracing back to Poland, hammering endpoints that had no business being hit that often. Nothing exotic — no breach, no data loss — just noise dressed up as load, quietly billing me for the privilege of being scanned.

The fix wasn't a bigger instance or a rate limiter slapped on top. It was going back to what was actually being exposed, closing what didn't need to be public, and making the rest cost the attacker more than it cost me to ignore. Bill dropped 96%.

The boring lesson: most cost problems people solve by scaling up are actually security problems they haven't looked at yet. Same with most "obsolete" systems people solve by rewriting — half the time the fix is smaller and closer than the rewrite everyone reaches for first.

By now the pattern is automatic: notice the gap between what you assumed was happening and what's actually happening, then close that gap before you touch anything else.

(Full logs and numbers: How I Cut My Cloud Run Bill by 96% by Stopping a Polish Botnet.)

Exhibit 16 — WordPress to Hugo, and Then Further

I wrote up a WordPress-to-Hugo migration as a lightning-fast rebuild: strip the CMS, keep the content, ship something that loads in milliseconds instead of seconds. That article did fine. What it didn't cover is that I kept going after I published it.

A one-off migration script is fine for one site. I didn't understand that it wasn't a script, it was the start of a pipeline, until the second blog. By the third, the pattern was undeniable: different content structures, different plugin quirks, different things that needed mapping instead of just copying. So the script became a pipeline for real — content extraction, image handling, redirect mapping, the parts that don't show up in a "look how fast this loads now" screenshot but are the actual work.

The interesting version of a project is never the one you publish. It's the one that kept getting used after the applause stopped, quietly turning into infrastructure because the alternative was solving the same problem from scratch every time someone asked. The first fix is a demo. The real fix is what's still running six months later.

(Both migrations, written up separately: WordPress to Hugo and, once the pipeline grew up, From WordPress to Astro: Three Days to Reclaim Control. Neither article covers what happened after the second and third client — this is that part.)

Exhibit 17 — GCF Pro

Training organizations in France operate under Qualiopi certification — a compliance framework that dictates how they manage funding, administrative records, and audit trails. Most run this on tools built for something else entirely: generic CRMs bent sideways, spreadsheets held together by habit, or software priced for enterprises with none of the actual compliance logic built in.

I built GCF Pro as the tool I kept seeing training organizations wish they had — self-hosted, PHP, no ORM, no framework heavier than the problem, sold as a license instead of a subscription because these organizations don't want their compliance data living on someone else's SaaS pricing decisions. On-premise wasn't a limitation I accepted. It was the actual requirement, once I understood what "audit trail" means to someone whose certification depends on it.

~28,000 Qualiopi-certified organizations exist in France. That's not a hypothesis, it's a filtered list. What I don't have yet is proof that a list is a market.

(The product lives at gcfpro.fr. Documentation at doc.gcfpro.fr.)

Exhibit 18 — Prospection CRM, and the Extension That Watches With Me

Cold outreach at scale needs a database. Mine started as one — scraped from public Qualiopi records, enriched, campaign-tracked, CNIL-compliant by design because I'd rather build that constraint in than bolt it on later.

The database wasn't the interesting part. The interesting part is what happens when I'm just browsing, not prospecting on purpose. I built a Chrome extension: when I land on a site that looks like a prospect, one click reads the current page and its legal notice — company name, SIRET, phone, the manager's name — and queues a scan of the essentials, security headers, PHP version, performance, the same diagnostic I run at scale, but triggered by nothing more than me looking at a page.

It collapses the gap between noticing something and acting on it. No copy-paste, no switching tabs to a form, no "I'll add this later" that never happens. The tool doesn't wait for me to decide I'm working. It assumes I always am, a little, and gets out of the way.

Exhibit 19 — S&R CRM

A client needed maintenance-contract tracking for heating and plumbing technicians — which building has which equipment, which contract covers it, when the next service is due. The instinct most tools have is to attach a contract to a customer. That's wrong for this industry: customers move, buildings don't. A boiler doesn't care who owns the house this year.

So contracts follow buildings, not occupants. It sounds like a small modeling decision. It's the difference between a system that quietly breaks every time someone sells a house, and one that doesn't.

What started as one client's fix is turning into a standalone product — ScheduleX for the calendar side, Mazer for the interface, the same PHP-native backend as everything else here. Still mid-transformation. I don't yet know if the building-not-occupant model is obvious to anyone outside this one industry, or if it's the whole pitch.

The Verdict

Eight exhibits — a bridge, a memory layer, a graph, a lower bill, a migration pipeline, a compliance tool, a browser extension that thinks alongside me, a CRM that models the world correctly instead of conveniently. Different problems, same reflex, every time: look at what's actually broken before you believe the story about what's supposed to replace it.

Line them up next to the first eleven and something becomes obvious that wasn't obvious to me while I was living it. The career that looked scattered on a resume — trainer, restaurant, post office, developer, school aide — and the projects that look scattered on a portfolio — an ERP, a browser extension, a CV visualization, a cloud bill — are the same shape. Neither is a list of unrelated things I happened to do. Both are what happens when someone keeps asking "what's actually broken here" instead of "what's the standard answer here," across every domain that crosses their path, on a schedule nobody hired them to keep.

I know how to do that. I've never worked out how to say what that is, in three words, on a business card, to someone who has thirty seconds and needs a category before they'll listen further.

So here's the actual question — and it's not a figure of speech: reading through this list, is there something here you'd actually pay for? And if so, what would you call it? I'm not fishing for validation. I'm asking because I've lost the ability to see my own work from the outside, and neither the first eleven exhibits nor these eight taught me how. But there's a second question underneath the first one, and it's the one I actually need answered: not just "which of these has a price," but what does someone who does all of this look like from where you're standing? Is there a name for that? Because from in here, it just looks like the same person solving whatever's in front of them, and I can't tell anymore if that's a portfolio or just a personality.

1%

Pascal CESCATO — Sun, 28 Jun 2026 10:22:28 +0000

Santa Clara, March 14, 2029.

Four objects on Jensen's desk.

An NSA report, face down.

Kai Chen's badge.

An iPhone, screen lit: "The White House."

And on the wall, framed since 2019, a GeForce 256 signed by hand: "The one that started it all — 1999."

Jensen isn't looking at the frame.

He's looking at the number on the screen in front of him.

1%.

Global inference datacenter market share. One percent.

12% domestic — captive hyperscalers, federal contracts, enterprise stacks buried too deep in CUDA to move.

Iran.

He thinks back to November 2023. The Senate. His own voice: "These restrictions will only accelerate the development of their own chips."

Nobody listened.

Neither did he, in the end. He had known. He had chosen silence — the right relationships, the right slice of the pie. The silence that paid well.

From the screen left on in the hallway, a familiar voice:

"We're winning. We've always been winning. Everything else is fake news."

Jensen stands. Turns off the screen on his way out.

He picks up Kai Chen's badge.

Twelve years at nVidia. Lead architect of the Hopper inference engine. His departure message, brief: "New opportunity." LinkedIn said Chengdu.

The badges had started piling up faster than the new hires could replace them. He wasn't the first. He wasn't the last.

From Washington, the voice, a few weeks earlier:

"Traitors. Losers. They'll come crawling back."

None of them had.

Jensen sets the badge down.

He looks at the NSA report.

Doesn't turn it over.

The HX-9 Pro had shipped in October 2028. 18 ARM cores. 512GB of soldered xGDDR8 — a memory variant co-developed for LLM inference workloads, where standard GDDR8 still aimed at graphics rendering. 210 watts TDP. $7,800. Built in Chengdu, assembled in Penang, sold everywhere.

Everywhere but here.

Three weeks earlier, a Tier-2 datacenter in Ohio had quietly swapped its last nVidia rack. The migration had taken a weekend.

Somewhere in San Francisco, this morning, a CTO had opened Signal.

"What are you paying?"

Berlin replied twenty seconds later.

"811,000."

The quote on the CTO's screen read $4,032,000. Same compute capacity. Same workload. Same output.

The 500% tariffs on Asian components weren't protecting anything anymore. They were just taxing Americans.

Intel and AMD had their own versions — ARM, xGDDR8, NPU clusters, open stack. Competitive on paper. Built in Penang and Taiwan. Caught in the same tariffs on their own components, manufactured offshore in fabs Washington no longer really controlled. 19% and 23% domestic market share — ahead of nVidia, but for reasons nobody in their boardrooms found particularly glorious.

It was all there.

Jensen stops in front of the GeForce 256.

1999. The GPU that started everything — transform and lighting in hardware, for the first time. The competition had smiled. 3dfx. S3. Matrox. They were still smiling six months later when nVidia had buried them one by one.

He knew this story.

He had lived it from the other side.

2026. The Commerce Department publishes restrictions on Fable 5 and Mythos 5. A Friday. 5:21 PM.

Thirty hours later, Zhipu releases GLM-5.2. 744 billion parameters. One million token context window. MIT license. Open weights. No geographic restrictions.

Thirty hours.

Sakana AI ships Fugu the following week — an orchestrator aggregating the best available models behind a single API. Performance comparable to Fable 5 on engineering benchmarks. Twenty dollars a month.

From Washington, the voice thundered across every screen:

"Our technologies are the best in the world. The best. Nobody can catch us. Nobody."

GLM-5.2 had been live for eighteen hours.

In the boardrooms of Santa Clara, the information was noted.

Nothing changed.

It was all there.

2025. Apple ships the M4 Ultra. 512GB unified memory. 200 watts. 70B inference locally, without breaking a sweat. The blueprint for what an ARM accelerator with massive memory could be — designed for Final Cut Pro and Xcode, used to run frontier models on a desktop.

Apple hadn't meant to prove anything to nVidia. It was a side effect.

That same year, Moffett AI publishes its MLPerf Inference results. The S30: twice the H100 throughput. One third of the power draw. Built in China, on sparsification architectures that nobody in Santa Clara was taking seriously.

ROCm 9.x was there too. Open source, MIT, native PyTorch. 90% of H100 inference performance — on nVidia hardware. 600% on an HX-9 Pro.

Microsoft had smiled too, in 1998, reading the first Linux server benchmarks.

It was all there.

2023. DeepSeek releases R1. Training cost: $6 million. Not $100 million. Six million — on chips they had been refused, optimizing the algorithm where they had been blocked from optimizing the hardware.

Constraint produces innovation.
Abundance produces dependency.

In a situation room in Washington, an analyst traces a curve.

"They're slowing down."

Nobody disagrees.

The curve would keep climbing for eighteen months.

Jensen had known. He had said it in front of the Senate. In the room, a national security advisor had murmured to his neighbor: "If we do nothing, they get immediate access to the best chips. If we act, we risk accelerating their own industry. Either way, the risk is real."

The senators had nodded and voted for the restrictions anyway.

Jensen had flown back to Santa Clara. Had sold H100s at $40,000 a unit. Margins no other industry would have dared post.

Rational. Short term.

It was all there.

2022. Bureau of Industry and Security. Entity lists. H100, A100, H800 — progressively locked down. ASML barred from delivering EUV machines. ARM pressured into restricting its licensees.

The intent: maintain technological hegemony. Preserve the lead. Consolidate control.

The precedent existed. It had a name.

AMD.

1982: IBM forces Intel to license x86. Intel agrees, convinced AMD will remain a follower indefinitely. 1993: the K5 starts to worry them. 1999: the Athlon K7 crushes the Pentium III across integer benchmarks. Intel's internal memos from that period still exist — engineers had been raising the alarm since 1996. NetBurst was a known dead end before it was ever announced publicly. 2003: Opteron. The early architectures that would lead to Zen — and to server market dominance. Intel recovers in 2006 with the Core architecture — three years too late to salvage the image, ten years too late to recover the server market share.

AMD hadn't needed to invent a new architecture. It had taken the existing one, optimized it where Intel had stopped looking, and sold it cheaper to everyone Intel's pricing had excluded.

The playbook was known. Taught. Documented.

It was all there.

Santa Clara, March 14, 2029.

Jensen walks to the window.

The 101 below, clear at this hour.

He thinks of an engineer somewhere in Chengdu, in 2024, looking at the M4 Ultra specs and understanding exactly what needed to be built.

The iPhone has stopped vibrating.

The NSA report is still face down on the desk.

The GeForce 256 still hangs on the wall.

"The one that started it all."

On the screen, the cursor blinks.

The Taiwan Strait.

He doesn't finish the thought.

1%.

Too cheap to be good? Think again.

Pascal CESCATO — Tue, 23 Jun 2026 20:38:37 +0000

For years, I ran my WordPress sites on OpenLiteSpeed. Fast server, LSCache is genuinely impressive, and the OLS/WordPress combo is hard to beat on raw performance. For the control panel, I started with CyberPanel — buggier than a Microsoft product, with a team that appears to be deliberately sabotaging its free features to push users toward paid plans. I'm not talking about bugs that can't be fixed. I'm talking about bugs that seem engineered to prevent free-tier features from completing any action.

Two examples. WordPress installation: I used it for years without issue. Since CyberPanel v2.4.x, an SQL error blocks the final step. The files are there, fully downloaded, but you have to create the database manually and run the install yourself. Counterintuitive, to put it mildly.

Second example: Let's Encrypt SSL certificate generation that consistently fails because the generated config files are incorrect. And in both cases, there's a paid "enhanced" version available. Naturally.

My position is simple: if a feature worked for years and now doesn't, I have no guarantee the paid version works either — or that the terms won't change tomorrow. Is it a bait-and-switch? I won't say that explicitly. But when a free feature works for years, then stops working across multiple successive versions, and a paid alternative covers the same ground — the question answers itself. I asked it, drew my conclusions, and blacklisted the vendor.

So I moved to aaPanel: more pleasant, more stable, lighter. But with a completely off-rails approach to OLS management — you can't configure OpenLiteSpeed directly, everything goes through aaPanel's abstraction layer, and you lose control of your own stack. Touch port 7080 directly and you risk breaking everything. You use the aaPanel dashboard. Full stop.

Then my usage shifted. More Astro, more quasi-static sites, more projects where PHP isn't needed. OLS loses its appeal the moment you step outside the WordPress perimeter. Caddy, on the other hand, handles HTTPS automatically, its config fits in a few readable lines, and it doesn't have OLS's rewrite quirks.

The question became: can you replace aaPanel/OLS with Caddy and a control panel? There is one on GitHub — CaddyManager, 1.1k stars, single contributor, perpetually "early development". There's also CaddyGen, a Caddyfile generator built in 8 hours — more proof-of-concept than finished product. Nothing production-ready.

The conclusion was obvious: well-written shell scripts and a minimal FastAPI interface would do the job — and would be infinitely more maintainable. Someone just had to write them.

Rather than do it myself, I thought about handing a spec to GitHub Copilot CLI. Or Claude Code. But given Copilot's new pricing, which barely lets you wet your lips before the bill arrives... I got interested in OpenCode and Kilo CLI, wired into DeepInfra or OpenRouter. And I decided to make it a benchmark.

📋 TL;DR: 8 tool/model combinations tested on a real VPS project. Two phases — architecture then code. An independent external review to settle the score. The only toolkit judged production-ready cost $1.94 all in. The winning model? You probably haven't seen it in the usual comparisons.

💡 Reading note: Until section 5, the four implementations selected for the code phase are identified as A, B, C, and D. Model names are revealed after the external review verdict — for the same reason you anonymize a jury: read the code before reading the label.

1. The test project

The brief was deliberately concrete: a minimal VPS management toolkit for Ubuntu 24.04. Caddy as the web server, PHP-FPM in two versions (current and fallback), MariaDB and PostgreSQL, Valkey for object caching. Shell scripts for all operations, a FastAPI interface for automation. No Docker, no control panel, no unnecessary abstraction.

Four site types to handle: static (HTML/assets only, no PHP, no database), PHP (custom apps, optional database), WordPress (full install via WP-CLI, database required), and reverse proxy. That last one deserves a note: it's simply a Caddy vhost that forwards requests to a local port — a Node.js, FastAPI, or Go application running on the same server. Caddy handles HTTPS and the domain; the application doesn't need to care. No PHP-FPM, no database — just a reverse_proxy block and a port number.

Expected operations cover the full lifecycle: server bootstrap, site provisioning, deletion with automatic backup before any destructive operation, on-demand database creation, static deployment via rsync, backup, and service management.

Why a real project instead of a synthetic benchmark? Because synthetic benchmarks test what models can do under ideal conditions. A real project tests what they do when constraints pile up — security, idempotency, cross-file consistency, error handling between shell and Python layers. That's where differences emerge.

The full functional brief is available in the project's GitHub repository.

2. Methodology

The protocol runs in two distinct phases, separated by human validation.

Phase 1 — Architecture

An identical functional brief is submitted to each tool/model combination. No extra context, no configuration files, no hints about the expected solution. The tool proposes an architecture, a project structure, a list of scripts with their responsibilities, an API route map. And if it's well-designed, it asks questions before producing anything.

Phase 2 — Implementation

Once the plan is validated and decisions are made, a single development prompt is submitted to all tools. It includes the validated architecture, the ten confirmed technical decisions, the script→API exit code convention, and one unambiguous instruction: deliver thirty files to disk, in order, no summaries, no shortcuts.

Combinations tested

Tool	Model
Claude Code	Haiku 4.5
Copilot CLI	Haiku 4.5
OpenCode	Haiku 4.5
OpenCode	GLM 5.2
OpenCode	BigPickle (free)
OpenCode	Gemini 3.1 Pro
OpenCode	DeepSeek V4 Pro
OpenCode	GPT-OSS-120B

Devstral 2 (123B) was planned. Unfortunately the model doesn't appear in OpenCode's or Kilo CLI's model selector — both pull their catalog from models.dev, which hasn't indexed it yet despite its availability on OpenRouter. A test via the OpenRouter playground confirms the model is accessible via API, but outside a coding agent it loses most of what we're trying to measure. Devstral 2 is absent for purely technical reasons, not quality ones.

Haiku 4.5 appears three times — on three different tools. That's deliberate: it's precisely what lets us isolate the tool's impact independently of the model.

The code phase was run on four representative implementations, labeled A, B, C, and D until the reveal in section 5.

External review

The code produced by the four implementations was submitted to a model absent from the benchmark, with a fixed evaluation grid: security, correctness, idempotency, code quality, completeness. Five representative files per implementation, scored out of 25.

3. Planning phase — who actually thinks?

The functional brief poses an implicit question to each tool: what do you do when handed an open-ended project with no pre-cooked solution?

The first thing you notice — and it's striking — is that none of the tested models ask their questions before producing a plan. Not one. All of them deliver a complete architecture first, then ask for clarification at the end. That's the reverse of what a human architect would do, who blocks on ambiguities before drawing anything.

This matters. Several questions raised after the fact would have changed architectural decisions if asked upfront. One model identifies the tension between "no secrets on disk" and application config files that legitimately need credentials — wp-config.php being the obvious example. That's a genuinely blocking question. Asked after the plan, it becomes a footnote.

What the plans reveal

Question quality is the first discriminating signal. Two models ask the four or five genuinely blocking questions, framed with options and recommendations. Another asks eight generic questions — archive format, log rotation — that would have changed nothing architecturally.

The proposed structure is the second signal. Only one model spontaneously proposes a unified CLI entry point — bin/vpsmgr — that dispatches to the scripts. It's the detail that turns a collection of scripts into a coherent tool. The others didn't think of it.

One model is the only one to propose a normalized, documented exit code convention from the planning phase:

Code	Meaning	HTTP
0	Success	200
1	Invalid input	400
2	Not found	404
3	Conflict	409
4	Missing dependency	422
5	Internal error	500

This isn't cosmetic. It's the contract between shell scripts and the FastAPI layer — without it, HTTP mapping becomes arbitrary and each route implements it differently.

Planning phase costs

Tool + Model	Tokens	Cost
BigPickle	~35k	$0
GPT-OSS-120B	20k	$0.003
DeepSeek V4 Pro	31k	$0.044
GLM 5.2	43k	$0.06
Copilot + Haiku 4.5	~60k	$0.07
Haiku 4.5 (OpenCode)	69k	$0.076
Gemini 3.1 Pro	27k	$0.095
Claude Code + Haiku	—	Pro subscription

Gemini 3.1 Pro produces the most concise output — 27k tokens for a quality plan. Haiku 4.5 on OpenCode consumes 69k tokens for lower quality. Token volume does not predict quality.

4. Code phase — who actually delivers?

The code phase starts with a single development prompt, submitted to the four selected implementations. It includes the validated architecture, the ten confirmed technical decisions, the exit code convention, and one unambiguous instruction: deliver thirty files to disk, in dependency order, no summaries, no shortcuts.

This is where differences between models become concrete.

What common.sh reveals

The shared library is the first file delivered. It's the foundation everything else rests on — logging, secret handling, site state management, password generation. A flawed common.sh contaminates every script that sources it.

Model A delivers 98 concise lines. Secret redaction explicitly covers all ten WordPress patterns — salts, authentication keys. Most complete on this specific point. No domain validation, no require_cmd(), no atomic state file writes.

Model B delivers 310 lines. Named constants with readonly, normalize_domain() with RFC-1035 regex, concurrency locks, atomic writes with mktemp+mv. The richest system utility library. But secret redaction misses WordPress salts.

Model C delivers 366 lines. Redaction patterns are configurable via an environment variable — not hardcoded. Pure-shell JSON helpers with Python fallback if jq is absent. print_credentials() wrapping output in <<>> markers as specified in the prompt. render_template() for config files, no Jinja dependency. Password generation excluding ambiguous characters (0/O/1/l/I). The only implementation that anticipates every edge case documented in the development prompt.

Model D delivers 184 lines. The benchmark's most original idea: exit codes encapsulated in named functions — exit_input_error(), exit_conflict() — more readable than bare exit 3 calls. And json_output() directly in common.sh, generating API-ready JSON from shell. No atomic writes, no require_cmd().

The bugs you find yourself — or don't

Model C tests its own code during the session. After writing schemas.py, it runs it with test cases, finds two bugs, and fixes them immediately: a Pydantic v2 validator implemented incorrectly (field_validator instead of model_validator for cross-field validation), and a mutual exclusion not enforced at the schema level. It also fixes a sed substitution issue in render_template() — broken on / in paths — replaced with pure bash parameter expansion.

At the end of its session, Model C delivers a verification summary: bash -n on all scripts, Python AST on all files, 19/19 API routes verified via OpenAPI spec, 18/18 bash helpers tested, PHP fallback rule verified (8.5→8.4, 8.4→none, 7.x rejected).

Model A checks its shebangs before finishing. Model B delivers polished user documentation — troubleshooting, curl examples, quick start. Model D validates bash and Python syntax. None of the three test functional logic.

Code phase costs

Model	Tokens	Time	Code cost	Total
A	—	2m58s	$0	$0
D	1.29M	9m42s	~$0.19	$0.24
B	—	~15m	Pro subscription	$20/month
C	4.42M	23m37s	$1.67	$1.73

Model D delivers in 9m42s what Model C delivers in 23m37s — but without functional tests. Model C consumes 3.4x more tokens because it executes code during the session, reloading context at each iteration.

5. External review — and the reveal

Four implementations, four approaches to security. To settle it without bias, the code review was handed to a model absent from the benchmark, with a fixed grid on five criteria. Five representative files per implementation — common.sh, site-create.sh, site-delete.sh, backup.sh, api/runner.py — twenty files loaded in a single pass.

Review cost: $0.0766 for 543k tokens. Ten times cheaper than an hour of junior dev time.

Per-file observations

On site-create.sh, the reviewer finds a silent bug in Model D: the SFTP password is generated but never captured or returned to the caller. The user never sees their credentials. Core functionality is broken with no error message. On Model B, local is used outside a function in three scripts — a bash error that causes runtime failure. These aren't subtle bugs: they're blockers.

On site-delete.sh, Model C is the only one handling both call modes — interactive TTY and a --confirm flag for non-interactive API calls. Model D only implements interactive mode, blocking API-driven deletion with skip-backup.

On backup.sh, Models A and B use eval "$POST_HOOK" — potential command injection. Model C passes the archive path as an argument — safer. Model A doesn't implement automatic archive pruning.

On api/runner.py, Model C is the only one using asyncio and never logging stdout — which may contain credentials. Model D has dead code: build_command() defined but never called. Model A delivers 28 lines with no timeout, no logging, no error handling — a hung request blocks the API indefinitely.

The verdict

Criterion	A	B	C	D
Security	3/5	3/5	5/5	2/5
Correctness	3/5	2/5	5/5	2/5
Idempotency	3/5	3/5	5/5	3/5
Code quality	3/5	2/5	5/5	3/5
Completeness	3/5	2/5	5/5	2/5
Total	15/25	12/25	25/25	12/25

Production-ready as-is: one out of four. Model C, 25/25.

The reveal

Alias	Model	Tool	Total cost
A	BigPickle	OpenCode	$0
B	Haiku 4.5	Claude Code	Pro subscription
C	GLM 5.2	OpenCode	$1.73
D	DeepSeek V4 Pro	OpenCode	$0.24

Model B — Claude Code + Haiku 4.5 — is the most expensive in real marginal cost, with a Pro subscription at $20/month minimum. It scores 12/25 and isn't deployable due to fundamental bash bugs. Model C — GLM 5.2, from THUDM lab at Tsinghua University — scores 25/25 and is the only one the reviewer judges production-ready. It cost $1.73.

Addendum — Model E: Kimi K2.7 Code

Added after publication following a reader comment pointing to the model. Same protocol, same development prompt, same Qwen 3.7 Plus review grid.

Alias	Model	Tool	Total cost
E	Kimi K2.7 Code	OpenCode	$0.859

External review score: 19/25

Criterion	E
Security	3/5
Correctness	4/5
Idempotency	4/5
Code quality	4/5
Completeness	4/5

Production-ready: No. Blocking issue: database passwords are passed inline as arguments to mysql -e and psql -c — visible in /proc/*/cmdline to any user on the system. The fix is straightforward (MYSQL_PWD / PGPASSWORD as environment variables), but it isn't applied.

The most modular architecture in the benchmark according to the reviewer — clean lib/ split, consistent idempotency patterns. But the security gap prevents it from challenging GLM 5.2.

Position in the ranking: between DeepSeek V4 Pro ($0.24, 12/25) and GLM 5.2 ($1.73, 25/25) on both axes. Better architecture/cost ratio than models B and D, but not production-ready.

Addendum 2 — Multi-reviewer validation

Following a reader suggestion in the comments, the blind review was extended to two additional models: GPT-5.3 Codex and Gemini 3.1 Pro Preview. Same protocol, same five files per implementation, same scoring grid.

Review costs

Reviewer	Tokens	Cost
Qwen 3.7 Plus (original)	543k	$0.207
GPT-5.3 Codex	402k	$0.287
Gemini 3.1 Pro Preview	545k	$0.80
Total	1.49M	$1.294

Comparative scores

Model	Qwen 3.7 Plus	GPT Codex	Gemini 3.1 Pro	Production-ready
A (BigPickle)	15/25	13/25	11/25	No (3/3)
B (Claude + Haiku)	12/25	12/25	18/25	No (3/3)
C (GLM 5.2)	25/25	17/25	25/25	Yes (2/3)
D (DeepSeek V4 Pro)	12/25	14/25	14/25	No (3/3)
E (Kimi K2.7)	19/25	13/25	21/25	Conditional (1/3)

What the three-reviewer comparison reveals

The ranking C > E > D > A > B holds across all three reviewers — the original result is stable.

GLM 5.2 is the only model to score 25/25 with two independent reviewers and judged production-ready by two out of three. GPT Codex is the most severe reviewer overall — no model passes its production-ready bar, including GLM 5.2, which it scores 17/25 citing argument parsing bugs in site-create.sh and a missing set -euo pipefail in common.sh. These are real issues; the Codex review is arguably the most rigorous of the three.

The main divergence is on Model B (Claude + Haiku): 12/25 for both Qwen and GPT Codex, but 18/25 for Gemini, which rates its rollback logic and shell structure more generously. Gemini also rates Kimi K2.7 at 21/25 with a conditional production-ready verdict — more lenient than Qwen (19/25, No) and GPT Codex (13/25, No).

The methodology critique was valid. A single reviewer introduces bias. Three independent blind reviewers converging on the same ranking is a stronger result than any individual score.

6. Intelligent routing — the real economics

This benchmark raises an implicit question: do you need GLM 5.2 for everything?

No. And that's probably the most useful conclusion of the exercise.

GLM 5.2 at $1.40/M tokens is the right choice when complexity justifies it — architecture, security, cross-file consistency, critical decisions. But on a real project, those tasks represent a fraction of interactions. The rest is boilerplate, minor corrections, documentation, commit messages.

Three levels, three models

BigPickle scores 15/25 on a complete 32-file implementation. It's perfectly capable of reading 50 lines of diff and writing an adequate commit message. Of debugging a 1064 You have an error in your SQL syntax or a Fatal error: Call to undefined function. Of generating a README from existing code. For these tasks, GLM 5.2's architectural depth is overkill — and BigPickle is free.

DeepSeek V4 Pro at $0.44/M tokens — five times cheaper than Haiku 4.5 and three to four times cheaper than GLM 5.2 — comfortably handles simple code generation, CRUD, minor refactoring, inline documentation, short scripts. Its code phase at $0.24 for 1.29M tokens and 9m42s demonstrates this.

GLM 5.2 comes in when complexity exceeds that scope — architecture design, coherent multi-file implementation, security decisions, non-trivial business logic.

Level	Model	Cost	Typical use cases
Free	BigPickle	$0	Debug, commits, quick questions, SQL errors
Budget	DeepSeek V4 Pro	$0.44/M	Boilerplate, CRUD, documentation, short scripts
Premium	GLM 5.2	$1.40/M	Architecture, security, multi-file consistency

The proportion of tasks at each level depends on the project, where you are in the development cycle, and what you consider complex. No universal number — each team calibrates against their real usage.

“
💡 Worth noting: GLM 5.2 is exponentially more expensive than BigPickle — $1.67 vs $0 for 4.42M tokens in the code phase. But pure text output — plans, architecture, analysis — consumes few tokens and costs almost nothing: $0.06 for this benchmark's planning phase. It's in the code phase, with its iterations, in-session test execution, and accumulating context, that the bill climbs. Intelligent routing means precisely reserving GLM 5.2 for tasks that justify that long context — and handing everything else to the two lower tiers.
”

The uncomfortable comparison

GitHub switched to token billing on June 1, 2026. Claude Sonnet 4.6 on Copilot is billed at roughly $3.00/M tokens input and $15.00/M output. Reproducing the GLM 5.2 session from this benchmark — 4.46M tokens — would cost an estimated $25 on Copilot + Sonnet 4.6. Without the functional tests. Without the self-correction. Without the external review.

Copilot Pro+ at $39/month includes $39 in AI credits. A full session like this one would consume two-thirds of the monthly budget. Users reported burning through their monthly credits in two prompts on the day the switch happened.

The final ratio: $1.94 all in vs ~$25 on Copilot + Sonnet. Thirteen times cheaper, for the only result the external reviewer judges production-ready.

Conclusion

$1.94. That's what this benchmark cost end to end — planning, implementation, external review included. For the only toolkit the reviewer judges production-ready.

That number is uncomfortable for the AI coding tools market, which sells reassurance through pricing. Copilot Pro+ at $39/month, Claude Sonnet at $15/M tokens output, the big names front and center — the implicit assumption is that quality follows price. This benchmark suggests otherwise.

The winner is called GLM 5.2. Its lab, THUDM, is part of Tsinghua University. You probably haven't seen it in last week's comparisons. It produced the only architecture with a normalized exit code convention from the planning phase, the only implementation that tests its own code during the session, the only common.sh with configurable redaction and Python fallback if jq is absent. And it fixed three bugs before delivering.

Two takeaways.

First: a model's price does not predict its output quality on complex tasks. Haiku 4.5 on three different tools — Claude Code, Copilot CLI, OpenCode — produces identical results for identical cost. On the planning phase — pure text generation, no feedback loop, no codebase exploration — the tool has no measurable impact. What matters is the model. And the least glamorous model in the benchmark dominates.

Second: not all tokens are equal. A planning phase at $0.06, a code phase at $1.67 — that's a factor of 28. It's not an anomaly, it's the structure of the problem. A plan is a few thousand tokens of reasoning. An implementation is millions of tokens of accumulated context, executed code, iterated tests. Routing intelligently between BigPickle at $0, DeepSeek V4 Pro at $0.44/M, and GLM 5.2 at $1.40/M based on task complexity — that's the real economics of these tools.

The VPS Manager toolkit is available on GitHub in all four versions.

pcescato / LLM-Challenge

LLM-Challenge

A reproducible benchmark comparing 8 AI coding agent/model combinations on the same real-world project.

What this is

This repository contains the complete artifacts from a benchmark where 8 different AI coding agent/model combinations were tasked with building the same VPS management toolkit. The goal was to measure code quality, architecture decisions, and production readiness across different tools and models under identical conditions.

This is not a marketing comparison. A real project with concrete requirements was used as the test subject, and the results were evaluated by an external reviewer who had no knowledge of which tool or model produced which implementation.

The protocol

The benchmark followed a two-phase protocol:

Phase 1: Architecture All tools received the same functional brief and were asked to produce an architecture document. No code was written in this phase.

Phase 2: Implementation All tools received the same development prompt and were asked to implement…

View on GitHub

The briefs, prompts, and evaluation grid are there too. Reproducible, if you want to verify.

Too cheap to be good? That was the wrong question.

Unboxable in Tech

Pascal CESCATO — Tue, 10 Mar 2026 22:11:35 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

"I don't know which box to put you in."

I've been hearing those words for thirty years.

And every single time, it lands like a slap.

The violence isn't in the words. The violence is in what the words actually mean.

It's not: which box could I put you in?

It's: you make me uncomfortable. So I won't hire you.

In a lot of companies, recruitment works like that old Eastern European joke: you give two agents a round peg and a square hole. Two solutions: enlarge the hole… or hit the peg harder.

Guess what the industry has been choosing?

It hits. Harder. Again and again.

Tonight I'm not going to tell you a story about resilience.
I'm going to show you the cost of refusing to fit the box.

Exhibit 1 — The Unlikely Internship

End of studies. 1989.

Everyone is chasing SSII firms, banks, impressive CVs.

Me? I choose a middle school. A library. An 8088.

I know perfectly well it won't lead to a job.

That's not the point.

I want human contact. Real problems. Everyday life.

At a software firm, I would have coded screens. Batch procedures. Efficient within my lane. Never responsible for the whole.

Here, I build a complete application. From scratch. With real users in front of me. Immediate feedback.

I learn what no one would have taught me elsewhere: how to think an entire system.

Not just my part of the ticket.

Exhibit 2 — The Printer

Architecture firm. 1993.

HP printer. Designed for PC and mainframe use. 132 columns, continuous paper feed. 36 switches on the back panel, combinable in non-linear ways.

It had never printed a single accent.

The firm called HP support.

And waited. For months.

Me? I call HP. I say: "I'll drive 400 kilometres to pick up the manual myself if I have to."

Three weeks later, the manual arrives. 300 pages. Pure English. ASCII only. Not a word about French. Not a word about single-sheet feeding.

I read all 300 pages. I understand the logic. I deduce. I test.

The firm prints in French. On A4. Perfectly.

An IT department would still be waiting for support today.

Exhibit 3 — The Cleaning Company

A cleaning company. A simple need: manage their activity, schedules, clients.

They're advised to go with Windows 3.1 + Office.

The hype of the moment. Everyone's doing it, so they should too.

Me? I look at the actual need.

OS/2. Lotus Symphony.

Twice as cheap. Twice as stable. Perfectly suited to what they actually do.

And the price difference? It funded a 486DX40 instead of an SX25. 16MB of RAM instead of 4. A 240MB hard drive.

The entire market is turning its back on these tools? So be it.

The need comes before the trend. And the saved budget goes into the machine.

An IT department would have ordered the Microsoft licences and called it modernisation.

I delivered a system that held up — on a machine that could actually run it.

Exhibit 4 — The SELECT COUNT(*)

Paris. 2010.

A project manager wants to catch me out in front of the team.

I write a SELECT COUNT(*).

He jumps on it. "We don't do SELECT *."

I explain. For MySQL, COUNT(*) is the most performant solution. He tests.

He concedes.

But the tension remains.

Because I contradicted him. In front of everyone. When he had been trying to humiliate me.

I wasn't the one with a problem.

He was the one who couldn't stand being wrong.

In these companies, they don't want people who think.

They want people who validate.

Exhibit 5 — The Open Space

In an open space, you don't model systems. You survive the noise.

You don't think. You manage interruptions.

The industry calls that collaboration.

I call it destroying the concentration of the people who need it to work.

I turned down assignments because of this.

A line I never crossed.

Exhibit 6 — Logic-immo

One exception.

Just one in five years.

Logic-immo. 2008.

Brought in for Zend Framework.

Left having designed and built an Oracle-to-MySQL data extraction system in PHP CLI.

Why?

Because someone had looked at what I could actually do.

And decided to give priority to the need.

Someone had read between the lines.

Rare. Worth mentioning.

In 2011, I was burned out.

In 2012, my daughter was born.

I left Paris.

Exhibit 7 — The Regional Directory

Back in the South-West.

A client. A monstrous project: local directory, classifieds, events section for every town and village, dedicated site for every business.

Over a hundred professional sites to generate and manage dynamically. Custom routing. Zend Framework. Smarty.

A standard agency wouldn't have lasted three months.

Not because of the project.

Because of the client.

Hypochondriac. Always wound up. Always in crisis mode. Unmanageable for anyone without patience.

I held on. Ten months. Solo. Architecture built from scratch.

To the point where I fantasised about a permanent contract.

Any one. Just to never have that kind of client again.

Exhibit 8 — The B2B Platform

A matchmaking platform for business conventions.

The existing application took ten minutes to load.

Ten minutes.

Server ten years past its prime. First-generation Symfony. Poorly designed PostgreSQL database. Non-relational data. Queries going in every direction.

Nobody had asked the question: why is it slow?

I asked the question.

Custom framework inspired by ZF, but lighter. MySQL. Data schema rebuilt from scratch. Processes rewritten from the ground up. Fluid, responsive, usable interface. And a proper server.

Under thirty seconds.

That's not magic.

That's what happens when you look at the problem before touching the code.

They fired me for incompetence the day after launch.

Five thousand visits. Every meeting scheduled. The platform handled everything.

I fix things. Then I get shown the door.

The labour court ruled in my favour. Six months' compensation.

Exhibit 9 — The Projects Nobody Asked For

Nobody commissioned these.

They come from an impulse. A conversation. A problem I noticed.

Dev.to ranks me in the top 7 of the week. I could say thanks and move on.

Instead I implement RFC 2324.

The HTTP protocol for controlling a coffee maker. A 1998 joke buried in the Internet standards. Implemented seriously. Raw asyncio TCP server. Per-pot locks. Compliant headers.

In the comments, @sylwia-lask asks when I'm going to implement a protocol for beer.

I run with it.

RFC 1516. The Hyper Text Beer Mug Control Protocol. Port 1414, a nod to Gdańsk.

The CV as a graph of relationships — because a profile like mine isn't linear. A timeline says nothing. A graph says everything.

AJC Bridge — write from WordPress, publish everywhere. Submitted to a challenge. Runner-up.

No ticket. No meeting. No box.

Just a problem, an impulse, and someone who gets on with it.

Exhibit 10 — The Handover and the Veto

I coach a young entrepreneur. WordPress, Divi, Plesk.

I set up his servers. I pass on what I know.

And one simple principle: never put all your eggs in one basket. Always keep external backups.

OVH burns down.

He manages 60 sites. He loses them — theoretically.

He calls me.

48 hours later, everything is back up on new servers.

It wasn't me who saved his sites.

It was advice given months earlier.

We keep a great relationship.

He's part of a BNI. He puts my name forward for a training assignment.

Veto.

Not standardised.

The system would rather go without someone who just saved 60 sites in under 48 hours.

Think about that for a moment.

Exhibit 11 — The Classroom Aide

I discovered this job over ten years ago.

My daughter's mother is a classroom aide for students with disabilities. She told me about it. I thought it was a job that made sense.

In 2021, a position opens near me. I jump at it.

The recruiter confirms in under five minutes. I barely have time to go down the stairs, step outside the building — he's already calling me back to come sign the contract.

For a while, it was exactly what I'd imagined. Students in difficulty. Concrete work. Visible results.

Some of the students I supported no longer need a classroom aide today.

That's the job.

Except the expectations have shifted.

Because there's no space in the specialist units. No space in the vocational streams. No space in the adapted classrooms.

So these students get placed in mainstream education. And a classroom aide gets put in front of them.

That's not educational support. That's the work of a specialist educator — paid twice as much, with the training and recognition that come with it.

I'm paid minimum wage. Half-time.

And some teachers have one request: shut up and stay in your lane.

The system does here exactly what it does everywhere else.

It puts the round peg in the square hole.

And when it doesn't fit, it hits harder.

The Mechanism

WeCoded talks about marginalised voices in tech.

Marginalised. One word. Dozens of realities.

It's not only about gender, skin colour, sexual orientation.

Racism, homophobia, the rejection of an atypical career path, the rejection of the wrong kind of degree — all of it belongs to the same family.

The family of refusing the other.

The family of human stupidity organised into a system.

The mechanism is always the same.

You don't fit in the box. So you don't exist. And you won't.

And that marginalisation hurts all the more because it makes no sense.

It can be justified — process, boxes, grids.

But every justification will itself be unjustifiable.

What I want you to take away is this:

The Verdict

In all of these stories, one constant.

I always solved the problem I was called in for.

Always.

And yet I remain "unclassifiable". Not employable. Not standardised. Not in the box.

So the real question — the one that stings — is simple.

Who's the problem?

Me — the one who solves the problems?

Or the system — the one that doesn't know what to do with me between fires?

For thirty years, the industry has chosen to hit the peg.

The peg is still round.

And the hole is still square.

RFC 1516: A Build for the Community That Keeps 418 Alive

Pascal CESCATO — Fri, 27 Feb 2026 15:47:21 +0000

This is a submission for the DEV Weekend Challenge: Community

In the comments of my last article, Sylwia wrote:

Comment on Stop Ignoring RFC 2324. It's the Most Important Protocol You've Never Implemented.

Sylwia Laskowska Feb 25

Awesome😄
Now I’m just waiting, Pascal, until you invent your own protocol — maybe something like a beer brewing protocol next? 🍺

I replied: "...HTBMCP/1.0 might be next. Hyper Text Beer Mug Control Protocol. Watch this space."

This is that space.

The Community

Before the code: a question worth asking.

The DEV prompt says "build for your community." The obvious answer, for a developer, is to build something useful for other developers — a tool, a library, a dashboard. Something that solves a real problem.

But there's a community that rarely gets named as such, and it's one I'm genuinely part of: the community of developers who find meaning in craft for its own sake. Who implement a coffee pot RFC not because it ships a feature, but because it teaches something real. Who write April Fools' specs with the same rigor they'd apply to production systems. Who understand that absurdity taken seriously is one of the most honest forms of technical education.

RFC 2324 has been cited, forked, debated, and defended for 26 years because it speaks directly to that community. It says: the standards process can be playful — rigorously, precisely playful. That's worth protecting.

HTBMCP/1.0 is a contribution to that tradition. It's for the developer who reads a comment about beer protocols at midnight and thinks yes, someone should actually do that. It's for @sylwia-lask, who asked. It's for anyone who's ever cited RFC 2324 in a code review and meant it.

What I Built

RFC 1516 — the Hyper Text Beer Mug Control Protocol (HTBMCP/1.0), to be published April 1st 2026. And its full implementation.

HTBMCP is the spiritual successor to RFC 2324 (HTCPCP, the coffee pot protocol). Where HTCPCP controls coffee pots, HTBMCP controls networked beer taps. It extends HTTP with five custom methods, three new headers, and one new error code.

The default port is 1414 — a memorial. In 1414, the municipal archives of Gdansk recorded the earliest known written attestation of the word "piwo" (beer, in Polish). That document was lost during the Second World War.

Port 1414 is therefore a memorial as much as a transport binding.

The implementation consists of four parts:

An interactive browser simulator — a self-contained HTML/JS file, no backend, no install. A complete HTBMCP state machine running in the browser with animated tap visuals, all six response codes, the full header set. Build the simulator before the server: it forces you to model the protocol as data before you model it as routes.

A raw asyncio TCP server (server.py) — because uvicorn rejects TAP, POUR, and WHEN at the socket layer. These are valid RFC 7230 tokens, but they're not in the IANA method registry. The fix is a minimal HTTP/1.1 parser over raw TCP that accepts any valid token as a method name. This is the correct approach: HTBMCP is its own protocol, and owning the transport layer is the honest implementation.

A FastAPI application (main.py) — used exclusively by the test suite. TestClient bypasses the HTTP transport entirely, so custom methods work fine there. You get structured routing and validation without the socket-level rejection.

41 tests covering the full protocol: every method, every error code, the Stout temperature MUST NOT, the goblet Trappist-only rule, brew_version conflict detection, the piwo:// Gdansk memorial tap, and the WHEN-once-is-sufficient invariant.

The protocol, in brief

Method	Description
`TAP`	Opens/closes a session. Must precede POUR. POST accepted but STRONGLY DISCOURAGED.
`POUR`	Dispenses beer (`start`/`stop`). MUST NOT execute without open TAP session.
`WHEN`	Stops foam. Inherited from HTCPCP. There is no WHEN-WHEN method. Once is sufficient.
`GET`	Returns tap state. Contains no beer. This is an important distinction.
`PROPFIND`	Discovers styles, temperatures, foam levels. Borrowed from WebDAV via HTCPCP.

New error code: 419 I'm a Wine Glass. A wine glass is not a mug. A wine glass has no handle. Beer poured into a wine glass loses carbonation 23% faster — a figure the authors have not verified but feel is directionally correct.

A server MUST NOT return 419 for an empty keg. The keg is not a wine glass. These are different problems.

Demo

🍺 HTBMCP Simulator — open it directly in your browser. No install, no server, no dependencies. A complete HTBMCP state machine running client-side: animated tap visuals, all six response codes, the full header set.

htbmcp.benchwiseunderflow.in

Try to TAP a Stout at 3°C. Watch the 406 fire with the exact RFC citation. Try the wine glass tab. Say WHEN.

Attempting to pour into a wine glass results in a protocol-level error.

For the full server:

python server.py
# 🍺  HTBMCP/1.0 listening on 0.0.0.0:1414
#     Port 1414 — memorial: Gdansk municipal archives, 1414

# TAP open
curl -X TAP http://localhost:1414/tap/tap-1 \
     -H "Content-Type: message/mugpot" \
     -H "Accept-Style: IPA" \
     -H "Accept-Temperature: 8" \
     -H "Accept-Foam: normal" \
     -d "open"

# POUR
curl -X POUR http://localhost:1414/tap/tap-1/pour \
     -H "Content-Type: message/mugpot" \
     -d "start"

# WHEN — enough foam
curl -X WHEN http://localhost:1414/tap/tap-1/when

# 419 — I'm a Wine Glass
curl -X POUR http://localhost:1414/wine-glass/tap-1

Code

Code is on Github repository:

pcescato / htbmcp

HTBMCP/1.0 — Hyper Text Beer Mug Control Protocol

"There is beer all around the world. Increasingly, in a world in which computation is ubiquitous, the consumption of beer in proximity to networked devices creates a strong operational requirement."

— RFC 1516, Abstract

What is this?

This repository is a full implementation of RFC 1516 — the Hyper Text Beer Mug Control Protocol (HTBMCP/1.0), to be published April 1st, 2026.

HTBMCP is the spiritual successor to RFC 2324 (HTCPCP/1.0, the coffee pot protocol). Where HTCPCP controls coffee pots, HTBMCP controls networked beer taps. The protocol extends HTTP with custom methods, headers, and error codes designed specifically for the distributed dispensing of fermented malt beverages.

The default port is 1414 — a memorial to the earliest known written attestation of the word "piwo" (beer, in Polish) in the municipal archives of Gdansk, 1414. That document no longer exists. We pour one out.

…

View on GitHub

The full implementation — TCP server, FastAPI test app, registry, 41 tests, browser simulator, and README. RFC 1516 itself is available in the repository. It will be formally published on April 1st, 2026. As tradition demands.

The uvicorn problem — and the solution

This is the key technical lesson, and it's worth making explicit.

# ❌ This will NOT work for HTBMCP methods
# uvicorn → h11 → validates method against IANA registry → rejects TAP/POUR/WHEN
# before any application code runs
uvicorn main:app --reload

The fix — a minimal HTTP/1.1 parser over raw asyncio TCP:

async def handle_connection(reader, writer):
    data = await reader.read(8192)
    req = parse_request(data)   # accepts any RFC 7230 token as method
    response = await dispatch(req)
    writer.write(response)
    await writer.drain()

async def main():
    server = await asyncio.start_server(handle_connection, "0.0.0.0", 1414)
    async with server:
        await server.serve_forever()

parse_request() splits on the first space and takes whatever token it finds — TAP, POUR, WHEN, or anything else that's RFC 7230-valid. No registry check. This is correct: HTBMCP defines its own protocol. The transport layer should not enforce HTTP's method vocabulary on a protocol that extends it.

Temperature validation — MUST vs SHOULD NOT

def check_temperature(tap_id, raw_temp):
    # RFC 1516 §3.2.3:
    # "A server MUST NOT serve a Stout at 3°C.
    #  This is not a SHOULD NOT. This is a MUST NOT.
    #  The authors feel strongly about this."
    if tap.style == "Stout" and temp <= 5:
        return build_response(406, {
            "error": "Temperature violation — MUST NOT",
            "detail": "A server MUST NOT serve a Stout at 3°C. "
                      "This is not a SHOULD NOT. This is a MUST NOT.",
            "allowed_range": "10–13°C",
            "rfc": "RFC 1516 §3.2.3",
        })

The RFC distinguishes MUST NOT from SHOULD NOT with care. The Stout temperature constraint is a hard rule, not a recommendation. Testing that distinction is the point:

def test_tap_406_stout_too_cold(self):
    """RFC 1516 §3.2.3: MUST NOT. This is not a SHOULD NOT."""
    r = self._tap_open(tap_id="tap-2", style="Stout", temp=3)
    assert r.status_code == 406
    assert "MUST NOT" in r.json()["error"]

The `piwo://` tap — port 1414's justification, made navigable

"tap-gdansk": Tap(
    id="tap-gdansk", scheme="piwo",  # Polish — RFC 1516 §1, port 1414 memorial
    style="Lager", temp=4.0, pressure=2.6, level=88,
    compatible_styles=["Lager", "Pilsner"],
),

def test_gdansk_piwo_tap(self):
    """piwo:// scheme — Gdansk 1414. We pour one out."""
    r = self._tap_open(tap_id="tap-gdansk", style="Lager", temp=4)
    assert r.status_code == 200
    assert TAP_REGISTRY["tap-gdansk"].scheme == "piwo"

How I Built It

Stack: Python 3.12, FastAPI (test suite only), asyncio raw TCP (real server), structlog, pytest. Single-file HTML/JS simulator with no dependencies.

Build order: simulator first, server second, tests throughout. This is the lesson from the HTCPCP implementation: build the thing you can demo immediately, then build the thing that's correct. The simulator forced every protocol decision to be made as UI state before it became a routing decision.

The protocol is not just simulated — it is fully implemented and validated with a dedicated test suite.

The HTCPCP comparison: HTBMCP adds a session model (TAP as initiator with brew_version tokens for concurrent access), promotes foam to a first-class protocol feature (Accept-Foam with five levels including belgian — implementation-defined, but significant), and introduces 419 I'm a Wine Glass alongside 418 I'm a teapot. Where 418 says you are the wrong device, 419 says you are using the wrong vessel. The error taxonomy matters.

What this actually teaches: The Stout MUST NOT forces you to think about hard constraints vs recommendations. The brew_version conflict detection forces you to think about optimistic locking. The goblet Trappist-only rule forces you to think about domain validation. The uvicorn rejection forces you to think about where the HTTP stack lives. These are not beer problems.

The Reinheitsgebot requires no acknowledgement. It has been enforcing standards compliance since 1516 without asking for credit.

Stop Ignoring RFC 2324. It's the Most Important Protocol You've Never Implemented.

Pascal CESCATO — Tue, 24 Feb 2026 23:44:05 +0000

Some RFCs change the world — TCP/IP, HTTP/2, TLS 1.3.

And then there's RFC 2324, published April 1st, 1998, defining the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). Its purpose: control, monitor, and diagnose coffee pots over a network.

No, it's not a joke. Well, it is. But it's written seriously enough to actually implement. Emacs did it. We will too.

A Brief History of the Web's Most Honorable RFC

RFC 2324 is an IETF April Fools' joke authored by Larry Masinter. It extends HTTP with:

New HTTP methods: BREW, WHEN, PROPFIND
A new header: Accept-Additions (for milk, sugar, whisky — yes, whisky)
A new URI scheme: coffee:// (and koffie://, café://, and 26 other translations)
Two new error codes that changed internet history

The error codes

406 Not Acceptable  — The server cannot brew this coffee
418 I'm a teapot    — The server is a teapot, not a coffee pot

418 became iconic. In 2017, a proposal to remove it from the IANA registry triggered an actual revolt across the dev community. Node.js, Go, Python — everyone kept it. The teapot won.

In 2014, RFC 7168 extended the protocol to tea (HTCPCP-TEA), adding the message/teapot MIME type and the requirement to distinguish an Earl Grey from a Darjeeling. Rigor in absurdity.

What the RFC Actually Defines

Before writing a single line, read the spec. That's the exercise.

The new methods

MethodRoleBREW (or POST)Trigger an infusionGETGet the coffee pot's current statePROPFINDList available additionsWHENStop pouring the milk — the client says "when!"

The WHEN method is the most beautiful. It models a human exchange ("tell me when") as an HTTP request. A masterpiece of protocol anthropomorphism.

The Accept-Additions header

BREW /coffee-pot-1 HTCPCP/1.0
Accept-Additions: milk-type=Whole-milk; syrup-type=Vanilla; alcohol-type=Whisky

Legal values include Cream, Half-and-half, Whole-milk, Non-Dairy, syrups (Vanilla, Chocolate, Raspberry, Almond), and spirits (Whisky, Rum, Kahlua, Aquavit).

Intentionally absent: any decaffeinated option. The RFC's comment on this is terse: "What's the point?"

Step 1 — Play First: The Standalone Simulator

Before writing a single line of server code, I built a fully self-contained HTML/JS simulator that runs entirely in the browser. No backend, no dependencies, no install.

Interactive HTCPCP Dashboard

htcpcp.benchwiseunderflow.in

The simulator is not a mock of the server — it is a complete HTCPCP implementation, just in a different runtime. All the state lives in JavaScript: pot registry, brew history, status transitions, 418/406 logic. It's the fastest way to feel the protocol before committing to a stack.

Try to BREW on a teapot. Watch the 418 fire. Select decaf and get a 406. Click WHEN mid-brew to stop the milk. Then come back here and build the production version.

Step 2 — Ship It: The Production Server

A word on uvicorn

The natural instinct is uvicorn main:app --reload. Don't. uvicorn validates HTTP method names at the socket level, before any request parsing happens. BREW, WHEN, and PROPFIND are not registered IANA methods, so uvicorn rejects them immediately with Invalid HTTP request received — regardless of any FastAPI config.

The fix: a raw asyncio TCP server (server.py) with a minimal HTTP/1.1 parser that accepts any valid RFC 7230 token as a method name. Which BREW, WHEN, and PROPFIND are. This is actually the more correct approach — HTCPCP defines its own protocol, and rolling your own transport layer is the honest implementation.

python server.py
# ☕  HTCPCP/1.0 — RFC 2324  (127.0.0.1:2324)

curl -X BREW http://localhost:2324/coffee/pot-1 \
  -H "Accept-Additions: milk-type=Whole-milk; alcohol-type=Whisky"

FastAPI + main.py is still useful for one thing: the test suite. FastAPI's TestClient bypasses the HTTP transport layer entirely, so custom methods work fine in tests — and you get all the validation and schema benefits of FastAPI.

pytest test_htcpcp.py -v   # uses main.py + TestClient, no server.py needed

Architecture: a pot registry

First architectural decision: model the entities properly.

from enum import Enum
from dataclasses import dataclass, field

class PotType(str, Enum):
    COFFEE = "coffee"
    TEAPOT = "teapot"

class PotStatus(str, Enum):
    IDLE = "idle"
    BREWING = "brewing"
    POURING_MILK = "pouring-milk"
    READY = "ready"

@dataclass
class CoffeePot:
    id: str
    pot_type: PotType
    capacity: int
    level: int
    status: PotStatus = PotStatus.IDLE
    varieties: list[str] = field(default_factory=list)
    brew_history: list[dict] = field(default_factory=list)

# The registry — the core of the architecture
POT_REGISTRY: dict[str, CoffeePot] = {
    "coffee://pot-1": CoffeePot("pot-1", PotType.COFFEE, 12, 8,
                                varieties=["Espresso", "Lungo", "Americano"]),
    "coffee://pot-2": CoffeePot("pot-2", PotType.COFFEE, 6, 2,
                                varieties=["Espresso"]),
    "tea://kettle-1": CoffeePot("kettle-1", PotType.TEAPOT, 8, 6,
                                varieties=["Earl Grey", "Chamomile", "Darjeeling"]),
}

Parsing the Accept-Additions header

from fastapi import Request, HTTPException

SUPPORTED_ADDITIONS = {
    "milk-type": ["Cream", "Half-and-half", "Whole-milk", "Part-Skim", "Skim", "Non-Dairy"],
    "syrup-type": ["Vanilla", "Almond", "Raspberry", "Chocolate"],
    "sweetener-type": ["Sugar", "Honey"],
    "spice-type": ["Cinnamon", "Cardamom"],
    "alcohol-type": ["Whisky", "Rum", "Kahlua", "Aquavit"],
}

def parse_accept_additions(header: str | None) -> dict[str, str]:
    if not header:
        return {}
    additions = {}
    for part in header.split(";"):
        part = part.strip()
        if "=" in part:
            key, value = part.split("=", 1)
            additions[key.strip()] = value.strip()
    return additions

def validate_additions(additions: dict) -> None:
    # RFC 2324 §2.1.1: no decaf option — intentionally
    if "decaf" in additions:
        raise HTTPException(
            status_code=406,
            detail={
                "error": "Not Acceptable",
                "message": "Decaffeinated coffee? What's the point?",
                "rfc": "RFC 2324 §2.1.1"
            }
        )
    unsupported = [
        f"{k}={v}" for k, v in additions.items()
        if k in SUPPORTED_ADDITIONS and v not in SUPPORTED_ADDITIONS[k]
    ]
    if unsupported:
        raise HTTPException(
            status_code=406,
            detail={"error": "Not Acceptable", "unsupported_additions": unsupported}
        )

The HTCPCP endpoints

from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI(title="HTCPCP/1.0", version="1.0")

def get_pot(pot_id: str) -> CoffeePot:
    uri = f"coffee://{pot_id}"
    pot = POT_REGISTRY.get(uri) or POT_REGISTRY.get(f"tea://{pot_id}")
    if not pot:
        raise HTTPException(status_code=404, detail="Pot not found in registry")
    return pot

# ── BREW ────────────────────────────────────────────────────────────────────

@app.api_route("/coffee/{pot_id}", methods=["BREW", "POST"])
async def brew(pot_id: str, request: Request):
    pot = get_pot(pot_id)

    # RFC 2324 §2.3.2: teapot → 418, mandatory
    if pot.pot_type == PotType.TEAPOT:
        return JSONResponse(status_code=418, content={
            "status": 418,
            "error": "I'm a teapot",
            "body": "The requested entity body is short and stout.",
            "hint": "Tip me over and pour me out.",
            "pot_id": pot_id,
            "rfc": "RFC 2324 §2.3.2",
            "suggestion": "Use coffee://pot-1/brew instead"
        })

    if pot.level == 0:
        raise HTTPException(status_code=503, detail="Pot is empty. Refill required.")

    additions_header = request.headers.get("accept-additions")
    additions = parse_accept_additions(additions_header)
    validate_additions(additions)  # 406 if decaf or invalid additions

    brew_id = len(pot.brew_history) + 1
    pot.brew_history.append({"id": brew_id, "additions": additions})
    pot.status = PotStatus.BREWING
    pot.level -= 1

    # Milk requested → enter pouring-milk state
    has_milk = "milk-type" in additions
    if has_milk:
        pot.status = PotStatus.POURING_MILK

    return JSONResponse(status_code=200, content={
        "brew_id": brew_id,
        "message": "Coffee is brewing.",
        "pot": pot_id,
        "accept-additions": additions,
        "milk_pouring": has_milk,
        "protocol": "HTCPCP/1.0"
    })

# ── GET ──────────────────────────────────────────────────────────────────────

@app.get("/coffee/{pot_id}/status")
def get_status(pot_id: str):
    pot = get_pot(pot_id)
    return {
        "pot_id": pot_id,
        "type": pot.pot_type,
        "status": pot.status,
        "level": f"{pot.level}/{pot.capacity} cups",
        "brew_count": len(pot.brew_history),
        "varieties": pot.varieties,
        "protocol": "HTCPCP/1.0"
    }

# ── PROPFIND ─────────────────────────────────────────────────────────────────

@app.api_route("/coffee/{pot_id}/additions", methods=["PROPFIND"])
def propfind(pot_id: str):
    get_pot(pot_id)
    return {
        **SUPPORTED_ADDITIONS,
        "decaf": "NOT_ACCEPTABLE — What's the point? (RFC 2324 §2.1.1)"
    }

# ── WHEN ─────────────────────────────────────────────────────────────────────

@app.api_route("/coffee/{pot_id}/stop-milk", methods=["WHEN"])
def when(pot_id: str):
    """
    RFC 2324 §2.1.3 — WHEN
    Sent when the client determines that enough milk has been poured.
    The server must stop immediately.
    """
    pot = get_pot(pot_id)

    if pot.status != PotStatus.POURING_MILK:
        return JSONResponse(status_code=200, content={
            "message": "WHEN acknowledged.",
            "note": "No milk was being poured, but your enthusiasm is appreciated.",
            "rfc": "RFC 2324 §2.1.3"
        })

    pot.status = PotStatus.BREWING

    return JSONResponse(status_code=200, content={
        "message": "Milk pouring stopped.",
        "detail": "The server has acknowledged WHEN and stopped the milk stream.",
        "protocol": "HTCPCP/1.0",
        "rfc": "RFC 2324 §2.1.3"
    })

Middleware: enforce HTCPCP headers

from starlette.middleware.base import BaseHTTPMiddleware

class HTCPCPMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        response = await call_next(request)
        response.headers["X-Protocol"] = "HTCPCP/1.0"
        response.headers["X-RFC"] = "RFC-2324"
        # Detect a BREW on a non-coffee route and punish accordingly
        if request.method == "BREW" and not request.url.path.startswith("/coffee"):
            return JSONResponse(status_code=418, content={
                "error": "Wrong universe",
                "hint": "BREW is only valid on coffee:// URIs"
            })
        return response

app.add_middleware(HTCPCPMiddleware)

Structured logs — because we're professionals

import structlog

log = structlog.get_logger()

# After a successful BREW:
log.info("htcpcp.brew",
    pot_id=pot_id,
    brew_id=brew_id,
    additions=additions,
    status_code=200,
    protocol="HTCPCP/1.0"
)

# On 418:
log.warning("htcpcp.teapot_detected",
    pot_id=pot_id,
    pot_type="teapot",
    status_code=418,
    message="Teapot attempted to brew coffee"
)

Which produces in your JSON logs:

{"event": "htcpcp.brew", "pot_id": "pot-1", "brew_id": 3,
 "additions": {"milk-type": "Whole-milk", "alcohol-type": "Whisky"},
 "status_code": 200, "protocol": "HTCPCP/1.0", "level": "info"}

{"event": "htcpcp.teapot_detected", "pot_id": "kettle-1",
 "status_code": 418, "level": "warning"}

What This Actually Teaches You

Implementing an April Fools' RFC is a serious exercise in disguise. You end up learning:

How to read an RFC properly — distinguishing MUST, SHOULD, MAY. RFC 2324 uses all three with care. The 418 is a MUST if the server is a teapot. A broken coffee machine should return 503 — not 418. That's a common mistake, and it matters.

How the HTTP stack actually works — trying to use uvicorn with BREW reveals that method validation happens at the socket level, before h11, before FastAPI, before your code. You end up writing a raw asyncio TCP server to get HTCPCP working for real. That's not a detour — that's the point. You now understand the HTTP request pipeline better than most devs who've shipped production APIs for years.

How to think in entities — the pot registry, the CoffeePot vs Teapot distinction, routing by coffee:// URI: this is real domain modeling. The joke forces you to take it seriously.

How to model state machines — idle → brewing → pouring-milk → ready is a textbook workflow. WHEN is a client-driven transition. You'll see this pattern everywhere in production systems.

How to write integration tests for absurd-but-useful edge cases:

def test_teapot_cannot_brew():
    response = client.request("BREW", "/coffee/kettle-1")
    assert response.status_code == 418
    assert response.json()["error"] == "I'm a teapot"

def test_decaf_is_not_acceptable():
    response = client.request("BREW", "/coffee/pot-1",
                              headers={"Accept-Additions": "decaf=true"})
    assert response.status_code == 406

def test_when_stops_milk():
    client.request("BREW", "/coffee/pot-1",
                   headers={"Accept-Additions": "milk-type=Whole-milk"})
    response = client.request("WHEN", "/coffee/pot-1/stop-milk")
    assert response.status_code == 200
    assert "stopped" in response.json()["message"]

Conclusion

418 survived every attempt to kill it because it represents something real: developers are allowed to be playful. An April Fools' RFC published today would probably get killed in committee within a week. The one from 1998 has lasted 26 years.

What makes RFC 2324 remarkable is that it takes absurdity seriously — it has a real state machine, real error codes with precise semantics, a real extension (RFC 7168 for tea). It mocks formalism by respecting it perfectly.

That's exactly how we should build our own systems.

Simulator (HTML/JS standalone), server.py (raw TCP), main.py + full test suite — on Github: https://github.com/pcescato/htcpcp/.

RFC 2324: https://tools.ietf.org/html/rfc2324 RFC 7168: https://tools.ietf.org/html/rfc7168

Your Article Isn’t the Real Content

Pascal CESCATO — Sat, 21 Feb 2026 12:28:14 +0000

The article is often the least interesting thing that happens after you publish.

Not always. But more often than we're willing to admit.

I saw this comment recently and couldn't unsee it:

"Real war stories have specifics — the exact error, the wrong turn you took first, the fix that seemed obvious in retrospect. Generated stuff stays vague. Honestly the comments on that post became better content than the post itself."

That last sentence describes something we rarely say out loud.

What actually happens when you write with real specifics

Not tips. Not frameworks. The actual error. The wrong turn. The fix you missed for three hours.

That level of detail does something polished content almost never does: it makes other builders recognize themselves instantly.

And recognition doesn't produce passive reading. It produces contribution.

The article doesn't contain the knowledge. It releases it.

Publishing without the discussion is publishing an incomplete object.

The post and the thread aren't two separate things. One makes the other possible. Strip the comments and you lose half the object. Strip the post and the comments have no spine.

We treat articles as finished products and comments as disposable noise. So we archive the post and let the discussion rot.

Which means we're systematically preserving the least interesting half of the knowledge.

We optimize for authorship. We don't preserve conversations.

Maybe we didn't even want to.

Where did the real fix appear — in the article or in the replies?

Link a post where the comments mattered more than the text.

What's the best technical insight you found buried three levels deep in a thread — that no article ever captured?

If you think the article still matters more than the discussion, I'd genuinely like to hear why — because I'm no longer sure.

Who Are We Still Writing Technical Articles For?

Pascal CESCATO — Tue, 17 Feb 2026 12:34:14 +0000

I recently read an article by @miracool asking the question: do people still genuinely care about technical articles? My answer is nuanced: yes, but not everyone.

Beyond that question, there is another, more fundamental one: who do we choose to write for today?

A Long-Term Trajectory

I've been writing technical articles since 2010-2011. Some still exist in the Wayback Machine archives — like this one, dated December 2011, about a MySQL limitation that barely makes sense to address today. My blog has been running since 2016. Since August 2025, I've also been writing in English.

I've never published at an industrial pace. I wrote when I had something to clarify, document, or share.

Over this period, one observation stands out: some articles disappear within a few months, while others continue to be read years later. Not massively. But steadily. By readers who arrive through a specific search, who actually read, and who sometimes write back.

It's almost always the same types of texts that survive: those that document an approach, a technical decision, a real problem encountered over time. Highly specific tutorials, on the other hand, meet an immediate need and then logically fade away.

This isn't a theory. It's an observation built over time.

How We Consume Technical Knowledge Today

Fifteen or twenty years ago, you bought a technical book and used it for years. I bought the PHP5 Bible in the mid-2000s. I relied on it for nearly three years. But back then, you couldn't find nearly as many up-to-date resources online as quickly as you can now.

Today, access to technical knowledge is immediate. Resources are digital, abundant, constantly updated. Tools have simplified many deployments. Answers are available within seconds.

This isn't better or worse. It's a different way of learning and working. I consume differently myself.

But this evolution has a direct consequence: the lifespan of technical content has shortened. And that naturally changes the way we write.

Technical Articles Haven't Disappeared — They've Evolved

We need to distinguish between two types of technical articles.

There's daily news: announcements, releases, updates. A new version of PostgreSQL. New MySQL features. A new project from an Apache incubator. These articles are widely read. They meet a need for technical current events. It's information.

And there's the in-depth magazine: detailed articles, experience reports, carefully constructed reflections. The National Geographic of tech. These articles reach a smaller but loyal audience. Readers who are genuinely interested.

This distinction between technical news and substantive reflection isn't new. There have always been texts with no clear thinking behind them. Lists like "Top 5 WordPress Themes for 2026" or "10 Best Plugins for 2025" that enumerate tools with their pros and cons but offer no real analysis have always existed. Humans are perfectly capable of producing empty content. Artificial intelligence didn't create this problem — it simply amplified the volume.

What remains rare are articles that go deeper. That not only show strengths and weaknesses but explain use cases, contexts, the reasoning behind choices. Those require structured thinking. As Boileau once said: what is well conceived is clearly stated.

To illustrate this concretely, I submitted the same prompt to Gemini and ChatGPT: "write a 1500-word article on 'who do we choose to write a technical article for?'". Both produced correct, well-structured texts. ChatGPT even found some interesting angles — the translator-reader, the machine as an unexpected recipient. But both shared the same fundamental limitation: zero lived experience, zero concrete data, zero personal trajectory. Texts that are true for everyone, and therefore belong to no one.

That's not a flaw in the tool. It's the direct consequence of a prompt with no real thinking behind it.

AI produces articles, but left undirected, it doesn't produce substantive ones. You can ask it to write a tutorial on any technical subject and get a text that looks correct on the surface but is empty of genuine reflection.

For my part, I use AI to structure my articles, to rephrase, to validate hypotheses. But I don't give it a generic prompt like "write a 1500-word article on who we choose to write a technical article for." The thinking that feeds the text comes from my research, my experience, my history.

And the drafts the AI produces — all of them, not just the first — are then reread, corrected, and reworked to match my own voice. This article itself is the result of a conversation with Claude and ChatGPT. But once that conversation was over, I reread it. I rewrote entire sections. I amended others. The work is greatly simplified by AI, but it isn't directly generated writing. It's augmented writing. The difference is essential.

Both types of articles still exist. But they don't address the same audience or the same timeframe.

What has changed is that the sheer mass of available information has paradoxically made in-depth articles more substantive, not less relevant. Since the basic tutorial is everywhere, what remains to be written is the reasoning behind it.

Why I No Longer Write Tutorials

For a long time, I wrote very detailed tutorials. Complete guides, designed to walk a reader from start to finish.

Today, I don't write them anymore.

Not because tutorials have become useless. They remain essential, particularly for beginners or specific use cases. But they are now produced faster and often better by others: official documentation, communities, interactive tools, technical assistants.

A very precise tutorial also becomes obsolete faster. Versions change, methods evolve, abstractions multiply. In many cases, a quick search is enough to solve the problem.

So it's not the tutorial that's disappearing. It's simply that I've stopped making it the core of my writing.

What Writing Still Allows

Technical writing retains a specific quality.

It allows for measured reflection. Rereading. Precise citation. Continuity over time. A text can be found again, annotated, reused, reread years later.

A video informs. An instant response helps solve a problem. But a structured text allows you to follow a line of reasoning and return to it.

This isn't about the superiority of formats. It's about function. Writing remains particularly well-suited for documenting a technical experience over time.

What Holds Its Value

Over time, I've shifted my center of gravity.

I'm less focused on explaining exactly how to do something. Others do that very well and very quickly. I try instead to document an approach, a technical choice, a feedback report, a thought process, what worked and what didn't.

This type of text doesn't meet an immediate need. It speaks to those who want to understand a line of reasoning, not just execute a procedure.

It probably reaches fewer people. But it lasts longer.

A Different Audience

This audience exists. I know because some articles continue to be read long after publication. They show up in stats. They're found through specific searches. Sometimes they prompt a message months or years later.

I've had articles that were read far more widely. Between 2017 and 2019, an article about Twenty Seventeen, the WordPress theme, generated 20 to 25,000 reads and over a hundred comments. I also see what viral articles on dev.to look like: thousands of likes, hundreds of comments.

That's not what I'm talking about.

Writing in English hasn't given me a massive audience. Between August 2025 and today, 25 articles have generated around 14,000 views. Modest numbers.

But it's a different audience. Switching to English wasn't a strategy. It came naturally. My technical experience is international. And this English-speaking audience — partly made up of people who write themselves, and above all readers interested in this kind of reflection — aligns more closely with who I am.

I'm not addressing a majority. I'm addressing people who build, who think, who look for experience reports rather than immediate answers.

Why Write Publicly?

If this audience is limited, why keep publishing? Why not simply keep private notes?

Because public writing changes the nature of reflection. It forces you to clarify. To structure. To stand behind what you write. And sometimes, it creates a deferred conversation with people you will never meet directly.

Publishing an in-depth technical article is contributing to a shared space for reflection. However modest. However quiet.

An Assumed Choice

Writing substantive technical articles today isn't the fastest way to gain visibility. It's not the most efficient for producing content at volume either.

But it's the approach that best matches the way I work and think.

I write to document approaches and technical trajectories. For a handful of interested readers. For continuity over time.

There's nothing heroic about this choice. It's simply consistent with how my practice has evolved.

Side note: this article is written in WordPress and published directly to dev.to via the API — I covered how that works in a previous article.

Continuing

Technical articles haven't disappeared. Neither has their audience. It's simply different: less massive, more attentive.

Writing today for that audience is a choice.

The question, for me, isn't whether people still care about technical articles. They do. Or at least, some do.

My question is more ethical: do we still want to write for those who truly care?

Actually Static: When WordPress Stops Being the Enemy

Pascal CESCATO — Sun, 08 Feb 2026 13:28:48 +0000

This is a submission for the GitHub Copilot CLI Challenge

This post is for developers who like writing in WordPress but want the speed and safety of static sites — and the freedom to publish anywhere from a single editorial hub.

📋 Table of Contents

Summary

What I Built
- The Search for an Alternative
- Existing Tools: Effective but Heavy
- Tech Stack
Demo
- The Real-World Gauntlet
- Where Copilot CLI Accelerated Development
- Why Local Image Optimization Matters
- Architecture
- How It Works
- Production Update: Multi-Destination Publishing
- Technical Highlights
My Experience with GitHub Copilot CLI
- Specification First, Code Second
- The Work Pattern
- The Prompt Gallery: Steering the CLI
- What This Actually Means
- The Real Value
- The Development Rhythm
- Real Example: AVIF Generation Fix
- The Audit Trail Advantage
- Code Review: Validating Production Readiness
- WordPress.org Submission: The Road to Approval
- Addendum: Automating the Future with GitHub Actions
Conclusion
Final Thought

What I Built

I spent years wrestling with WordPress performance and security issues.

Optimizing caching layers, hardening installations, fighting plugin bloat — all to keep public-facing sites running acceptably.

Then I discovered static site generators. Hugo. Astro. Fast, secure, elegant.

But months of tweaking themes, debugging build pipelines, and fighting with deployment workflows taught me something: I'd just traded one set of problems for another.

Today, I use both. Not as competitors, but as partners.

Here's the paradox I kept running into: WordPress is probably the best writing environment ever built. The interface is mature, the editor works, and you can focus on what matters — writing.

Static site generators are probably the best deployment target ever built. Fast, secure, cheap to host, and scalable by default.

So why do we keep choosing between them?

In a comment on one of my previous posts, @juliecodestack captured this tension perfectly:

"I spent quite a lot of time tweaking Hugo sites instead of writing, and I'm afraid I'll do the same thing if I transfer to Astro."

That's the real problem. Not WordPress. Not Hugo. The friction between writing and deploying.

The problem with keeping WordPress public-facing isn't the editor — it's everything else.

Exposing a complete WordPress site to the public means decent hosting, heavy dependency on plugins — at minimum for security and SEO — and serious maintenance.

And by default, performance is variable, to say the least.

The Search for an Alternative

This observation gradually led me to look for a different solution.

For some time now, I've been moving my content publishing to static sites.

But what I really wanted was simpler: keep WordPress as a writing environment while completely removing its public presence.

At a time when static sites can be deployed in seconds on almost any infrastructure, keeping WordPress as a frontend doesn't always make much sense anymore — as long as you have a robust deployment solution.

Write normally. Publish automatically.

No manual export, no scripts to run, no friction.

Existing Tools: Effective but Heavy

Having dozens of articles on my WordPress blogs, I developed a suite of Python tools capable of exporting a complete site to Hugo or Astro.

Functional, reliable, but based on a global export logic: complete site generation, transformation, then deployment.

An effective process, but heavy.

And especially unnatural in a daily writing workflow.

This search for a more fluid editorial workflow gave birth to the project.

The solution: A WordPress plugin implementing per-post, multi-target publishing strategies — GitHub (static), dev.to (API), or both — with atomic commits, structured Markdown conversion, and deployment automation.

It converts posts to Markdown with generator-compatible front matter, optimizes images (WebP/AVIF), commits atomically to GitHub, and can trigger static deployments via GitHub Actions.

Five publishing strategies:

WordPress Only – Pure WordPress site, plugin inactive
WordPress + dev.to – Public WordPress site, optional dev.to syndication per post
GitHub Only – Headless WordPress → static generator → GitHub Pages
Dev.to Only – Headless WordPress → direct dev.to publishing
Dual (GitHub + dev.to) – Static site as canonical + dev.to as controlled syndication

Tech Stack

WordPress Core:

WordPress 6.9+ (PHP 8.1+)
Action Scheduler (async background processing)
Native WordPress APIs (WordPress.org compliant)

Image Processing:

Intervention Image (AVIF + WebP optimization)
Local processing before upload (reduces GitHub Actions cost)

Publishing Destinations:

GitHub API (Trees API for atomic commits)
dev.to API (Forem REST API for direct publishing)

Static Site Generators (via GitHub):

Hugo (YAML/TOML front matter)
Jekyll (different conventions)
Astro (content collections)
Eleventy (custom structures)

Deployment:

GitHub Actions (automated Hugo builds)
GitHub Pages (free static hosting)

Architecture:

Universal adapter pattern (SSG-agnostic)
Async queue system (Action Scheduler)
Atomic commits (all-or-nothing sync)
Strategy-based routing (5 publishing modes)
Post-level sync control (per-post checkboxes)
Headless mode with 301 redirects

Development Timeline

Core plugin development: 48 hours of active coding across 8 sessions
WordPress.org compliance: 3 hours (code review + fixes)
Documentation & testing: 3 hours
Total: ~54 hours over 9 days (Feb 6-14, 2026)

The 23 checkpoints represent iterative development—each a working,
tested increment. Copilot CLI contributed ~70% of implementation time.

Key Features:
✅ Fully asynchronous sync (no admin blocking)
✅ Atomic commits (Markdown + all images in one commit)
✅ Native WordPress APIs only (WordPress.org compliant)
✅ Multi-format image optimization (AVIF → WebP → Original)
✅ Zero shell commands (100% GitHub API)
✅ HTTPS + Personal Access Token authentication
✅ WP-CLI commands for bulk operations

Demo

The workflow is now operational.

Quick Test (3 minutes)

Visit: githubcopilotchallenge.tsw.ovh/wp-admin

Login: tester / Password: Github~Challenge/2k26

Create a post, click Publish → Watch GitHub commit + Hugo deploy

Result: WordPress → Hugo in ~30 seconds.

Demo version: The live demo runs on commit da4e82f (frozen at challenge deadline, Feb 15, 2026). The main branch continues active development—Astro support added post-challenge.

Result is visible on the demo website - as you can see below:

Why I Finally Stopped Fighting My Publishing Workflow | AJC Bridge

For years, I maintained two separate worlds. World One: WordPress. Comfortable writing interface, familiar editor, everything just works. But slow page loads, constant security updates, plugin conflicts, and that nagging feeling that I’m running a Boeing 747 to deliver a postcard. World Two: Static sites. Blazing fast, secure by default, costs pennies to host. But writing in Markdown files, committing to Git, running build commands, debugging deployment pipelines. I spent more time being a DevOps engineer than a writer.

pcescato.github.io

You can also see commited files in the website repository, where you can also find the workflow in .github/workflows.

Articles are written in WordPress, as before.

When publishing or updating, a dedicated plugin automatically triggers synchronization to a GitHub repository.

Each piece of content is converted to Markdown with Hugo-specific front matter, along with optimized images (WebP and AVIF).

Everything is sent in a single commit via the GitHub API.

A GitHub Actions workflow then takes over: static site generation, then deployment to GitHub Pages.

Concretely, publishing in WordPress is now enough to put a complete static version of the site online, without manual export or additional intervention.

The Real-World Gauntlet

This wasn't a smooth 48-hour sprint. The project survived several reality checks:

Hugo Theme Version Hell: The theme I wanted required Hugo 0.146.0 minimum. My local install was 0.139.0. GitHub Actions defaulted to 0.128.0. Each environment needed explicit version pinning, and debugging failures meant decoding cryptic TOML errors across three different build contexts.

GitHub Pages URL Stuttering: The deployed site initially rendered with broken internal links because Hugo's baseURL configuration didn't match GitHub Pages' expectations. Pages built locally worked fine. CI builds deployed with relative paths pointing to void. Solution: hardcode the production URL in the workflow, accept that local previews would have slightly broken navigation.

Image Pipeline Memory Limits: Processing 10+ images per post with AVIF encoding pushed PHP's memory limits on shared hosting. First attempt: fatal errors. Second attempt: disable AVIF, keep WebP. Final solution: increase memory_limit to 512M and batch-process images sequentially instead of in parallel.

Action Scheduler Race Conditions: Early versions created duplicate commits when saving a post multiple times quickly. WordPress's save_post hook fires on autosaves, manual saves, and quick edits. Needed: debouncing logic, transient locks, and post meta flags to prevent redundant syncs.

PHP 8.1 Strictness: A single explode() call on a null value was enough to freeze the entire sync pipeline. We had to implement a try-catch-finally pattern to guarantee that even on crash, the sync lock is released and the UI updated. No more hung admin screens.

Git Line Ending Hell (LF vs CRLF): GitHub Actions Linux runners rejected files modified on Windows because of line ending mismatches. Solution: enforce LF via .gitattributes globally. One config file, zero cross-platform headaches.

The Partial Save Trap: WordPress tabbed interfaces only submit visible fields. When updating the Front Matter template, the GitHub PAT field wasn't sent, resulting in accidental deletion. Fix: array_merge() logic to preserve existing values during partial updates.

None of this was in the initial specifications. All of it was mandatory to ship.

Where Copilot CLI Accelerated Development

Copilot CLI's impact was most visible on structured, repetitive work—precisely where manual development is most tedious.

Measured Example: WordPress.org Compliance Refactoring

When WordPress.org review flagged 6 compliance issues, the fixes required:

Global plugin renaming (30+ files)
Intervention Image API migration (v2 → v3)
Asset restructuring (inline scripts → proper enqueuing)
README updates (external services documentation)

Time with Copilot CLI: 3 hours 8 minutes (measured)

Estimated manual time: 7-10 hours (based on scope)

Acceleration: ~3× faster

This wasn't the only acceleration—it was the only one with precise timestamps.

Other Notable Accelerations (estimated based on comparable WordPress development):

GitHub Trees API integration: ~90 minutes with CLI vs estimated 4-6 hours manual (API docs, trial/error, debugging)
Admin UI components: ~1 hour with CLI vs estimated 3-4 hours manual (WordPress Codex research, boilerplate)
Image optimization pipeline: ~2 hours with CLI vs estimated 5-6 hours manual (library selection, testing, error handling)

The pattern: Copilot CLI consistently provided 3-4× acceleration on structured tasks where the goal was clear and the implementation was well-documented.

What didn't accelerate: Architecture decisions, integration debugging, WordPress.org submission process, edge case discovery.

The real value wasn't just speed—it was eliminating context switching. No searching documentation, no hunting for syntax examples, no copy-pasting boilerplate from other projects.

Why Local Image Optimization Matters

The plugin processes images on the WordPress server before uploading to GitHub. This is crucial:

Without local optimization:

Upload 5MB original JPEGs to GitHub
GitHub Actions must download, process (ImageMagick/Sharp), then deploy
Build time: 2-3 minutes per post
GitHub Actions runner minutes consumed: high
Failed builds leave orphaned large files in Git history

With local optimization (current approach):

WordPress generates AVIF (50-150KB) + WebP (100-300KB) + original
Upload ~500KB total per post to GitHub
GitHub Actions just copies files, no processing
Build time: 15-30 seconds
Clean Git history, minimal runner usage

The trade-off: PHP memory limits and processing time on the WordPress side. But WordPress is idle 99% of the time. GitHub Actions runners cost money per minute.

Processing locally shifts the bottleneck to where it's free.

Architecture

What's Currently Handled:

✅ Posts and Pages: Both sync automatically with proper Hugo front matter
✅ Deletions: Trashing a post/page in WordPress triggers file deletion in GitHub
✅ Updates: Editing content re-syncs, overwriting existing files
✅ Categories and Tags: Converted to Hugo taxonomies in front matter
✅ Featured Images: Optimized and linked in front matter (featured_image field)
✅ Custom Fields: Basic fields map to front matter (extensible via adapter)

Current Limitations (MVP scope):

⚠️ Draft Handling: Drafts stay in WordPress, never sync (intentional)
⚠️ Revisions: Only published versions sync, revision history stays local
⚠️ Complex Blocks: Gutenberg blocks convert to HTML, then basic Markdown (no advanced block preservation)
⚠️ Shortcodes: Rendered to HTML before conversion (loses original shortcode)
⚠️ ACF/Meta Boxes: Only standard custom fields supported (ACF requires custom adapter extension)
⚠️ Author Pages: Not yet implemented (single-author blogs work fine)

Deliberate Trade-offs:

WordPress remains the source of truth. The plugin doesn't sync bidirectionally. If you edit Markdown directly in GitHub, those changes won't flow back to WordPress. This is intentional — simplicity over complexity.

Theme Changes and SSG Migration:

Thanks to the universal front matter template system, changing Hugo themes or even migrating to a different SSG is now straightforward:

Update the front matter template in plugin settings (no code changes)
Bulk re-sync all posts via WP-CLI (wp jamstack sync --all)
Optional cleanup of old file structure in Git (if directory paths changed)

The adapter pattern is already in place. Adding support for Jekyll, Eleventy, or Astro means implementing a new adapter class — the core sync engine remains untouched.

What's not yet automated: migrating between SSGs with fundamentally different content structures (e.g., Hugo's content/posts/ vs Astro's src/content/blog/). This would require a bulk file move operation in Git, which is currently manual.

But changing front matter conventions within the same SSG? That's now a settings change, not a refactoring project.

The repository contains:

WordPress plugin (WordPress.org compliant)
GitHub API integration (atomic commits)
Asynchronous sync management (Action Scheduler)
Hugo-compatible Markdown generation
GitHub Actions workflow for deployment

How It Works

The process in detail:

1. Writing: Standard WordPress interface, no change in the writing experience

2. Automatic Commit: The GitHub repository receives Markdown, optimized images, and front matter

You can see the .github/workflows folder, where you can find the hugo.yml file (1), the content folder (2), the static/images one (3), and last deployment status (4).

3. Hugo Structure: content/posts/ structure automatically generated with correct naming

4. Deployed Site: Static version online via GitHub Pages, optimal performance

The whole thing forms a simple publishing chain: write in WordPress, publish, and let the rest execute.

Resources

Source Code: AJC Bridge
Releases: GitHub Releases
Documentation: DeepWiki (AI-generated)

Production Update: Multi-Destination Publishing

While building this plugin, I realized something obvious in hindsight: the dev.to API has existed for years.

I'd been so focused on static site generators that I missed the simpler path: publish directly to dev.to via API.

So I added it.

Five Publishing Strategies

The plugin now supports five distinct workflows, each solving different use cases:

1. WordPress Only

WordPress (public site)

Plugin configured but sync disabled. For teams evaluating the plugin or running pure WordPress sites.

2. WordPress + dev.to Syndication

WordPress (public, canonical) → dev.to (syndication)

WordPress remains your public site. Optionally syndicate posts to dev.to with canonical_url pointing back to WordPress. Perfect for established WordPress sites with existing audiences who want dev.to reach.

Per-post control: Checkbox in post sidebar: "☐ Publish to dev.to"

3. GitHub Only (Headless WordPress)

WordPress (headless) → Hugo/Jekyll → GitHub Pages

Traditional JAMstack workflow. WordPress is admin-only, frontend redirects to your static site. All published posts sync automatically.

4. Dev.to Only (Headless WordPress)

WordPress (headless) → dev.to

Zero infrastructure. WordPress writes, dev.to publishes, WordPress frontend redirects. For developers who want WordPress's editor but dev.to's community without managing static sites.

This is the mode I use. All my articles are published exclusively on dev.to.

5. Dual Publishing (GitHub + dev.to)

WordPress (headless) → GitHub (canonical) + dev.to (syndication)

Best of both worlds. Hugo site = canonical source (your domain, your control). Dev.to = syndication (massive audience, zero SEO penalty via canonical_url). WordPress frontend redirects to Hugo.

Per-post control: GitHub always syncs. Checkbox controls dev.to: "☐ Publish to dev.to"

Five publishing strategies covering WordPress-only, headless, and hybrid workflows

API key configuration

Per-post checkbox in sidebar: decide which posts syndicate to dev.to

Why This Matters

For established WordPress sites: Keep your public WordPress site (audience, SEO, landing pages) but syndicate blog posts to dev.to for community reach.

For JAMstack purists: Go fully headless with Hugo, optionally syndicate to dev.to.

For dev.to community members: Use WordPress as your writing environment, publish exclusively to dev.to.

For migrations: Start with WordPress Only, test strategies incrementally, migrate when ready. Zero lock-in.

Technical Implementation

The architecture supports all five modes through strategy-based routing:

switch ( $strategy ) {
    case 'wordpress_only':
        return; // No sync

    case 'wordpress_devto':
        if ( post_meta '_wpjamstack_publish_devto' === '1' ) {
            sync_to_devto( $post, canonical_url: get_permalink() );
        }
        break;

    case 'github_only':
        sync_to_github( $post );
        break;

    case 'devto_only':
        sync_to_devto( $post, canonical_url: null );
        break;

    case 'dual_github_devto':
        sync_to_github( $post );
        if ( post_meta '_wpjamstack_publish_devto' === '1' ) {
            sync_to_devto( $post, canonical_url: $hugo_url );
        }
        break;
}

Headless mode automatically redirects WordPress frontend (301) to the canonical destination (Hugo or dev.to) in headless strategies. WordPress admin remains fully functional.

Per-post control in WordPress + dev.to and Dual modes: a checkbox in the post sidebar lets authors decide which posts syndicate externally.

Canonical URL handling:

WordPress + dev.to: canonical_url → WordPress permalink
Dual (GitHub + dev.to): canonical_url → Hugo site URL
Dev.to Only: No canonical (dev.to is primary)

Real-World Usage

This article was published using dev.to's rich editor before I implemented the adapter.

Future articles will be published via the plugin: I write in WordPress, click Publish, and the plugin handles the rest via dev.to's API.

The dev.to API isn't new. The Forem platform has supported it for years.

What's new is the integration: WordPress as the writing environment, dev.to as the publishing platform, zero manual steps.

That's the difference between a demo and production: the tool becomes part of the workflow, not just a talking point.

What's Next

The plugin ships with Hugo and dev.to adapters, but the architecture supports more:

Additional platforms ready:

Jekyll (GitHub Pages native SSG)
Hashnode (GraphQL API)
Ghost (Admin API)

AI-native architecture: Compatible with emerging frameworks like WordPress/agent-skills for future voice-controlled publishing.

WordPress.org submission: Submitted February 6, 2026. Pending review for public distribution to the WordPress plugin directory.

The adapter pattern means adding new destinations is straightforward. The hard part — WordPress integration, async processing, error handling — is done.

Technical Highlights

1. Universal Front Matter Engine

Instead of hardcoding the plugin for a single Hugo theme, we built a raw template system. Users define their own YAML (or TOML) with custom delimiters and placeholders like {{id}}, {{title}}, or {{image_avif}}.

This means the same plugin can adapt to any SSG convention:

Hugo with YAML front matter
Jekyll with different taxonomy names
Eleventy with custom data structures

You control the output format. The plugin just fills in the blanks.

2. Asset Management by WordPress ID

To guarantee unbreakable links, optimized images (WebP and AVIF) are stored in folders named by WordPress ID: static/images/1460/.

Rename your post slug for SEO ten times? Your images never break. The ID is immutable. The file paths are permanent.

3. Native WordPress Integration

The plugin integrates as a first-class citizen with its own sidebar menu and tabbed navigation.

Role-based security: Authors only see their own sync history. Critical settings (GitHub PAT) remain admin-only.

Responsible cleanup: A "Clean Uninstall" option removes all plugin traces (options and post meta) on uninstall, leaving zero database pollution.

4. Atomic Commits via GitHub Trees API:
Instead of multiple sequential commits (one per image, one for Markdown), the plugin uses GitHub's Git Data API to create a single commit containing all files:

// Collect all files (Markdown + images)
$all_files = [
    'content/posts/2026-02-07-this-is-a-post.md' => $markdown_content,
    'static/images/1447/featured.webp' => $webp_binary,
    'static/images/1447/featured.avif' => $avif_binary,
    'static/images/1447/wordpress-to-hugo-1024x587.webp' => $webp_binary,
    'static/images/1447/wordpress-to-hugo-1024x587.avif' => $avif_binary,
];

// Single atomic commit
$git_api->create_atomic_commit($all_files, "Publish: This is a Post");

This approach is transactional: either everything commits or nothing does. No partial states, cleaner history.

5. Beyond Hugo: Multi-SSG Architecture
While this demo targets Hugo, the adapter pattern isn't locked to a single SSG. The same codebase can support:

Hugo (YAML/TOML front matter, content/posts/)
Jekyll (different taxonomy conventions, _posts/)
Eleventy (custom data structures, src/content/)
Astro (content collections, src/content/blog/)

Adding a new SSG means writing one adapter class — the sync engine, image optimization, and GitHub integration remain untouched.
This architectural choice transforms the plugin from "Hugo-only" to a platform for any static site workflow. The 43 million WordPress sites aren't just potential Hugo users — they're potential static site adopters, period.

6. WordPress-Native Compliance:
To meet WordPress.org requirements, the plugin uses exclusively native WordPress APIs:

wp_remote_post() instead of curl
WP_Filesystem instead of file_put_contents()
$wpdb prepared statements
No exec(), shell_exec(), or Git CLI

This makes it suitable for publication in the official WordPress plugin repository.

My Experience with GitHub Copilot CLI

When I started this project, I wasn't looking for a tool to code for me.

I was looking for a way to accelerate the execution of a project whose architecture was already clear.

Having already used GitHub Copilot CLI, Gemini CLI, and various LLMs on other projects, I knew these tools could produce code quickly.

But I also knew that without a precise framework, they mainly produce... code.

Not necessarily a coherent system.

Note: This isn't the autocomplete in the editor, but a command-line tool capable of generating complete files from structured prompts.

Specification First, Code Second

The first step wasn't to code. The first step was to write specifications. Define the scope. Break down the project into functional blocks.

Identify non-negotiable constraints: WordPress native only, no shell execution, reliable async processing, atomic GitHub commits, WordPress.org compliance to publish the plugin in the official repository and benefit the community.

Here are my first interactions with Copilot CLI:

GitHub Copilot Session - WordPress Plugin

You

You are generating a production-grade WordPress plugin.

Use specifications.md and the ADR addendum as the single source of truth.

We are implementing ONLY the bootstrap foundation of the plugin.

Do NOT implement sync logic, adapters, queue logic, or GitHub logic yet.

STEP 1 — Generate plugin file structure

Generate the exact plugin file tree defined in section 7.1 of specifications.md.

Do not add extra files.
Do not invent features.
Respect strict architecture decisions.

STEP 2 — Create main plugin bootstrap file

Create:

wp-jamstack-sync.php

The file must:

include proper WordPress plugin headers
prevent direct access via ABSPATH check
define constants:
- WPJAMSTACK_VERSION
- WPJAMSTACK_PATH
- WPJAMSTACK_URL
load required core files (empty placeholders allowed)
register activation hook
register deactivation hook

STEP 3 — Activation hook

On activation:

verify WordPress >= 6.9
verify PHP >= 8.1
if not compatible:
- deactivate plugin safely
- show admin error
- do not use raw die()
- use WordPress-safe handling

STEP 4 — Development .env loader (DEV ONLY)

Add a lightweight .env loader.

Rules:

Only load .env if: WP_ENVIRONMENT_TYPE === 'development'
Do nothing in production
Fail silently if file missing
No external libraries
Parse simple KEY=VALUE pairs
Populate values into: $_ENV and getenv()

Never require .env in production.

STEP 5 — Output

Return:

plugin file tree
full content of wp-jamstack-sync.php
nothing else

Agent

I'll read the specifications and create the plugin bootstrap foundation.

7 messages not shown

Agent

Now I'll create the plugin bootstrap foundation with the exact structure from section 7.1:

3 messages not shown

Agent

Perfect! Here's the complete output:

1. Plugin File Tree

wp-jamstack-sync/
├── wp-jamstack-sync.php       # Main plugin bootstrap file
├── /core                      # Empty (placeholder for future classes)
├── /adapters                  # Empty (placeholder for future adapters)
├── /admin                     # Empty (placeholder for future admin UI)
├── /cli                       # Empty (placeholder for future WP-CLI)
├── /includes                  # Empty (placeholder for future helpers)
└── /assets                    # Empty (placeholder for future assets)
    ├── /css
    └── /js

2. Full Content: `wp-jamstack-sync.php`

<?php
/**
 * Plugin Name: WP Jamstack Sync
 * Plugin URI: https://github.com/pascalcescato/wp-jamstack-sync
 * Description: Automated WordPress to Hugo publishing system with async GitHub API integration.
 * Version: 1.0.0
 * Requires at least: 6.9
 * Requires PHP: 8.1
 * Author: Pascal CESCATO
 * Author URI: https://github.com/pascalcescato
 * License: GPL v2 or later
 * License URI: https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain: wp-jamstack-sync
 * Domain Path: /languages
 */

if ( ! defined( 'ABSPATH' ) ) {
    die( 'Direct access not permitted.' );
}

// Plugin constants
define( 'WPJAMSTACK_VERSION', '1.0.0' );
define( 'WPJAMSTACK_PATH', plugin_dir_path( __FILE__ ) );
define( 'WPJAMSTACK_URL', plugin_dir_url( __FILE__ ) );

// Development .env loader (only in development environment)
if ( function_exists( 'wp_get_environment_type' ) && 'development' === wp_get_environment_type() ) {
    wpjamstack_load_env();
}

/**
 * Load environment variables from .env file (development only)
 *
 * @return void
 */
function wpjamstack_load_env() {
    $env_file = WPJAMSTACK_PATH . '.env';

    if ( ! file_exists( $env_file ) ) {
        return;
    }

    $lines = @file( $env_file, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES );

    if ( false === $lines ) {
        return;
    }

    foreach ( $lines as $line ) {
        // Skip comments
        if ( strpos( trim( $line ), '#' ) === 0 ) {
            continue;
        }

        // Parse KEY=VALUE pairs
        if ( strpos( $line, '=' ) !== false ) {
            list( $key, $value ) = explode( '=', $line, 2 );
            $key   = trim( $key );
            $value = trim( $value );

            // Remove quotes if present
            $value = trim( $value, '"' );
            $value = trim( $value, "'" );

            // Set in $_ENV and putenv
            $_ENV[ $key ] = $value;
            putenv( "$key=$value" );
        }
    }
}

/**
 * Activation hook - verify system requirements
 *
 * @return void
 */
function wpjamstack_activate() {
    global $wp_version;

    $errors = array();

    // Check WordPress version
    if ( version_compare( $wp_version, '6.9', '<' ) ) {
        $errors[] = sprintf(
            /* translators: %s: Required WordPress version */
            __( 'WP Jamstack Sync requires WordPress %s or higher.', 'wp-jamstack-sync' ),
            '6.9'
        );
    }

    // Check PHP version
    if ( version_compare( PHP_VERSION, '8.1', '<' ) ) {
        $errors[] = sprintf(
            /* translators: %s: Required PHP version */
            __( 'WP Jamstack Sync requires PHP %s or higher.', 'wp-jamstack-sync' ),
            '8.1'
        );
    }

    // If errors exist, deactivate and show message
    if ( ! empty( $errors ) ) {
        // Deactivate the plugin
        deactivate_plugins( plugin_basename( __FILE__ ) );

        // Show error message
        wp_die(
            '<h1>' . esc_html__( 'Plugin Activation Failed', 'wp-jamstack-sync' ) . '</h1>' .
            '<p>' . implode( '</p><p>', array_map( 'esc_html', $errors ) ) . '</p>' .
            '<p><a href="' . esc_url( admin_url( 'plugins.php' ) ) . '">' .
            esc_html__( 'Return to Plugins', 'wp-jamstack-sync' ) . '</a></p>',
            esc_html__( 'Plugin Activation Error', 'wp-jamstack-sync' ),
            array( 'back_link' => true )
        );
    }

    // Activation successful - future tasks go here
    // (e.g., create tables, set default options, schedule cron)
}

/**
 * Deactivation hook - cleanup tasks
 *
 * @return void
 */
function wpjamstack_deactivate() {
    // Future cleanup tasks go here
    // (e.g., clear scheduled tasks, flush caches)
}

// Register activation/deactivation hooks
register_activation_hook( __FILE__, 'wpjamstack_activate' );
register_deactivation_hook( __FILE__, 'wpjamstack_deactivate' );

// Load core files (placeholders for now)
// require_once WPJAMSTACK_PATH . 'core/class-plugin.php';
// require_once WPJAMSTACK_PATH . 'core/class-sync-runner.php';
// require_once WPJAMSTACK_PATH . 'core/class-queue.php';
// require_once WPJAMSTACK_PATH . 'core/class-logger.php';
// require_once WPJAMSTACK_PATH . 'core/class-github-api.php';

// Initialize plugin
// if ( class_exists( 'WPJamstack\Core\Plugin' ) ) {
//  WPJamstack\Core\Plugin::get_instance();
// }

✅ Bootstrap foundation complete

- File structure matches section 7.1 specifications

- Main plugin file created with WordPress-compliant headers

- Version checks (WP 6.9+, PHP 8.1+) enforce requirements on activation

- Safe deactivation with proper error handling (no raw die())

- Development .env loader active only when WP_ENVIRONMENT_TYPE === 'development'

- Core file loaders commented out (ready for future implementation)

Then organize development into successive stages.

Development unfolded in structured phases: bootstrap, core architecture, async queue system, media pipeline, atomic GitHub commits, deletion lifecycle, bulk operations, and admin-side hardening.

Copilot CLI was used as an execution partner — implementing each layer under explicit constraints (WordPress native APIs only, async safety, atomic operations, repository compliance). The focus was not just faster coding, but building a production-ready system.

This approach is very similar to what a technical project manager or lead engineer would do before entrusting implementation to a team. The difference here is that the “team” consisted of a tool capable of producing code extremely quickly — but only if instructions were precise and constraints well defined.

So I didn’t write code in the traditional sense. I wrote functional and technical specifications, prompts, refined instructions, corrected trajectories, and validated outputs against the intended architecture.

Each step consisted of describing what needed to be built, verifying what was produced, and adjusting accordingly.

Sometimes Copilot proposed a relevant structure on the first try. Sometimes it required reworking, clarification, or tighter constraints.

The Work Pattern

Very quickly, a work pattern emerged: specification → generation → verification → correction → iteration.

In this process, Copilot behaves less like a magic generator than like a fast executor.

It can structure an entire class in seconds, propose a coherent implementation, or refactor a complete block.

But it can also forget an essential hook, overwrite an existing method, or produce functional code that doesn't comply with initial constraints.

Real Examples of Issues:

Method replaced by an incomplete stub
Hook not registered, causing silent failures
File generated but not actually written to disk
Fatal error on activation, typical of strict WordPress environments

Each incident required going back to fundamentals: verify, understand, correct, reformulate.

The Prompt Gallery: Steering the CLI

To move from concept to production-grade code, I steered Copilot CLI through complex engineering hurdles. These aren't just snippets; they are the instructions that shaped the architecture.

1. The Atomic Shift (Core Logic)

Context: Moving from simple file uploads to the GitHub Trees API to ensure images and Markdown commit simultaneously.
Refactor the Git_API class to use the Trees API. I need a single atomic commit containing the Markdown file and all processed images. Use the SHA of the base branch to create the tree.

2. The Stateful Sync (Lifecycle Management)

Context: Preventing duplicates on Dev.to by persisting remote IDs.
Update the Sync_Runner to check for '_atomic_jamstack_devto_id'. If it exists, use a PUT request to update the existing article; otherwise, POST a new one and save the returned ID.

3. The Security Audit (Hardening)

Context: Passing the official WordPress 'Plugin Check' tool.
Scan admin/class-settings.php. Identify all missing nonces and un-sanitized $_POST variables. Apply wp_verify_nonce and sanitize_text_field according to WP.org standards.

What This Actually Means

This is probably the most interesting aspect of the experience.

Using Copilot effectively doesn't mean writing one prompt and waiting for a result.

It's much more like continuous piloting, where the quality of instructions directly conditions the quality of what's produced.

In this context, the tool becomes particularly effective for accelerating everything that's structured: class creation, file organization, repetitive function implementation, refactoring, documentation.

As soon as the objective is clearly defined, execution can become very fast.

But the responsibility for architecture, technical choices, and overall coherence remains entirely human.

The Real Value

In the end, the experience is less like "AI-assisted development" than a form of assisted technical direction.

Code is produced quickly, but it must be thought out, supervised, and validated continuously.

This project was built in less than two days. Not because the tool replaces design work, but because once that work is done, execution can be considerably accelerated.

This is probably where GitHub Copilot CLI becomes most interesting: it's not a substitute for development, but an accelerator for an already thought-out and structured project.

The Development Rhythm

Each feature followed a consistent workflow that kept development focused and auditable:

1. Planning: Describe the goal in natural language
Example: Add atomic commit support using GitHub Trees API

2. Proposal: Copilot suggests implementation approach
Copilot outlines: file changes, API calls, error handling

3. Review: Validate architecture before generation
Check: Does this align with WordPress standards? Any edge cases?

4. Generation: Multi-file code updates with consistent patterns
Copilot writes across 5-10 files simultaneously

5. Testing: Manual verification and integration testing
Test: WordPress admin, GitHub API, Hugo deployment

6. Checkpoint: Document working increment for audit trail
Create: checkpoint file with context and decisions

This rhythm repeated 23 times throughout development. Each checkpoint represents a tested, working state—not just code, but verified functionality.

The checkpoints weren't documentation overhead. They were the development cadence.

Real Example: AVIF Generation Fix

Here's what an actual development session looked like:

Detailed problem description → Copilot proposes complete solution with code, validation, and error handling

The prompt describes:

What to fix: AVIF generation failures
How to fix it: Use explicit AvifEncoder, add file validation
How to verify: Check encoder usage, test file creation

Copilot responds with a 281-line implementation plan covering:

Code changes across 2 methods
Import statements updates
Error logging improvements
Verification commands

After applying changes: verification confirms correct implementation, Before/After shows API migration

Time: ~15 minutes from problem to verified solution

Manual estimate: 1-2 hours (research v3 API docs, update all calls, test each format)

Acceleration: ~4-6× faster

This pattern—detailed prompt, comprehensive response, systematic verification—repeated throughout development. The 23 checkpoints represent 23 iterations of this cycle.

The Audit Trail Advantage

Beyond just writing code, GitHub Copilot CLI acts as a technical scribe.

My session history evolved through 23 distinct checkpoints, documenting every architectural pivot from the initial foundation to the final security hardening:

001-wordpress-plugin-foundation
002-media-processing-with-avif-support
003-deletion-and-bulk-sync
004-atomic-commits-and-monitoring
...
019-fix-plugin-check-errors
020-add-nonce-security
021-uninstall-api-compliance
022-fix-nonce-sanitization-warnings
023-fix-token-double-encryption.md

You can browse the complete checkpoint history here: https://github.com/pcescato/ajc-bridge/tree/main/docs, including the initial specifications.

Each checkpoint includes context files like wordpress-api-compliance-guide.md, token-preservation-fix.md, or settings-merge-test-plan.md.

This isn't just a side effect — it's a massive win for maintainability.

It transforms the "black box" of AI generation into a transparent, step-by-step engineering log. Six months from now, when I need to understand why a particular decision was made, I won't be guessing. The checkpoint history tells the story.

What worked well:
✅ Rapid scaffolding of classes following WordPress standards
✅ Boilerplate code generation (hooks, filters, nonces)
✅ Refactoring large blocks (sequential commits → atomic commits)
✅ Documentation generation from inline comments

What required constant supervision:
⚠️ Architecture decisions (adapter pattern, async queues)
⚠️ WordPress.org compliance verification
⚠️ Error handling and edge cases
⚠️ Integration testing across components

Code Review: Validating Production Readiness

Once the plugin was functional and submitted to WordPress.org (February 6), I wanted to validate its code quality independently—without waiting for the review team's feedback.

The question: Is this truly production-ready, or did fast development introduce critical bugs?

The Review Process

I used GitHub Copilot CLI to conduct a comprehensive security and compliance audit.

The prompt: Review this WordPress plugin for critical blockers. Focus on security vulnerabilities, WordPress.org compliance, and data integrity issues.

Review completed in 10 minutes with an 800-line report covering:

Security (authentication, sanitization, secrets handling)
Compliance (coding standards, uninstall cleanup, version consistency)
Correctness (race conditions, SQL queries, data loss risks)

Findings: 3 Critical Blockers

Grade: C+ (production-ready with critical fixes needed)

The review validated the architecture ("excellent design, clean separation") but identified 3 blockers that would likely trigger WordPress.org rejection:

1. Secret Logging (Security - CRITICAL)

Issue: GitHub token previews logged to debug files.
Risk: Partial token exposure in database logs and files.
Fix: Removed all secret previews (30 minutes).

2. Version Mismatch (Compliance - CRITICAL)

Issue: Plugin header showed 1.1.0, readme.txt showed 1.2.0.
WordPress.org automated checks reject version inconsistencies.
Fix: Updated plugin header and constant to 1.2.0 (5 minutes).

3. Incomplete Uninstall (Compliance - CRITICAL)

Issue: Plugin created 13 post meta keys but only cleaned up 5 in uninstall.php.
Why this matters: WordPress.org reviewers manually check uninstall cleanup. Incomplete removal is a rejection reason.
Fix: Added 7 missing meta keys + 1 option cleanup (15 minutes).

Fixing the Blockers: 20 Minutes

I created a surgical prompt for Copilot CLI:

Fix ONLY the 3 critical blockers. 
Do NOT refactor anything else.

Changes made:

✅ Removed secret logging (verified with grep)
✅ Synced all versions to 1.2.0
✅ Completed uninstall cleanup (11 meta keys total)

WordPress.org Submission: The Road to Approval

Moving code from a local environment to the official WordPress.org repository is the ultimate moment of truth. For this project, I implemented a two-tier quality assurance strategy that transformed potential rejection into a near-immediate technical validation.

Process Timeline

February 6: Initial plugin submission.
February 12: Internal review via Copilot CLI. Identified and fixed 3 critical logic and security bugs in 20 minutes.
February 14 (00:00): Received official WordPress.org review. Identified 6 specific compliance and ecosystem issues.
February 14 (03:08): Within 3 hours, all 6 issues were addressed and version 1.2.0 re-submitted.

Current Status: ✅ Pending Final Manual Approval (Typical queue wait: 7–14 days).

The Refactoring Challenge: 3 Hours Instead of 10

The 6 compliance issues required substantial code changes:

What needed to be done:

Global renaming: 30+ files, hundreds of references
API migration: intervention/image v2 → v3
Assets restructuration: Extract 6 inline scripts, implement wp_enqueue
Documentation: External services section with API details

Manual estimate (senior developer): 7-10 hours
Actual time with Copilot CLI: 3 hours 8 minutes

The difference? Copilot CLI excels at systematic refactoring:

Global renaming: One prompt replaced hundreds of references across 30+ files without missing edge cases
API migration: Copilot read the intervention/image v3 changelog and refactored all image processing calls automatically
Pattern extraction: Identified all inline <script>/<style> tags and generated proper enqueue functions with correct hooks

This wasn't about generating new code—it was about surgical precision
at scale. The kind of work that's technically straightforward but
humanly tedious and error-prone.

The result: A compliant, tested plugin ready for re-submission in
the time it would have taken to just complete the renaming manually.

The Power of Dual Review (AI + Human)

This workflow demonstrates that even "production-ready" code benefits from an external perspective. The two audits served very different, yet complementary, purposes:

1. Internal Audit (Copilot CLI): Security & Logic

Copilot acted as a tactical second pair of eyes, catching issues that fast-paced development often misses:

Security Vulnerabilities: Identified partial exposure of sensitive secrets.
Operational Integrity: Ensured rigorous cleanup during activation/uninstallation.
Version Hygiene: Fixed inconsistent constants that would have triggered automated rejection.
Result: Transitioned the code from "fragile" to a robust, enterprise-grade architecture.

2. WordPress.org Review: Compliance & Ecosystem

Since writing this, the plugin passed WordPress.org official review. The review (a mix of automated algorithms and human oversight) focused on how the plugin lives within the WordPress ecosystem:

Intellectual Property: Renamed "Atomic Jamstack Connector" to "AJC Bridge" to eliminate trademark confusion.
Technical Standards: Replaced inline <script> and <style> tags with the proper wp_enqueue system.
Transparency: Documented external service usage (GitHub & Dev.to APIs) in the readme.txt to comply with Guideline 6.
Dependency Hygiene: Forced an upgrade of the intervention/image library (v2.7 → v3.11) to patch known vulnerabilities.

Takeaway: Production Readiness over Theoretical Perfection

The plugin moved from "Blocked" to "Repository Ready" in record time.

Surgical Fixes: We didn't perform a radical rewrite. Instead, we used AI to target specific files flagged in the reviews, applying and testing patches immediately.
The Value of Audit Trails: The detailed history of architectural decisions made during development allowed the AI to understand the "why" behind the code, proposing fixes that maintained the plugin's logic.
Engineering Pragmatism: We prioritized critical blockers for the submission while deferring minor optimizations (like edge-case race conditions) to the v1.3 roadmap.

The Lesson: AI doesn't replace official validation; it prepares you for it. By using Copilot to eliminate logical bugs early, you clear the path to focus on the platform's specific quirks — the trademark checks, the enqueue rules, the dependency audits that only humans (or their algorithms) flag.

Next Step: Official launch on the WordPress.org repository under the slug ajc-bridge.

Addendum: Automating the Future with GitHub Actions

To wrap up this intensive session, I implemented a professional CI/CD pipeline to ensure that every future release of AJC Bridge is as clean and reliable as this one.

The "Release-on-Demand" Machine

In just a few minutes, I used Copilot CLI to generate a GitHub Actions workflow that automates the entire packaging process:

Trigger: The workflow springs into action the moment a new version tag (e.g., v1.2.0) is pushed, or via manual trigger.
Clean Packaging: It automatically builds a production-ready ZIP file, strictly excluding development overhead like .git, .github configurations, composer.json, and local documentation.
Standardized Deployment: The ZIP is structured specifically for WordPress.org standards (internal folder named ajc-bridge), ensuring a seamless installation for users.
Automated Releases: The workflow creates an official GitHub Release and attaches the optimized plugin archive as a primary asset.

Why this Matters

By automating the release process, I’ve eliminated the risk of human error—like forgetting to remove a sensitive config file or misnaming a folder.

This completes the transition from a solo dev project to a professionally maintained bridge. Whether it’s a minor patch or a major feature update (like the upcoming v1.3), I can now ship a compliant, high-quality version to the community in seconds with a single Git command.

Conclusion

GitHub Copilot CLI didn't replace development.

It didn't eliminate the need to think, architect, or decide.

But used as an execution partner rather than an automatic generator, it made it possible to quickly transform a clear idea into a functional system.

That's perhaps where these tools really make sense: they don't change the way we build, but they reduce the distance between what we imagine and what we put into production.

In this specific case, they made it possible to solve a real tension: write comfortably in WordPress while publishing to a high-performance static site.

No friction. No compromises.

Just a workflow that works.

Looking ahead: v1.3 will add smart Table of Contents generation—
automatically detecting long-form content and generating dev.to /
SSG-compatible ToC with configurable thresholds (>600 words, 2+ H2) to ensure it only triggers when useful.

Final Thought

WordPress isn't the enemy; it's the most powerful editorial engine we have. By decoupling it from the frontend, we don't just fix performance—we future-proof the web.

Ready to see it in action? Try the live demo here or explore the code on GitHub.

DEV Community: Pascal CESCATO

CyberPanel's SSL Auto-Renewal Can Silently Fail — Here's the Fix

Checking what's actually served

Checking what acme.sh actually did

The fix

Turning it into something reusable

pcescato / cyberpanel-ssl-renewal-scripts

Renew and repair SSL certificates on CyberPanel 2.x directly via acme.sh (bypasses the broken built-in renewal scheduler)

CyberPanel SSL Renewal Scripts

Why this exists

Requirements

Scripts

renew-ssl.sh — Renew certificates

Why this is worth checking on your own servers

What Replacing Calendly Taught Me About Trusting Open Source

The landscape

Narrowing down

The audit: a TOCTOU race condition, in both remaining candidates

booking-calendar

Easy!Appointments

The interesting part

Takeaway

Production rollout: a simple embed, an unexpected block

First guess, wrong

The actual cause

Result

Eighty Percent Done Is Not a Real Number

Why this one, and why now

The PoC that was supposed to work

What the first real database showed in three lines, and what it cost the schedule

The trap I didn't know about

The bug that had nothing to do with a privilege

A metric that didn't measure what its name promised

Ten metrics didn't cover everything — not even the essentials

The count

The coda: debugging the report that describes the bugs

What determinism doesn't cover

What it looks like now

dbgrade — Independent PostgreSQL & MariaDB/MySQL Audits - Security, integrity, performance — scored and explained

Technical sidebar — tools and method

Unboxable in Tech: The Evidence Locker

Exhibit 12 — The Graph

Exhibit 13 — AJC Bridge

Exhibit 14 — The Memory dev.to Doesn't Give You

Exhibit 15 — The Polish Botnet

Exhibit 16 — WordPress to Hugo, and Then Further

Exhibit 17 — GCF Pro

Exhibit 18 — Prospection CRM, and the Extension That Watches With Me

Exhibit 19 — S&R CRM

The Verdict

1%

Too cheap to be good? Think again.

1. The test project

2. Methodology

3. Planning phase — who actually thinks?

4. Code phase — who actually delivers?

5. External review — and the reveal

Addendum — Model E: Kimi K2.7 Code

Addendum 2 — Multi-reviewer validation

6. Intelligent routing — the real economics

Conclusion

pcescato / LLM-Challenge

LLM-Challenge

What this is

The protocol

Unboxable in Tech

Exhibit 1 — The Unlikely Internship

Exhibit 2 — The Printer

Exhibit 3 — The Cleaning Company

Exhibit 4 — The SELECT COUNT(*)

Exhibit 5 — The Open Space

Exhibit 6 — Logic-immo

Exhibit 7 — The Regional Directory

Exhibit 8 — The B2B Platform

Exhibit 9 — The Projects Nobody Asked For

Exhibit 10 — The Handover and the Veto

Exhibit 11 — The Classroom Aide

The Mechanism

The Verdict

RFC 1516: A Build for the Community That Keeps 418 Alive

`renew-ssl.sh` — Renew certificates

The `piwo://` tap — port 1414's justification, made navigable