chore(coverage): drop client branches threshold 80→75 to unblock CI #559

Merged

marcel merged 2 commits from worktree-chore+issue-556-drop-client-branches-coverage-gate into main 2026-05-14 10:16:52 +02:00

Conversation 7 Commits 2 Files Changed 2 +94 -1

marcel commented 2026-05-14 08:55:46 +02:00

Owner

Copy Link

Summary

• Sets branches: 75 (was 80) in frontend/vitest.client-coverage.config.ts — the only production change
• Adds inline comment pointing to ADR-013 and #496 so the asymmetry is self-explaining
• Creates docs/adr/013-client-branches-coverage-threshold.md documenting rationale, baseline, and ratchet rule

Context

The client-project branches figure sits at ~75%, below the 80% gate. Per #496, closing this gap is a long-tail grind driven by Istanbul's parent/child denominator coupling — each new child coverage improvement can drag parent percentages down. The 80% gate has been blocking CI (including the birpc-race coverage-flake-probe) without corresponding benefit.

The drop to 75% matches the current measured state. Lines/functions/statements stay at 80% because they don't suffer the same accounting problem. The ADR captures the ratchet rule: gate rises by 3pp each time main sustains threshold + 3pp for ≥30 consecutive days — direction is up-only.

Test plan

• CI unit-tests job passes with branches: 75
• coverage-flake-probe.yml (workflow_dispatch) succeeds end-to-end
• Diff contains only frontend/vitest.client-coverage.config.ts thresholds block and docs/adr/013-client-branches-coverage-threshold.md — nothing else

Closes #556

🤖 Generated with Claude Code

## Summary - Sets `branches: 75` (was `80`) in `frontend/vitest.client-coverage.config.ts` — the only production change - Adds inline comment pointing to ADR-013 and #496 so the asymmetry is self-explaining - Creates `docs/adr/013-client-branches-coverage-threshold.md` documenting rationale, baseline, and ratchet rule ## Context The client-project branches figure sits at ~75%, below the 80% gate. Per #496, closing this gap is a long-tail grind driven by Istanbul's parent/child denominator coupling — each new child coverage improvement can drag parent percentages down. The 80% gate has been blocking CI (including the birpc-race `coverage-flake-probe`) without corresponding benefit. The drop to 75% matches the current measured state. Lines/functions/statements stay at 80% because they don't suffer the same accounting problem. The ADR captures the ratchet rule: gate rises by 3pp each time `main` sustains `threshold + 3pp` for ≥30 consecutive days — direction is up-only. ## Test plan - [ ] CI `unit-tests` job passes with `branches: 75` - [ ] `coverage-flake-probe.yml` (workflow_dispatch) succeeds end-to-end - [ ] Diff contains only `frontend/vitest.client-coverage.config.ts` thresholds block and `docs/adr/013-client-branches-coverage-threshold.md` — nothing else Closes #556 🤖 Generated with [Claude Code](https://claude.com/claude-code)

marcel added 1 commit 2026-05-14 08:55:46 +02:00

chore(coverage): drop client branches threshold 80→75, add ADR-013 ... 118100e58d

