[FEATURE] Coverage Phase 4: Steady-state 80% / 70%

[sergio-sisternes-epam]

Is your feature request related to a problem? Please describe.
After Phase 3, integration is gated at 55% -- well below the 70%
steady-state target. The coverage policy is not documented for
contributors.

Describe the solution you'd like
Raise the integration gate to the 70% steady-state target and
document the coverage policy in CONTRIBUTING.md.

Changes

1. Confirm unit fail_under remains at 80
2. Raise integration coverage gate to 70% in ci-integration.yml
3. Document coverage policy in CONTRIBUTING.md:
   • Unit: 80% hard gate
   • Integration: 70% hard gate
   • Ratchet rule for future raises
4. Add lowest-covered-files report to help contributors target gaps

Describe alternatives you've considered

• Higher targets (85%/75%) -- could be adopted later via the ratchet
  rule if actual coverage justifies it.

Additional context
Parent: #1398 -- Phase 4 of the progressive coverage strangler-fig ratchet.

This is the steady-state configuration. After this phase, coverage
gates only move upward via the ratchet rule: if actual exceeds gate
by 5+ points, raise gate to actual - 3.

Acceptance criteria

• Both gates pass in CI at steady-state levels
• CONTRIBUTING.md documents the coverage policy and ratchet rule
• Contributors can see which files need coverage via CI summary

[github-actions]

Triage decision

accept

Proposed labels

area/ci-cd
area/testing
area/docs-site
type/feature
status/accepted

Milestone

null

Suggested next action

Raise the integration coverage gate to 70% in the CI pipeline and add the coverage policy section to CONTRIBUTING.md in a single PR that satisfies all four acceptance criteria.

Suggested issue comment

Thanks for the clear acceptance criteria, `@sergio-sisternes-epam`. Phase 4 is the right steady-state target: 80% unit / 70% integration with a documented ratchet rule.

This issue is accepted. A few notes from triage:
- The `quality` label on this issue is not in the APM label taxonomy. A maintainer should decide whether to retain it as a free-form label or remove it.
- `area/docs-site` is added because this issue explicitly requires "Document coverage policy in CONTRIBUTING.md." The implementing PR should include that docs work -- the coverage policy section should state the gate values and the ratchet rule once, then cross-reference rather than embed the full phase plan.
- No milestone is assigned at triage: this phase depends on Phases 2 and 3 landing first. The implementing PR can carry the milestone once the sequencing is confirmed.

Next step: confirm Phases 2 and 3 are in-flight or done, then open a PR that raises the integration gate and adds the CONTRIBUTING.md coverage policy section.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

Phase 4 is the steady-state configuration. Raising the integration gate from 55% to 70% plus CONTRIBUTING.md documentation is excellent contributor ergonomics -- contributors will know exactly why CI fails and what the ratchet rule means before they encounter it. The lowest-covered-files report adds actionable guidance rather than a bare pass/fail. All four acceptance criteria are concrete and verifiable. No UX concerns.

Supply Chain Security Expert -- Risk-Surface Reviewer

No risk-surface implication. This phase changes CI YAML gate thresholds and adds a CONTRIBUTING.md section. No lockfile, marketplace, MCP config, signing, auth, or download paths are touched. No theme/security or theme/governance label is warranted.

OSS Growth Hacker -- Contributor-Tone Reviewer

Not activated -- author is an established collaborator (COLLABORATOR association) and this is a CI quality improvement with no conversion-surface impact.

Python Architect -- Architecture Reviewer

Not activated -- CI threshold tuning and CONTRIBUTING.md documentation require no cross-cutting Python architecture decision. The implementation is two CI YAML edits and one documentation section.

Doc Writer -- Documentation Reviewer

Doc work is explicitly required: acceptance criterion 3 is "Document coverage policy in CONTRIBUTING.md." The area/docs-site label is warranted. The CONTRIBUTING.md coverage section should follow PROSE principles: state the gate values (80% unit, 70% integration) and the ratchet rule once, then link to any CI guide page for background rather than repeating the full phase plan. Use consistent terminology with the parent issue (#1398). If a CONTRIBUTING.md file does not exist yet, create a minimal one rather than embedding coverage policy in a CI YAML comment.

APM CEO -- Triage Arbiter

Phase 4 closes the strangler-fig ratchet at steady-state. The proposal is well-scoped: two CI YAML edits, one CONTRIBUTING.md section, and a lowest-covered-files report. Decision: accept. Pure infra (area/ci-cd, area/testing; no product surface implication), so no mega-theme label is required. No milestone assigned at triage -- this phase is sequentially dependent on Phases 2 and 3; the implementing PR should carry the milestone once sequencing is confirmed.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": null,
  "areas": ["area/ci-cd", "area/testing", "area/docs-site"],
  "type": "type/feature",
  "status": "status/accepted",
  "priority": null,
  "preserved_labels": [],
  "milestone": null,
  "next_action": "Raise the integration coverage gate to 70% in the CI pipeline and add the coverage policy section to CONTRIBUTING.md in a single PR that satisfies all four acceptance criteria.",
  "comment_markdown": "Thanks for the clear acceptance criteria, `@sergio-sisternes-epam`. Phase 4 is the right steady-state target: 80% unit / 70% integration with a documented ratchet rule.\n\nThis issue is accepted. A few notes from triage:\n- The `quality` label is not in the APM label taxonomy. A maintainer should decide whether to retain it or remove it.\n- `area/docs-site` is added because this issue explicitly requires CONTRIBUTING.md documentation. The implementing PR should include that docs work.\n- No milestone is assigned at triage: this phase depends on Phases 2 and 3 landing first.\n\nNext step: confirm Phases 2 and 3 are in-flight or done, then open a PR that raises the integration gate and adds the CONTRIBUTING.md coverage policy section."
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Note

🔒 Integrity filter blocked 26 items

The following items were blocked because they don't meet the GitHub integrity level.

• #1120 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1122 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1130 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1138 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1156 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1157 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1209 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1225 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1231 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1266 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1273 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1293 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1295 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1300 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1326 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1329 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• ... and 10 more items

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Triage Panel · ● 999.8K · ◷