Make the fan-out reduce step a real procedure - #72
Merged
Conversation
Fanning a large goal out into one distill (or one loop) per service is the map. The reduce -- assembling the slices and driving the seams between them to convergence -- was only a hand-wave in driving-the-loop §6: "run a whole-spec integration pass". Slices distilled in isolation don't agree at their seams: the same entity defined twice, a rule that depends on a trigger another slice was meant to emit, a contract demanded with nothing to fulfil it. Turn §6 into a concrete reduce: assemble and wire the slices (canonical owner for a shared entity, use imports), cross-check the whole set with a single `allium analyse` call (now cross-module aware, so it reasons across use seams and returns the seams that don't line up), route each finding through the existing taxonomy to tend/weed, then cross-service propagate and a final witness. The CLI does the seeing and the existing phase agents do the edits, so the orchestrator holds slice paths and JSON, never slice bodies -- and no new agent is added. - New reference integrating-slices.md: the seam detail (canonical entity ownership, use wiring, contract matching, which findings signal a broken seam). - driving-the-loop §6 rewritten as the four-step reduce, linking it. - actioning-findings gains the cross-seam framing and documents allium.reference.unknownName as the seam signal to read from diagnostics. - test-skills: a reduce group pinning the procedure's constructs and links.
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.
Why
For a big goal the loop already splits the work up and runs one distill or one loop per service. It works like a map reduce, and that fan-out is the map. This adds the reduce, the part where you bring those separate specs back together and check they still agree where they meet. Specs written apart tend not to line up. Something gets defined in two places, or one service waits for an event another service was supposed to send, or a contract gets asked for and nothing provides it. The loop already gathered these into an integration pass, and this makes that pass a real, concrete step.
How
Once the separate specs are done, the loop wires them together and picks one owner for anything shared. Then it runs allium analyse once over the whole set. The checker recently learned to trace behaviour across the joins between specs, so one call now tells the loop where the specs don't agree. That landed in the allium CLI 3.6.0, and it's what makes this step possible. The loop works through what it finds the same way it fixes anything else, then runs the tests that cross between services and a final check over the whole thing.
The checker does the reading and the existing steps do the fixing, so the loop only holds the results rather than every spec, and there's nothing new to add to it.