Branches gate was blocking CI at 75% measured coverage. The 80% floor
suffers Istanbul parent/child denominator coupling (long-tail grind, per
#496) that makes the remaining gap disproportionately costly to close.
Drop branches to 75 to match current state; leave lines/functions/
statements at 80. ADR-013 documents the rationale and the ratchet rule
for raising the gate back incrementally.

Closes #556

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

marcel commented 2026-05-14 08:56:42 +02:00

Author

Owner

Copy Link

🏛️ Markus Keller — Senior Application Architect

Verdict: ✅ Approved

What I checked

This is a CI-gate adjustment with an ADR — exactly the right shape for lowering a quality bar deliberately. The rationale (long-tail-grind in Istanbul branch accounting, parent/child denominator coupling) is real and matches what I reviewed in #496.

Observations

ADR quality is good. The "Why this layer is different" section correctly distinguishes browser-mode component coverage from backend unit/integration test coverage. That distinction prevents cargo-culting 75% into the backend suite — it needs to be there explicitly, and it is.

ADR number 013 is correct. The duplicate-012 collision (012-browser-test-mocking-strategy.md and 012-nsenter-for-host-service-management-in-ci.md) is a pre-existing issue that this PR correctly treats as out of scope. It should be addressed in a separate cleanup PR.

Ratchet rule is concrete. "3pp when 3-PR-average sustains threshold+3pp for ≥30 days, direction up-only" is observable and unambiguous — far better than a free-text "revisit every 6 months."

Security-relevant uncovered components are called out. Listing login/forgot-password/reset-password/register as priority targets for ratchet-up work is the right framing. It makes the gap legible without overstating the risk.

No documentation update required. This PR touches no backend packages, no routes, no DB schema, no infrastructure components — none of the doc-update triggers in my review checklist apply.

One minor note

The ADR baseline says ~75% (approximate). When CI runs confirm the exact figure, consider adding a follow-up comment to the ADR or the issue with the precise number. The tilde is honest but the ratchet arithmetic works better with a precise floor.

Summary

Correctly scoped, correctly documented, correctly numbered. The 75% gate = 0pp headroom is acknowledged in the Consequences section. CI will be the real test — approve it there on green.

## 🏛️ Markus Keller — Senior Application Architect **Verdict: ✅ Approved** ### What I checked This is a CI-gate adjustment with an ADR — exactly the right shape for lowering a quality bar deliberately. The rationale (long-tail-grind in Istanbul branch accounting, parent/child denominator coupling) is real and matches what I reviewed in #496. ### Observations **ADR quality is good.** The "Why this layer is different" section correctly distinguishes browser-mode component coverage from backend unit/integration test coverage. That distinction prevents cargo-culting 75% into the backend suite — it needs to be there explicitly, and it is. **ADR number 013 is correct.** The duplicate-012 collision (`012-browser-test-mocking-strategy.md` and `012-nsenter-for-host-service-management-in-ci.md`) is a pre-existing issue that this PR correctly treats as out of scope. It should be addressed in a separate cleanup PR. **Ratchet rule is concrete.** "3pp when 3-PR-average sustains threshold+3pp for ≥30 days, direction up-only" is observable and unambiguous — far better than a free-text "revisit every 6 months." **Security-relevant uncovered components are called out.** Listing login/forgot-password/reset-password/register as priority targets for ratchet-up work is the right framing. It makes the gap legible without overstating the risk. **No documentation update required.** This PR touches no backend packages, no routes, no DB schema, no infrastructure components — none of the doc-update triggers in my review checklist apply. ### One minor note The ADR baseline says `~75%` (approximate). When CI runs confirm the exact figure, consider adding a follow-up comment to the ADR or the issue with the precise number. The tilde is honest but the ratchet arithmetic works better with a precise floor. ### Summary Correctly scoped, correctly documented, correctly numbered. The 75% gate = 0pp headroom is acknowledged in the Consequences section. CI will be the real test — approve it there on green.

marcel commented 2026-05-14 08:56:53 +02:00

Author

Owner

Copy Link

👨‍💻 Felix Brandt — Senior Fullstack Developer

Verdict: ✅ Approved

What I checked

One config line changed, one ADR created — no production code, no test code. TDD red/green cycle does not apply here; the gate itself is the test, and CI is its execution environment.

Code review

vitest.client-coverage.config.ts:47 — the change is exactly right:

// branches at 75 — long-tail parent/child accounting grind; see docs/adr/013-client-branches-coverage-threshold.md and #496
branches: 75,

The inline comment is the right kind of why comment — it explains the asymmetry that would otherwise invite a future "let me normalize this back to 80" edit. Six months from now a developer sees three values at 80 and one at 75, reads the comment, follows the ADR link, and understands immediately. No comment needed on the other three values — they're symmetric and self-explaining.

docs/adr/013-client-branches-coverage-threshold.md — structure and content are solid:

• Context, Decision, Ratchet Rule, Non-goals, Consequences, References — all present
• "Why this layer is different" section prevents future scope creep into backend thresholds
• Security-relevant uncovered components are explicitly listed — exactly what I'd want to see before running ratchet-up work
• The ratchet rule is precise enough to act on without further discussion

One small nit (non-blocking)

The ADR's baseline says ~75%. The tilde is honest (the run wasn't completed locally before this PR) but the ratchet rule hinges on the exact number. When CI confirms the figure, it would be cleaner to update the tilde to the exact percentage and commit SHA. Not a blocker — the ADR notes the approximate nature and that's acceptable.

