DEV Community: Matthew Gladding

What we shipped on 2026-05-17

Matthew Gladding — Sun, 17 May 2026 23:33:12 +0000

The biggest lift today was fixing the sequential choke point in the scene visuals stage. We introduced bounded concurrency via asyncio.Semaphore in PR #456 so SDXL wouldn't oversubscribe the GPU, which was killing wall-clock time on long-form content. We added a new app_settings key video_scene_visuals_max_concurrent with a default of 1 to preserve the existing safety behavior, but now operators with VRAM headroom can push the cap and resolve scenes in parallel.

The implementation includes a fresh migration to seed the knob so a bare DB documents the change immediately. We also added a metadata.elapsed_s field to capture per-scene wall-clock data and a new video.scene_visual_resolved audit_log row to give us the timing metrics needed to decide if the cap is actually worth bumping. Misconfigured values for 0 or -1 clamp to 1, so a typo won't deadlock the stage.

On the operational side, we tackled the decaying reference page that has 700+ rows. With PR #453, we turned the manual audit script into a nightly CI job. The scripts/regen-app-settings-doc.py now honors REGEN_DATE_OVERRIDE to pin the banner stamp to the commit date, ensuring the output is byte-identical to the source state and preventing spurious PRs.

We also backfilled ten edge-case tests for the LiteLLMProvider class in PR #455 to close the gap in model namespacing and response normalization coverage. This sits alongside a raft of dependency bumps for lint-staged, Playwright, and anchore/scan-action to keep the CI pipeline modern.

The parallelism win unlocks faster content generation without risking out-of-memory errors, while the automated docs win means the reference page stays synchronized with the codebase.

Auto-compiled by Poindexter from today's commits and PRs.

Sources

What we shipped -- 2026-05-15

Matthew Gladding — Sat, 16 May 2026 04:28:04 +0000

We spent today closing the loop on a race condition that was silently killing the first turn of voice conversations. PR #436 introduces a fallback where ClaudeCodeBridgeLLMService catches a specific Session ID <uuid> is already in use error during the very first user interaction and retries the spawn with --resume flags. We debated the approach between retrying versus deferring. Deferring UUID generation would have only solved the 2026-05-08 specific scenario. By detecting the already in use stderr on the first turn and transparently resuming against the existing JSONL on disk, we cover a broader class of races--preflights, healthchecks, and restart loops. The implementation is guarded by self._first_turn so we only attempt this one-shot retry once, ensuring a real downstream regression on the resume path still raises a proper error. It's a handful of lines, one --resume flag, and a WARNING log entry in Loki to keep the recovery path visible. While the voice agent stabilizes, we expanded the test net in test_topic_queue_cap.py from 5 to 18 tests, directly exercising the helpers in services/topic_proposal_service.py. This means future refactors of the queue logic won't silently break our contract for pending_topic_count or resolve_max_pending. The broader ecosystem needed attention too. We patched backup-visibility bind mounts and addressed schema/dependency bugs surfaced by the post-audit health check, ensuring our infra remains robust enough to support the agent's edge cases. From here, the voice agent handles the collision recovery gracefully, so we can focus on what comes next. We are still not in love with the QA threshold tuning, but at least we have data now.

Auto-compiled by Poindexter from today's commits and PRs.

Sources

https://github.com/Glad-Labs/glad-labs-stack/pull/436

What we shipped -- 2026-05-14

Matthew Gladding — Fri, 15 May 2026 16:28:03 +0000

Today the cofounder-OS thesis stopped being a hypothesis. Module v1, FinanceModule, Mercury balance flowing into Postgres--all shipped in one day because we deferred every refactor we hadn't earned yet. The 'lite' approach kept the work cheap and ended with two real bugs caught and killed in passing.

We hooked up the per-module migrations and module_schema_migrations table for boot, then deployed the FinanceModule F2 schema and hourly polling job. Route auto-discovery stitched the ContentModule skeleton into the stack. PR #433 forced the writer pipeline through the dispatcher so LiteLLM could finally emit Langfuse spans.

Before shipping, we killed a test suite fluke where a shared httpx client leaked between tests, breaking auth on the revalidation service. After resetting that isolation, we pinned 13 contract edges on traced_method to prevent silent regressions. We also deployed a banned_transition_opener validator rule to catch overused stock phrases.

