Retrieval rows move into the skill that owns them - #536
Open
ion-alpha-dev wants to merge 2 commits into
Open
Conversation
The pack kept one retrieval table beside the skill directories, so every branch that added a skill appended to the same last line. Two skills authored in the same week conflicted on text no reviewer reads, and the resolution was by hand, once per branch. Each skill now carries its own retrieval.txt and LoadTable assembles the pack's table from them, so adding a skill is an added file. A row must name its own directory's skill in one of its columns, which keeps the file the whole of what the pack claims about that skill, and rows now carry the file they came from so a failure reads as an address. Signed-off-by: Ion Alpha <contact@ionalpha.io>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…names The pack's messages tell an author to open skills/<slug>/retrieval.txt, and the rows are found by walking the tree, so nothing until now checked that the two agree. A file that exists and will not open is also now distinguished from one that is absent, which is the difference between a broken checkout and a skill that has not written its rows yet. Signed-off-by: Ion Alpha <contact@ionalpha.io>
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.
What
Each bundled skill now carries its own
retrieval.txt, andskillrecall.LoadTableassembles the pack's retrieval table from those files instead of reading one table beside the skill directories. A row must name its own directory's skill in one of its two columns, and every row now carries the file it was written in, so a retrieval failure printsskills/deletion/retrieval.txt:4rather than a bare line number.Why
The single table gave every branch that adds a skill the same last line to append to. Four skill branches in flight meant four conflicts on the same tail, each resolved by hand, on text a reviewer does not read and a merge tool cannot order. Adding a skill is now an added file, which nothing else touches.
The split costs something real: the rows for two skills no longer sit next to each other, and reading one skill's claims beside another's is how the "must not be offered" column gets written. The ownership rule pays that back by making a skill's file the whole of what the pack asserts about it, so there is one file to open per skill rather than a region of a shared one to find.
How to verify
go test ./skill/....TestPackIsRetrievableandTestEveryPackSkillStatesItsTriggersrun over the same 68 rows as before, now loaded from ten files; a skill whose rows went missing still fails, because the coverage test refuses a shipped skill no row claims. New tests inskill/skillrecallcover the loader: rows assembled across skills, a skill with no rows yet, a row that wandered into another skill's file, and a malformed row refused by file and line.Notes for reviewers
The row text is unchanged: the split was mechanical, and the per-file contents are the old blocks in the same order. The three unmerged skill branches (concurrency, performance measurement, untrusted input) each need their rows relocated from the end of the old table into a new file, which is the last conflict any of them has to resolve.