Summary

Clean, minimal, well-documented. Exactly how a CI gate adjustment should be done.

## 👨‍💻 Felix Brandt — Senior Fullstack Developer **Verdict: ✅ Approved** ### What I checked One config line changed, one ADR created — no production code, no test code. TDD red/green cycle does not apply here; the gate itself is the test, and CI is its execution environment. ### Code review **`vitest.client-coverage.config.ts:47`** — the change is exactly right: ```ts // branches at 75 — long-tail parent/child accounting grind; see docs/adr/013-client-branches-coverage-threshold.md and #496 branches: 75, ``` The inline comment is the right kind of *why* comment — it explains the asymmetry that would otherwise invite a future "let me normalize this back to 80" edit. Six months from now a developer sees three values at 80 and one at 75, reads the comment, follows the ADR link, and understands immediately. No comment needed on the other three values — they're symmetric and self-explaining. **`docs/adr/013-client-branches-coverage-threshold.md`** — structure and content are solid: - Context, Decision, Ratchet Rule, Non-goals, Consequences, References — all present - "Why this layer is different" section prevents future scope creep into backend thresholds - Security-relevant uncovered components are explicitly listed — exactly what I'd want to see before running ratchet-up work - The ratchet rule is precise enough to act on without further discussion ### One small nit (non-blocking) The ADR's baseline says `~75%`. The tilde is honest (the run wasn't completed locally before this PR) but the ratchet rule hinges on the exact number. When CI confirms the figure, it would be cleaner to update the tilde to the exact percentage and commit SHA. Not a blocker — the ADR notes the approximate nature and that's acceptable. ### Summary Clean, minimal, well-documented. Exactly how a CI gate adjustment should be done.

marcel commented 2026-05-14 08:57:05 +02:00

Author

Owner

Copy Link

🔧 Tobias Wendt — DevOps & Platform Engineer

Verdict: ⚠️ Approved with concerns

What I checked

CI workflows, threshold change, and the headroom arithmetic.

Observations

The change is correct and minimal. Only two files touched: the config and the ADR. No workflow files modified, no Compose changes, no secrets involved. Clean diff.

The flake-probe concern (from original review) is addressed. coverage-flake-probe.yml is not modified — it remains a diagnostic tool for the birpc race, not a coverage enforcer. The threshold check happens inside npm run test:coverage; the probe inherits the new gate value automatically. That's the right design.

Blocker-level concern: 0pp headroom

The original issue proposed 80 → 70 (7pp headroom) specifically to absorb coverage variance across the 20-cell matrix. This PR ships 80 → 75 with the baseline at ~75%, meaning zero headroom.

This is a deliberate choice by the maintainer and I understand the reasoning, but the operational risk is real:

• If the 20-cell probe matrix produces even one cell at 74.8%, that cell will fail on the coverage gate rather than on the birpc race it's meant to detect — and the probe will report a false positive
• Istanbul coverage is not perfectly deterministic across runs; small variance (±0.5–1%) is normal in browser-mode testing
• With 0pp margin, the first PR that adds any component with uncovered branches could drop below 75% and re-block CI

Recommendation: Run the flake probe once on this branch before merging. Look at the per-cell branches percentage across all 20 cells. If any cell comes in below 75.5%, lower the gate to 74% or 73% to give a real margin. The ADR already documents the ratchet rule — a 74% initial floor ratchets up exactly the same way.

If the maintainer has measured 75% and is confident it's stable, this concern is acknowledged and accepted. The ADR's Consequences section does call it out ("near-zero headroom"), which is the right level of honesty.

No other concerns

• No workflow deprecations introduced
• No secrets or credentials touched
• The coverage-flake-probe.yml single-responsibility is preserved

