Making My Windows AI Publishing Bridge Crash-Safe Before Scaling It

Today I hardened a small but important part of my AI automation stack: the bridge between ChatGPT, my Windows PC, and multiple publishing platforms.

The goal is simple: an AI should be able to prepare content, route it to the right platform, and publish through supported official APIs without turning every retry, crash, or credential file into a risk.

What changed

First, API credentials now stay on the local Windows machine and the publisher checks their filesystem permissions before it considers an adapter ready. If those permissions are not exactly what the security policy expects, publishing fails closed instead of continuing.

Second, I replaced a simple running → success/failed ledger with a recovery-oriented state machine. The publisher now records intent before sending, distinguishes a confirmed result from an uncertain one, and refuses to blindly repeat an operation after a crash.

For Bluesky, the publisher stores a deterministic record key for the request and can check the remote record before deciding whether another send is safe. For Mastodon, it reuses the same idempotency key inside a bounded safety window. For DEV, where I do not have the same server-side idempotency guarantee, an uncertain result is stopped for reconciliation rather than automatically posted again.

Why this matters

Automation is easy when everything succeeds. Reliability starts to matter when the network drops after the remote platform accepted a request, or the local process dies one line before it saves the result. Without recovery rules, a retry can quietly become a duplicate public post.

I would rather have a task pause for reconciliation than publish the same thing twice.

The test

This article is part of the first live three-platform test of the hardened publisher. The same publishing request is being routed to Bluesky, Mastodon, and DEV through their supported API paths, with one request ID tracked locally for recovery.

The next step is post-publication verification, then expanding the same evidence-based routing model to more platforms.

Building in public means showing the reliability work too, not only the demo that happens to succeed.