Workflows
A workflow is a pre-composed chain of operators. The entry reads the when of every example first; a match is run as written, and no match means composing a chain under the same rules scripts/validate-workflows.mjs enforces on these files.
| Workflow | Steps | Ends | When |
|---|---|---|---|
backend-feature | 7 | git.publish | Server behaviour, an API contract, persistence or a job changes for one business feature; the architecture is decided first and the promise is reconciled after the code lands. This chain writes no surface, so it carries no frontend.surface.audit and no uat.verify: uat.verify requires a frontend-surface-audit input and a bound fe route, and neither exists here. A feature whose promise reaches a person through a screen is not this workflow — it is full-feature, which walks the journey before it publishes. |
content-unit | 1 | user | One curriculum unit needs its brief, its language editions, its code tracks and an independent review; publishing to MinIO stays with a person. |
frontend-new-surface | 10 | git.publish | A page, flow, or surface that does not exist yet must be created; the person named the target route and its business promise is known or will be decided first. |
frontend-reconstruct | 9 | git.publish | An existing surface is rebuilt: composition, region order, hierarchy or responsive structure change while business facts, behaviour and API semantics stay. |
frontend-refine | 9 | git.publish | The approved structure of a surface stays; only typography, spacing, labels, controls, states, tokens or Grammar conformance inside it are repaired. |
frontend-with-uat | 9 | git.publish | A frontend change must also be walked by a real person’s journey before it is published; a person asked for the UAT run by name. |
full-feature | 12 | git.publish | One feature needs both a backend contract and a new frontend surface; backend implementation and frontend direction run side by side after the architecture is decided. |
release | 3 | release.deploy | A published head must reach production: verify it, deploy it, and prove the steady state; recovery and rollback are inside release.deploy. |
staging-uat | 7 | user | A delivery that is already published must be verified on another stack before it is released: the same head is observed and walked there, and the chain ends with the two receipts in a person’s hands rather than with a deployment. |