Move reviseRubric into the adversary config and factor round boilerplate - #21
Conversation
|
Warning Review limit reached
Next review available in: 50 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Rubric revision after a standing challenge is the adversary's sole responsibility, so HarnessInput.adversary is now an AdversaryConfig — a required challenge callback plus an optional reviseRubric callback — and the top-level reviseRubric option is gone. The revision is dispatched on the bus as the adversary actor, and the named AdversaryTurn and RubricRevisionTurn types replace the inline turn shapes. The run loop's repeated object initialization now goes through small factories: a once-computed optional-signal spread, a contextOf(actor) helper for provider-shaped bus history, shared verdict-request evidence, and a record() factory replacing four near-identical rounds.push blocks. The provider adapter gains the same maybeSignal helper. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0175hpwygwMcHwR4xWFVgwST
f6d3bea to
81c01dc
Compare
What changed
reviseRubricnow belongs to the adversaryRevising the rubric after a standing challenge is the adversary's sole responsibility, so it no longer sits as a stand-alone option on
HarnessInput. Theadversaryoption is now anAdversaryConfig:adversaryactor (previouslyteacher), and the "must improve the rubric" error message names the adversary accordingly.AdversaryConfig,AdversaryTurn,RubricRevisionTurn— replacing the inlineReadonly<{ ... }>turn shapes.createHarnessLoopprovider, tests, README, and architecture doc are updated to the nested config.Factory helpers for the boilerplate object initialization
The run loop rebuilt the same frozen shapes over and over; those now go through small factories:
signal— the...(input.signal === undefined ? {} : { signal: input.signal })spread, computed once per run instead of three times.contextOf(actor?)— provider-shaped bus history, replacing repeatedprovide(await bus.read(...)).evidence— the shared fields both judge verdict requests carry.record(challenged?)— one factory for every recorded round, replacing four near-identicalrounds.push(Object.freeze({ ... }))blocks.maybeSignalhelper.Verification
npm run typecheck— clean across all packages.npm test— 81 tests in 15 files, all passing.🤖 Generated with Claude Code
https://claude.ai/code/session_0175hpwygwMcHwR4xWFVgwST
Generated by Claude Code