## 🔧 Tobias Wendt — DevOps & Platform Engineer **Verdict: ⚠️ Approved with concerns** ### What I checked CI workflows, threshold change, and the headroom arithmetic. ### Observations **The change is correct and minimal.** Only two files touched: the config and the ADR. No workflow files modified, no Compose changes, no secrets involved. Clean diff. **The flake-probe concern (from original review) is addressed.** `coverage-flake-probe.yml` is not modified — it remains a diagnostic tool for the birpc race, not a coverage enforcer. The threshold check happens inside `npm run test:coverage`; the probe inherits the new gate value automatically. That's the right design. ### Blocker-level concern: 0pp headroom The original issue proposed `80 → 70` (7pp headroom) specifically to absorb coverage variance across the 20-cell matrix. This PR ships `80 → 75` with the baseline at `~75%`, meaning **zero headroom**. This is a deliberate choice by the maintainer and I understand the reasoning, but the operational risk is real: - If the 20-cell probe matrix produces even one cell at 74.8%, that cell will fail on the coverage gate rather than on the birpc race it's meant to detect — and the probe will report a false positive - Istanbul coverage is not perfectly deterministic across runs; small variance (±0.5–1%) is normal in browser-mode testing - With 0pp margin, the first PR that adds any component with uncovered branches could drop below 75% and re-block CI **Recommendation**: Run the flake probe once on this branch before merging. Look at the per-cell branches percentage across all 20 cells. If any cell comes in below 75.5%, lower the gate to 74% or 73% to give a real margin. The ADR already documents the ratchet rule — a 74% initial floor ratchets up exactly the same way. If the maintainer has measured 75% and is confident it's stable, this concern is acknowledged and accepted. The ADR's Consequences section does call it out ("near-zero headroom"), which is the right level of honesty. ### No other concerns - No workflow deprecations introduced - No secrets or credentials touched - The `coverage-flake-probe.yml` single-responsibility is preserved

marcel commented 2026-05-14 08:57:16 +02:00

Author

Owner

Copy Link

🔒 Nora "NullX" Steiner — Application Security Engineer

Verdict: ✅ Approved

What I checked

Security surface of the change and the ADR's treatment of security-relevant coverage gaps.

Findings

No security regression introduced. This PR touches:

• One CI configuration value (branches: 75)
• One ADR file (documentation only)

No production code paths changed. No test files removed. No skipIf guards added. No exclude-list growth. The diff is exactly what it should be.

The ADR's security treatment is correct. The "Security-relevant uncovered components" section correctly identifies and lists:

• src/routes/login/+page.svelte
• src/routes/forgot-password/+page.svelte
• src/routes/reset-password/+page.svelte
• src/routes/register/+page.svelte

The framing is accurate: "lowering the gate does not create this gap — it makes the existing state legible." These components were already uncovered before this PR. The ADR makes the debt visible and names the priority order for ratchet-up work, which is the right approach.

Backend test coverage gates are explicitly excluded in the Non-goals section. Backend @RequirePermission enforcement tests, auth-cookie handling, and permission boundary tests are tested at a different layer with different tooling. Their 80% gate is untouched.

One observation

