# Final remediation verification review Use this for a read-only final working-tree review limited to confirming whether previously reported findings were actually resolved. ## Method 1. Convert each prior finding into an explicit invariant and at least one counterexample. 2. Review the exact base-to-working-tree candidate, including staged and untracked files. Do not rely on the implementer summary or green tests alone. In a concurrently changing worktree, re-resolve `HEAD`, status, and current file contents after focused tests: fixes may move from staged to committed while the review runs, so an empty unstaged diff is not proof that no candidate exists. Anchor the final report to the tree/commit actually rechecked. 3. Trace every invariant end to end across storage/query → service/read model → API contract → frontend rendering/action. A backend fix is incomplete if the frontend reconstructs weaker semantics rather than consuming the authoritative contract. 4. Run focused tests, then disposable synthetic probes for uncovered boundaries. Keep runtime state below a test-only temporary directory; do not modify repository files. 5. Return one PASS/FAIL row per original finding, list new regressions separately, and explicitly state whether any blocker remains. ## Counterexample checklist ### Provenance matrices When cache/resume validity requires provider, symbol, currency, and exchange, mutate each field independently. Apply exchange validation to the mapped primary provider as well as fallback providers. A green wrong-currency test does not prove exchange provenance. For every named provider class, pair the negative wrong-exchange case with a positive correct-exchange or recognized-alias control; otherwise an implementation that rejects every row can appear correct. If the permanent suite lacks one matrix cell, use a disposable in-memory probe rather than editing the repository during a read-only review. ### Historical cutoff versus quote date Keep the requested analysis cutoff distinct from the accepted source quote date. Test a quote accepted one or two business days before cutoff and an all-missing state. Deriving retry cutoff from valued rows can shift it backward or yield null, silently reverting to today. Frontends should consume the authoritative summary/as-of contract. Trace the value through backend summary generation, frontend state assignment, batch retry, per-position retry, and any follow-up batch. A dated-row UI test alone is insufficient for the no-valued-row boundary: inspect or probe that the backend still supplies the historical `as_of` and that the frontend preserves it when every quote date is null. ### Stale and nullable valuation semantics Test stale price and stale FX independently. Verify position value, partial value, complete total, coverage status, allocations, and advisor/global signals. Numeric presence alone is not freshness. ### Empty-set semantics Probe zero positions. Avoid vacuous completeness from `len(valued) == len(positions)`: an empty portfolio should normally be unavailable or a documented empty state, not complete with a fresh-looking zero total. ### Privacy remediation Inspect final added documentation lines for real identifiers, holdings, symbols, provider mappings, account-linked counts, and values. Generic technical semantics are acceptable; calling a real inventory “sanitized” is not. ### Financial import and reconciliation remediation For versioned import, duplicate, transfer, card, receipt-link, and review-action fixes, add disposable negative controls beyond the permanent golden suite. #### Trace semantic invariants across every decision surface Do not stop after proving category-type compatibility in inline import overrides, clusters, and canonical classifiers. Enumerate every later decision surface too: persisted review inbox, batch review preview/confirm, grouped actions, learned-history lookup, exact/source/similarity rules, and final transaction materialization. A common residual defect is a review helper that validates only that a category is active, followed by confirm code that derives `transaction_type` from amount sign; this can persist an expense under an income category despite green import-preview tests. Use a disposable in-memory probe that selects an opposite-type active category, proves whether preview accepts it, and—only in reversible synthetic state—checks the persisted `(transaction_type, category_type)` pair. #### Keep readiness partitions economically disjoint Recompute readiness with safe paired-transfer legs, unmatched neutral decisions, receipt details, duplicates, and ordinary unresolved rows separated. Never let two legs of a safe transfer inflate `ordinary_monetary_count`, coverage, or the individual-review denominator. Use a dilution counterexample: many uniquely matched transfer pairs plus one unresolved ordinary row. If the result becomes business-ready only because transfer legs enter the denominator, the server gate is financially false even though it executes before writes. #### Distinguish receipt review records from links For receipt enrichment, inspect both preview status and confirmed storage. `unmatched` or `review` may be valid workflow states, but a relation named or counted as a link must not be persisted with both money references null unless the schema contract explicitly models such placeholders. Probe a receipt with no money counterpart, confirm only in an in-memory/reversible database, and inspect `(status, money_candidate_id, money_transaction_id)`. Also verify exactly one non-null money reference for every `linked` row. #### Challenge user-confirmed neutral-transfer evidence A row-scoped user confirmation is not sufficient if the server offers the action from broad payment vocabulary. Counterprobe ordinary expenses containing phrases such as `payment`, `zahlung an`, `wallet`, or `top up`. The action should require narrow own-account evidence derived from account roles, transfer-specific references, or an unmatched deterministic pairing state; generic payment text must not make an expense eligible for budget-neutral materialization. If the action is exposed, exercise the complete reversible path through decided preview and confirm and inspect the stored transaction type and category. For each previously reported finding, record the original path as PASS/FAIL separately from newly discovered adjacent paths. A fixed inline/cluster guard does not justify a global PASS when a post-import review path still violates the same semantic invariant. #### Adversarial transfer-membership graph probes Do not test duplicate membership only by cloning a valid paired-transfer relation. Also attach one ordinary income/expense transaction to two distinct transfer relations, each with a different transfer counterpart. The canonical reader must still emit one financial/category/count row for the ordinary transaction, but **any** conflicting membership anywhere in the scoped transfer graph must make movement volume `null`/unavailable. A guard such as `transaction_type='transfer' AND membership_conflict=1` is insufficient because it lets malformed relations rooted at an ordinary transaction contribute apparently trustworthy counterpart volume. Trace the conflict through every wrapper and visible surface, not only the canonical summary. Verify the household overview exposes the conflict count/status/message and does not describe all null transfer volume as missing FX. A null KPI beside an overall `current`/`Aktuell` status is still false completeness. #### Mixed-provider aggregate consistency When a canonical effect reader replaces legacy `COALESCE(amount_chf, amount_original)` arithmetic, inspect every downstream overlay that can overwrite its fields. Budget planning, forecasting, previous-year, recurring, and category-control helpers may still use the legacy fallback and reintroduce foreign original amounts as CHF. Counterprobe one missing-FX foreign transaction and compare `(actual_current_month, actual_ytd, forecast, status, data_status)` across the raw canonical reader, category status, category detail, cockpit, and visible page. Contradictory output such as canonical actual `0.00` plus legacy forecast `50.00` and a green status is blocking even if a separate dashboard has a partial-data banner. #### Envelope compatibility checks For any list-to-envelope API remediation, compare the exact base and candidate top-level JSON types. Inventory in-repository consumers, but do not infer compatibility from their absence: unversioned HTTP endpoints can have external consumers. Preserve the legacy shape, add an explicitly versioned endpoint/query contract, or provide a documented compatibility path. A status-only endpoint test does not prove response-envelope compatibility. Existing negative controls: - **Transfer vocabulary:** pair equal/opposite amounts on different mapped accounts where one unrelated description contains a broad token such as `payment`. Stable account mappings, equal amounts, opposite signs, and date proximity do not prove an own-account transfer. Require transfer-specific evidence or an explicit card-payment class, and prove an unrelated income/expense pair remains reviewable rather than being posted budget-neutral. - **Terminal duplicate states:** replay a previously confirmed refund/reversal using a fresh preview. Later semantic enrichment (reversal matching, pending/final collapsing, receipt linking, transfer pairing) must not overwrite `duplicate_file`, `duplicate_source_row`, or another terminal non-writable disposition. Confirm must return an idempotent result or a controlled conflict, never leak a storage `IntegrityError`. - **Capability parity:** for every review group, enumerate each API-advertised `supported_action` and call its preview endpoint. The read-model capability list and confirm validator must use one authoritative policy; a visible `duplicate`/`ignore`/posting action that deterministically returns 409 is a release blocker. - **Cross-batch one-to-one links:** attempt to attach a second receipt/detail record to a money candidate or productive transaction already consumed by an earlier link. Verify the canonical movement is not reused ambiguously and no second expense or duplicate detail lineage is created. Treat deterministic financial misclassification, duplicate-guard bypass, uncaught constraint errors, and advertised-but-rejected required review actions as release blockers even when the focused suite is green. Report the exact synthetic inputs in sanitized form, observed classification/disposition or HTTP/storage result, and source lines responsible. ## Focused frontend/accessibility closure When the prior findings are a short named list of UI or accessibility defects, keep the re-review finding-oriented rather than turning it into a broad redesign audit. 1. Build a finding → invariant → implementation → test matrix and inspect every affected surface. Include untracked imported components and tests: base-to-tree diffs omit them, so pair the diff with status and direct reads. 2. For custom clickable transaction rows, require an accessible name, `role="button"`, `tabindex="0"`, Enter, Space, and visible focus treatment. Native buttons already supply Enter/Space; if a pointer-clickable table row remains, an equivalent clearly exposed keyboard button can satisfy the action path without forcing invalid table semantics. 3. For checkbox-target findings, verify both the checkbox's accessible name and that the claimed `44×44` hit area is an associated clickable label or equivalent activation surface. Decorative wrapper size alone is not proof. 4. For dialog-name findings, resolve the complete `aria-labelledby` sequence and confirm the computed name contains both operation/intent and record identity. Recheck initial focus, inert background, focus trap, Escape, and return focus when the changed modal code owns those behaviors. 5. For chart-bar names, require category, month, actual, budget, and action purpose. Prefer the point's own budget when the contract permits month-varying budgets; use a category-level monthly budget only when it is invariant. 6. For unavailable converted-currency previews, ensure `null` never becomes a displayed zero. Name the unavailable valuation, preserve original amount/currency, say that no conversion was derived, and bind confirmation to the explicit preview contract rather than a visual fallback. 7. Run the smallest focused component suite covering every named closure, then typecheck and `git diff --check`; recheck status afterward to prove the read-only review added nothing. Separate warnings from failures. 8. If the requested output is only remaining P0/P1/P2 findings, report exactly that. When none remain, say so directly and provide concise positive evidence and exact test results rather than inventing a lower-severity issue. Unit/jsdom tests can close attribute and handler semantics when they assert the exact behavior. They cannot prove real pixel geometry, focus-ring visibility, responsive overlap, or accessibility-tree output; require a browser probe whenever those runtime properties are part of the original finding. ## Verdict rules - PASS requires the full invariant across every named path and boundary case. - A deterministic counterexample overrides a green focused suite. - Remaining false-completeness, provenance, or historical-cutoff defects are blocking when they can affect financial interpretation or repair behavior. - Separate remaining original findings from newly introduced regressions. - State that no files were modified for a read-only review.