docs(quick-260909-laa): Etappe 2 Bereich tenders abgeschlossen, Luecke behoben
This commit is contained in:
+3
-2
@@ -375,6 +375,7 @@ None yet.
|
||||
| 260909-dgj | Mandantentrennung auf Datenbankebene vorbereitet (WINDOWS #18). Ausloeser war ein gemessener Befund: die Anwendung verbindet als Rolle mit Superuser- und BYPASSRLS-Recht, daher greifen die sieben vorhandenen Policies gar nicht — ohne gesetzten Mandantenkontext lieferte 'SELECT count(*) FROM Group' zwei statt null Zeilen. Gebaut wurden: Rolle `tessera_app` ohne Umgehungsrecht (wiederholbare Migration, kein Kennwort im SQL), Trennung von Migrations- und Laufzeitverbindung ueber TESSERA_MIGRATE_DATABASE_URL, ein Pruefwerkzeug mit fuenf transaktionssicheren Nachweisen, Policies fuer die 16 fehlenden Tabellen und eine Betriebsanleitung. **Der Schalter bleibt bewusst aus, #18 bleibt offen:** im Code stehen 182 Datenbankzugriffe ohne Mandantenkontext gegen 19 mit — darunter zwingend der Anmeldeweg, der die Benutzerzeile liest, bevor der Mandant bekannt ist (er kommt erst aus dieser Zeile). Ein Umschalten wuerde die Anmeldung fuer alle sperren. Dabei fiel #19 an: SearchProvider und TenderRssFeedSource haben ein nullable tenantId; die einfache Policy wuerde die plattformweiten Zeilen nach dem Scharfschalten fuer jeden Mandanten unsichtbar machen. 673/673 Tests gruen | 2026-09-09 | efaabc9 | [260909-dgj-mandantentrennung-auf-alle-tabellen-mit-](./quick/260909-dgj-mandantentrennung-auf-alle-tabellen-mit-/) |
|
||||
| 260909-ipc | Mandantentrennung Etappe 2, Bereich ldap: alle 21 klassifizierten Zugriffe in `ldap-config.service.ts` (9) und `ldap.service.ts` (12) an `forTenant()` gebunden. **Zuerst gemessen, dann gebaut:** `rls-scratch-check.mjs` um `runLdapAreaChecks` erweitert (13/13 bestanden), Beleg ist die Zeile `ldapconfig-ungebunden-null-zeilen` gegen die echte, ausgelieferte Policy — die Umkehr der Fehlerrichtung ist damit gemessen, nicht behauptet. Die geforderte Kritikschrift liegt in `docs/mandantentrennung-etappe2-fehlerrichtung.md` mit Signaltabelle je Pfad und vier namentlich benannten Stellen, die Leere als Abwesenheit deuten. **Sicherheitsluecke nebenbei geschlossen (T-IPC-01):** `DELETE /ldap/config/mappings/:id` nahm nur die Kennung — ein Administrator von Mandant A konnte die Feldzuordnung von B loeschen; der Mandant kommt jetzt aus der Sitzung. **Drei Stellen bleiben bewusst ungebunden, jede mit Begruendung im Code:** `getAllActiveConfigs` und die Start-Nachverschluesselung lesen zwingend uebergreifend; `resolveEmailForWrite` darf nicht gebunden werden, weil `email`/`username` plattformweit eindeutig sind — gebunden saehe die Kollisionspruefung keinen fremden Halter, meldete 'frei', und aus einer sauber berichteten Kollision wuerde ein P2002-Abbruch (Produktfrage fuer Etappe 3). **Befund, der die Testlage aendert:** `forTenant` war in `ldap.service.spec.ts` als Identitaet gemockt — die Tests haetten den Umbau in keiner Richtung bemerkt; ersetzt durch zwei unterscheidbare Clients. `rls-access-inventory.spec.ts` um eine `Stand`-Spalte und Erkennung gebundener Fundstellen erweitert, dabei zwei bisher unbekannte Paare gefunden (`auth.service.ts`/`passwordResetToken`, `ldap.service.ts`/`groupMembership`), Klassifikationsdokument auf 61 Paare nachgezogen. Schema, Migrationen, Compose und Umgebungsdateien unberuehrt, Schalter weiter aus. **Verifiziert 7/7** (unabhaengig nachgemessen: 719/719 Tests, Typpruefung sauber, 13/13 Live-Pruefungen gegen den echten Container) | 2026-09-09 | a0c9ef0,9a57fa7,e1586a4 | [260909-ipc-mandantentrennung-etappe-2-bereich-ldap-](./quick/260909-ipc-mandantentrennung-etappe-2-bereich-ldap-/) |
|
||||
| 260909-jts | Mandantentrennung Etappe 2, Bereich groups — die Berechtigungsschicht. Alle 34 echten Zugriffe in `groups.service.ts` (21) und `module-grants.service.ts` (13) gebunden, dazu fuenf Zugriffe, die **keine Pruefung dieses Projekts je gesehen hatte**: sie laufen innerhalb einer Transaktion ueber den Callback-Parameter, den der Detektor der Inventarpruefung nicht kannte — einer davon ist der Schreibvorgang, der Modulfreigaben vergibt. Das Paar `(groups.service.ts, tenantModuleActivation)` fehlte im Klassifikationsdokument komplett und ist ergaenzt; der Detektor sieht jetzt auch Transaktionsparameter. **Kernbefund — neues Hilfsmittel `withTenantTransaction()`:** die Frage, welche Transaktionsform den Mandantenkontext auf derselben Verbindung traegt, wurde an der lebenden Datenbank gemessen statt angenommen. Form (i) faellt durch (zwei verschiedene `pg_backend_pid()`), Form (ii) besteht die Einzelmessung, bricht aber unter 40 gleichzeitigen Aufrufen mit P2028 ab, weil jeder Aufruf eine verschachtelte Transaktion aus demselben endlichen Verbindungsvorrat oeffnet; Form (iii) besteht beides. Alle weiteren Bereiche bauen darauf auf. **Die Lastprobe war zunaechst nur Fliesstext** — eine Zahl, die eine Entscheidung trug, ohne nachvollziehbar zu sein; vom Verifizierer beanstandet und als `runConcurrencyProbe` nachgereicht (604428a), laeuft seither bei jedem Werkzeuglauf mit: 24 Verletzungen von 40 fuer Form (ii), 0 von 40 fuer Form (iii). **Zwei Datenbankregeln greifen kuerzer als gedacht** und sind bewusst nur gemessen und festgehalten, nicht repariert: die Regel fuer Gruppenmitgliedschaften prueft nur die Gruppen-, nicht die Benutzerseite (T-JTS-02), die fuer Modulfreigaben nur die Mandantenkennung, nicht die referenzierte Gruppe (T-JTS-03) — dort haengt der Schutz allein an `assertTargetBelongsToTenant`. Umgekehrter Gefahrenfall geschlossen: `ensureDefaultGroup` deutet Leere als 'Mandant hat noch keine Gruppe' und baut alles neu auf, eine halb umgestellte Fassung haette eine zweite Standardgruppe samt Freigaben erzeugt — Zaehler und Transaktion sind deshalb gemeinsam gebunden. Beide Testdateien hatten gar keine Attrappe fuer den Helfer, waeren nach der Umstellung also aus dem falschen Grund rot gewesen; ersetzt durch den Zwei-Client-Nachweis, vom Verifizierer durch Rueckbau falsifiziert. Schema, Migrationen, Compose und Umgebungsdateien unberuehrt, Schalter aus. **Verifiziert 9/9** (743/743 Tests, Typpruefung sauber, 23/23 Live-Pruefungen) | 2026-09-09 | fd0b9f7,7f08b27,abb6c8b,604428a | [260909-jts-mandantentrennung-etappe-2-bereich-group](./quick/260909-jts-mandantentrennung-etappe-2-bereich-group/) |
|
||||
| 260909-laa | Mandantentrennung Etappe 2, Bereich tenders — anders geschnitten als die bisherigen: von 23 Paaren werden nur 5 umgestellt (die Nutzer-CRUD-Dienste fuer gespeicherte Suchen, Bearbeitungsstand, Benachrichtigungen, Postfach, RSS), 10 bleiben bewusst ungebunden, weil der Ausschreibungskatalog plattformweit ist (D-03), 2 sind Verteiler, die absichtlich ueber alle Mandanten lesen, und 6 sind Mischfaelle, deren uebergreifende Haelfte zu Etappe 3 gehoert — nur die Je-Treffer-Schleifen wurden gebunden. **Die gefaehrlichste Grenze lag in `tender-rss-feed.service.ts`:** dort haben plattformweite RSS-Quellen ein leeres Mandantenfeld; drei der vier Zugriffe duerfen deshalb NICHT binden, sonst waeren diese Quellen nach dem Scharfschalten fuer JEDEN unsichtbar statt nur fuer fremde (WINDOWS #19). Die Datei endet bewusst auf Stand `gemischt`, und das einzelne bedingte Loeschen blieb eine Anweisung — es aufzuteilen haette das Pruef-/Nutzungsfenster geoeffnet, das der Dateikopf vermeidet. **Neue Gegenrichtung, die die Bindung selbst erzeugt:** drei `upsert`-Pfade laufen auf Eindeutigkeitsschluesseln ohne Mandantendimension; ist die Zeile unter dem gebundenen Kontext unsichtbar, wird aus stillem Ueberschreiben ein harter Fehler — jetzt als deutsche Meldung statt als 500. **Der Verifizierer fand, dass genau eine der drei fehlte** (`setTriage`), obwohl die Zusammenfassung alle drei behauptete; nachgereicht mit 8cbf4c1 samt zwei Tests, deren Rotwerden durch Rueckbau belegt ist. **Befund E, festgehalten statt repariert:** alle fuenf Policies dieses Bereichs lesen nur `tenantId = current_tenant_id()` und haben KEINE Benutzerdimension — zwei Nutzer desselben Mandanten sind auf Datenbankebene fuereinander vollstaendig sichtbar; die Trennung haengt allein am Anwendungscode, der stichprobenartig als korrekt belegt wurde. Produktfrage vor dem zweiten Kunden. **Befund K, neue Reihenfolgebedingung fuer Etappe 4:** der Mailversand holt SMTP aus dem noch nicht umgestellten Bereich `settings` — nach dem Scharfschalten ginge fuer NIEMANDEN mehr eine Mail raus; `settings` muss vor Etappe 4 durch sein. Vierte Zaehlkorrektur des Vorhabens: 62 Rohtreffer sind 61 Modellzugriffe, und von zehn vermeintlichen Controller-Stellen brauchten acht die Durchreichung. **Verifiziert 8/9, Luecke behoben** (772/772 Tests, Typpruefung sauber, 32/32 Live-Pruefungen) | 2026-09-09 | 3498147,3336a6e,df5c5b7,8cbf4c1 | [260909-laa-mandantentrennung-etappe-2-bereich-tende](./quick/260909-laa-mandantentrennung-etappe-2-bereich-tende/) |
|
||||
| 260909-eor | Etappe 1 der Mandantentrennung: Anmeldeweg mandantenfaehig gemacht und alle Zugriffe klassifiziert. **Kernfund (#20):** `forTenant()` setzte den Mandantenkontext per set_config auf der Transaktionsverbindung, dispatchte die Abfrage aber ueber den aeusseren Client — empirisch reproduziert (set_config auf Backend-PID 254999, Abfrage auf 255000, Kontext dort NULL). Die Trennung hat damit nie funktioniert, auch nicht an den Stellen, die sie scheinbar nutzten; nach dem Scharfschalten haetten diese Abfragen NULL Zeilen geliefert, was der LDAP-Loeschzweig als 'Gruppe im Verzeichnis verschwunden' gedeutet und geloescht haette. Behoben und live nachgewiesen. Der Anmeldeweg bekam drei SECURITY-DEFINER-Funktionen als schmale Ausnahme (feste Spaltenliste, Gleichheitsbedingung, LIMIT 1) — eine Policy haette nicht gereicht, weil sie zwangslaeufig die ganze Tabelle freigibt. Browser-Gegenprobe lokal bestanden: Anmeldung laedt das Portal, falsches Kennwort verraet weiterhin nicht welches Feld, Kennwort-vergessen laeuft durch (der einzige Protokollfehler war ein lokal fehlender Mailserver, also NACH dem Datenbankzugriff). Klassifikation aller 227 Zugriffe in 59 Einheiten, maschinell gegen Abdriften abgesichert: 31 muessen mandantengebunden werden, 9 teilweise, 16 betreffen keine mandantengebundene Tabelle, 3 bleiben bewusst uebergreifend. 701 Tests gruen | 2026-09-09 | da0ac04 | [260909-eor-anmeldeweg-mandantenfaehig-machen-und-al](./quick/260909-eor-anmeldeweg-mandantenfaehig-machen-und-al/) |
|
||||
|
||||
## Deferred Items
|
||||
@@ -417,6 +418,6 @@ sind. Kein Anlass, sie vorher erneut vorzulegen.
|
||||
|
||||
Last session: 2026-09-09T12:13:05.681Z
|
||||
Resumed: 2026-09-09 — Sitzung ueber /gsd-resume-work fortgesetzt; Einstiegspunkt Etappe 2 (Bereich ldap), Auswahl des Nutzers steht aus.
|
||||
Stopped at: Etappe 2, zwei von elf Bereichen durch (ldap 260909-ipc, groups 260909-jts). Naechster Bereich: tenders (62 Zugriffe), danach dkv, user, module-registry, dashboard, calendar, tenant, favorites, settings. Der User hat am 2026-09-09 gesagt, die restlichen Bereiche sollen ohne Rueckfrage durchlaufen; beim Scharfschalten (Etappe 4) wird ausdruecklich angehalten.
|
||||
Stopped at: Etappe 2, drei von elf Bereichen durch (ldap 260909-ipc, groups 260909-jts, tenders 260909-laa). Naechster Bereich: dkv (21 Zugriffe), danach user, module-registry, dashboard, calendar, tenant, favorites, settings. ACHTUNG settings: Befund K aus 260909-laa macht ihn zur Reihenfolgebedingung fuer Etappe 4 — ohne ihn kein Mailversand nach dem Scharfschalten. Der User hat am 2026-09-09 gesagt, die restlichen Bereiche sollen ohne Rueckfrage durchlaufen; beim Scharfschalten (Etappe 4) wird ausdruecklich angehalten.
|
||||
Resume file: None
|
||||
Last activity: 2026-09-09 - Completed quick task 260909-jts: Mandantentrennung Etappe 2, Bereich groups (verifiziert 9/9)
|
||||
Last activity: 2026-09-09 - Completed quick task 260909-laa: Mandantentrennung Etappe 2, Bereich tenders (verifiziert 8/9, Luecke behoben)
|
||||
|
||||
+173
@@ -0,0 +1,173 @@
|
||||
---
|
||||
phase: quick-260909-laa
|
||||
plan: 01
|
||||
subsystem: database
|
||||
tags: [prisma, postgresql, row-level-security, multi-tenancy, nestjs]
|
||||
|
||||
# Dependency graph
|
||||
requires:
|
||||
- phase: quick-260909-jts
|
||||
provides: forTenant()/withTenantTransaction() pattern proven for background-job "beides" cases (groups)
|
||||
provides:
|
||||
- Five tender user-CRUD services (saved-search, triage, notification-pref, email-config, rss-feed) bound to forTenant()
|
||||
- Per-hit halves of both tender background services (digest scheduler, matching service) bound to forTenant()
|
||||
- rls-scratch-check.mjs tenders-area section measuring WINDOWS #19 boundary and the missing user dimension in the delivered policies
|
||||
- docs/mandantentrennung-etappe2-fehlerrichtung.md "Bereich tenders" section (signal table + silent-failure form)
|
||||
- docs/mandantentrennung-zugriffsklassifikation.md fully synced for all 23 tenders pairs
|
||||
affects: [quick-260909-next-tenders-area-or-stage-3, settings-area-quick-task, stage-3-planning]
|
||||
|
||||
# Actuals (#2632)
|
||||
actuals:
|
||||
tokens: 39000
|
||||
tasks: 3
|
||||
commits: 3
|
||||
|
||||
tech-stack:
|
||||
added: []
|
||||
patterns:
|
||||
- "forTenant() bound once per method / once per loop-hit-row, never shared across methods (groups/ldap convention)"
|
||||
- "__makeBoundClient() two-client test proof (same in-memory Map, per-call logging wrapper) instead of an identity mock"
|
||||
- "P2002 on a tenant-less unique key (userId, [userId,tenderId]) translated into a German ConflictException — NACHTRAG: bei Lieferung galt das nur fuer die beiden userId-Schluessel; setTriage() auf [userId,tenderId] fehlte und wurde vom Verifizierer gefunden, nachgereicht mit 8cbf4c1 samt zwei Tests, deren Rotwerden durch Rueckbau belegt ist"
|
||||
|
||||
key-files:
|
||||
created: []
|
||||
modified:
|
||||
- apps/api/scripts/rls-scratch-check.mjs
|
||||
- docs/mandantentrennung-etappe2-fehlerrichtung.md
|
||||
- docs/mandantentrennung-zugriffsklassifikation.md
|
||||
- apps/api/src/tenders/tender-saved-search.service.ts
|
||||
- apps/api/src/tenders/tender-triage.service.ts
|
||||
- apps/api/src/tenders/tender-notification-pref.service.ts
|
||||
- apps/api/src/tenders/tender-email-config.service.ts
|
||||
- apps/api/src/tenders/tender-rss-feed.service.ts
|
||||
- apps/api/src/tenders/tenders.controller.ts
|
||||
- apps/api/src/tenders/tender-digest.scheduler.ts
|
||||
- apps/api/src/tenders/tender-matching.service.ts
|
||||
|
||||
key-decisions:
|
||||
- "tender-rss-feed.service.ts reclassified from muss-mandantengebunden to beides (same precedent as ldapConfig in 260909-ipc) — createForUser binds, listForUser/createPlatform/remove stay deliberately unbound (WINDOWS #19)"
|
||||
- "No withTenantTransaction() introduced in this area — measured exactly one $transaction (array form, platform-global Tender table, tender-fingerprint-backfill.service.ts), outside any tenant binding"
|
||||
- "tender-digest.scheduler.ts candidate query additionally selects the denormalized tenantId of the match row so the loop can bind; the tenant-switch edge case is named, not solved (Stage 3)"
|
||||
|
||||
patterns-established:
|
||||
- "Silent-failure notification form documented separately from the visible-emptiness form in the critique doc, with the notifiedAt-stays-NULL retry guarantee as the one checkable signal"
|
||||
|
||||
requirements-completed: [WINDOWS-20, ETAPPE-2-TENDERS]
|
||||
|
||||
coverage:
|
||||
- id: D1
|
||||
description: "rls-scratch-check.mjs tenders-area section measures the three special cases (no user dimension in the policies, WINDOWS #19 platform-row invisibility, P2002 on a bound upsert to an invisible row) against the delivered migration"
|
||||
verification:
|
||||
- kind: other
|
||||
ref: "node apps/api/scripts/rls-scratch-check.mjs — 32/32 checks passed"
|
||||
status: pass
|
||||
human_judgment: false
|
||||
- id: D2
|
||||
description: "Five user-CRUD services (saved-search, triage, notification-pref, email-config, rss-feed) bound to forTenant(); rss-feed's three intentionally-unbound paths stay unbound with WINDOWS #19 comments"
|
||||
requirement: "WINDOWS-20"
|
||||
verification:
|
||||
- kind: unit
|
||||
ref: "apps/api/src/tenders/tender-saved-search.service.spec.ts, tender-triage.service.spec.ts, tender-notification-pref.service.spec.ts, tender-email-config.service.spec.ts, tender-rss-feed.service.spec.ts, tenders.controller.spec.ts"
|
||||
status: pass
|
||||
human_judgment: false
|
||||
- id: D3
|
||||
description: "Per-hit halves of tender-digest.scheduler.ts and tender-matching.service.ts bound to forTenant(); cross-tenant candidate/profile queries stay unbound with a Stage-3-handoff comment"
|
||||
requirement: "ETAPPE-2-TENDERS"
|
||||
verification:
|
||||
- kind: unit
|
||||
ref: "apps/api/src/tenders/tender-digest.scheduler.spec.ts, tender-matching.service.spec.ts, tender-notifications.integration.spec.ts"
|
||||
status: pass
|
||||
human_judgment: false
|
||||
- id: D4
|
||||
description: "docs/mandantentrennung-etappe2-fehlerrichtung.md gets a 'Bereich tenders' section with the observed measurement, a per-path signal table, and a dedicated silent-failure-form subsection; docs/mandantentrennung-zugriffsklassifikation.md stays in sync with rls-access-inventory.spec.ts for all 23 tenders pairs"
|
||||
verification:
|
||||
- kind: unit
|
||||
ref: "apps/api/src/prisma/rls-access-inventory.spec.ts"
|
||||
status: pass
|
||||
human_judgment: false
|
||||
|
||||
duration: 45min
|
||||
completed: 2026-09-09
|
||||
status: complete
|
||||
---
|
||||
|
||||
# Quick Task 260909-laa: Etappe 2 Bereich tenders Summary
|
||||
|
||||
**Five tender user-CRUD services and the per-hit halves of two background notification services bound to `forTenant()`, with the platform-wide catalog, two fan-out adapters, and three WINDOWS-#19-affected RSS paths deliberately left unbound and documented as such.**
|
||||
|
||||
## Performance
|
||||
|
||||
- **Duration:** ~45 min
|
||||
- **Started:** 2026-09-09T13:20:00Z (approx.)
|
||||
- **Completed:** 2026-09-09T14:03:00Z
|
||||
- **Tasks:** 3
|
||||
- **Files modified:** 20 (13 source/spec files + 2 docs, across three commits)
|
||||
|
||||
## Accomplishments
|
||||
|
||||
- Measured the three special cases of this area against the delivered `_rls_remaining_tenant_tables` migration (32/32 scratch checks): the five policies have no user dimension, a platform-wide RSS row is invisible under every tenant context, and a bound `upsert` onto an invisible cross-tenant row fails on the unique constraint, not the policy.
|
||||
- Bound the five per-user CRUD services (`tender-saved-search`, `tender-triage`, `tender-notification-pref`, `tender-email-config`, `tender-rss-feed`) to `forTenant()`; `tender-rss-feed.service.ts` binds only `createForUser` and leaves `listForUser`/`createPlatform`/`remove` deliberately unbound with a WINDOWS #19 code comment, because they touch the nullable-tenant platform-wide row.
|
||||
- Bound the per-hit halves of both background notification services (`tender-digest.scheduler.ts`, `tender-matching.service.ts`) to the tenant of the candidate/profile row currently being processed; their cross-tenant candidate/profile queries stay unbound and are commented as a Stage 3 handoff.
|
||||
- Wrote a `## Bereich tenders` section into the critique document with the observed scratch-tool output, a per-path signal table, and a dedicated subsection for this area's new failure form: two notification paths that, on too little read, send nothing — silently.
|
||||
- Kept `docs/mandantentrennung-zugriffsklassifikation.md` in sync with `rls-access-inventory.spec.ts` for all 23 tenders pairs, including reclassifying `tenderRssFeedSource` from `muss-mandantengebunden` to `beides`.
|
||||
|
||||
## Task Commits
|
||||
|
||||
Each task was committed atomically:
|
||||
|
||||
1. **Task 1: Measure the three special cases and write the tenders failure-direction section** - `3498147` (feat)
|
||||
2. **Task 2: Bind the five user-CRUD services and thread tenantId through the controller** - `3336a6e` (feat)
|
||||
3. **Task 3: Bind the per-hit halves of both background services and close both documents** - `df5c5b7` (feat)
|
||||
|
||||
**Plan metadata:** committed separately by the orchestrator after this summary.
|
||||
|
||||
_Note: all three tasks were TDD-flavored (test proof before/alongside the binding change), single commit per task since the two-client proof and the binding change belong to the same logical unit._
|
||||
|
||||
## Files Created/Modified
|
||||
|
||||
- `apps/api/scripts/rls-scratch-check.mjs` — new `runTendersAreaChecks` section (9 checks: no user dimension, WINDOWS #19 invisibility + rejected insert, P2002 on invisible-row upsert), wired into `main()` after `runGroupsAreaChecks`
|
||||
- `docs/mandantentrennung-etappe2-fehlerrichtung.md` — new `## Bereich tenders` section (t1–t5), plus a Task 3 nachtrag closing the per-hit halves
|
||||
- `docs/mandantentrennung-zugriffsklassifikation.md` — Stand column for 5 pairs updated in Task 2, 5 more in Task 3; area overview table, class distribution, and "Der Hintergrunddienst als Falle" section all re-measured and updated
|
||||
- `apps/api/src/tenders/tender-saved-search.service.ts` — `list`/`update`/`remove` bind via `forTenant()`, gained `tenantId` parameter
|
||||
- `apps/api/src/tenders/tender-triage.service.ts` — `listForUser`/`favoriteIds` bind via `forTenant()`, gained `tenantId` parameter
|
||||
- `apps/api/src/tenders/tender-notification-pref.service.ts` — `getForUser` binds, `setForUser` translates P2002 into a German `ConflictException`
|
||||
- `apps/api/src/tenders/tender-email-config.service.ts` — `getConfigForApi`/`testConnection` bind and gained `tenantId`; `saveConfig`'s internal read now also binds; P2002 translated
|
||||
- `apps/api/src/tenders/tender-rss-feed.service.ts` — `createForUser` binds; `listForUser`/`createPlatform`/`remove` stay unbound with WINDOWS #19 comments
|
||||
- `apps/api/src/tenders/tenders.controller.ts` — eight call sites thread `tenantId` from `extractTriageContext` into the newly-parameterized service methods
|
||||
- `apps/api/src/tenders/tender-digest.scheduler.ts` — candidate query selects denormalized `tenantId`; per-candidate loop binds pref/match/user/stamp
|
||||
- `apps/api/src/tenders/tender-matching.service.ts` — per-profile loop binds match upsert and the instant-dispatch fresh/user/stamp accesses
|
||||
- All corresponding `.spec.ts` files — `__makeBoundClient()` two-client proof, per-method binding tests, gegentest for the three intentionally-unbound RSS paths, silent-failure tests for both background services
|
||||
|
||||
## Decisions Made
|
||||
|
||||
- `tender-rss-feed.service.ts`/`tenderRssFeedSource` reclassified from `muss-mandantengebunden` to `beides` in the classification doc — mirrors the `ldapConfig` precedent from 260909-ipc, no behavior change, just a more accurate class.
|
||||
- No `withTenantTransaction()` introduced anywhere in this area: Task 1 measured exactly one `$transaction` in `apps/api/src/tenders` (array form, on the platform-global `Tender` table in `tender-fingerprint-backfill.service.ts`), outside any tenant binding — the extension header's mandated re-check for a new transactional case is answered with "no new case," not assumed.
|
||||
- The digest scheduler's candidate query now additionally selects the match row's denormalized `tenantId` so the per-row loop can bind at all; the edge case of a user having matches under two different tenants (a stale denormalized value after a tenant switch) is named in code and in both docs, not solved — explicitly Stage 3's problem.
|
||||
|
||||
## Deviations from Plan
|
||||
|
||||
None — plan executed exactly as written. The one place where execution diverged from the plan's literal wording (Befund C's "zehn Aufrufstellen") is a clarification, not a deviation: of the ten controller call sites that today discard `tenantId`, only eight actually needed the parameter threaded through, because the two RSS call sites (`listRssFeeds`, `removeRssFeed`) call service methods (`listForUser`, `remove`) that deliberately stay unbound and therefore never gained a `tenantId` parameter. This is the same "a raw count is a claim, not a finding" lesson the plan itself calls out repeatedly (Befund C is analogous to the 62-vs-61 raw-hit correction) — verified by re-reading each of the ten call sites individually rather than trusting the count.
|
||||
|
||||
## Issues Encountered
|
||||
|
||||
- The `rls-access-inventory.spec.ts` doc-vs-source consistency check failed after Task 2's and Task 3's binding changes, as expected since the check runs on every test invocation — the classification doc's Stand column was updated within the same task (not deferred to a later pass) so every task's own verification stayed self-contained and green.
|
||||
- TypeScript flagged two implicit-`any` parameters in `tender-matching.service.ts` after `tenantPrisma` (typed `any`) replaced `this.prisma` as the receiver for two `.map()` calls — fixed with explicit inline parameter types (`match: { tender: unknown }`, `match: { id: string }`).
|
||||
|
||||
## User Setup Required
|
||||
|
||||
None — no external service configuration required. `DATABASE_URL` remains on the `tessera` role with `BYPASSRLS`; the switch stays off.
|
||||
|
||||
## Next Phase Readiness
|
||||
|
||||
- The `tenders` area is now at a mixed-but-fully-documented state: 5 pairs fully bound, 1 pair (`tenderRssFeedSource`) mixed with a code-level WINDOWS #19 boundary, 2 pairs (`tenderMatch`/`user` in the two background services split across `beides`/`gemischt`) with their per-hit halves closed and cross-tenant halves named as Stage 3 handoffs, and 12 pairs deliberately untouched (D-03 catalog + fan-out adapters).
|
||||
- Stage 3 inherits: the WINDOWS #19 policy fix for `TenderRssFeedSource`/`SearchProvider`, the cross-tenant halves of the two background services (with the documented tenant-switch edge case), and the `req.tenantPrisma` architecture question (still undecided, as in every prior area).
|
||||
- Stage 4 (cutover) preflight inherits Befund K: `tender-mail.service.ts` depends on `SettingsService.getDecryptedSmtpConfig(tenantId)`, and `settings.service.ts` (4 raw hits) is still fully unbound — after cutover this would silently stop all outbound mail. Recorded in the critique doc, not solved here.
|
||||
- The classification doc's area overview now shows `tenders` at 36 ungebunden / 26 gebunden (was 62/0); remaining areas at their prior stand: `dkv` (21), `user` (17), `module-registry` (17), `dashboard` (13), `calendar` (12), `tenant` (8), `favorites` (7), `settings` (4) — all still fully untouched, the largest remaining pool of work for whichever Stage 2 area comes next.
|
||||
|
||||
---
|
||||
*Phase: quick-260909-laa*
|
||||
*Completed: 2026-09-09*
|
||||
|
||||
## Self-Check: PASSED
|
||||
|
||||
All 12 referenced artifact files found on disk; all 3 task commit hashes (`3498147`, `3336a6e`, `df5c5b7`) found in git history.
|
||||
+153
@@ -0,0 +1,153 @@
|
||||
---
|
||||
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)_
|
||||
Reference in New Issue
Block a user