Repository navigation
Hydra tutorial series: describe the pipeline the flows actually run - #238
Merged
Merged
Conversation
The parts on concept, pipelines and gates still described the retired shell pipeline: - a ready-to-build trigger - automatic hand-off from build to review to applier - an applier skip rule - a post-review quality recheck - reviews/<round>.json - *:running labels - yolo auto-merge - "22 gates" Checked against ConductionNL/hydra flows/ (identical on main and development): - Part 1: build:queued plus the change named in the issue body is the trigger. It gives the end-to-end path (build, gates, one fix pass, a PR on pass and fail, review only on code-review:queued, a human merges) and no longer promises lead times or model env vars. - Part 2: the build lane with its four outcomes, the review lane routed on hydra-verdict.json, and nothing queuing code review after a build. Also one unit of work per tick, the slot pool and lock, the labels no flow acts on, and a blocked review re-running every tick. - Part 3: about 96 declared gates and the COVERAGE line. The runner is a delegator to conduction/hydra-gates. The only re-gate is after the build's fix pass, and the false-positive example is real gate history. English and Dutch; the Dutch pages had drifted further and now say the same as the English ones. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ill tree - Part 4: skill, gate and persona counts follow the repo, or are phrased so they do not go stale (about 96 gates, 9 personas). It says what the factory actually runs. The image table now says: builder copies .claude/skills/ only; reviewer and security carry hydra-gates plus 16 hydra-gate-* skills. Wrong skill descriptions are rewritten. - Part 5: a real run starts with build:queued and the change named in the issue body. Code review is queued by hand after build:pass. The label sequence has no :running, done or merge. Image defaults are localhost/hydra:test. The base image is COPY --from, not FROM. - Part 6: the recovery ladder uses the re-queue levers that work, and says a blocked review stage must lose its :queued label first. It states that retry:queued and rebuild:queued are not handled. The supervisor-log commands and the double-prefix example are gone. The hydra.json example shows what the record flow writes. - Part 7: hydra-sequencer polls; hydra-dispatch does not. There are no dependency or sibling checks. The owner comes from the hermiq workload step; the owner:<uid> marker is dropped because nothing in hydra parses it. The quiz drops "22 gates". English and Dutch (part 7 has no Dutch page). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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.
Summary
The seven-part Hydra tutorial still largely described the retired shell pipeline: supervisor,
orchestrate.sh, automatic hand-offs, a yolo auto-merge. Hydra now runs as OpenRegister flows. These two commits rewrite the pipeline mechanics in all seven parts, in English and Dutch (part 7 is English only), against whatConductionNL/hydraactually does.The source is
flows/*.flow.jsontogether with the scripts, images and agent configs. On those pathsmainanddevelopmentare identical (they differ only in.claude/skills/), so the text holds for both branches.What the tutorial now says, which it did not before
build:queuedplus the change named in the issue body (openspec/changes/<name>). The trigger is notready-to-build, and it ishydra-sequencerthat polls, nothydra-dispatch.build:pass,build:fail,build:no-change,build:blocked) and opens a PR on both pass and fail.build:pass; the reader addscode-review:queued. Code review, security and applier then run in sequence, routed onhydra-verdict.json. The applier has no skip rule.*:runningordonelabels, no auto-merge, no yolo, no post-review re-gate, no dependency or sibling checks, and no handling ofretry:queuedorrebuild:queued.:queuedlabel and runs again every tick until that label is removed.Claims that could not be verified in the hydra repo are removed rather than kept. Examples: lead-time estimates, the
owner:<uid>issue marker, and a retry/rebuild operations guide that does not exist.The hydra-side counterpart (CLAUDE.md,
secrets/.env.example, the credentials cleanup) is ConductionNL/hydra#719.Test plan
build(MDX compile and broken links, both locales) is green🤖 Generated with Claude Code