Correct the self-healing Router classification and its dead-zone reporting - #3441
Merged
Conversation
Whether a doc target is `micro` or `full` is a mechanical rule: micro means every target action is add_link, add_mention or add_tip. Haiku has now got it wrong twice, in opposite directions, and both times the run ended green. On 2026-06-20 (run 27857268241) it stamped `micro` on update_section targets and then did nothing, so FULL=0 gated Sonnet out and both PRs were lost. On 2026-09-03 (run 33705096766) it stamped `micro` on add_section and update_section targets and drafted whole sections itself, prose its micro-edit procedure does not even cover, and Sonnet was again never invoked. Apply the rule in the workflow rather than asking the model to honour it. A misclassified target with no doc PR is rewritten to `full` so Sonnet picks it up; one that already has a doc PR is left alone, since rerouting would duplicate the PR, and flagged as drafted beyond the micro scope. Report the three outcomes separately. Sharing one message is what made the 2026-09-03 Slack post announce "2 doc PR(s) created" and "claimed but not delivered" about the very same two PRs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The step comment claimed it passed "only full-complexity PRs" to Sonnet while handing over the whole router results file, and the Drafter prompt filters on `decision` alone. A run with both micro and full targets would therefore have had Sonnet redraft the micro PRs Haiku had just opened. Filter here rather than trusting the prompt, and exclude anything that already carries a doc PR URL. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Resetting to origin/main at the end of each micro-edit iteration was not enough. On 2026-09-03 the Router opened PR #3439, then ran `git checkout -b` for the next PR while still on that branch, so PR #3440 carried #3439's commit as well and touched a file unrelated to its own source PR. Reset before creating the branch, so each branch is independent of whatever the previous iteration left behind. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The complexity rule was stated once, as a definition, and Haiku twice decided against it after reasoning correctly about the same targets in prose. Say plainly that the classification comes from the action values alone, that one add_section among ten add_link targets still makes the PR full, and that the workflow now overwrites a wrong answer. Add the matching hard stop to the rules list: a micro-edit is a link, a mention or a tip, and anything needing a section stops at the routing decision. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Collaborator
Author
|
LGTM, let's try it with the next self-healing round tomorrow 👀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR makes the docs self-healing workflow apply the micro/full rule itself instead of trusting what the Router claims, and splits the dead-zone reporting into the three situations it was conflating.
Whether a target is micro or full is mechanical: micro means every action is add_link, add_mention or add_tip. Haiku has got it wrong twice, in opposite directions. On 2026-06-20 (run 27857268241) it stamped micro on update_section targets then did nothing, so FULL=0 gated Sonnet out and both PRs were lost without a trace. On 2026-09-03 (run 33705096766) it stamped micro on add_section and update_section targets and drafted the sections itself, which its micro-edit procedure does not cover, and Sonnet was again never invoked.
Replayed the new jq against the router results of run 33705096766: the real run reports 2 PRs created and 2 flagged for review with an empty Sonnet payload, the 2026-06-20 case reroutes both targets to Sonnet, and a genuine micro target with no PR is still reported as dropped. All 13 run blocks pass bash -n at each of the 4 commits.
One call for you: this touches .github/workflows/, so the workflow diff deserves a careful read rather than a skim.