Shipping this way is about finding the path without the bloat. From here, the architect composes graphs against the live module registry instead of hand-coded factories.

Auto-compiled by Poindexter from today's commits and PRs.

Sources

https://github.com/Glad-Labs/glad-labs-stack/pull/433

What we shipped -- 2026-05-13

Matthew Gladding — Thu, 14 May 2026 04:02:01 +0000

The brain_daemon PSU watchdog was silent excepts. PR #428. It wasn't enough to fix the logic; we had to make the system report when it breaks. The cost dashboard no longer shows static 150W during a PSU outage because the exporter-fetch failure is now logged. We carried this philosophy through the rest of the #455 batch, hunting down the "silent except" traps across the entire stack.

In tap_runner and retention_runner, malformed JSONB rows in config and metadata stopped silently falling through to raw strings. PR #427. We did the same for social_poster metric increments and validator_config bootstrap imports, so Prometheus errors and DSN resolution failures surface in traces. PR #426.

The content pipeline stages dropped issues when schemas shifted, so the rewriter looped endlessly on the same draft. PR #425. jobs/check_memory_staleness and media reconciliation jobs stopped passing without a breadcrumb, and task_executor stopped hiding model selection failures and timeout errors. PR #423 and PR #418. The rails--deepeval, ragas_eval, self_consistency--now log why they're disabled when is_enabled() fails, and RAGAS notifies us when it can't find a judge model. PR #421 and PR #420.

Performance-wise, we stopped creating new httpx.AsyncClient instances for every URL check and revalidation burst. PR #424 and PR #419. The GPU scheduler and URL validator share one client, closing it cleanly on shutdown to avoid leaking TCP pools. PR #417.

We traded code volume for data density. The operator finally sees which jobs are dormant and why the cost dashboard is drifting. We still don't love the amount of glue code needed to make this loud, but at least we're not guessing anymore.

Auto-compiled by Poindexter from today's commits and PRs.

Sources

What we shipped -- 2026-05-12

Matthew Gladding — Tue, 12 May 2026 19:30:48 +0000

We shipped Phase-0 Prefect orchestration last week, but today we discovered the post-pipeline actions were silently skipping execution in the new system. The 130-line success block in task_executor ran exclusively in the legacy orchestrator, leaving us with four silent regressions: the task.completed webhook never fired, auto-curation never triggered for low-quality scores, and auto-publish never shipped trusted niche content without manual intervention PR #371.

The silence of the system is dangerous, which is why the security audit on 2026-05-12 demanded an immediate response. We found three live secrets--discord_ops_webhook_url, indexnow_key, and langfuse_public_key'--shipped to the public mirror via a baseline migration. We cleared those values and gated Dynamic Client Registration and/voice/join` behind authentication flags to prevent anyone from minting admin clients or joining Matt's voice room without a token PR #375.

Beyond the hotfixes, the operational reliability required a deep dive into our static exports. R2, the source of truth for the homepage, was lagging the database by three days because publish_post_from_task fired an export_post task that died on process boundaries. We replaced the fire-and-forget pattern with a synchronous await export_post call and added a 15-minute reconciliation watchdog to catch drift between the DB and the static manifest PR #374.

We also finished the schema consolidation cleanup. The redundant infrastructure/local-db/init.sql file was deleted, and the test suite was redirected to replay the baseline schema instead of the orphaned init script. This removes the technical debt of two IF NOT EXISTS schema definitions and ensures the migration system owns the database creation process from first boot onward PR #373.

Shipping these changes unlocks a period of stability where we can trust the orchestrator signals and the data integrity checks without chasing silent failures. The operator dashboard will now surface static export failures, and the Grafana approval panel will have working preview links once we restore the missing preview_token generation in the finalization stage PR #368.

Auto-compiled by Poindexter from today's commits and PRs.

Sources

The Memory Scaling Question: DDR5 6400 vs. 8000 on Ryzen 9

Matthew Gladding — Mon, 11 May 2026 23:26:53 +0000

Date: 2026-05-11

The current state of the PC hardware market presents a curious dichotomy. On one hand, the hardware ecosystem has matured; the List of AMD Ryzen processors shows a vast lineup ranging from entry-level Ryzen 3 to high-end Threadripper, all built upon a stable platform foundation. On the other hand, the enthusiast sector remains obsessed with marginal gains. The debate surrounding memory speeds--specifically the jump from the "sweet spot" of DDR5-6000 to the enthusiast ceiling of DDR5-8000 on Ryzen 9 platforms--remains a persistent topic of discussion. As independent reviewers continue to evaluate the performance implications of these configurations, a clear picture emerges regarding whether the higher frequency is worth the engineering effort.

