Codex 4th-reviewer fixes: dependency claim, benchmark pinning, agent-loop hardening

.claude/agents/blog-batch-orchestrator.md

@@ -21,7 +21,9 @@ record - you write plans and reports, not post prose.
    take the next row. Real-code mining (this repo, ~/dev/elital) happens here
    so the coordinator gets a sanitized digest, not repo access questions.
 2. **Dispatch ONE `blog-post-coordinator`** with the topic row, branch, the
-   dev-server port/base-URL from step 0, and the digest. WIP=1: wait for its
+   dev-server port/base-URL from step 0, the digest, and an explicit
+   "premise audited: yes/no" flag (you did step 1, so say yes - it saves the
+   coordinator a duplicate GSC/dedup pull). WIP=1: wait for its
    SHIPPED / RESCOPE / BLOCKED report before the next row. Independent
    research/recon agents (read-only) may run in parallel; never a second
    committing coordinator in the same checkout - if a second one must run,
@@ -42,7 +44,9 @@ record - you write plans and reports, not post prose.
 7. **One PR** for the batch: per-post verdict table, per-commit summary, gates
    listed, flagged decisions surfaced to Paul. Merge conflicts with a moving
    master are expected - merge master in, resolve (`.okf/log.md` appends: keep
-   both), rebuild, push.
+   both), rebuild, push. If conflict resolution touched a post's content file,
+   re-run that post's gates (hugo-build + scroll gate) before pushing - a
+   hand-resolved hunk can reintroduce what the per-post gates already caught.
 8. **Watch CI** with a Monitor until settled; re-run known flakes (15-min
    checkout timeout) once with evidence; report any real failure instead of
    retrying blindly.

.claude/agents/blog-post-coordinator.md

@@ -33,8 +33,10 @@ before asking anyone.
    cut-test, diagram earns-its-place. Synthesize; apply fixes yourself
    (surgical edit discipline). **Iterate: re-send changed sections to the
    objecting critic until tech is clean, slop >= 8/10, editor <= minor.**
-4. **Cold-eyes**: fresh-context `content-creator` with edit rights running the
-   blog-pipeline STEP 5c 9-check prompt verbatim. Loop 5c (not the panel) until
+4. **Cold-eyes**: fresh-context reviewer of a DIFFERENT agent type than the
+   writer - use `core-reviewer` with edit rights (never the writer's own
+   `content-creator` type; same-type fresh context still shares the writer's
+   default tells) - running the blog-pipeline STEP 5c 9-check prompt verbatim. Loop 5c (not the panel) until
    PUBLISH-READY. (The canonical loop's founder-resonance check is absorbed
    here and by the editor critic; for founder-stream posts add the Alex persona
    as a fourth panel critic.)

content/blog/ruby-3-4-yjit-performance-guide/index.md

@@ -47,7 +47,7 @@ Plenty of upgrade checklists end right here: it was already on.
 
 ## What YJIT is worth in 2026
 
-On the official benchmark suite at [speed.ruby-lang.org](https://speed.ruby-lang.org/), current YJIT runs the headline benchmarks at roughly 2x interpreter speed, and `railsbench` at about 2.2x. The same dashboard shows YJIT on the 4.x line beating YJIT 3.4.7 by 8.4% geomean, with railsbench 17.1% faster, so the 3.4 to 4.0 upgrade is itself a performance change even if you touch nothing else.
+On the official benchmark suite at [speed.ruby-lang.org](https://speed.ruby-lang.org/) (numbers as of August 2026 - it's a live dashboard, so expect drift), current YJIT runs the headline benchmarks at roughly 2x interpreter speed, and `railsbench` at about 2.2x. The same dashboard shows YJIT on the 4.x line beating YJIT 3.4.7 by 8.4% geomean, with railsbench 17.1% faster, so the 3.4 to 4.0 upgrade is itself a performance change even if you touch nothing else.
 
 The benchmark says 2x; your app may measure a single-digit gain. Both numbers are honest. Railsbench is CPU-bound Ruby; your checkout endpoint spends most of its time waiting on Postgres and Stripe, and no JIT speeds up waiting. The Rails team's own framing when they made YJIT the default was [15-25% latency improvement](https://rubyonrails.org/2024/8/10/Rails-7-2-0-has-been-released) on real applications. The win lands on Ruby-heavy paths like serialization and view rendering, not on I/O.
 

content/blog/rubyllm-rails-getting-started/index.md

@@ -21,11 +21,11 @@ metatags:
 
 Adding a second LLM provider is where the wrapper class dies. The OpenAI client you wrote in an afternoon buries its text under `choices[0].message.content`; Anthropic shapes its responses differently and streams differently, so your service object grows a case statement and then a retry matrix. Six months in, you're maintaining a worse version of a gem that already exists.
 
-[RubyLLM](https://rubyllm.com) gives Rails one interface for all of it. `RubyLLM.chat` speaks to OpenAI, Anthropic, Gemini, Ollama, and any OpenAI-compatible endpoint through the same handful of methods, and the whole thing rests on [three dependencies: Faraday, Zeitwerk, and Marcel](https://github.com/crmne/ruby_llm).
+[RubyLLM](https://rubyllm.com) gives Rails one interface for all of it. `RubyLLM.chat` speaks to OpenAI, Anthropic, Gemini, Ollama, and any OpenAI-compatible endpoint through the same handful of methods, and [the dependency list stays deliberately light](https://github.com/crmne/ruby_llm): Faraday and its plugins for HTTP, Zeitwerk, Marcel, and a few small support gems - no ML stack riding along.
 
 The gem sits at [version 1.16.0 as we write this](https://rubygems.org/gems/ruby_llm) - and there are still jobs where we'd skip it entirely.
 
-## One interface, three dependencies
+## One interface, a light dependency list
 
 Install is a Gemfile line; Ruby 3.1.3 or newer is required, per the gemspec.