Add product quality gates and milestone acceptance

This commit is contained in:
Emil Shanaty
2026-10-28 00:17:37 +03:00
parent 2309fda7b7
commit 4e1cc29874
10 changed files with 180 additions and 12 deletions
+7
View File
@@ -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}}
+5
View File
@@ -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}}/`.
+13
View File
@@ -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.