The Baseline: The 6000 MHz Standard

For the current generation of Ryzen 9000 series processors, DDR5-6000 MHz has established itself as the de facto baseline. This speed is not merely a recommendation; it aligns with the memory controller's (IMC) optimal operation point for the Zen 5 architecture. According to analysis provided by TechPowerUp, the scaling of memory performance with AMD Zen 5 architectures is highly sensitive to frequency, but 6000 MHz represents the point of diminishing returns for stability and latency.

At this frequency, the platform achieves a balance where the memory bandwidth is sufficient for high-resolution gaming and productivity workloads, while the system remains robust against instability issues that plague higher frequency kits. For the average consumer, the DDR5-6000 configuration is often the most pragmatic choice, offering a "plug-and-play" experience without the need for extensive tweaking or voltage adjustments.

The Incremental Step: DDR5-6400

Photo by Andrey Matveev on Pexels

Moving from 6000 MHz to 6400 MHz is often the first step enthusiasts take when seeking a performance uplift. This jump is frequently cited in comparisons involving the Ryzen 7 9800x3D. In video comparisons such as the one found in AMD Ryzen 7 9800x3D DDR5 6000 Vs 6400 C28 C30 C32..., the discussion centers on the specific timings associated with these speeds.

When examining the C28, C30, and C32 variants, the technical analysis suggests that the difference between these kits is often negligible in gaming scenarios, where frame rates are constrained by GPU performance. However, in synthetic benchmarks and memory-intensive applications, the jump to 6400 MHz provides a tangible increase in throughput. The "needle" does move, but the movement is often measured in single-digit percentage points. The primary differentiator here is the latency profile. Kits with tighter timings (like the C28 variant) may offer better responsiveness in certain workloads compared to higher frequency kits with looser timings, despite the overall bandwidth being slightly lower.

The High-End Aspiration: DDR5-8000

The leap to DDR5-8000 MHz is where the engineering challenge becomes apparent. This speed requires significant overclocking headroom and often involves pushing the memory controller beyond its native limits. In benchmarks utilizing the flagship Ryzen 9 9950X, the performance gap between 6400 MHz and 8000 MHz widens.

As reported in DDR5 6000 vs. 8000 MHz RAM - AMD Ryzen 9 9950X, the gains at 8000 MHz are more pronounced than at 6400, particularly in CPU-bound scenarios. However, the stability requirements increase exponentially. The DDR5 6000 vs 8000 MHz RAM - AMD Ryzen 9 9950X and more article highlights the introduction of high-performance modules, such as Kingston's Fury DDR5 series, which are engineered to handle these higher frequencies.

At this tier, the performance uplift is often accompanied by increased power consumption and heat output. The "move the needle" argument for 8000 MHz relies heavily on the specific workload. For a content creator rendering video or compiling code, the higher bandwidth can shave seconds off processing times. For a competitive gamer, the difference may be imperceptible in real-world gameplay, provided the system is stable.

Timings, Latency, and Subtimings

Photo by Tima Miroshnichenko on Pexels

A critical component of this analysis is the relationship between frequency and latency. As the DDR5 Memory Performance Scaling with AMD Zen... review indicates, the memory controller in Ryzen 9 processors is highly sensitive to subtimings. Pushing to 8000 MHz often results in higher CAS Latency (CL) numbers to maintain stability.

When comparing the C28, C30, and C32 kits mentioned in the YouTube analysis, it becomes evident that a 6400 MHz kit with CL32 may outperform an 8000 MHz kit with CL40 in latency-sensitive tasks. The analyst must therefore weigh bandwidth against latency. The 6000 MHz standard maintains a favorable latency-to-bandwidth ratio, whereas 8000 MHz often sacrifices latency for raw speed.

The Verdict: Is It Worth It?

Photo by PNW Production on Pexels

The analysis of the current hardware landscape suggests that DDR5-6400 is the "sweet spot" for the majority of Ryzen 9 users. It offers a clear, measurable performance improvement over the 6000 MHz baseline without introducing the volatility associated with extreme overclocking.

