ci(coverage): ratchet line floor from 97 to 100#561
Merged
Conversation
With wave 1-3 closed and scoped line coverage at 100 %, the 3 pp safety buffer below the measured value no longer matches the "100 % rule" stated in README. Pin the floor at 100 so any regression — including a single accidentally-uncovered line — fails CI immediately. When a future change genuinely needs to drop below 100 % (e.g. a Flutter SDK update that re-counts a defensive branch), use the `coverage:lower-floor` PR label so the regression is visible in the PR list rather than silently smuggled in. Functions floor stays at 50 (placeholder, no FN records emitted).
TaprootFreak
added
the
tier3:full
3 tasks
TaprootFreak
added a commit
that referenced
this pull request
May 23, 2026
## Summary All three primary CI workflows (`pull-request.yaml`, `tier3-handbook.yaml`, `bitbox-simulator.yml`) were filtered with `pull_request.branches: [develop]`. That meant stacked PRs (e.g. `feature → integration → develop`) never triggered CI on the lower stack levels — every regression was only caught once the stack collapsed to a develop PR. Concretely visible on PR #561 (`ci/coverage-floor-100` → `feat/visual-regression-pilot`): zero check-runs. This PR drops the `branches:` filter on all three so every PR fires CI regardless of target branch. The actual cost controls (draft-gate, `tier3:full` label, `paths:` filter on bitbox-simulator) are unchanged. ## What changes - **`pull-request.yaml`** — `branches: [develop]` removed from `pull_request:`. Block comment rewritten to explain why the branch filter is gone and what the remaining gates are (draft-gate, concurrency). `push: develop` kept as the authoritative post-merge run. - **`tier3-handbook.yaml`** — `branches: [develop]` removed from `pull_request:`. Block comment updated: "label gate is the cost control, not the branch filter". `push: develop` kept. - **`bitbox-simulator.yml`** — `branches: [develop]` removed from `pull_request:`. Comment rewritten: "`paths:` filter is the real cost control". No `push:` trigger here, unchanged. ## What stays the same - Draft PRs still skip every job via `if: github.event.pull_request.draft == false` guards. - Tier 3 still opt-in via `tier3:full` label. - BitBox simulator still path-gated to hardware_wallet / wallet / bitbox files. - `push: develop` post-merge verification on the two workflows that had it. - Concurrency groups unchanged — stacked-PR runs land in different groups by PR number, so they don't cancel each other. ## Test plan - [x] `python3 -c "import yaml; …"` — all three YAML files parse - [ ] CI green on this PR itself (which now means it triggers on `pull_request` against develop AS WELL as on any future stacked PR) - [ ] After merge: PR #561 (currently stacked on `feat/visual-regression-pilot`) should trigger CI on the next push or synchronize event
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
After PR #539 closed wave 1-3 and brought scoped line coverage to 100.0 % (4 751 / 4 751), the 3 pp safety buffer below the measured value no longer matches the "100 % rule" stated in
README.md. Pin the floor at 100 so any regression — including a single accidentally-uncovered line — fails CI immediately.When a future change genuinely needs to drop below 100 % (e.g. a Flutter SDK update that re-counts a defensive branch), use the
coverage:lower-floorPR label so the regression is visible in the PR list rather than silently smuggled in.Functions floor stays at 50 (placeholder,
flutter test --coveragestill emits no FN records).Stacked on
feat/visual-regression-pilotso it lands together with the visual-regression scale-out work. When that branch merges, this PR retargets todevelopautomatically (orgh pr edit 560 --base develop).Test plan
Coverage Floor Gatepasses at 100.0 % == 100 floor