1.7 KiB
1.7 KiB
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.