---
phase: quick-260909-laa
verified: 2026-09-09T16:15:00Z
status: gaps_found
score: 8/9 must-haves verified
covered_files:
  - ".planning/quick/260909-laa-mandantentrennung-etappe-2-bereich-tende/260909-laa-PLAN.md"
  - ".planning/quick/260909-laa-mandantentrennung-etappe-2-bereich-tende/260909-laa-SUMMARY.md"
  - "apps/api/scripts/rls-scratch-check.mjs"
  - "apps/api/src/tenders/tender-digest.scheduler.spec.ts"
  - "apps/api/src/tenders/tender-digest.scheduler.ts"
  - "apps/api/src/tenders/tender-email-config.service.spec.ts"
  - "apps/api/src/tenders/tender-email-config.service.ts"
  - "apps/api/src/tenders/tender-matching.service.spec.ts"
  - "apps/api/src/tenders/tender-matching.service.ts"
  - "apps/api/src/tenders/tender-notification-pref.service.spec.ts"
  - "apps/api/src/tenders/tender-notification-pref.service.ts"
  - "apps/api/src/tenders/tender-notifications.integration.spec.ts"
  - "apps/api/src/tenders/tender-rss-feed.service.spec.ts"
  - "apps/api/src/tenders/tender-rss-feed.service.ts"
  - "apps/api/src/tenders/tender-saved-search.service.spec.ts"
  - "apps/api/src/tenders/tender-saved-search.service.ts"
  - "apps/api/src/tenders/tender-triage.service.spec.ts"
  - "apps/api/src/tenders/tender-triage.service.ts"
  - "apps/api/src/tenders/tenders.controller.spec.ts"
  - "apps/api/src/tenders/tenders.controller.ts"
  - "docs/mandantentrennung-etappe2-fehlerrichtung.md"
  - "docs/mandantentrennung-zugriffsklassifikation.md"
