Add product quality gates and milestone acceptance
This commit is contained in:
@@ -12,6 +12,13 @@ Scope is checked by the lead with the skill's `scripts/audit-scope.mjs`; workers
|
||||
## Non-goals
|
||||
- {{What must not change or be attempted.}}
|
||||
|
||||
## Quality profile
|
||||
- Profile: {{prototype / product}}
|
||||
- Performance budget: {{p95 frame time / latency / startup / memory, or n/a}}
|
||||
- Baseline version/scenarios: {{version + 3–5 step scenario, or none}}
|
||||
- User acceptance owner: {{name / pending}}
|
||||
- Release build command: {{command or n/a}}
|
||||
|
||||
## Domain profile
|
||||
- Domain: {{software / research / content / data / design / operations}}
|
||||
- Primary artifacts: {{paths, sections, datasets, renders, services}}
|
||||
|
||||
@@ -37,6 +37,11 @@ Role: worker | Wave: {{n}} | Depends on: {{ids or —}} | Effort: {{S/M/L}}
|
||||
2. `{{citation check / metric / render at sizes}}` → {{expected result}}
|
||||
3. Every criterion must have evidence a fresh verifier can reproduce.
|
||||
|
||||
If the quality profile is `product` and this task touches UI/interaction, also record:
|
||||
- release-build p95 frame time and input latency at the target size;
|
||||
- the 3–5 step user scenario;
|
||||
- baseline comparison (new must not be worse).
|
||||
|
||||
## Report
|
||||
`.swarm/reports/{{ID}}.json` per `.swarm/report.schema.json`; status `done|partial|blocked|failed`.
|
||||
Keep the report to summary + evidence lines; raw logs go to `.swarm/tmp/{{ID}}/`.
|
||||
|
||||
@@ -32,8 +32,21 @@ For GUI products, run the app in your own isolated Xvfb/display (never a shared
|
||||
|
||||
Computer-use (mouse/keyboard) is an optional last-resort tier: one agent, disposable desktop/VM, after deterministic checks, never parallel, never the sole evidence. Prefer app screenshot mode or scripted input.
|
||||
|
||||
## Product quality (product profile only)
|
||||
Verify the release/optimized build, not a debug build:
|
||||
- p50/p95 frame time at the target size, input-to-visible latency, startup, idle CPU/memory;
|
||||
- the 3–5 step real user scenario, not just a screenshot;
|
||||
- baseline comparison on the same scenario (regression = fail);
|
||||
- report `not_run` if these were not measured.
|
||||
|
||||
A technical pass is **not** product acceptance. The user still runs the artifact and gives an explicit
|
||||
verdict (usable / usable with issues / not usable). Do not mark the product gate `pass` on the user's
|
||||
behalf.
|
||||
|
||||
## Verdict
|
||||
`pass` / `pass_with_risks` / `fail` — with the top risks and exact repro commands.
|
||||
For product-profile work, `pass` requires functional + measured performance + UX scenario + baseline;
|
||||
otherwise use `pass_with_risks` with missing gates named, or `not_run`.
|
||||
|
||||
## Report
|
||||
Keep the review to findings + commands + evidence (target 5–8k tokens); raw logs stay in `.swarm/tmp/`. Review the diff and affected checks, not the whole repository.
|
||||
|
||||
Reference in New Issue
Block a user