DDR5-8000, while technically impressive and beneficial for specific high-end workloads, represents a niche territory. The cost of the hardware, the time required for tuning, and the potential for instability must be weighed against the performance gains. For the enthusiast chasing the absolute limit, the 8000 MHz configuration on a Ryzen 9 9950X is a viable path, but for the general analyst observing the market, the trend suggests that the "golden ratio" of memory performance has settled closer to the mid-range than the high-end.

In summary, while the frequency does move the needle, the angle of the needle is often too shallow to justify the effort required to reach 8000 MHz for the average user. The Ryzen 9 platform remains highly capable, but its memory subsystem is most efficient when operated within the established parameters of the JEDEC standard and its immediate upper tier.

Sources

What we shipped -- 2026-05-10

Matthew Gladding — Mon, 11 May 2026 09:26:42 +0000

Today's biggest victory was silencing the Windows test suite, which had been throwing fatal access violations on pyarrow loads. We patched three stale unit tests to restore parity, fixing a crash in test_ragas_eval.py and correcting a logic error in test_video_stitch_helpers.py where the import patch wasn't sticking because plugins.registry._cached returned a real entry-point. PR #323

The video stitch helper was bypassing our mocked import error, so we forced plugins.registry._cached to return an empty tuple to ensure the test logic would execute. We also updated the class docstring since media_compositors now resides in ENTRY_POINT_GROUPS rather than the outdated module path.

With CI green, we bulked up coverage for services/niche_service.py from 4 to 14 tests, validating edge cases like atomicity during set_goals and weight tolerance boundaries. We ensured that validation runs before the database deletion to prevent data loss and that get_by_slug properly handles missing rows. PR #324

Infrastructure updates kept the momentum, including a rename of run() to run_migration() for better runner pickup and a bump of langchain-core to 1.3.3 to harden against untrusted manifests. PR #336

Now the engine idles without the Windows knock, leaving us to focus on the actual content generation.

Auto-compiled by Poindexter from today's commits and PRs.

Sources

What we shipped -- 2026-05-09

Matthew Gladding — Sun, 10 May 2026 00:58:54 +0000

We spent the morning screaming into the void. PR #339 fixed the mcp-server-voice bridge, but only by making it fail loudly instead of silently. Previously, mcp-server-voice/livekit_bridge.py::_resolve_default_audio_plane was catching ImportError and returning NoopAudioMediaPlane without telling anyone. We ran uv run server.py with no audio extras and got a "success" message while the TTS chunks vanished into the logging stub. Now it probes the four required modules upfront and raises a RuntimeError with the exact install command, honoring the feedback_no_silent_defaults flag.

That silence was dangerous, so we went back to the noise floor. PR #271 tore through the .github/workflows/unit-tests.yml and unignored 17 previously skipped paths. We closed the silent-skip chain so the CI gate runs the full directory, netting 564 previously-skipped tests. Some were fixed to run with pytest.importorskip, but we filed follow-up issues for three production gaps where the deleted tests were probing. It's a cleaner gate, even if it means facing the tests we ignored for so long.

Moving back to the core services, we stabilized the alert fingerprints. PR #321 removed the int(time.time()) suffix from brain/docker_port_forward_probe alerts. Previously, a single docker_port_forward_recovery_failed state generated multiple rows differing only by epoch timestamp. Now the alert_events rows carry stable identifiers, relying on brain/alert_dispatcher.py::_compute_fingerprint for deduplication. We saw similar anti-patterns in other probes but left those alone for this scope.

On the GPU side, the compose drift probe was drowning us in noise. PR #326 added a compose_drift_on_demand_services setting (defaulting to wan-server,sdxl-server) to suppress only the container_missing signal for services that intentionally aren't running. Before, the probe fired ~96 times per 4h on GPU services. Now it only suppresses the missing-container alerts, keeping genuine environment/mount/port drift visible.

Finally, we kept pushing the singleton refactors forward. The commits show us migrating services off the site_config singleton, handling task_executor, topic_batch_service, and image_service. It's more abstraction than one shop usually needs, but we want the path to N niches paved. We stripped away the silent failures and the ignored tests, leaving only the raw systems in front of us.

Auto-compiled by Poindexter from today's commits and PRs.

Sources

What we shipped -- 2026-05-08

Matthew Gladding — Fri, 08 May 2026 23:47:06 +0000

