Add isolated local_heavy diagnostic record (2026-08-07) - #150
Merged
Merged
Conversation
Records one governed invocation of the local_heavy path under explicit operator authorization, deliberately outside the daily-use evidence window's day and trial numbering. Not Day 4, not Trial 012. The invocation did not complete through the currently configured governed local_heavy path within the 120-second read timeout. Console reported a read timeout at 120 seconds; the route_decision to worker_result wall-clock gap was approximately 122.04 seconds, corroborating the mechanism. The ledger records the same generic backend_error with elapsed_seconds 0.0 that Day-1 Trials 006 and 007 produced, so the mechanism survives only outside the durable record. Establishes that the earlier 30-second ceiling is not a sufficient explanation for the local_heavy failures, and that CR-DD-014 route/model binding worked correctly. Records that zero token usage means no completed backend response was returned, and does not claim the model performed no internal inference. Four precondition findings from source inspection: substantive architecture work cannot naturally reach local_fast, because security_review terminates at human handoff while architecture_planning prefers local_heavy; route class is determined by prompt lexicon rather than evidenced execution policy; the SpecialistRouter per-category timeout is live code on the execution path, resolving a previously unestablished timeout source; and the unconditional 8.8.8.8:53 reachability probe is source-confirmed on the live path but was not runtime-observed this session. Confirms at runtime that human_review_required and terminal human_handoff are separate concepts. Documentation only. No code, test, or configuration is changed. The record makes no implementation recommendation and grants no authority. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
✅ Deploy Preview for poetic-quokka-0fd859 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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
1 participant
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.
Records one governed
local_heavyinvocation under explicit operator authorization, deliberately outside the daily-use evidence window's day and trial numbering. Not Day 4, not Trial 012.Documentation only: one new file,
docs/operations/local-heavy-diagnostic-2026-08-07.md, 251 insertions. No code, test, or configuration change.Bounded question
Answer: no, for this invocation. It did not complete within the 120-second read timeout. Console reported
Read timed out. (read timeout=120), exit code 3; theroute_decision→worker_resultwall-clock gap was approximately 122.04 seconds, corroborating the mechanism.What this establishes
local_heavyfailures — this run had four times the budget and still timed out.architecture_planning→local_heavy→deepseek-r1:latest, no binding issues. Binding is not the failing element.backend_errorwithelapsed_seconds: 0.0, byte-identical to Day-1 Trial 007's fast HTTP 400. The mechanism survives only in console output and the event gap.human_review_requiredand terminalhuman_handoffare separate concepts — confirmed at runtime, not only by source reading.Four precondition findings from source inspection are recorded, including that the
SpecialistRouterper-category timeout table is live code on the execution path — resolving a question earlier records left unestablished.Claim discipline
Zero token usage is recorded as meaning no completed backend response was returned. The record explicitly does not claim the model performed no internal inference, and does not claim
deepseek-r1:latestcannot serve the route. The unconditional reachability probe is recorded as source-confirmed on the live path but not runtime-observed this session; that distinction is preserved deliberately.Sequencing
First of two related documentation PRs. Empirical observation lands before the external architecture interpretation that it partly motivated.
The record makes no implementation recommendation and grants no authority. No timeout was changed, no model was changed, no code was modified.
Verified before opening: base commit is exactly
0dc5019; single commit ahead ofmain; one new file; document-reading guards (test_governed_decision_integration_absence.py,test_propose_cli.py) pass, 12 tests.Generated with Claude Code