Skip to main content
The flow is configured once, per project, and applied the same way every time. It is what makes moving a card deterministic enough to automate.

​
Stages

The board’s columns are the flow’s stages, in order. Each one carries:
​
per repository
Where a branch is cut from when a card enters this stage, and where it merges into. This is the whole engine — a column is not a label, it is a base and a target.
​
Who may move a card into this stage. Promoting to production is not the same permission as starting work.
The branch name comes from a template — feature/{{number}}-{{title}} by default. It matters more than it looks: the board recognises branches by that convention, and one named anything else never reaches the card it was for.

​
Moving a card runs Git

Depending on where the card lands, the move cuts a branch, opens a pull request, or merges one. The same gesture on screen, three different things underneath, decided by the flow rather than by the person doing it.
Moving a card backwards is not cosmetic. What was merged has to come back out first, so Tylon opens the revert as a pull request and the card waits where it is until that lands.

​
When it refuses

Tylon never forces. If it cannot act safely it stops and says why, in the forge’s own words: the branch has conflicts, the checks are failing, there is nothing to merge. A card in that state is blocked, and the block names the repository that refused. On a card touching three repositories it also names what already landed in the other two — two facts, not one sentence somebody has to take apart. The block clears when the world changes under it: a push to the card’s branch, a pull request opening, the forge saying the branch merges again.
Whether a red check blocks a promotion is a setting — requireGreenChecks, off by default. A team whose repositories run no checks at all would otherwise never move a card.

​
Who runs Git from the second stage onwards

Three modes, and the trade is the choice.
Every promotion is that card’s own pull request, at every stage. Simple, and each card is independent of the others.
The release merges one stage’s branch into the next, as a whole. Fastest to operate, and it carries whatever else is on that branch — which is the trade it sells.
The release promotes its cards, each through its own pull request. The release is still the unit of intent; the merges stay per card.

​
What stays with the forge

Code review, branch protection and CI. Tylon orchestrates above them and never underneath: it reads what the checks said and refuses the card, rather than running checks of its own or arguing with a protected branch. Each repository also keeps its own identity — merge method and versioning are per project. A team shipping a library and a service has every reason to squash one and merge the other.