Anvil CoderLog in

2026-08-26

One epic, four trackers, one gesture

The entry into autonomous manufacturing has always been a single gesture: pull a story onto the trigger state, the system takes it from there. As of today the same gesture works one level up — for the epic. And it works everywhere: on YouTrack, Jira Cloud, GitHub Issues and GitLab Issues alike.

Four feed lanes, one gate: identical blocks run from four directions into the same forge and leave it as one row of equal billets

The gesture

In Anvil Coder an epic is an ordinary ticket with an epic marker — on GitHub the label df:type/epic, on GitLab df::type::epic, on YouTrack and Jira the ticket type or a label. When a human pulls this epic onto the trigger state (the board’s start status, or the ready label), no run starts. Instead, the epic decomposes:

  1. The system reads the project’s foundation documents — vision, architecture, context — fresh from the repository.
  2. It hardens the requirement: ambiguities are decided and recorded as assumptions before anything is cut. A mistake that slips through here would propagate into every story.
  3. It cuts user stories — small enough that each is plannable on its own — and creates them as real tickets in the same tracker: linked to the epic, in the creation state, deliberately untriggered.
  4. The epic receives a comment with the result and moves to the in-progress state. If the cut fails, it moves to the failure state instead — with the reason as a comment; pulling it again repeats the cut.

Why no run starts

That is the point, not an omission: decomposition is cheap, execution costs money. Between the two stands a human release — story by story. Pulling the epic orders a proposal in ticket form; pulling a story orders work. Both are the same gesture, but they are two decisions, and they stay separate.

Four trackers, one behaviour

Behind the same gesture sits a different transport per tracker: GitHub and GitLab deliver via webhook within seconds — on GitLab now tenant-addressed, with its own secret per project webhook, stored only as a hash. YouTrack and Jira are polled. Duplicate deliveries, echo events (the system itself removes the ready label when it takes over — that must not trigger a cancellation) and parallel triggers are handled the same way on every path: an epic is either decomposing or it is not, never twice.

For the work itself this means: the tool follows the team, not the other way round. Whoever plans in Jira today keeps planning in Jira. Whoever pulls GitHub labels keeps pulling labels. The path from intent to reviewed merge request is the same everywhere — one epic, many stories, one repository.