ci(coverage): turn on the reporting leg, and record that the 85% target is already met - #2243
Conversation
|
Warning Review limit reachedNext included review available in 57 minutes. View limit detailsLimit details: You’ve used the included review currently available. Your 84 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d7c42ccf32
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Hold: merge order matters. This must land after sync PR #2244, which carries the repaired Why: this PR turns on the coverage reporting leg. Until #2244 lands, this repo still has the old reporter, which renders an absent baseline as No conflict between them — #2244 touches other workflows plus #2244 is waiting on its Maint 71 delivery seal, which is normal: sync PRs merge fleet-wide in batches roughly twice a day (last: 2026-08-24T22:16Z). Nothing is stuck. Measured for reference: this repo is at 86.25%, against its configured floor of 60 — and the |
Without config/coverage-baseline.json, tools/coverage_trend.py reports baseline_status=absent and computes NO delta, and Maint Coverage Guard has nothing to compare against -- so a coverage regression here is currently undetectable. Set at MEASURED CURRENT (86.25%, Gate payload; reporting enabled by the held PR #2243), floored to 86, with warn_drop 1.0 absorbing run-to-run jitter. Deliberately not an aspiration: a baseline above reality is red on arrival and gets switched off, and one far below it can never fail. Both failure directions are live in this fleet right now -- Fine-Art-Archive carries 25 against a real 81.45%, Workflows carries 85 against a real 76.72%. Keyed `line`: coverage_trend.py and coverage_guard.py both accept `line` or `coverage`, with `line` taking precedence. That mismatch was itself a live defect until stranske/Workflows#3251. This is a ratchet, not a target: raise it as coverage rises. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
) Without config/coverage-baseline.json, tools/coverage_trend.py reports baseline_status=absent and computes NO delta, and Maint Coverage Guard has nothing to compare against -- so a coverage regression here is currently undetectable. Set at MEASURED CURRENT (86.25%, Gate payload; reporting enabled by the held PR #2243), floored to 86, with warn_drop 1.0 absorbing run-to-run jitter. Deliberately not an aspiration: a baseline above reality is red on arrival and gets switched off, and one far below it can never fail. Both failure directions are live in this fleet right now -- Fine-Art-Archive carries 25 against a real 81.45%, Workflows carries 85 against a real 76.72%. Keyed `line`: coverage_trend.py and coverage_guard.py both accept `line` or `coverage`, with `line` taking precedence. That mismatch was itself a live defect until stranske/Workflows#3251. This is a ratchet, not a target: raise it as coverage rises. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
Updated: the floor now moves in this PR too, 60 -> 86. The first commit here said the floor was deliberately left at 60 because raising one is a gate change that belongs with the baseline work rather than with the PR that first turns reporting on. #2245 has since set Folded in rather than opened as a second PR because it touches this same file and would have conflicted. The line also carried Still held from merge. This repo is the last one without the repaired reporter — its sync PR #2244 is blocked on |
d7c42cc to
3c41d5a
Compare
GitHub Actions
Inactive
|
Closer lane update (2026-08-26): prerequisite sync #2244 merged at Next: rebase this branch onto current |
…et is already met Only the REPORTING leg was off here: `coverage` defaults to true upstream, but `enable-soft-gate` defaults to false, so the Gate computed a coverage number on every run and discarded it -- no trend artifact, no hotspot table, and nothing for Maint Coverage Guard to read. Report-only by construction: coverage_trend.py runs with --soft and always exits 0, so this cannot fail a PR or block a merge. Measured 86.25% from this repo's own coverage payload on 2026-08-25. The floor here is 60 with the comment "Target: 85% - tracking issue to be created" -- that target is ALREADY MET, and has been, invisibly, for as long as reporting was off. A number nobody publishes cannot show you that you already succeeded. The floor stays at 60 in this change. Raising it is a gate change and belongs with the baseline work, not with turning reporting on; doing both at once would mean shipping a new red without ever having seen a green report. Sequenced deliberately AFTER stranske/Workflows#3251/#3253/#3254, which repaired the reporter: before those an absent baseline rendered as 0.00% and every run showed a large fake improvement. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Folded into this PR rather than opened separately, because a second PR would touch the same file and conflict with this one. The Gate carried `coverage-min: "60" # Target: 85% - tracking issue to be created` while measured coverage is 86.25%. Two things wrong with that line at once: the target it calls untracked was ALREADY MET, and the floor sat 26 points below reality, so it reported a pass on every input and could not have failed if coverage fell by a quarter. A number nobody publishes cannot tell you that you already succeeded. Sequenced deliberately, and the precondition is now met. The first commit on this branch said the floor was being left at 60 because raising a floor is a GATE change that belongs with the baseline work, not with the PR that first turns reporting on. #2245 has since set config/coverage-baseline.json at measured current, so that condition is satisfied and the floor moves here. 86 rather than 86.25 leaves the jitter tolerance where it belongs -- in the guard's warn_drop of 1.0 -- and matches the baseline file, so the soft gate's Status line and Maint Coverage Guard's comparison agree about this repo. The stale comment is removed with it. Leaving "tracking issue to be created" beside a met target would keep pointing a reader at work that does not exist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3c41d5a to
ccba0ed
Compare
GitHub Actions
Inactive
GitHub Actions
Inactive
|
Workflow state fingerprint for Agents Verifier. Do not edit. |
|
Closer disposition (2026-08-26): Agents Verifier compare mode completed with verdict skipped — no acceptance criteria or linked source issue on this coverage-infrastructure PR. Fingerprint-only state is terminal; no Provider Comparison PASS is expected. Chain finalized by closer batch sweep; no issue-closure debt remains. Workflow run: https://github.com/stranske/Portable-Alpha-Extension-Model/actions/runs/32949241184 |
1 participant
What
One line:
enable-soft-gate: trueon the Gate'sreusable-10-ci-pythoncall.Why
Only the reporting leg was off.
coveragedefaults totrueupstream, butenable-soft-gatedefaults tofalse— so the Gate computed a coverage number on every run and discarded it: nocoverage-trendartifact, no hotspot table, nothing for Maint Coverage Guard to read.The finding worth reading
This repo's Gate config carries:
Measured from its own coverage payload on 2026-08-25: 86.25%.
The 85% target is already met — and has been, invisibly, for as long as reporting was off. A number nobody publishes cannot show you that you already succeeded.
Risk: none
coverage_trend.pyruns with--softand always exits 0. It cannot fail a PR or block a merge.What this change does NOT do
The floor stays at 60. Raising it is a gate change and belongs with the baseline work, not with turning reporting on — doing both at once would mean shipping a new red without ever having seen a green report.
Sequencing
Deliberately after stranske/Workflows#3251, #3253 and #3254, which repaired the reporter. Before those, an absent baseline rendered as
0.00%and every run showed a large fake improvement.🤖 Generated with Claude Code