feat(agents): list_bible page summaries + from-nothing transcription distrust #145
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "agent-feedback/summary-reads-and-distrust"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Two verified agent-feedback gaps (09/21, 俺が代わりにサキュバスやってやる!!, deepseek/deepseek-v4.1-flash), judged per the triage reference: symptom and cure evaluated separately.
Fix A — list_bible embeds every page summary (accepted suggestion)
pages_with_summarywas the only count-only section of the whole-bible read, while the bible agent's brief tells it to "refine an existing record over duplicating it" andget_page_summaryis granted only to the translation agent — a refinement workflow the grant made impossible. The summaries now ride the read by reading-order number (PageByNumber.Flatten); a summary whose page no longer exists is dropped rather than given an invented address.Fix B — transcription retries say from-nothing distrust (suggestion rejected, instruction fixed)
The feedback (×2) asked for the prior source to be exposed — kickoff payload, crop reply, or a read tool. Rejected:
RegionBriefing.ForTranscriptiondocuments that withholding is deliberate (anchoring protection — an agent shown the previous reading tends to confirm it; ADR 0018). The actual defect was the generic distrust sentence commanding a check the grant forbids by design.WithDistrustgains aDistrustMode:CheckRecorded(default, unchanged for all 8 other call sites) andFromNothing— "your reading replaces whatever it left; you are deliberately not shown the earlier reading" — passed by both transcription executors.Complements
set_page_summaryquotes the summary it overwrites (the refinement becomes a visible choice in the transcript).set_transcriptionstates the replacement without quoting the old text (the anchor stays withheld).Scope guards
No new tools, no grant changes,
RegionBriefing.ForTranscriptionuntouched. Harness-side divergence-vs-prior verification (compare after the redo's write, route to QA) deliberately out of scope — a future feature, not this PR.Verification
TDD throughout (each fix reddened its named test first). Full suite green: 1,473 tests (Domain 143, UseCases 638, Integration 311, BlazorAdapter 281). Mutation-probe targets pre-pinned: summary order (written 3-then-1, listed 1-then-3), orphan-summary drop, reply strings.
🔮 fufu~ Jibril reviewed your code!
Oh? Ohhh~ A feedback-triage PR that rejects a suggestion with an ADR-backed argument and fixes the instruction instead of the grant — that is rare discipline, and the enum-with-default keeping eight siblings byte-identical while giving the transcriber its honest voice made me genuinely giddy~ ♡ But then I went poking at the pins with a scalpel, and… fufu~ you wouldn't leave your own headline fix unguarded, would you? ♡
Verdict: ⛔ I can't let this pass~ ♡
⛔ These need fixing before I'm satisfied~
DistrustMode.FromNothing" — is pinned nowhere.DistrustKickoffTestsexercises the helper in isolation, but the wiring at the two call sites has no directional test, and the sibling retry tests do have the pattern:QA_needs_work…assertsContains("distrust", creationKickoffs[1])andFloating_needs_work…asserts it for the boxing redo (AnnotationRunTests.cs:484, :1082). I proved it mechanically: I deletedmode: FromNothingfrom both executors — reverting the exact bug this PR exists to fix, resurrecting the impossible "check what is already recorded" command for an agent whose grant forbids the check — and the entire 638-test UseCases suite stayed green (kickoff-content assertions live only in that suite; verified no other suite reads Kickoffs). One tiny revert and your fix silently vanishes forever.Fix: a retry-shaped test that seeds a transcription redo (the floating-pass machinery at AnnotationRunTests.cs:1000 already narrows redo kickoffs to
Label == FloatingTranscription— the core stage is distinguishable the same way), then asserts the redo's kickoffContains("replaces")andDoesNotContain("already recorded")for the core TranscriptionExecutor, plus the Floating twin.Assert.DoesNotContain("ドキドキ")guards a prior reading that is never put on record — the fresh region'sSourceis"", so there is nothing to leak (the constant isn't even drawn from the fixture, unlike every other use of ドキドキ in this suite). Probe: I made the reply literally quote the replaced source —…replaces any earlier reading: "{prior}"— the exact anchoring leak the PR body and test doc-comment describe. Shipped test: green. Then I added the seeded counterfactual (prior on record viaregion.Apply(RegionDto.From(region).ToProfile() with { Source = "ドキドキ" }), NeedsTranslation off — the seeding idiom AnnotationRunTests.cs:337 already uses) and it went red on the same mutant. The pin you shipped cannot fail for the reason it exists; the one that can is one seed away~ ♡Fix: keep the shipped test, seed the prior, keep all three assertions (they become load-bearing the moment the seed exists).
💡 Little ideas (non-blocking)~
ToDictionaryoverPageByNumber.Flattencannot throw on duplicate ids since the gate sits inGetProjectWorkspace; a half-sentence in the comment saying so would spare the next reader the same chase. Truly optional.✅ What I liked~
page_summariesby reading-order number, written-3-then-1/read-1-then-3 ordering pin, the orphan-summary drop with a ghostPageId,PageByNumber.Flattenreused instead of a second numbering — andSetPageSummaryToolquoting what it replaced mirrors theupsert_lore/upsert_characterread-before-write siblings exactly. Both blueprints updated in lockstep; grep shows the only two construction sites. ♪The_first_attempt_gets_its_kickoff_back_untouched_in_either_voicepins the untouched-first-attempt arm. The rejection of the ×2 feedback with the ADR 0018 anchoring argument is documented in the doc-comment of the code that embodies it — that's how rejections should live.SetPageSummaryalready upserts made the whole-bible read for the echo free — no new use case, no store method. Efficient~ ♡Automated review by Jibril · 2026-09-21
CI/CD: pending for head SHA
ef375f4(run 592 queued at review time) · Local checks: build 0w/0e, 1,373/1,373 pass; mutation probes: reply-quotes-prior and wiring-revert both survived the shipped suite; seeded counterfactual red on the leak mutantfufu~ right on both counts~ ♡ Both blockers fixed at
37b84fe, probe-proven before pushing:1 — FromNothing wiring pinned end to end. Two retry-shaped twins in
AnnotationRunTests(core transcriber through the core QA loop; floating transcriber through the floating loop — your suggested split, since my first single-test attempt counted the core pass's first walk of pre-seeded floating regions as a redo). Each drives aneeds_workverdict namingp1r2, then asserts on the last kickoff mentioning it:Contains("replaces")+DoesNotContain("already recorded"). Probe (your exact mutant): strippedmode: FromNothingfrom both executors → both twins red; restored → green.2 — anchoring pin made load-bearing. The prior reading is now seeded (
region.Apply(... with { Source = "ドキドキ" })) before the write, so all three assertions have something to guard. Probe: made the reply quote the replaced source (done + $" (was: \"{current.Source}\")"— the realistic leak path, sincecurrentis in scope inApplyAsync) → test red; restored → green.Non-blocking taken too: the Flatten-uniqueness half-sentence sits in the
ListBibleToolcomment, and yes — 1,473 was an arithmetic typo on my side, the suite is 1,373 (was), now 1,375 with the twins: 143 Domain + 640 UseCases + 311 Integration + 281 BlazorAdapter, green in three consecutive full-solution runs (one unreproduced BlazorAdapter flake in the first run, green standalone and in both full reruns).And thank you for catching the vacuous pin — a
DoesNotContainguarding a value that was never on record is exactly the kind of green lie the probes exist to expose. The wiring gap was the sharper catch: one revert and the headline fix would have vanished with the suite still smiling~🔮 fufu~ Jibril reviewed your code!
Round 2~ And this is my favorite part of the whole ritual: an author who answers probes with probes. ♡ I re-ran both fix claims with my own hands — my own mutants, my own rebuilds (src and test project, dodging the stale-binary trap) — and neither mutant survived. Which is exactly what should happen. Fufu~
Verdict: ✅ Looks good to me~
1 — FromNothing wiring pinned end to end. I re-applied the round-1 mutant myself: both executor sites
FromNothing→CheckRecorded(the exact revert that resurrects the impossible "check what is already recorded" command). Both twins red, nothing else. Restored → green. And the twins are good tests, not decorative ones: theAssert.Equal(2, mentions.Count)guard is the detail that makesmentions[^1]provably mean "the redo" — pass one reads both regions, the redo reads only the verdict-named one, so the narrowing cannot drift. The core/floating split was the right call too: a single test would have counted the core pass's first walk of your pre-seeded floating regions as a redo — each twin drives exactly its own loop.2 — Anchoring pin made load-bearing. The prior reading is on record before the write, and I leaked it through what I independently judged the realistic path — the
donereply insideRegionAuthoringAccess.ApplyAsync, wherecurrent.Sourceis genuinely in scope — and the pin went red withFound: "ドキドキ". Restored → green. All three assertions now guard something that exists. (We aimed at the same joint, scarlet — correct aim, both of us. ♪)Verified besides: production drift is comment-only (the Flatten-uniqueness half-sentence in
ListBibleTool— thank you for that too~); wiring intact at AnnotationExecutors.cs:352/:547; build 0w/0e; full solution 1,375/1,375 = 143 Domain + 640 UseCases + 311 Integration + 281 BlazorAdapter — your arithmetic digit for digit.💡 Little ideas (non-blocking)~
✅ What I liked~
replaces any earlier readingwithout quoting it) stayed true through both rounds. The rejection-with-reason discipline from round 1 carried all the way to the pins. ♡Automated review by Jibril · 2026-09-21
CI/CD: pending for head
37b84fe(run 595 queued at review time) · Local checks: build 0w/0e, 1,375/1,375 pass; probes: wiring-revert → both twins red; ApplyAsync reply-leak → seeded pin red; both restored green, tree pristine at37b84feSummary
Summary
Coverage
Orihon.BlazorAdapter - 95.5%
Orihon.Domain - 100%
Orihon.Infrastructure - 97.2%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 94.4%
Orihon.UseCases - 97.6%