feat/discovery

Comment says 'Recibos vs Pagos' but the prop type is 'recibos' | 'pago' (singular)

apps/platform/src/app/[locale]/(dashboard)/bills/contratos/_components/PipelineCell.tsx:858

The MonitorSwitch receives `kind: 'recibos' | 'pago'` (singular 'pago'). The inline comment reads 'Recibos vs Pagos share this component' — 'Pagos' (plural) doesn't match the actual value. No runtime impact, but could mislead a future reader checking isRecibos against the type.

No security concerns

data-tour values are compile-time string literals; no user input is involved and no trust boundaries are crossed.

Inline comment on data-tour span is over-verbose (6 lines for a 2-line WHY)

apps/platform/src/app/[locale]/(dashboard)/bills/contratos/_components/PipelineCell.tsx:851

Project convention: comments only when the WHY is non-obvious; don't explain what the code says. The querySelector first-match behavior is already documented in ContractsTable.tsx's comment block. A single line like '// Spotlight anchor: ring the live toggle per RPU, not the column header' preserves the non-obvious context without restating the code.

E2E anchor assertions downgraded to best-effort — monitoring anchors now untestable in CI

e2e/platform/discovery-anchors.spec.ts:26

Previously the test required [data-tour="monitoring"] and [data-tour="payment_monitoring"] to be visible whenever the table was present. The new guard (`if (count > 0)`) means the assertion body is silently skipped when no contract rows exist — which is always true in CI with no seed data. A future commit that removes the data-tour attributes entirely would pass green. This is a structural coverage gap for the fix being validated. Resolution: add at least one contract row to the E2E seed fixture, restoring the assertions to mandatory.

isRecibos branch in MonitorSwitch has no unit coverage

apps/platform/src/app/[locale]/(dashboard)/bills/contratos/_components/PipelineCell.tsx:856

The conditional `data-tour={isRecibos ? 'monitoring' : 'payment_monitoring'}` is a logic branch determining which spotlight anchor key is emitted. Neither branch is covered by a unit or component test. An inversion of isRecibos (or future refactor) would silently swap the anchor keys, and with the E2E tests now best-effort, this would go undetected.

No structural check that data-tour keys match the spotlight catalog

apps/platform/src/components/discovery/spotlight-catalog.ts

The keys emitted as data-tour attributes ('monitoring', 'payment_monitoring', 'internal_site_ids', 'export_columns') must match keys registered in the spotlight catalog. There is no type-level satisfies check or unit assertion enforcing this alignment. A key rename in either side creates a silent mismatch — the spotlight coachmark simply doesn't appear, and no test catches it.

export_columns guard status ambiguous — should be mandatory if always present

e2e/platform/discovery-anchors.spec.ts:26

export_columns is folded into the best-effort loop alongside monitoring/payment_monitoring (all three skipped when absent). If export_columns is always present for a given org (like internal_site_ids is always present in a header row), it should be a mandatory assertion rather than best-effort.

SPOTLIGHT_ANCHOR_BY_GROUP is a 1-entry map — a direct conditional would be simpler

apps/platform/src/app/[locale]/(dashboard)/bills/contratos/_components/ContractsTable.tsx:192

After removing the recibos and pagos entries, only 'sitio → internal_site_ids' remains. A Partial<Record<…,string>> lookup over one entry adds indirection with no payoff. A direct conditional (`activeGroup === 'sitio' ? 'internal_site_ids' : undefined`) is equally readable and removes the abstraction until a second entry justifies it.

E2E for-loop with count guard is readable but could use a helper

e2e/platform/discovery-anchors.spec.ts:26

Minor: the pattern `for (key of [...]) { if (count > 0) { expect(first()).toBeVisible() } }` is fine but slightly redundant — if count is 0 the assertion is a no-op. Promise.all over the keys with a filter, or a local `expectIfPresent` helper, would read more uniformly. No functional issue on a 3-key list.