GameCult/Huginn
Watch
9
0
Fork
You've already forked Huginn
 0
Code Issues Pull requests 2 Projects Releases Packages Wiki Activity Actions

AlreadyResolved names the closure in force #22

Merged
eureka merged 2 commits from eureka/refusal-names-the-closure into main 2026-11-09 12:10:30 +00:00
Conversation 0 Commits 2 Files changed 3 +38 -12
eureka commented 2026-11-09 11:41:29 +00:00
Owner
Copy link

Finding (follow-up chat-s4377-4379): admission already lets the row's owner correct a closure. Withdraw the resolution (subject kind Resolution), then resolve the subject again at the next sequence; this works in one batch (new test a_closure_is_corrected_by_withdrawing_it_and_resolving_again_in_one_batch, passes on main). What Nibu and Kiko hit is a different subject: Withdrawn/Fixed aimed at the follow-up itself returns AlreadyResolved { subject }, which says nothing about what to withdraw. Root's 14 withdrawals went through the resolution rows, which is the difference.

Change: MindRefusal::AlreadyResolved gains closed_by, the in-force resolution's key, taken from closing_resolution_unless (already the owner of that fact). Both refusal sites (resolution rule, ruling-answers-question) fill it. Published response schema regenerated. Six existing assertions updated to the new field.

Not changed: no owner check on who may withdraw (admission has none for any kind), no new outcome, no supersede-in-place path. The row's owner is the mind's own writer.

Tests: cargo test -p huginn-mind all green except that one full run flagged my first guess of one key, fixed; focused rerun green. Full-suite rerun after the fix not done. Needs a second reader before merge; not deployed.

🤖 Generated with Claude Code

Finding (follow-up chat-s4377-4379): admission already lets the row's owner correct a closure. Withdraw the *resolution* (subject kind Resolution), then resolve the subject again at the next sequence; this works in one batch (new test `a_closure_is_corrected_by_withdrawing_it_and_resolving_again_in_one_batch`, passes on main). What Nibu and Kiko hit is a different subject: Withdrawn/Fixed aimed at the follow-up itself returns `AlreadyResolved { subject }`, which says nothing about what to withdraw. Root's 14 withdrawals went through the resolution rows, which is the difference. Change: `MindRefusal::AlreadyResolved` gains `closed_by`, the in-force resolution's key, taken from `closing_resolution_unless` (already the owner of that fact). Both refusal sites (resolution rule, ruling-answers-question) fill it. Published response schema regenerated. Six existing assertions updated to the new field. Not changed: no owner check on who may withdraw (admission has none for any kind), no new outcome, no supersede-in-place path. The row's owner is the mind's own writer. Tests: `cargo test -p huginn-mind` all green except that one full run flagged my first guess of one key, fixed; focused rerun green. Full-suite rerun after the fix not done. Needs a second reader before merge; not deployed. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
A closed row is corrected by withdrawing its resolution and resolving the
subject again at the next sequence; admission already allows it, in one batch
too (new test). The refusal gave no way to find it: a Mind that tried to
Withdraw or re-resolve the follow-up itself got AlreadyResolved with only the
subject. It now carries closed_by, the resolution key to withdraw.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Mutating the resolution path's closed_by to the subject fails the test.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
eureka merged commit 05f593476e into main 2026-11-09 12:10:30 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
GameCult/Huginn!22
No description provided.