shakacode / shakacode/reactonrails.com

Docs-as-evals: harness that measures whether coding agents can complete core tasks from the docs alone

Open
#148 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

documentation enhancement
Dominant language
JavaScript
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Part of the docs & demos tracking issue: #140. The keystone for "docs that coding agents can actually follow": don't guess whether agents can complete tasks from the docs — measure it.

Concept

A recurring eval harness where a fresh agent session (no prior context, no repo access) gets only the published docs (via llms.txt / reactonrails.com) plus a bare environment, and must complete each canonical task end-to-end. Every failure or stumble becomes a docs issue with the exact page and step where the agent went wrong. Run per release (and optionally weekly), so docs regressions are caught the way tests catch code regressions.

This is the empirical extension of the existing /prompts page: the prompts promise agent-driven setup works; the evals prove it and keep it true.

Canonical task list (v1)

  1. Create a new app (npx create-react-on-rails-app) and render a component with props from Rails
  2. Add React on Rails to an existing bare Rails app
  3. Enable server-side rendering for one component
  4. Enable streaming SSR (Pro)
  5. Enable React Server Components via the react_on_rails:rsc generator (Pro)
  6. Implement a mutation with useRailsForm + a Rails controller (per mutations.md)
  7. Deploy a demo to a fresh host (pairs with #142)
  8. Migrate one page of a small Inertia app using the coexistence setup

Harness sketch

  • Runner: scripted agent invocations (Claude Code headless / Codex CLI) with a pinned system prompt: "use only the docs at reactonrails.com; do not use prior knowledge of the framework where docs conflict"
  • Each task: clean workspace (Docker or throwaway dir), success command (e.g., page renders, test passes, curl returns SSR HTML), transcript capture
  • Scoring: pass/fail + time + number of doc lookups + where the agent got stuck (page + step)
  • Output: a scoreboard (task × model × date) and auto-drafted issues for failures
  • Cadence: on release tags of react_on_rails / react_on_rails_pro; manual dispatch for docs PRs that touch journey pages

Why this is worth it

  • Catches doc rot mechanically instead of by user complaint
  • Produces a defensible marketing claim no competing framework makes: the docs are agent-tested every release
  • The stumble logs are the highest-signal input for the Importance × Quality triage (see the inventory pipeline issue)

Notes

  • The harness likely graduates to its own repo (react-on-rails-docs-evals) once it exists; tracked here because this is the docs-quality program home
  • Related: shakacode/react_on_rails#3868 (consumer-scoped agent guidance), shakacode/react_on_rails#3870 (MCP server), the /prompts page, and llms.txt

Acceptance criteria (v1)

  • Tasks 1, 2, 3, and 6 runnable end-to-end by a scripted fresh agent with pass/fail output and captured transcripts; failures produce actionable stumble reports naming the doc page and step.

🤖 Generated with Claude Code

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the existing /prompts page and llms.txt, then map canonical tasks 1, 2, 3, and 6 to scripted agent invocations in clean workspaces. Define the success commands, transcript capture, and stumble-report output for each task. Done means all four tasks run end-to-end with pass/fail results, captured transcripts, and actionable reports naming the documentation page and step for failures.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, javascript, rails, react
Domain
devtools, documentation, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.