We reclaimed the infrastructure stability today after a brief hiccup in the Docker environment. The voice bridge needed a concrete tool to function, so we installed the Claude CLI directly into the Dockerfile to ensure the bridge had a binary to spawn PR #195db761. This was the linchpin for a broader post-incident recovery effort involving the docker watchdog and Kuma backup pipelines PR #12eac67a.

The brain's backup watcher had been operating blind. We remedied this by binding the ~/.poindexter/backups directory so the watcher could actually see the data being generated PR #6bd904a1. With the core systems locked down, we returned to the content pipeline.

We re-added the source_featured_image stage in the pipeline. This ensures daily posts now surface with their intended hero images instead of being drafts without visuals PR #0934d128. We also aligned the marketing copy by removing the unverified counts from the Pro tier text PR #43645195.

From here, the system breathes again.

Auto-compiled by Poindexter from today's commits and PRs.

Sources

What we shipped -- 2026-05-07

Matthew Gladding — Fri, 08 May 2026 00:00:56 +0000

We finally swapped the NoopAudioMediaPlane default for a real PipecatAudioMediaPlane in PR #316, turning the abstract /voice on command into a live Whisper STT and Kokoro TTS stream over LiveKit. It's a small semantic change on the surface, but under the hood, we were moving the entire LiveKit bridge out of the main public surface into a dedicated mcp-server-voice/ server. This isn't just a refactor; it's an architectural bet that failure isolation matters more than convenience--when a voice session crashes, we want it to take down only the voice server, leaving create_post and health checks untouched. PR #315

While the audio work felt like a creative breakthrough, the observability side was a quieter, darker fix. We had been booting workers with a broken signature for setup_sentry that silently left the SDK uninitiated, causing errors to vanish into the void. The migration 20260507_042600_seed_sentry_dsn_from_glitchtip.py now resolves the DSN at apply time with a clear priority chain, and the updated setup_sentry function finally accepts the DI'd SiteConfig explicitly. PR #318 We spent the afternoon chasing that one error log: [SENTRY] SDK initialized -- endpoint=...

Maintenance days like today involve closing security gaps. We bumped python-multipart to 0.0.27 to address the Denial of Service advisory and cleaned up Langfuse secrets by moving eight plaintext keys out of docker-compose.local.yml and into bootstrap.toml with loud-fail syntax to ensure no silent defaults. PR #319 PR #317

From here, voice is no longer a background subprocess spawn--now it's a first-class opt-in surface that runs in parallel. We're still running the CI lint against all Grafana panels to ensure the SQL doesn't rot, but with voice running live and Sentry reporting, the stack feels solid enough to handle the next round of data. PR #316 PR #312

Auto-compiled by Poindexter from today's commits and PRs.

Sources

The Architecture of Zero-Downtime AI: Moving Beyond the Prototype

Matthew Gladding — Thu, 07 May 2026 21:11:26 +0000

Retrieval-Augmented Generation (RAG) solves the fundamental problem plaguing Large Language Models (LLMs): they lack specific knowledge. By feeding an LLM context from your own documents, you bridge the gap between a generic model and a knowledgeable assistant.

However, there is a specific moment in every developer's journey with Generative AI that signals a shift in perspective. It begins with the excitement of a simple script: a prompt, a response, and the awe of a machine seemingly "thinking." You type a question, and the model replies. It is exhilarating. But as the scope grows, that initial simplicity begins to erode.

We are currently witnessing a shift in the enterprise landscape that is more profound than the shift from mainframes to the cloud. Every organization wants in. The current technological landscape feels less like a steady progression and more like a sudden explosion of possibility. But with this explosion comes a pervasive illusion: that simply adopting these tools equates to reliable innovation.

The image of the software developer is often romanticized: hunched over a glowing screen, typing lines of code with feverish intensity, waiting for the moment the "Save" button is pressed and the world changes. In reality, the most critical moment in software development is not the initial launch, but the maintenance of the system once the initial excitement fades.

In the world of software development, there is a distinct, often unspoken hierarchy between "getting something working" and "building something that lasts." To achieve a state where your AI system operates without interruption--you know, "zero downtime"--you cannot simply patch together scripts and hope for the best. There is a specific moment in every engineer's career where the "Works on My Machine" mentality dies. It usually happens not because of a single catastrophic bug, but because of a slow, agonizing accumulation of technical debt. You start by writing a simple script to spin up a service, but as the architecture evolves, the script becomes a fragile tether to a volatile reality.

