Severity: Low–Medium (guidance + maintenance)
Source: PR #5 review.
Two related gaps:
1. No guidance on WHEN to scope
Docs say the :module suffix is "optional" but never say when a user should use it. A first user can't tell whether to scope every e2e (cost: N CI splits) or none.
2. Manual CI drift
spec-tracer's own ci.yml hand-lists one behave … -o reports/e2e-MODULE.json per module. Every new @require-e2e:X stays silently MISSING until someone also edits CI. Nothing catches the gap between declared modules and CI splits.
Expected
- README/usage: a 2-line note on when to scope (e.g. "scope when a result only proves one subsystem; leave unscoped when it exercises the whole flow / multiple modules").
- A guard (or at least a doc step) so adding
@require-e2e:X without a matching CI split is caught — e.g. a test asserting every module-scoped requirement has a corresponding config module key + CI artifact, or a generated list of required modules printed during the self-report run.
Related: #2 (module validation).
Severity: Low–Medium (guidance + maintenance)
Source: PR #5 review.
Two related gaps:
1. No guidance on WHEN to scope
Docs say the
:modulesuffix is "optional" but never say when a user should use it. A first user can't tell whether to scope every e2e (cost: N CI splits) or none.2. Manual CI drift
spec-tracer's ownci.ymlhand-lists onebehave … -o reports/e2e-MODULE.jsonper module. Every new@require-e2e:Xstays silently MISSING until someone also edits CI. Nothing catches the gap between declared modules and CI splits.Expected
@require-e2e:Xwithout a matching CI split is caught — e.g. a test asserting every module-scoped requirement has a corresponding config module key + CI artifact, or a generated list of required modules printed during the self-report run.Related: #2 (module validation).