covered_digest: "v1:sha256:7dd683c122609581224bf2f8d84ea0e357cf4bf5dbbabcda9a4aeecf2120c5ed"
behavior_unverified: 0
overrides_applied: 0
gaps:
  - truth: "Die Kehrseite der Bindung (Befund F) ist fuer alle drei tenantlosen upsert-Pfade genuin behandelt: tenderEmailConfig, tenderNotificationPref UND tenderTriage uebersetzen P2002 in eine verstaendliche deutsche Meldung, nachgewiesen durch einen Test."
    status: failed
    reason: >
      tender-triage.service.ts's setTriage() upserts on the tenant-less
      @@unique([userId, tenderId]) key exactly as described in Befund F /
      T-LAA-07, but never gained the P2002-to-ConflictException translation
      the plan's Task 2 <action> explicitly requires for "die drei
      upsert-Pfade" (tenderEmailConfig, tenderNotificationPref,
      tenderTriage). The rls-scratch-check.mjs measurement
      (tendertriage-einfuegen-auf-unsichtbare-zeile-verletzt-eindeutigkeit)
      correctly proves the DATABASE throws a raw P2002 on this exact shape
      — but the SERVICE never catches it. A stale-tenant user hitting this
      path today gets an unhandled 500, not a German message. This also
      contradicts the SUMMARY's own key-decisions/tech-stack-patterns claim
      ("P2002 on a tenant-less unique key (userId, [userId,tenderId])
      translated into a German ConflictException") — [userId,tenderId] is
      TenderTriage's key, and no such translation exists for it.
      Independently confirmed at both delivery commits (3336a6e, df5c5b7):
      neither introduces a catch/P2002/ConflictException in
      tender-triage.service.ts. tender-triage.service.spec.ts also has zero
      test coverage for this path (no "P2002"/"Conflict"/"unique" match),
      so setTriage()'s only two other upsert-adjacent guarantees
      (idempotence, partial update) are tested but the conflict path is not.
    artifacts:
      - path: "apps/api/src/tenders/tender-triage.service.ts"
        issue: "setTriage() upsert has no try/catch around the P2002 case — a stale-tenant conflict surfaces as a raw, unhandled Prisma error instead of a ConflictException"
      - path: "apps/api/src/tenders/tender-triage.service.spec.ts"
        issue: "No test exercises a P2002/unique-constraint-violation on setTriage()'s upsert"
    missing:
      - "Wrap tenderTriage.upsert in setTriage() with the same P2002 -> ConflictException translation used in tender-saved-search.service.ts / tender-notification-pref.service.ts / tender-email-config.service.ts, with a German user-facing message."
      - "Add a test in tender-triage.service.spec.ts that forces a P2002 from the mocked upsert and asserts a ConflictException with a German message is thrown, not a raw error."
---

# Quick Task 260909-laa: Etappe 2 Bereich tenders Verification Report

**Task Goal:** Bind the five user-CRUD services and the per-hit halves of the two
background services to a tenant-bound client, leave the platform-global catalogue
and the two fan-out adapters deliberately unbound, respect the WINDOWS #19 boundary
inside `tender-rss-feed.service.ts`, and leave the classification document and its
machine guard in sync.

**Verified:** 2026-09-09T16:15:00Z
**Status:** gaps_found
**Re-verification:** No — initial verification

## Goal Achievement

### Observable Truths (orchestrator's 10-point checklist)

| # | Truth | Status | Evidence |
|---|-------|--------|----------|
| 1 | WINDOWS #19 boundary in `tender-rss-feed.service.ts`: only `createForUser` binds; `listForUser`/`createPlatform`/`remove` stay unbound; `remove`'s single conditional `deleteMany` was NOT split | ✓ VERIFIED | Read the full file. All three unbound methods carry explicit WINDOWS #19 comments naming the concrete consequence of binding. `remove()` is still one `deleteMany({ where: { id, OR: [...] } })` call — no read-then-delete split. `createForUser` is the only method calling `forTenant()`. Classification doc marks the pair `beides` / `gemischt`. |
| 2 | Stage-3 line in both background services: cross-tenant fan-out queries stay unbound with a stage-3 comment; only per-row loop bodies bind | ✓ VERIFIED | `tender-digest.scheduler.ts`: candidate `tenderMatch.findMany({distinct:['userId']})` unbound with an explicit `260909-laa, Aufgabe 3` / Stage-3-handoff comment; per-candidate loop binds `tenderNotificationPref.findUnique`, `tenderMatch.findMany`, `user.findUnique`, `tenderMatch.updateMany`, one client per row. `tender-matching.service.ts`: `tenderSavedSearch.findMany()` (profiles) and `tender.findMany()` (catalog) both unbound with comments; per-profile loop binds `tenderMatch.upsert`, `tenderMatch.findMany`, `user.findUnique`, `tenderMatch.updateMany`, one client per profile (not per row, as required). |
| 3 | Platform-global sites (10 pairs + 2 fan-out adapters) untouched, and their `Stand` in the classification doc reads as deliberately unbound | ✓ VERIFIED | `git diff --name-only b86675b..HEAD` touches none of `tender-dedup.service.ts`, `tender-fingerprint-backfill.service.ts`, `tender-ingestion.service.ts`, `tender-scheduler.service.ts`, `tenders.module.ts`, `adapters/email-alert.adapter.ts`, `adapters/rss.adapter.ts`. All twelve rows in `docs/mandantentrennung-zugriffsklassifikation.md` read `ungebunden` with a named reason (`keine-mandantengebundene-tabelle` / `bewusst-uebergreifend`), not as pending work. |
| 4 | The upsert counter-direction (Befund F) is genuinely handled for all three tenant-less-unique-key upserts, each with a German conflict message and a test | ✗ **FAILED** | `tenderEmailConfig` and `tenderNotificationPref` both translate P2002 into a German `ConflictException`, each with a passing test. **`tenderTriage.setTriage()` does not** — no try/catch around its `@@unique([userId,tenderId])` upsert, confirmed absent at both delivery commits (3336a6e, df5c5b7), and no test in `tender-triage.service.spec.ts` exercises a conflict. See Gaps. |
| 5 | Befund I self-referential test trap: `tender-ingestion.service.ts` gained neither code nor a comment naming `forTenant` | ✓ VERIFIED | `grep -n forTenant apps/api/src/tenders/tender-ingestion.service.ts` — zero matches. The guard test in `tender-ingestion.service.spec.ts:514-516` (`not.toMatch(/forTenant/)`) still passes. |
| 6 | Measurements are committed, not just described — scratch tool at 32/32 with the three named special-case checks | ✓ VERIFIED | Independently re-ran `rls-scratch-check.mjs` against the live `tessera-ctl-db-1` container (freshly resolved IP `172.19.0.2`, not copied from any document). Output: **32/32 Pruefungen bestanden**, exit 0. All three named checks present and passing: `tendersavedsearch-fremder-nutzer-desselben-mandanten-sichtbar` (no user dimension), `tenderrssfeed-plattformzeile-unter-jedem-mandanten-unsichtbar` + `tenderrssfeed-gebundenes-einfuegen-ohne-mandant-abgelehnt` (WINDOWS #19), `tendertriage-einfuegen-auf-unsichtbare-zeile-verletzt-eindeutigkeit` (P2002-on-invisible-row). Same output (modulo trimming) is pasted verbatim into `docs/mandantentrennung-etappe2-fehlerrichtung.md` (t1). |
| 7 | Test honesty: all 7 (+1 integration) spec files genuinely go red on a binding regression, not merely compile | ✓ VERIFIED | All 8 files (`tender-saved-search`, `tender-triage`, `tender-notification-pref`, `tender-email-config`, `tender-rss-feed`, `tender-digest.scheduler`, `tender-matching`, `tender-notifications.integration`) carry the `__makeBoundClient()` two-client proof via `vi.mock('../prisma/prisma-tenant.extension', ...)`. Live-reverted one binding (`tender-triage.service.ts`'s `listForUser`, forTenant -> plain `this.prisma`), ran the file's spec: **1 test failed** with a specific, correctly-named assertion (`erwaeteter gebundener Aufruf tenderTriage.findMany(tenant=t1) fehlt im Protokoll`), 10 others stayed green. Reverted the change back; the file is now byte-identical to the committed version and the full spec file passes again (11/11). |
| 8 | Executor's Befund-C correction (10 controller call sites -> only 8 needed threading) is right, not a silent skip | ✓ VERIFIED | Read `tenders.controller.ts` around all `extractTriageContext` call sites. `listRssFeeds` (line 267-268) destructures only `{ userId }` and calls `listForUser(userId)` (no `tenantId` param exists on that method — it's deliberately unbound). `removeRssFeed` (line 323-325) destructures `{ userId, role }` and calls `remove(feedId, { userId, isAdmin })` (same — `remove` has no `tenantId` param). The other 8 call sites (`favoriteIds`, `createRssFeed`/`createForUser`, `getEmailConfig`, `saveEmailConfig`, `testEmailConnection`, `listTriage`, `setTriage`, `listSavedSearches`, `createSavedSearch`, `updateSavedSearch`, `removeSavedSearch`, `getNotificationPref`, `setNotificationPref`) all thread `tenantId` through. Confirmed correction, not a skip. |
| 9 | Befund K (settings-area dependency) is written down, not just mentioned in a commit | ✓ VERIFIED | `docs/mandantentrennung-etappe2-fehlerrichtung.md` line 576-581+ carries an explicit "Befund K" paragraph naming `tender-mail.service.ts`'s dependency on `SettingsService.getDecryptedSmtpConfig(tenantId)` and the post-cutover silent-mail-stop consequence. |
| 10 | Constraints held: no schema/migration/compose/env change, cutover switch OFF, no `withTenantTransaction()` introduced, the two non-atomic multi-step sites left alone | ✓ VERIFIED | `git diff --name-only b86675b..HEAD` — exactly the 20 files listed in the plan's frontmatter, none of them schema/migration/compose/env. `.env.example` still `DATABASE_URL=postgresql://tessera:...@db:5432/tessera` (role `tessera`, BYPASSRLS). `grep -rn withTenantTransaction apps/api/src/tenders` — zero matches. The one remaining `$transaction` in the area (`tender-fingerprint-backfill.service.ts:89`) is untouched, array form, on the platform-global `Tender` table. |

**Score:** 8/9 must-haves verified (0 present-but-behavior-unverified)

### Required Artifacts

| Artifact | Expected | Status | Details |
|---|---|---|---|
| `apps/api/scripts/rls-scratch-check.mjs` | New `runTendersAreaChecks` section, 9 new checks | ✓ VERIFIED | 32 total checks (23 prior + 9 new), all pass live |
| `docs/mandantentrennung-etappe2-fehlerrichtung.md` | `## Bereich tenders` with (t1)-(t5) | ✓ VERIFIED | Section present with all five subsections, content matches live measurement |
| `docs/mandantentrennung-zugriffsklassifikation.md` | All 23 tenders pairs' `Stand` in sync | ✓ VERIFIED | `rls-access-inventory.spec.ts` passes (10/10); all 23 rows present and reasoned |
| `tender-saved-search.service.ts` | `list`/`create`/`update`/`remove` fully bound | ✓ VERIFIED | All methods bind via `forTenant()`, P2002 handled |
| `tender-triage.service.ts` | `setTriage`/`listForUser`/`favoriteIds` fully bound + P2002 handled | ⚠️ PARTIAL | Binding complete; P2002 handling MISSING (see gap above) |
| `tender-notification-pref.service.ts` | `getForUser`/`setForUser` bound + P2002 handled | ✓ VERIFIED | Bound, P2002 -> German ConflictException, tested |
| `tender-email-config.service.ts` | `getConfigForApi`/`testConnection`/`saveConfig` bound + P2002 handled | ✓ VERIFIED | Bound, P2002 -> German ConflictException |
| `tender-rss-feed.service.ts` | `createForUser` bound; other three deliberately unbound | ✓ VERIFIED | Matches WINDOWS #19 boundary exactly |
| `tenders.controller.ts` | 8 of 10 call sites thread `tenantId` | ✓ VERIFIED | Confirmed line-by-line |
| `tender-digest.scheduler.ts` | Per-hit half bound, cross-tenant half stage-3-commented | ✓ VERIFIED | |
| `tender-matching.service.ts` | Per-hit half bound, cross-tenant halves stage-3/D-03-commented | ✓ VERIFIED | |

### Key Link Verification

| From | To | Via | Status |
|---|---|---|---|
| bound client | 5 policies from delivered migration | `readRemainingTenantTablesMigrationSql()`/`extractPolicySql()` | ✓ WIRED — scratch tool extracts, not retypes, all 5 |
| `extractTriageContext` | 10 controller call sites | tenantId threading | ✓ WIRED (8/10 threaded, 2/10 correctly not, per Befund C correction) |
| nullable `TenderRssFeedSource.tenantId` | `listForUser`/`createPlatform`/`remove` | WINDOWS #19 boundary | ✓ WIRED — all three deliberately unbound, code comments cite the boundary |
| bound loop-body read | 5 continue/return silent-failure sites | notifiedAt-stays-NULL retry guarantee | ✓ WIRED — tested in both `tender-digest.scheduler.spec.ts` and `tender-matching.service.spec.ts` |
| `@@unique` keys without tenant dimension | bound `upsert` -> hard error | P2002 translation | ⚠️ PARTIAL — 2/3 wired (tenderEmailConfig, tenderNotificationPref); tenderTriage's upsert is bound but its P2002 is NOT translated |
| `rls-access-inventory.spec.ts` | classification doc `Stand` column | doc-vs-source consistency check | ✓ WIRED — 10/10 tests pass |

### Behavioral Spot-Checks

| Behavior | Command | Result | Status |
|---|---|---|---|
| Scratch tool measures the 3 special cases against the live, delivered migration | `TESSERA_SCRATCH_ADMIN_URL=... node apps/api/scripts/rls-scratch-check.mjs` (fresh IP resolution) | 32/32 passed, exit 0 | ✓ PASS |
| Falsification: revert one binding, observe a named test go red | Reverted `tender-triage.service.ts` `listForUser`'s `forTenant()` call, ran `npm --prefix apps/api run test -- src/tenders/tender-triage.service.spec.ts` | 1/11 failed with a specific, correctly-scoped assertion; reverted back, 11/11 green again | ✓ PASS |
| Doc-vs-source consistency for all 23 tenders pairs | `npm --prefix apps/api run test -- src/prisma/rls-access-inventory.spec.ts` | 10/10 passed | ✓ PASS |
| WINDOWS #19 file ends at `Stand: gemischt` | Read classification doc row for `tender-rss-feed.service.ts` | `beides` / `gemischt` | ✓ PASS |

### Anti-Patterns Found

None of TBD/FIXME/XXX/TODO/HACK/PLACEHOLDER found in the 18 modified source/spec files. No stub returns, no hardcoded empty-data anti-patterns beyond the intentional, commented WINDOWS #19 no-ops.

### Requirements Coverage

No `.planning/REQUIREMENTS.md` entries exist for `WINDOWS-20`/`ETAPPE-2-TENDERS` (quick-task IDs, not tracked in the formal requirements ledger) — not a gap for a quick task.

### Human Verification Required

None. All findings were verifiable from source, the live scratch-check run, and one live test-suite falsification.

### Gaps Summary

One genuine gap, isolated and narrow: `tender-triage.service.ts`'s `setTriage()` upserts on the tenant-less `@@unique([userId, tenderId])` key — the exact shape the plan's Befund F names and the scratch tool measures
(`tendertriage-einfuegen-auf-unsichtbare-zeile-verletzt-eindeutigkeit`) — but never received the P2002-to-German-ConflictException translation the plan's Task 2 explicitly requires for all three affected upsert paths. The sibling paths (`tenderEmailConfig`, `tenderNotificationPref`) got it correctly, with tests. This also means the SUMMARY.md's own claim ("P2002 on a tenant-less unique key (userId, [userId,tenderId]) translated into a German ConflictException") is not accurate for the `[userId,tenderId]` case — the SUMMARY describes work that was not actually done for `tenderTriage`. Everything else checked — the WINDOWS #19 boundary, the stage-3 split in both background services, the 12 untouched platform-global pairs, the classification-doc sync, the measurement's live re-run, the test-honesty falsification, the controller-threading correction, Befund K, and the "nothing touched that shouldn't be" constraints — verified directly against the codebase and holds.

---

_Verified: 2026-09-09T16:15:00Z_
_Verifier: Claude (gsd-verifier)_