From 83362842b58fc87305fa97049382f59b83f3c233 Mon Sep 17 00:00:00 2001 From: Paul Keen <125715+pftg@users.noreply.github.com> Date: Thu, 20 Aug 2026 18:22:50 +0200 Subject: [PATCH] fix: apply codex 4th-reviewer findings on the merged sprint (1 high, 2 medium, 2 low) HIGH: the 'three dependencies' claim in the RubyLLM post mirrored the gem README's marketing line but the live gemspec lists nine runtime deps - reworded to 'deliberately light: Faraday and its plugins, Zeitwerk, Marcel, and a few small support gems' (H2 retitled to match). MEDIUM: speed.ruby-lang.org numbers now carry an 'as of August 2026, expect drift' qualifier (the dashboard is a moving target and unpinned precision reads like the pattern this rewrite purged); blog-post- coordinator's cold-eyes now mandates a DIFFERENT agent type than the writer (core-reviewer, not content-creator - same-type fresh context shares the writer's default tells, per CLAUDE.md's own anti-pattern). LOW: orchestrator dispatch contract now carries a premise-audited flag (kills a duplicate GSC pull per post); conflict-resolution rule now requires re-running gates on any post file touched by a resolved hunk. Reviewer: codex:codex-rescue independent cross-check of f05c30146, claims verified against live gemspec/rails source, not panel citations. Co-Authored-By: Claude Fable 5 --- .claude/agents/blog-batch-orchestrator.md | 8 ++++++-- .claude/agents/blog-post-coordinator.md | 6 ++++-- content/blog/ruby-3-4-yjit-performance-guide/index.md | 2 +- content/blog/rubyllm-rails-getting-started/index.md | 4 ++-- 4 files changed, 13 insertions(+), 7 deletions(-) diff --git a/.claude/agents/blog-batch-orchestrator.md b/.claude/agents/blog-batch-orchestrator.md index 278c74f40..37f74901b 100644 --- a/.claude/agents/blog-batch-orchestrator.md +++ b/.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. diff --git a/.claude/agents/blog-post-coordinator.md b/.claude/agents/blog-post-coordinator.md index b49addb98..495d87b14 100644 --- a/.claude/agents/blog-post-coordinator.md +++ b/.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.) diff --git a/content/blog/ruby-3-4-yjit-performance-guide/index.md b/content/blog/ruby-3-4-yjit-performance-guide/index.md index ce6fbc89c..979be9d34 100644 --- a/content/blog/ruby-3-4-yjit-performance-guide/index.md +++ b/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. diff --git a/content/blog/rubyllm-rails-getting-started/index.md b/content/blog/rubyllm-rails-getting-started/index.md index 90af618ef..335277bfa 100644 --- a/content/blog/rubyllm-rails-getting-started/index.md +++ b/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.