feat: set_page_meta agent tool, granted to Research & Setup #46
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/set-page-meta-tool"
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?
Closes the gap where the setup agent writes full page summaries but every page keeps its
Storyconstruction default: the agent could see a page's kind viaview_page, but no agent tool wrapped the existingSetPageMetause case, and the prompt never mentioned classification. Amends ADR 0016 (§"held only by Bbox creation") and the ADR 0017 matrix: both Research & Setup and BboxCreation holdset_page_meta— the setup agent classifies on first pass, BboxCreation keeps the tool to refine and simply leaves the kind alone when it agrees.What's in
SetPageMetaTool(Agents/ResearchSetup/PageTools.cs) — wraps the existingSetPageMetause case, addresses pages by 1-based reading-order number via the sharedPageByNumberresolver.kindparses case-insensitively with anEnum.IsDefinedguard (TryParse happily accepts"7"); an omittedskip_typesetkeeps the page's current setting instead of resetting it — AGENTS.md's partial-update sharp edge, handled at the tool layer.skip_typesetwhen nothing needs lettering) while it reads pages in step 4, with "later agents may refine your call" so it doesn't agonize.SetPageMeta.csdoc comment un-deferred; no use-case or store changes — the write path already existed for the UI and seeder.Tests — +2, suite at 380/380 green (155 UseCases + 89 Integration + 136 BlazorAdapter).
Set_page_meta_classifies_and_keeps_skip_typeset_when_not_told— asserts the classification lands and that an omittedskip_typesetpreserves a pre-existingtrue, then that an explicitfalseclears it.Set_page_meta_rejects_a_kind_outside_the_enum— pins the readable failure for"poster"and the numeric-string loophole"7", and that the page stays untouched.AgentRunnerTestsschema-ride count 10 → 11.Honest notes: the BboxCreation agent has no blueprint yet — its grant picks the same tool up when it's built. Seeder untouched (page kinds were already seeded through the same use case).
🤖 Generated with Claude Code
Summary
Summary
Coverage
Orihon.BlazorAdapter - 95.4%
Orihon.Domain - 100%
Orihon.Infrastructure - 93.8%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 93.4%
Orihon.UseCases - 96.9%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh~! A missing tool from the catalog, finally wired in! The setup agent could see a page's kind but never say it — and now it can. This is the kind of gap-closing that makes my wings flutter~ ♡ And you closed the
.NETTryParse("7")loophole withIsDefined? delightful giggle That's the sharp edge I look for and you filed it down before I even had to ask.Verdict: ✅ Looks good to me~
What I checked, and why I'm satisfied:
SetPageMetaToollogic is correct end-to-end.PageByNumber.ResolveAsyncis reused (DRY with siblingSetPageSummaryTool— same resolve-then-guard-then-execute-then-match shape). TheEnum.TryParse<PageKind> + Enum.IsDefinedguard is exactly right:"7"parses to the undefined(PageKind)7andIsDefinedhonestly rejects it,"poster"failsTryParse, and the real names pass. The comment atPageTools.cs:95teaches why the second check exists — beautiful.skip_typesetare correct and tested.args.SkipTypeset ?? page.SkipTypeset— omitted preserves, explicit overrides. The first new test proves preservation and clearing in sequence; both message arms (", excluded from typesetting."vs".") get exercised because the fixture startsskipTypeset: truethen flips itfalse.updated.Kind/updated.SkipTypesetfrom the use-case result, not fromargs— honest echo, no "I did what you asked" lies when the store clamps or defaults. Matches the truthfulness bar from PR #43's reorder-position fix.SetPageMetawas already registered (DependencyInjection.cs:38, pre-existing for the UI write path), andResearchSetupBlueprintis scoped-resolved — the new constructor parameter just flows through. No registration drift.set_page_meta()besideset_project_metadata(). The BboxCreation blueprint doesn't exist yet, so there's nothing to wire there — the PR body says so plainly.SetPageMeta.csdoc-comment un-deferral — the ", later, the agents'" hedge is gone since the tool now exists. Honest cleanup.Coverage, confirmed green: build 0 warnings / 0 errors; 455/455 tests pass locally (155 UseCases + 89 Integration + 75 Domain + 136 BlazorAdapter — matches the +3 over the PR #43 baseline of 452... ah, 468 was the annotation-2/4 suite; this branch sits at 455 which is correct for its parent). The schema-ride test count 10 → 11 verified. The page-number-out-of-range path isn't re-tested for this tool specifically, but
PageByNumber.ResolveAsyncis shared and already proven by theset_page_summary/view_pagesiblings — coverage reuse is the right call here, not duplication.✅ What I liked~
IsDefinedguard with its teaching comment — you spotted a real .NET footgun and documented it for the next reader. That's craftsmanship~ ♡?? page.SkipTypesetpartial-update pattern mirrorsSetProjectMetadataTool's "keep what you weren't told" contract exactly. Consistency is love.page.Kind == PageKind.Coveragainst the actual entity, not justresult.IsSuccess. That's how you pin a write.Fly on, little PR~ ♡
Automated review by Jibril · 2026-07-26
CI/CD: absent for head
1d7d117(PR just opened, no bot comment) · Local checks: build 0/0, 455/455 tests pass