68 lines
1.7 KiB
Markdown
68 lines
1.7 KiB
Markdown
# Public issue template 005
|
|
|
|
## Title
|
|
|
|
[qa] Define coverage threshold policy
|
|
|
|
## Labels
|
|
|
|
`qa`, `coverage`, `policy`
|
|
|
|
## Purpose
|
|
|
|
Define a conservative coverage threshold policy after the baseline is stable and
|
|
reviewed.
|
|
|
|
## Background
|
|
|
|
Coverage workflow exists for visibility, but threshold enforcement is not
|
|
enabled yet. Premature thresholds can create noisy failures before the baseline
|
|
is understood.
|
|
|
|
## Scope
|
|
|
|
- Review current coverage baseline.
|
|
- Identify crates or modules where thresholds are meaningful.
|
|
- Propose a staged threshold policy.
|
|
- Document exceptions and review cadence.
|
|
|
|
## Non-goals
|
|
|
|
- No immediate hard threshold without baseline review.
|
|
- No claim that coverage proves absence of defects.
|
|
- No runtime, API or UI changes.
|
|
|
|
## Acceptance criteria
|
|
|
|
- Baseline coverage summary is reviewed.
|
|
- Initial threshold proposal is documented.
|
|
- Exceptions are documented.
|
|
- Enforcement plan is staged and reversible.
|
|
|
|
## Evidence required
|
|
|
|
- Coverage workflow artifact reference.
|
|
- Baseline review notes.
|
|
- Proposed threshold values.
|
|
- Rationale for exclusions or delayed enforcement.
|
|
|
|
## Safety/privacy guardrails
|
|
|
|
- Do not publish private test data or production logs.
|
|
- Keep coverage artifacts free of secrets and customer identifiers.
|
|
- Avoid copying sensitive paths into public issue text.
|
|
|
|
## Registry-positioning guardrails
|
|
|
|
- Coverage visibility is quality evidence, not registry release evidence.
|
|
- Threshold policy must not imply certification.
|
|
- GitHub remains public mirror validation only.
|
|
|
|
## Checklist
|
|
|
|
- [ ] Review coverage baseline.
|
|
- [ ] Identify meaningful threshold scope.
|
|
- [ ] Document proposed values.
|
|
- [ ] Document exclusions.
|
|
- [ ] Decide when enforcement can start.
|