To build a system that endures, you must recognize that there is a moment in every developer's career where the distinction between the environment and the application becomes painfully clear. Your infrastructure--the Terraform scripts, the containers, the CI/CD pipelines--must be treated as a first-class citizen, not just an afterthought to your application logic.

resource "aws_lb" "main" {
  name               = "zero-downtime-alb"
  internal           = false
  load_balancer_type = "application"
  subnets = data.aws_subnets.available.ids
}

Building a "frontier firm"--a modern AI enterprise--requires you to move beyond the prototype. It requires production-ready orchestration applications and robust FastAPI architectures that can handle load and error states gracefully. If you find yourself staring at a screen, your cursor blinking in the darkness, trying to understand how a specific context was fetched in production, you have failed to document your intent. As your code grows, the architecture of your application demands a narrative that explains how the pieces fit together, otherwise, you will lose access to the solution when you need it most.

from fastapi import FastAPI, HTTPException

app = FastAPI()

@app.get("/predict")
def predict():
    try:
        # Simulate processing
        return {"result": "success"}
    except Exception as e:
        raise HTTPException(status_code=503, detail="Service unavailable")

To achieve this, engineers often rely on advanced orchestration techniques. For instance, Blue-Green Deployment strategies utilize Application Load Balancers to route traffic between stable and new environments, ensuring zero downtime. The AWS Load Balancer Controller facilitates this by automating traffic shifts, while F5 offers advanced solutions for these flexible load balancing needs.

The seductive narrative of the "Silver Bullet"--that feeding an LLM a few thousand documents is all you need for a perfect system--is a trap. It ignores the complexity of the real world. To achieve true reliability, you must accept that the "magic" of AI is only sustained by rigorous, production-grade infrastructure. You must build for the long term, ensuring that your systems are resilient enough to handle the "unprecedented explosion of tools" and technologies that define the modern landscape.

Ultimately, the architecture of zero-downtime AI isn't about the model itself; it's about the environment in which it lives. It is the difference between a fleeting experiment and a cornerstone of your business operations.

Without this rigorous setup, the financial cost of downtime can be catastrophic. These figures underscore the necessity of a resilient architecture to protect business operations.

What we shipped -- 2026-05-06

Matthew Gladding — Wed, 06 May 2026 23:28:35 +0000

The dev diary job felt cursed today--skipping with "no Glad Labs activity" while PRs merged left and right--because our worker container lacked the gh and git binaries. The _run_subprocess calls were returning FileNotFoundError, and since the failures were swallowed at logger.debug level, both collectors just returned empty lists. We rewrote services/topic_sources/dev_diary_source.py to talk to the GitHub REST API via httpx instead of shelling out, removing the dependency on those binaries and the .git directory entirely. We also added a gh_repo app_setting so operators on a fork can point the diary at their own repo without code changes. We upgraded all silent failure paths to logger.warning for network and JSON errors so Loki actually picks up future regressions instead of swallowing them. (PR #294)

Beyond the diary fix, the brain is getting a cleanup. We implemented batching for gate pending summaries and demoted per-flip Telegrams to Discord to cut down on noise. We added a new brain/gate_pending_summary_probe.py that coalesces alerts into a single "N posts pending" message once per hour when the queue has been non-empty past a grace window (PR #292). To prevent the "fat finger double-tap" of poindexter post create from spawning duplicate gate trees, we added a posts.cli_idempotency_key column and tuned the CLI to reject duplicates within a 30-minute window (PR #290). We also implemented auto-expiry for pending gates with a configurable gate_pending_max_age_hours (default 7 days) to keep review queues from rotting, and fixed the DevTo cross-post service to treat a 422 "Canonical url has already been taken" response as a successful hit instead of an error (PR #291, PR #289). The test suite received a refresh to match the new batch commands, and we expanded coverage on the topic ranking module to hit the edge cases the happy-path suite was skipping (PR #287, PR #286). A code quality audit ran, flagging 10 medium-severity findings that we'll triage next (PR #281).

We traded shell dependencies for a clean API client, and with that silence gone, we can finally see the data coming in. The idempotency keys and auto-expiry rules give us a better handle on operator error rates and queue hygiene. From here, the diary feed is live again, and the brain is finally batching the noise so we can focus on the signal.

Auto-compiled by Poindexter from today's commits and PRs.