Six fixes for things that loaded fine and showed nothing

[guillaumelauzier]

Platform audit, part five. 1064/1064 tests, typecheck clean, lint 0 errors, all three gates green, Jekyll builds.

Every fix here shares one failure mode: a query that parses, runs, returns nothing, and is indistinguishable from healthy-and-empty. Nothing errors, nothing logs, and the screen just says there is no data.

---

1. Four dashboard paths that loaded and showed nothing

• /dashboard/profile/ ignored ?id=. profile-tab.js read only ?entity=. Seven links across six pages pass ?id= — ops-garbage-review.js, predictions.html (twice), watchlists.html, power-nodes.html, dossiers.html, ops-quality.html — and every one landed on "No entity selected." Fixed in the reader rather than at the seven call sites, so links written the same way in future also work.
• The Leads list sent a legacy id to an entity-keyed page. Every name linked to /dashboard/people/?id=<leads.id>, but that page feeds the value to /api/profilers/:entity_id/*, keyed on u_entities. A legacy integer id never matches a uuid, so every name on the page opened a profile with every panel blank. GET /api/leads now returns the mapped entity_id — the listing already joins entity_legacy_map for the role badges, so it costs one more correlated subquery — and the name links there, or to the lead detail page when no entity exists yet.
• Bulk "select page" was dead on two of the four pages that offer it. bulk-bar.js resolved #ads-bulk-header-check once in init(). On leads and accounts that cell is static HTML, so it worked. On investors and companies it is emitted inside the async row render — absent at init(), and replaced wholesale on every non-append load. The checkbox still ticked, so it looked like it had worked. Now bound by delegation, like the bar's own buttons.
• The deep health sweep was publicly callable. The Access allow-list covers /api/health because it is a cheap liveness probe, but /deep shares that router: 18 binding probes, three COUNT(*) scans of error_log, and a live fetchPage() with an 8 s budget that walks every fetcher tier — including the metered Browser Rendering tier when the cheaper tiers escalate. Unauthenticated, anyone could drive that in a loop. Verified against the repo's own Hono that /health and /api/health still answer 200 and both deep paths answer 401. The documented operator workflow is a browser session, which carries the cookie the guard reads, so it is unaffected; the ops checklist now says so and points uptime monitors at the cheap probe.

2. Persona matching could not score above 0.90, on anything, ever

scoreCompanySize carries weight 0.10 and returns 0 with reason "company size unknown" when it has no headcount. loadEmployerFacts asked facts for four spellings — org.headcount, org.employees, company.employees, company.headcount — and nothing in the worker writes any of them. A hard ceiling of 0.90 on every match, and a permanent false line in the rationale the dashboard shows to explain why someone matched.

The predicate that exists is bare employees: what the registry declares in entities/profile-predicates.ts and what secEdgar/persist.ts writes. Closed end to end, because fixing two of three would look right and still score 0.90:

• The account dual-write now emits it — accounts.employees was the one sizing column it dropped, so no account entity carried a headcount fact at all.
• backfillAccounts names its columns explicitly and did not name that one, so the bulk path — the one that actually populates the graph — would have kept dropping it.
• personaMatchTrigger's RELEVANT_PREDICATES gains it, or a fresh headcount fact never re-scores its entity.

Checked and left alone: loadEntityCoords reads six lat/lng predicates nothing writes either, but scoreGeo falls back to a country centroid and then an ISO2 comparison — degrading as designed rather than silently zeroing a component.

3. Sector lookups read predicates nothing writes

Found by scanning every predicate = '...' and predicate IN (...) read site in the worker against every predicate: "..." write site, then keeping only the sites where no alternative in the list has a writer. That narrowed 43 orphan predicates to 11 read sites. Two were live defects:

• Per-sector PageRank ran on an empty map, every sweep. loadPrimarySectors drives the partition computeInfluence uses for per-sector PageRank and the per-sector power-node flags. Every node fell into one unsectored bucket and sectors_ranked was 0 — identical to a graph that genuinely has no sector data, which is why it went unnoticed.
• Filtering a comp panel by sector returned an empty panel, always. A sector miss does not widen the result — it continues past the candidate. So an operator who filtered by sector got an empty panel and the reasonable conclusion that nothing was comparable. The private-member discovery query had the same predicates in a JOIN; getCompanySector returned null for every company, so impliedValuation's sector-matched panel fallback never fired.

What is actually written: the plural firm.sectors (a JSON array in value_json, from the profile workflows), industry (value_text, from the account dual-write), and entity_summary.sectors_csv (the materialised slug list the summary rebuild derives from sector tags). entities/sector.ts is now the one place that knows all three shapes.

sectors_csv is matched with comma-delimited instr, not a substring test — a bare instr matches "fin" inside "fintech" and would widen every filter it was meant to narrow. monitoring/smart.ts already uses this technique against the same column.

Deliberately left alone: company.business_model in the same screen also has no writer, but unlike sector there is no alternative spelling anywhere in the schema to converge on. Widening it would mean inventing a source.

4. Founder diligence could not link a founder through facts

getFoundersOf unions a founder.company_founded fact with career_history rows whose role title contains "founder". The fact branch matched on value_entity_id, but the only writer — crawler/profileWorkflows/founder.ts — stores the company as free text in value_text, because at extraction time it has a name off a bio page and no resolved entity.

The branch returned nothing every time. It did not fail loudly: the union silently reduced to the career path, and where that had no row with a resolved organization_entity_id, the founder checks reported "no founders on record" rather than "we could not link them."

Blank names are excluded explicitly — without that, TRIM('') = TRIM(' ') joins every blank-named fact to every blank-named company.

Checked and left alone: company.privacy_policy_url and company.customer_logo also have no writer, but those checks return cautionResult("No privacy policy URL on record.") and needsHuman("no_customer_logos_recorded") — visible, correct outcomes for absent data.

5. The weekly firm team snapshot picked zero firms, forever

runWeeklySnapshotSweep is the only producer for firm_team_snapshots, which the spinout detector reads to notice partners leaving. Its eligibility query required both a current firm.team_url fact (no writer) and entity_roles.role = 'investor_firm' (assigned only by deals/investorResolver, while every firm that got its role from the dual-write carries firm). Either alone was fatal, and the sweep returned picked:0 — which is also what "every firm is up to date" looks like.

firm_people.source_url is the page scraper/pipeline.ts actually parsed a firm's people from, and the only populated team-page URL in the schema. It is now a second-preference candidate behind the explicit fact, so an operator override still wins, and ROW_NUMBER collapses the two sources to one row per firm. The role filter is widened to the set the sibling detector (movements/spinout.ts) already uses — two files in the same feature reading the same graph through different role sets was itself part of the bug.

6. An idle buyer-signal crawler looked exactly like a working one

The seven ATS sources — greenhouse, lever, ashby, workable, recruitee, personio, smartrecruiters — each select accounts by an operator-set meta_json key. Nothing sets those keys automatically. That is by design, but it means a deployment where nobody has seeded one records 0 emitted, ok: byte-for-byte the same run row as a source that fetched a hundred boards and found nothing new.

Each source now returns seeded_accounts and boards_fetched, counted from the loop rather than hardcoded. That alone would have changed nothing, because the channel was never connected: CrawlResult.meta is documented as "per-source counters appended to crawler_runs.meta_json" and the column has existed since migration 161, but runCrawl.ts never read the field and its finalize UPDATE never wrote the column. Both fixed, stringifying defensively so an unserialisable value cannot be the reason a run records no outcome at all. The crawlers console gains a Notes column — meta_json already reached the client via SELECT *, nothing displayed it.

This does not build ATS detection — no key is now set that was not set before. It makes the absence visible instead of silent.

---

Verification

Eight new test files, 48 tests. Each was run with its fix reverted to confirm it fails. The SQL-level ones lift the statement out of the source and execute it against the real migrations, because in every case the bug was a query that parsed, ran, and matched nothing — reading it would not have caught it. The site has no JS test runner, so the three dashboard contracts are asserted statically over the files, the approach ci_wrangler_version.test.mjs already takes for the workflow YAML.

One correction: I suspected admin.ts's backfill-coverage counters were broken — they join entity_legacy_map without a CAST, and firms.id/companies.id are INTEGER against a TEXT legacy_id. I expected that never to match. It does; SQLite applies numeric affinity to the TEXT operand. Verified against the same engine before touching anything, so no change was made.

Still open, and needs you

Unchanged from #39 and #40: src/ai/workflows.ts declares all 29 Workflow classes as plain classes with a run method rather than extending WorkflowEntrypoint. If that assumption is wrong, every Workflow instance fails on start — which would also mean the profiler batch and the frontier drain silently do nothing. Not checkable without a live dispatch, and I will not rewrite 29 classes on a guess. If you can dispatch one Workflow and say whether it runs, I will act on the answer.

Verified real and deliberately not fixed here: publication_authors and identity_posts have no migration and no writer, and both consumers document the absence and degrade honestly; 292 mutating handlers have no Origin/Referer check, which is a design decision rather than a patch.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EgworUXKA6pZzEcUUJXCmA

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	lead	418d7a7	Sep 06 2026, 11:16 PM