feat/discovery

export_columns on alsoOn surface (descargas) may CTA-redirect to wrong page

domains/cross-domain/src/feature-discovery.decisions.ts:123

When decideSpotlight returns 'export_columns' because the user is on bills-descargas (via alsoOn), the returned key resolves to signal.page = 'bills-contratos'. If the UI uses signal.page as the CTA navigation destination, users on descargas who click 'Configurar columnas' will be taken to contratos instead of /settings/columns. The DiscoverySignal.page JSDoc says 'The hub still deep-links to page' but does not clarify behavior for the in-page spotlight CTA on an alsoOn surface. Confirm spotlight-catalog.ts or the FeatureSpotlight CTA routes to /settings/columns directly, not through the catalog page.

Deleted requestedKey test was testing an impossible case (export_columns on contratos was cross-page before)

domains/cross-domain/src/__tests__/feature-discovery.decisions.test.ts:329

Minor: the old test ('never returns a requested key that belongs to another page') requested export_columns from the default page (contratos). Since export_columns previously lived on bills-descargas, this correctly returned null. Now export_columns lives on contratos so the old assertion would return the key — deletion is correct. No action needed here beyond the missing cross-page test noted above.

listEligibleSpotlights duplicates eligibility guards from eligibleCandidatesOnPage

domains/cross-domain/src/feature-discovery.decisions.ts:264

The refactored listEligibleSpotlights re-implements the adminOnly + hasCfeCredential + eligible() + isRetired() guards that already live in eligibleCandidatesOnPage. If eligibleCandidatesOnPage is still used by decideSpotlight, the two eligibility paths must stay in sync manually. Extracting a shared predicate (isEligibleForHub vs isEligibleOnPage) or having the hub iterate via a page-independent helper would be safer.

Priority 1→5 change lacks a catalog-level ordering comment

domains/cross-domain/src/feature-discovery.decisions.ts:111

The inline comment explains the rationale ('Priority after the core setup/activate signals so it doesn't pre-empt them on Contratos') but there is no summary comment on the catalog that documents the intended priority order across all signals. As the catalog grows, a brief ordering legend (e.g. '// priority: 1=cfe 2=monitoring 3=payment 4=ids 5=columns 6=api') would help future editors avoid accidental re-ranking.

activeRecibosConfigId column assumed present on userPreferences — confirm migration covers it

domains/cross-domain/src/feature-discovery.queries.ts:87

The query now selects userPreferences.activeRecibosConfigId. If this column was added in the current branch, confirm the Drizzle migration (0058 or a prior one) covers the userPreferences table (not just discovery_state). Typecheck green implies the Drizzle schema already has the column; this is an informational flag for the reviewer's awareness.

Both-configs-set suppression not tested from contratos (the new primary surface)

domains/cross-domain/src/__tests__/feature-discovery.decisions.test.ts:170

The 'both set → done' assertion is only exercised from bills-descargas. There is no case asserting that decideSpotlight(page='bills-contratos', hasRecibosConfig=true, hasDescargasConfig=true) returns null. A regression where the contratos path ignores the combined-completion gate would go undetected.

Cross-page suppression for export_columns no longer tested

domains/cross-domain/src/__tests__/feature-discovery.decisions.test.ts:329

The deleted test verified that requesting export_columns on a page that is neither its primary nor alsoOn returns null. That cross-page blocking case is now entirely untested for export_columns. The replacement test uses api_keys (an adminOnly signal) which is a different gate. A minimal additional case — e.g. requestedKey='export_columns' on 'credentials-api' → null — would restore coverage.

No symmetric test: export_columns fires on descargas after core signals are settled

domains/cross-domain/src/__tests__/feature-discovery.decisions.test.ts:181

The new contratos test verifies that export_columns surfaces after core signals (hasMonitored, hasPaymentMonitored, hasInternalSiteIds) are satisfied. There is no symmetric descargas test confirming the same settled-state fires export_columns as a secondary surface. The per-view test only uses baseSignals, leaving an asymmetry between the two surfaces.

listEligibleSpotlights comment updated but no new structural assertion added

domains/cross-domain/src/__tests__/feature-discovery.decisions.test.ts:345

The comment on expect(keys).toContain('export_columns') was updated to mention 'bills-contratos (primary) + descargas' but the assertion unchanged. A test that explicitly calls listEligibleSpotlights and checks the returned page field is 'bills-contratos' (the catalog's primary) would give structural confidence the hub deep-link promotion is preserved.