Built-in workflows

Expecto Centum comes with two workflows: Greenfield, for building a new project, and Brownfield, for keeping a published one moving. Each takes your tickets one at a time and carries every ticket from a plan to finished, tested code.

A workflow is the sequence of stages Expecto Centum runs for each ticket. Both built-in workflows write the tests first, then the code that makes them pass, review the result against your project's own quality checks, and document what changed. Where they differ is where the work starts and how it lands.

I Greenfield

Greenfield is for a project you're building from the start. Rather than answering reported issues, it works through what you've described you want built. Its stages, in order:

1. Specifications — the default first stage. Takes a short, focused request, reads it against your project's specification, and breaks it into a handful of tickets. The Spec board shows every ticket as a card, from queued to done.
2. Ticket Scanner — the alternative first stage, for work that's already written up in your tracker: it pulls the tickets that match your filters. Choose between the two with the dropdown above the first stage.
3. Architecture — sets the rules each ticket's code has to follow — where things go, how they're named, which layer they belong to — so the project stays consistent as it grows.
4. Test Plan — plans the tests the ticket needs — the behaviour it asks for and the edge cases around it — then writes them so they fail until the work is done.
5. TDD Coding — writes the code that makes the tests pass, then tidies it up with the tests still green.
6. Improve — reviews the change and runs your project's own quality checks, rolling back anything that breaks them.
7. Documentation — writes up each ticket's change in the repository, adds a wiki entry if you've set one up, and updates any README the change made out of date.
8. Merge — the default landing: merges each finished ticket into your project's main branch as soon as it passes, without touching your own working copy.
9. Pull Request — the alternative landing, chosen from a dropdown on the same machine: each ticket's work stays on its own branch, so it lands through review instead. Each ticket can build on the one before it, or start fresh from your main branch when the tickets don't depend on each other.
10. Publish — once every ticket has run, makes the run's one trip to your Git host: after Merge it pushes your main branch, after Pull Request it pushes each ticket's branch and opens its pull request.
11. Assessment — rates the finished run's architecture for extensibility, testability and code smells.

II Brownfield

Brownfield is for maintaining a project that's already out in the world — fixing bugs and adding features to code people depend on. Its stages, in order:

1. Ticket Scanner — the default first stage: pulls the tickets that match your filters from your tracker.
2. Specifications — the alternative first stage, for work you'd rather describe yourself: it breaks your written request into tickets. Choose between the two with the dropdown above the first stage.
3. Triage — reads each ticket and works out whether it's a bug, a feature, or something else.
4. Context Retrieval — finds the repository the ticket belongs to and the branch the work should merge into.
5. Verify — confirms the bug really happens, or the feature is really missing, before any code is written. A ticket that can't be acted on gets a comment on the tracker explaining why; a refactor or an upgrade has nothing to confirm and goes straight through.
6. Architecture — looks for what the change should fold in: an existing pattern to reuse, duplication to unify, a tangled module to split.
7. Test Plan — plans the tests the ticket needs — the behaviour it asks for and the edge cases around it — then writes them so they fail until the work is done.
8. TDD Coding — writes the code that makes the tests pass, then tidies it up with the tests still green.
9. Improve — reviews the change and runs your project's own quality checks, rolling back anything that breaks them.
10. Documentation — writes up the ticket's change and adds a wiki entry if you've set one up.
11. Publish — pushes the ticket's branch and opens a pull request for it.

III Choosing between them

Choose by the stage your project is at, not by where the tickets come from — either workflow can start from your tracker or from a request you write.

• Run Greenfield when you're building something new. You describe what you want, Expecto Centum breaks it into tickets and keeps the project's structure consistent as it grows, and the finished work either merges as it goes or arrives as pull requests once the whole batch is done.
• Run Brownfield when the code is already published and people rely on it. Bug reports and feature requests arrive in your tracker, nothing changes until the problem is confirmed, and each ticket becomes its own pull request for your team to review.

IV Switch workflows

Pick the active workflow from the workflow picker on the right side of the dashboard, or from the dropdown at the top of Config → Workflow. The dashboard updates to show that workflow's stages, and its header names the workflow with a line on when to use it.