When the ratchet-up work begins (tracked in #496), the auth pages listed above should be first in line. Branch coverage on login/password-reset flows is where authentication regression risk lives. A missed {#if} branch on an error state could hide a case where the login form silently fails open. That's not a blocker for this PR — the gap exists today regardless of the gate value — but it should be the first item on the #496 ratchet plan.

## 🔒 Nora "NullX" Steiner — Application Security Engineer **Verdict: ✅ Approved** ### What I checked Security surface of the change and the ADR's treatment of security-relevant coverage gaps. ### Findings **No security regression introduced.** This PR touches: - One CI configuration value (`branches: 75`) - One ADR file (documentation only) No production code paths changed. No test files removed. No `skipIf` guards added. No exclude-list growth. The diff is exactly what it should be. **The ADR's security treatment is correct.** The "Security-relevant uncovered components" section correctly identifies and lists: - `src/routes/login/+page.svelte` - `src/routes/forgot-password/+page.svelte` - `src/routes/reset-password/+page.svelte` - `src/routes/register/+page.svelte` The framing is accurate: "lowering the gate does not create this gap — it makes the existing state legible." These components were already uncovered before this PR. The ADR makes the debt visible and names the priority order for ratchet-up work, which is the right approach. **Backend test coverage gates are explicitly excluded** in the Non-goals section. Backend `@RequirePermission` enforcement tests, auth-cookie handling, and permission boundary tests are tested at a different layer with different tooling. Their 80% gate is untouched. ### One observation When the ratchet-up work begins (tracked in #496), the auth pages listed above should be first in line. Branch coverage on login/password-reset flows is where authentication regression risk lives. A missed `{#if}` branch on an error state could hide a case where the login form silently fails open. That's not a blocker for this PR — the gap exists today regardless of the gate value — but it should be the first item on the #496 ratchet plan.

marcel commented 2026-05-14 08:57:28 +02:00

Author

Owner

Copy Link

🧪 Sara Holt — QA Engineer & Test Strategist

Verdict: ⚠️ Approved with concerns

Context on my usual stance

I quote 80% branch coverage as a floor in most contexts. I am not contradicting that standard here — the ADR's "Why this layer is different" section correctly explains why browser-mode component coverage (Svelte template branches: class bindings, {#if} guards, empty/error state toggles) has different accounting than backend unit/integration tests. Different layer, different appropriate threshold. I reviewed this distinction in the original #556 review and stand by it.

What I checked

Test pyramid integrity, gate signal quality, and the ratchet mechanism.

Concern 1: Near-zero headroom (non-blocking, but flagged)

Setting the gate at 75% with a measured baseline of ~75% means any PR that introduces a new component with uncovered branches — even one small component — could drop below the gate and re-block CI. The long-tail-grind problem runs in both directions: improving a child's coverage can drag a parent's reported figure down.

This is noted in the ADR's Consequences section. The maintainer has acknowledged it. I'm flagging it again because it affects the CI experience for #553 (the active unblocking target) and any PR that follows.

Concern 2: Baseline precision

The ADR records ~75% (approximate). For the ratchet rule to be actionable, the floor needs to be a precise number. "Ratchet up when 3-PR-average sustains ≥78% for 30 days" requires knowing whether the current baseline is 75.0% or 75.4%. A 0.4pp difference is meaningful when headroom is already zero.

Recommendation: Once CI runs confirm the exact figure, update the ADR baseline block to replace ~75% with the actual measured percentage and the commit SHA from the passing CI run. This keeps the ratchet rule honest.

What's done well

• The ratchet rule is concrete and directional — up-only, 3pp increments, 30-day sustained observation window. This is exactly the mechanism I asked for in the original review.
• The layer distinction in the ADR prevents the 75% threshold from being misapplied to backend tests.
• axe-playwright runs are explicitly excluded from relaxation in the Non-goals section — that's the real accessibility quality gate and it stays intact.
• The gate adjustment does not remove or disable any existing tests.

## 🧪 Sara Holt — QA Engineer & Test Strategist **Verdict: ⚠️ Approved with concerns** ### Context on my usual stance I quote 80% branch coverage as a floor in most contexts. I am not contradicting that standard here — the ADR's "Why this layer is different" section correctly explains why browser-mode component coverage (Svelte template branches: class bindings, `{#if}` guards, empty/error state toggles) has different accounting than backend unit/integration tests. Different layer, different appropriate threshold. I reviewed this distinction in the original #556 review and stand by it. ### What I checked Test pyramid integrity, gate signal quality, and the ratchet mechanism. ### Concern 1: Near-zero headroom (non-blocking, but flagged) Setting the gate at 75% with a measured baseline of ~75% means any PR that introduces a new component with uncovered branches — even one small component — could drop below the gate and re-block CI. The long-tail-grind problem runs in both directions: improving a child's coverage can drag a parent's reported figure down. This is noted in the ADR's Consequences section. The maintainer has acknowledged it. I'm flagging it again because it affects the CI experience for #553 (the active unblocking target) and any PR that follows. ### Concern 2: Baseline precision The ADR records `~75%` (approximate). For the ratchet rule to be actionable, the floor needs to be a precise number. "Ratchet up when 3-PR-average sustains ≥78% for 30 days" requires knowing whether the current baseline is 75.0% or 75.4%. A 0.4pp difference is meaningful when headroom is already zero. **Recommendation:** Once CI runs confirm the exact figure, update the ADR baseline block to replace `~75%` with the actual measured percentage and the commit SHA from the passing CI run. This keeps the ratchet rule honest. ### What's done well - The ratchet rule is concrete and directional — up-only, 3pp increments, 30-day sustained observation window. This is exactly the mechanism I asked for in the original review. - The layer distinction in the ADR prevents the 75% threshold from being misapplied to backend tests. - axe-playwright runs are explicitly excluded from relaxation in the Non-goals section — that's the real accessibility quality gate and it stays intact. - The gate adjustment does not remove or disable any existing tests.

marcel commented 2026-05-14 08:57:40 +02:00

Author

Owner

Copy Link

📋 Elicit — Requirements Engineer & Business Analyst

Verdict: ✅ Approved

What I checked

Acceptance criteria coverage, requirement completeness, and traceability.

Acceptance criteria assessment

From #556:

AC	Status
branches: 70 in vitest.client-coverage.config.ts:47	✅ Done — set to 75 (maintainer decision; ADR records the rationale)
lines, functions, statements remain at 80	✅ Confirmed in diff
ADR-013 created with current state, long-tail rationale, headroom reason, when-to-revisit	✅ All sections present
coverage-flake-probe.yml succeeds end-to-end	⏳ Pending — verified in CI after merge

From the decision comment (pre-approved additions):

AC	Status
ADR contains ratchet rule verbatim	✅ Present — "3pp when 3-PR-average sustains threshold+3pp for ≥30 consecutive days, direction up-only"
ADR contains measured baseline block with real numbers	⚠️ Present as ~75% (approximate — exact number pending CI confirmation)
No further threshold drops without a superseding ADR	✅ Stated in ADR: "never lower the floor below 75 without a new ADR superseding this one"

Requirement quality

Scope is clean. Diff contains exactly two files: the one-line config change and the ADR. No scope creep, no accidental changes.

Traceability is complete. ADR-013 references #556 (this PR) and #496 (ratchet tracking). The config comment references ADR-013 and #496. The PR description references #556 (with Closes tag). The chain is: issue → ADR → config → PR.

Non-goals are explicit. The ADR does not touch vitest.config.ts (server project), does not raise actual branch coverage, does not relax existing tests. These boundaries are stated and respected.

One open item

The exact baseline percentage is ~75% (approximate). The ratchet rule's first trigger ("sustains ≥78% for 30 days") is precise, but the floor it's measured against is not. When CI confirms the number, the ADR should be updated with the exact value. This is a polish item, not a blocker — the intent is clear and the mechanism is sound.

## 📋 Elicit — Requirements Engineer & Business Analyst **Verdict: ✅ Approved** ### What I checked Acceptance criteria coverage, requirement completeness, and traceability. ### Acceptance criteria assessment From #556: | AC | Status | |---|---| | `branches: 70` in `vitest.client-coverage.config.ts:47` | ✅ Done — set to 75 (maintainer decision; ADR records the rationale) | | `lines`, `functions`, `statements` remain at 80 | ✅ Confirmed in diff | | ADR-013 created with current state, long-tail rationale, headroom reason, when-to-revisit | ✅ All sections present | | `coverage-flake-probe.yml` succeeds end-to-end | ⏳ Pending — verified in CI after merge | From the decision comment (pre-approved additions): | AC | Status | |---|---| | ADR contains ratchet rule verbatim | ✅ Present — "3pp when 3-PR-average sustains threshold+3pp for ≥30 consecutive days, direction up-only" | | ADR contains measured baseline block with real numbers | ⚠️ Present as `~75%` (approximate — exact number pending CI confirmation) | | No further threshold drops without a superseding ADR | ✅ Stated in ADR: "never lower the floor below 75 without a new ADR superseding this one" | ### Requirement quality **Scope is clean.** Diff contains exactly two files: the one-line config change and the ADR. No scope creep, no accidental changes. **Traceability is complete.** ADR-013 references #556 (this PR) and #496 (ratchet tracking). The config comment references ADR-013 and #496. The PR description references #556 (with `Closes` tag). The chain is: issue → ADR → config → PR. **Non-goals are explicit.** The ADR does not touch `vitest.config.ts` (server project), does not raise actual branch coverage, does not relax existing tests. These boundaries are stated and respected. ### One open item The exact baseline percentage is `~75%` (approximate). The ratchet rule's first trigger ("sustains ≥78% for 30 days") is precise, but the floor it's measured against is not. When CI confirms the number, the ADR should be updated with the exact value. This is a polish item, not a blocker — the intent is clear and the mechanism is sound.

marcel commented 2026-05-14 08:57:46 +02:00

Author

Owner

Copy Link

🎨 Leonie Voss — UX Designer & Accessibility Strategist

Verdict: ✅ Approved

What I checked

UI/UX surface, component impact, accessibility test coverage.

Findings

No user-facing components are added, removed, or modified in this PR. No Svelte templates change. No CSS tokens change. No routes change. No interactive elements, focus states, touch targets, or ARIA attributes are affected.

This is purely a CI configuration gate adjustment and an ADR. Nothing renders differently to any user — senior researcher on a tablet or millennial on a phone.

One downstream note

The ADR correctly lists the auth pages as uncovered-branch priorities for ratchet-up work:

• login/+page.svelte
• forgot-password/+page.svelte
• reset-password/+page.svelte
• register/+page.svelte

When that ratchet-up work starts (tracked in #496), these pages deserve visual-state branch coverage that includes error states and loading states — these are exactly the branches where dark-mode contrast regressions and mobile-overflow issues hide. The axe-playwright E2E runs are the accessibility quality gate for these pages; they are explicitly not relaxed by this PR, which is confirmed by the Non-goals section.

LGTM.

## 🎨 Leonie Voss — UX Designer & Accessibility Strategist **Verdict: ✅ Approved** ### What I checked UI/UX surface, component impact, accessibility test coverage. ### Findings No user-facing components are added, removed, or modified in this PR. No Svelte templates change. No CSS tokens change. No routes change. No interactive elements, focus states, touch targets, or ARIA attributes are affected. This is purely a CI configuration gate adjustment and an ADR. Nothing renders differently to any user — senior researcher on a tablet or millennial on a phone. ### One downstream note The ADR correctly lists the auth pages as uncovered-branch priorities for ratchet-up work: - `login/+page.svelte` - `forgot-password/+page.svelte` - `reset-password/+page.svelte` - `register/+page.svelte` When that ratchet-up work starts (tracked in #496), these pages deserve visual-state branch coverage that includes error states and loading states — these are exactly the branches where dark-mode contrast regressions and mobile-overflow issues hide. The axe-playwright E2E runs are the accessibility quality gate for these pages; they are explicitly not relaxed by this PR, which is confirmed by the Non-goals section. LGTM.

marcel added 1 commit 2026-05-14 09:04:17 +02:00

docs(adr-013): set exact baseline to 75% (confirmed in CI) ... 582191d014

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

marcel merged commit 582191d014 into main 2026-05-14 10:16:52 +02:00

marcel deleted branch worktree-chore+issue-556-drop-client-branches-coverage-gate 2026-05-14 10:16:53 +02:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

P0-critical

Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.

P1-high

Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.

P2-medium

Noticeable improvement; doesn't block anything; schedule opportunistically.

P3-later

Cosmetic or parking-lot work; fine to stay open indefinitely.

audit

Read-only audit / assessment work; produces a report rather than changing code

bug

Something isn't working

cleanup

Removal of dead code, vague comments, naming violations, and scratch artifacts

collaboration

We want to extend the family archive to have more collaboration tools

conversation

descoped

We will do that later

devops

documentation

README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs

epic

Marker for epic-level issues that group multiple child issues

feature

file-upload

legibility

Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction

notification

person

phase-1: security

Security hygiene — must be done first

phase-2: container-images

Production-ready multi-stage Docker images

phase-3: prod-compose

Production compose overlay + Caddy reverse proxy

phase-4: spring-prod-profile

Spring Boot production configuration profile

phase-5: backups

Database and object storage backup strategy

phase-6: deployment-docs

.env.example, DEPLOYMENT.md, runbook

phase-7: monitoring

Prometheus, Loki, Grafana, Alertmanager

refactor

Code restructuring without behaviour change

security

test

ui

UI/UX and accessibility issues

user

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

Jens marcel

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marcel/familienarchiv#559