docs(guides): adding-a-feature reflects manifest-first ordering
This commit is contained in:
@@ -25,6 +25,21 @@ per-use-case patterns below.
|
||||
|
||||
---
|
||||
|
||||
## Workflow ordering
|
||||
|
||||
For any new use case, follow these four steps in order:
|
||||
|
||||
1. **Manifest entry** — declare the use case in `src/feature.manifest.ts` with its `mutates` flag and (initially empty) `audits` / `publishes` / `consumes` arrays.
|
||||
2. **Contracts** — export `xInputSchema`, `xOutputSchema`, and the `IXUseCase` type alias from the use-case file. Factory body starts as `throw new Error("not implemented")`.
|
||||
3. **Tests (red)** — write the failing test that exercises the contract via the factory + a mock repository.
|
||||
4. **Implementation (green)** — fill the factory body until the tests pass.
|
||||
|
||||
The `feature-must-have-manifest` ESLint rule will catch step 1 omissions; `usecase-must-have-test-file` catches step 3. The boot assertion (`assertFeatureConformance` at the tail of `bindProductionX`) catches forgotten wrappers at startup.
|
||||
|
||||
For the fast path, run `pnpm turbo gen feature <name>` — the generator emits the manifest + contracts + bind-production with the assertion already wired in.
|
||||
|
||||
---
|
||||
|
||||
## 1. Overview
|
||||
|
||||
Every feature package owns:
|
||||
|
||||
Reference in New Issue
Block a user