Decide and prune the parallel Neon fish-data path

[paccloud]

What to build

The repo maintains two sources of yield data: the static dataset the frontend actually uses (89 species, fully test-covered), and a parallel database-backed path (a fish-data API endpoint, Neon species/yield tables, and an import script) that nothing in the frontend calls.

Decision needed: is the database path the future (per PRD.md) or dead weight? Then either delete the unused endpoint/tables/import script, or wire the frontend to it behind a flag — and document the canonical data source in CLAUDE.md so contributors stop maintaining two data models.

Context: AUDIT_REPORT.md §2 (surprises), task 2.4, Open Question #5 (branch claude/repo-audit-improvement-ozhlau).

Acceptance criteria

• Decision recorded (static file canonical vs. DB-backed roadmap)
• The losing path is deleted or the winning path is actually used — no orphaned parallel implementation remains
• CLAUDE.md documents the canonical data source

Blocked by

None - can start immediately (decision first)

[paccloud]

This was generated by AI during triage.

Re-triage: reopened as ready-for-human, and it's worse than when filed

On main (d6ee642) the fish-data endpoint is no longer dead. The calculator fetches it (added in cb8ee3c), which turns the duplicate data model into a live divergence:

• The calculator seeds from the static FISH_DATA_V3, then replaces it with the /api/fish-data response whenever that response is non-empty. On error it silently keeps the static data.
• Local and production serve different datasets. The SQLite adapter returns the static file. The Neon adapter reads the species, fish_yields, and species_profiles tables.
• Likely production bug: the only script that populates those tables (scripts/import-fish-data-to-neon.js) creates a table named profiles, not species_profiles. The production read has no creator anywhere in the repo, so it probably 500s and the frontend silently falls back. Or, if the tables exist and are stale, production shows different yields from local.
• A third representation now exists: the SQL Connect sandbox's PublicSpecies/PublicYieldConversion in dataconnect/.
• The mergeFishData module (feat: fish-data merge module owning precedence rules #52) owns precedence rules, but only tests call it. The calculator merges inline.
• No doc says which source is canonical.

Why this can't go to an agent yet: choosing the canonical source is a product and data-ownership decision. Should MAB-37 yields stay a bundled file or become DB-managed? It also needs a look at what the production Neon tables actually contain, which can't be seen from the repo.

Once you pick, the brief below is agent-ready. It is written assuming the static dataset is canonical; adjust if you choose otherwise.

Agent Brief

Category: enhancement
Summary: Make one research yield dataset canonical and remove the other fish-data representations.

Current behavior: described above.

Desired behavior (assuming static is canonical):

• The fish-data endpoint returns the bundled static dataset (conversions, profiles, source attribution) in both environments, with an identical payload shape.
• The production adapter no longer queries the species, yields, or species-profiles tables, and the one-off Neon import script is deleted.
• The calculator builds its species list through mergeFishData (static base, then custom yields, then local custom species) and stops merging inline.
• A non-2xx or error-bodied fish-data response never replaces the data.
• The project guide and architecture docs name the canonical source and describe the SQL Connect public-species schema as an unwired sandbox.

Key interfaces: handleGetFishData, the DbAdapter method getFishData() → { fishData, profiles, source }, the static exports FISH_DATA_V3/PROFILES_DATA/DATA_SOURCE, mergeFishData(staticData, customYields, customSpecies), and the calculator's fish-data fetch effect and combinedData memo.

Acceptance criteria:

• Production and local getFishData() return deep-equal payloads, with a unit test for each adapter against the static exports
• No runtime code references the species, fish_yields, or species_profiles tables
• The Neon fish-data import script is removed, along with any doc references to it
• The calculator uses mergeFishData, with a test that custom yields override static conversions for the same species and label
• A failed or error-bodied response leaves the calculator on static data (tested)
• Docs name the canonical source and describe the SQL Connect schema as a sandbox
• Lint and tests pass

Out of scope:

• Dropping the tables from the live database (a manual operator step; note it in the PR)
• Migrating yields to SQL Connect
• Editing yield values in the dataset
• Custom-yield or community-data storage

---

Generated by Claude Code