fix(seed): rename the purchased-goods dimension from Destino to Origen

[mrivas00]

What & why

• The "Productos comprados" capture form labels its second dimension "Destino", but its values are "Primera mano", "Reutilizado" and "Con material reciclado" — that is where the purchased material comes from. Raised in the verifier feedback session on the demo (Sept 2026).
• "Destino" is correct in "Disposición de residuos sólidos" and stays there. Two separate dimensions happened to share the name.
• First of the two content PRs from that review that need a data migration, because this label lives in the database and the seed cannot re-apply it to an installed deployment.

Key changes & decisions

1. The seed label

tools/seed/src/data/base/methodologies.json · dd91382, tools/seed/src/data/testing/methodologies.json · 16b60e8

• Trigger — wrong word on a field people fill in.
• Change — the dimension's name becomes "Origen". Exactly one of the two "name": "Destino" entries in the file changes; the waste one is left. The testing dataset carries the same PD / "Metodología inicial" dimension and gets the same one-line change, keeping both datasets in sync as the earlier methodology-content PRs did (fresh testing databases are seeded after migrations run, so the migration alone would leave them on "Destino"). The manual-testing doc table header follows along (edf7026).
• Why this way — the code keeps its historical Productos comprados_Destino value. It is the key every emission factor of the subcategory references the dimension by (19 references in the same file) and it backs a partial unique index on ("subcategory_id", "code"). Renaming it would move a key to fix a label — the same trade-off as the rate-unit abbreviation in the CO₂e PR, resolved the same way.

2. The migration that lands it on installed deployments

packages/database/.../20260924120000_rename_purchased_goods_dimension_to_origin · 32f9227

• Trigger — seed.ts aborts the whole run when the database already contains data (the country-count gate), so a running instance keeps serving the name it was seeded with. The seed edit alone reaches only fresh installs.
• Change — one guarded UPDATE, matched by the dimension's code and scoped through category → methodology_version → country to the demo country's base methodology.
• Why this way — the shape is lifted from 20260825150000_update_business_travel_transport_explanation: scoping to the demo country's methodology means a country deployment maintaining its own methodology decides for itself, and IS DISTINCT FROM 'Origen' makes a re-run touch zero rows. Matching on code rather than on the old name is what keeps the waste dimension out of range even though it carried the same name.

Test plan

Gates that ran on this branch:

• pnpm format

• pnpm lint — 13/13, zero warnings

• pnpm type-check — 13/13

• pnpm test:api -- /countrySectors/getAllCountrySectors --coverage=false — 15 tests passing, re-run after the rebase. This boots a Testcontainers Postgres and applies the full migration chain, so it proves the new migration is valid SQL and does not break the chain. It does not prove the rename targets the right row: that database is created empty, so the migration runs before any data exists.

• Targeting and idempotency verified separately (before the latest rebase; the migration SQL is byte-identical since, only its folder timestamp changed) against a scratch Postgres: full chain applied with prisma migrate deploy, then rows inserted to mimic a seeded database — the demo country PD and a second country CL, each with both a Productos comprados_Destino and a Disposición de residuos sólidos_Destino dimension, all four named "Destino". Result:

  country	subcategory	name after
  PD	Productos comprados	Origen
  PD	Disposición de residuos sólidos	Destino
  CL	Productos comprados	Destino
  CL	Disposición de residuos sólidos	Destino

  First pass reported UPDATE 1, second pass UPDATE 0. code unchanged on every row.

Manual smoke checks (the app was not launched for this PR):

• Capture a "Productos comprados" line → the second selector is labelled "Origen" and still offers Primera mano / Reutilizado / Con material reciclado.
• Capture a "Disposición de residuos sólidos" line → still labelled "Destino".
• Maintainer → emission factor dimensions → the row reads "Origen" with its code unchanged.
• An existing inventory with captured purchased-goods lines → the selected values are still selected and the computed emissions are unchanged.

Risk / blast radius

• One label on one row of emission_factor_dimension. No factor, no dimension value, no captured line and no computed total is touched.
• A country deployment with its own methodology is deliberately out of range and will keep the old label until its administrators change it — see Out of scope.
• Merge order: rebased onto current main and the timestamp moved 20260915150000 → 20260924120000, so it sorts after the three migrations merged meanwhile (20260915160000, 20260916120000, 20260921120000) and the folder order matches the apply order. None of them touch the tables this UPDATE reads or writes, and the SQL is unchanged.

Out of scope

• Telling República Dominicana. The migration scopes itself to the demo country's methodology by design, so RD — which is loading its own — will not receive this rename. The note for country deployments goes with PR 6, which is where the rest of the methodology-content corrections live.

[nivek0o0]

1. Executive Summary

A small, well-scoped label fix. The migration and its write-up are careful work. Production readiness: Approve with Comments.

I checked these against the code and they hold:

• Targeting. The join path (subcategory → category "Otras emisiones indirectas" → methodology_version "Metodología inicial" → country "PD") matches exactly where Productos comprados_Destino sits in base/methodologies.json. Matching on code rather than name correctly keeps the Disposición de residuos sólidos "Destino" dimension out of range.
• Index safety. The d."status" <> 'DELETED' filter matches the predicate of emission_factor_dimension_subcategory_id_code_active_unique, so it targets at most one row per subcategory. name is not part of any unique index, so the rename cannot collide.
• Idempotency. IS DISTINCT FROM 'Origen' makes a re-run a no-op, the same shape as 20260825150000_update_business_travel_transport_explanation.
• Migration discipline. It is a new additive migration and no existing one is edited. The timestamp 20260915150000 sorts after 20260915140000 as the PR states.
• No name-keyed consumers. Nothing in apps/api, apps/web or tools/seed looks up a dimension by name. Emission factors reference it by dimensionCode, and the web only displays name (maintainer screens, Excel export). The rename cannot break factor resolution or captured lines.
• Scope. The diff matches the description, with no scope creep. CI is green.

3. Prioritized Findings

• 🟢 Low · Maintainability: tools/seed/src/data/testing/methodologies.json:2613 still names the dimension "Destino". Depending on when an environment was seeded, the testing dataset shows either label. Earlier content PRs (#606, #609, #619) kept both datasets in sync. Details are in the inline comment.

8. Final Recommendation

I'd approve once the testing dataset gets the same one-line rename (the author can decline it, since it only affects the testing dataset). The migration is correct, idempotent, scoped the same way as existing precedent, and touches only a display label. It changes no key, factor, captured value or computed total.

Advisory review: submitted as COMMENT.

[nivek0o0]

Checked the follow-up and it looks good:

• The testing dataset now labels the dimension "Origen" too, with the code unchanged (16b60e8), so both seed files match.
• The manual-testing doc table is updated (edf7026). The remaining "Destino" there belongs to the waste subcategory, where it's correct.
• The migration was renamed to 20260924120000 and now sorts after the migrations merged since. The SQL is identical to the version reviewed earlier, and none of the new migrations touch emission_factor_dimension.

CI is green. Approving.