Client-reported 2026-07-30 and never filed: the complications filter 'quedo vacio, no abre nada'

CLIENT-REPORTED DEFECT, verbatim: the complications filter 'quedo vacio. No abre nada'. Reported by the client on 2026-07-30 and it never became a row - found 2026-10-06 by support-evolutiva-cc reading the saved WhatsApp record while assembling the consolidated client-question bundle. Over two months unacknowledged, and nobody was looking for it because it was never filed. FIRST STEP IS VERIFICATION, NOT A FIX, and the coverage limit is real: support's sweep covered the 90 OPEN venus rows only, so this may already live in a CLOSED row and may already be fixed. Check the live app before writing any code. Three outcomes: (a) still broken live - fix it, p1, a filter that opens nothing is a dead control surface the client has been looking at since July; (b) already fixed in a closed row - say which row and SHA, close this one citing it, and that is a good outcome; (c) cannot reproduce - say exactly what you exercised, with which role and which data, because 'works for me' on a client-reported empty dropdown usually means the client's own data population differs from the test account's. READ IT AGAINST VENUS-47 BEFORE DESIGNING ANYTHING. On the same 2026-07-30 exchange the client asked, unprompted, for TWO SEPARATE complication filters rather than one pool. An empty filter and a request to split that filter in two are plausibly one conversation about the same surface, so handle them together and do not ship a fix that the split then re-does. Provenance note for whoever reads this later: the row exists because a client message was read, not because telemetry fired. A filter that renders empty throws no error and logs nothing, so there was no signal to catch - which is why the client record is a monitoring surface and not just context.