test(#323): Niger is CLEARED for #627 — pin the geo wiring that the fix did not carry#643
test(#323): Niger is CLEARED for #627 — pin the geo wiring that the fix did not carry#643ligon wants to merge 4 commits into
Conversation
…ost the column Niger's site-4 cell was already fixed on `development` by 3488b79; PR #627's body still lists it as "not yet written". This re-derived the diagnosis independently from the data, verified cold against #627's core that Niger is genuinely cleared, and adds the regression test the fix did not carry. WHAT THE CELL WAS. `Niger/2011-12/_/data_info.yml`'s `cluster_features.df_geo` pointed at `NER_HouseholdGeovars_Y1.dta` and asked for `lat_dd_mod` / `lon_dd_mod`. Under #627's core: RuntimeError: Niger/2011-12/cluster_features: sub-df(s) 'df_geo' ... loaded but do NOT carry the column(s) the YAML asks for, leaving required declared column(s) ['Latitude', 'Longitude'] ENTIRELY ABSENT from 'cluster_features'. First error: KeyError('lat_dd_mod not in columns of dataframe.') Exactly one failing cell. #627's brief said "Niger's geo file has no lat/lon at all", which invites `optional: true`. THAT IS THE TRAP, and it is the reason this test exists. THE EVIDENCE, from the data. `NER_HouseholdGeovars_Y1.dta` is 4051 x 43 at HOUSEHOLD grain and carries no coordinate column of any name -- only derived raster covariates (dist_road, dist_popcenter, dist_market, af_bio_*, srtm, twi, sq1..sq7, EVI/NDVI). Withholding the coordinates is what a geovariables extract is FOR. But the coordinates ship in the sibling `NER_EA_Offsets.dta`, already DVC-tracked in the same directory: 271 x (grappe, LAT_DD_MOD, LON_DD_MOD), 270 non-null grappes + one trailing null-key row, lat 11.876-18.747 N / lon 0.405-13.698 E. Its grappe set matches ecvmamen_p1's exactly (270/270, no orphans either way; all 3968 households covered), so the merge on v is 1:many, not cartesian. Wrong file AND wrong casing -- not missing data. `optional: true` would also have been wrong in a second way nobody would have noticed: `data_scheme.yml` is COUNTRY-grain, so silencing one wave disarms the required-column guard for the three waves that DO have coordinates (2018-19 grappe_gps_ner2018, 2021-22 s00_me_ner2021 GPS__*). 2014-15 genuinely ships no geovariables and no offsets file, and its cover page has no coordinate column -- honestly absent, correctly not wired. It is invisible to the #323/#515 guard, which fires only on a DROPPED sub-df. No absent-verdict is filed: the ECVMA-II questionnaire has not been read, and an unevidenced closing verdict is worse than an open one. VERIFIED (#627's core on PYTHONPATH with `lsms_library.__file__` asserted to resolve there; this config tree via LSMS_COUNTRIES_ROOT, asserted; isolated LSMS_DATA_DIR wiped before each run with only dvc-cache symlinked -- COLD, because LSMS_NO_CACHE=1 alone is soft for script-path L2-wave parquets; LSMS_GRAIN_STRICT=1 so any cartesian is fatal): before (pre-3488b791 config) RuntimeError, as quoted above after builds, 1599 rows rows Latitude Longitude Region 2011-12 270 270 270 270 <- was 0 2014-15 270 0 0 270 <- not shipped 2018-19 504 493 493 504 2021-22 555 555 555 555 2011-12: 0 duplicate v, 0 null v, lat/lon inside Niger's bounding box. ALL 23 Niger tables build cold under LSMS_GRAIN_STRICT=1 -- 0 raises, 0 cartesian warnings. WHAT THIS ADDS. 9 tests, no config change (development already carries it). Nothing in tests/ mentioned `EA_Offsets`, `LAT_DD_MOD`, or Niger `cluster_features`; the reasoning lived only in a YAML comment, and prose is not enforcement. The tests pin the file, the casing, `merge_how: left` and the one trailing null-key row that makes it load-bearing, the geovariables file's ABSENCE of coordinates (the negative control, made permanent), that Latitude/Longitude stay REQUIRED in data_scheme.yml, and the built table's coverage + grain + freedom from a phantom null-key cluster. Deliberately NOT included: origin/fix/323-niger's 3 `aggregation:` keys (dead config, forbidden by D1) and its EXTENSION re-key / majority-vote cluster_features / plot_inputs reductions -- all Site 1 (#614) work routing through `Niger/_/niger.py`, which GH #637 owns. No file under lsms_library/*.py. Ledger: .coder/ledger/323-niger-config.md. Refs #323, #515, #627. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3dcae09 to
b722bbb
Compare
Adversarial review — PR #643I re-derived every headline number cold and independently, on both cores, and tried to break the tests. The geo diagnosis and the wiring it pins are correct — I verified them at the value level, not just the null-count level. One claim in the PR body and in the git-tracked ledger is false, and two of the nine tests do not discriminate the thing their docstrings say they discriminate. Method. Two throwaway worktrees ( What reproduced exactly (I could not break any of this)
Two checks the PR did not run, which I added because "270 non-null" is not "270 right":
Test discrimination. Verified, not assumed. With HIGH — the "0 raises under
|
…e ledger claim Adversarial review of PR #643 returned FIX_FIRST. The wiring and the diagnosis survived it; three claims and two tests did not. Every number below was re-derived here, cold, in a wiped isolated LSMS_DATA_DIR, on both cores. 1. FALSE CLAIM, CORRECTED (the one with teeth). The ledger and the PR body said "all 23 Niger tables build cold under LSMS_GRAIN_STRICT=1 -- 0 raises". Measured, #627's core, cold: **10 of 23 RAISE** -- cluster_features, household_roster, individual_education, shocks, assets, housing, food_security (2014-15), crop_production and plot_inputs (2011-12), plus household_characteristics as a cascade. In the default mode all 23 build, 10 of them emitting a GrainCollapseWarning; 0 cartesian warnings either way. What was actually established is narrower: #627's required-column RuntimeError no longer fires for Niger. The grain conflicts are pre-existing on `development`, unrelated to the geo wiring, and remain open (GH #614/#637). A git-tracked ledger claiming "Niger is strict-clean" would have suppressed ten cells of real work -- the Albania "no shocks module" failure mode. Corrected in .coder/ledger/323-niger-config.md, in Niger/_/CONTENTS.org (new section, so the next reader of the country's own file cannot be misled), and in the PR body. 2. TWO TAUTOLOGICAL TESTS. test_no_phantom_null_key_cluster and test_2011_12_is_at_cluster_grain pass with AND without `merge_how: left` -- confirmed by dropping only that key: the built table is identical, because the (t, v) collapse goes through groupby, which drops NaN-key rows anyway. The PR body's "checked ... on the built table" was wrong. What `left` actually buys is the elimination of the `nan_key_rows: 1` grain report -- a GrainCollapseWarning, fatal under LSMS_GRAIN_STRICT=1. Added test_2011_12_emits_no_nan_key_grain_warning, which asserts exactly that and fails when the key is dropped; the two invariant tests now say in their docstrings that they do not discriminate and which test does. 3. THE END-TO-END TESTS DISARMED THEMSELVES. The fixture was `except Exception: pytest.skip(...)`. Measured: the old file, reverted config, #627's core -> 3 failed, 3 passed, 3 SKIPPED; under LSMS_GRAIN_STRICT=1 at HEAD -> 6 passed, 3 SKIPPED. The three tests that touch real numbers went green-by-skip on the very regression they exist to catch. The fixture now catches nothing: tests/conftest.py's missing-credentials net (PR #648, merged in here) covers the data-free CI job, and a GrainCollapseError/RuntimeError fails the file. The module drops LSMS_GRAIN_STRICT for its own duration and asserts the strict *condition* directly instead, so it neither skips nor trips over Niger 2014-15's unrelated pre-existing conflict. Also: `<= 1` rather than `== 1` on the offsets file's trailing null-key row (a WB release artifact, not something to fail a test over), and a note on test_merge_how_is_left that the key is inert until #627 lands. DISCRIMINATION, re-measured (10 tests, each row a separate cold run): HEAD config / development core -> 9 passed, 1 skipped HEAD config / #627 core -> 10 passed (also under strict) 2011-12 @ 3488b79^ / development core -> 4 failed, 5 passed, 1 skipped 2011-12 @ 3488b79^ / #627 core -> 3 failed, 4 errors, 3 passed HEAD minus merge_how / #627 core -> 2 failed, 8 passed The reviewer's count of 4 (not the ledger's 3) is right: the fourth is the end-to-end test_2011_12_clusters_all_have_coordinates. Still no change under lsms_library/*.py; Niger/_/niger.py untouched; no `aggregation:` key; no wave `data_info.yml` edited (a comment-only edit there would invalidate the wave's cache hash for nothing). Refs #323, #515, #627. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Su5JKX3wKChyfMAdXrdCTr
b722bbb to
0fa94be
Compare
Fixed. Every finding reproduced independently before it was acted on.Pushed as One trap worth recording, since it nearly cost me the same mistake in reverse: HIGH — "0 raises under
|
| mode | result |
|---|---|
| default | 23 / 23 build; 10 emit GrainCollapseWarning; 0 cartesian warnings |
LSMS_GRAIN_STRICT=1 |
10 of 23 RAISE |
Same ten tables you listed, same waves, same destroyed-row counts (42 / 210 / 58 / 80 / 482 / 23 / 38 / 19 / 51 + the household_characteristics cascade). Corrected in the PR body, in .coder/ledger/323-niger-config.md (the false sentence is replaced by the table, plus an explicit "do not cite this ledger as evidence that Niger needs no further grain work" in §1), and — because it is the file the next person actually opens — in lsms_library/countries/Niger/_/CONTENTS.org, which now carries a dated section listing all ten. The established claim is stated at its true width: #627's required-column RuntimeError no longer fires for Niger; the Site-1/Site-2 grain raises are pre-existing on development and remain open.
MEDIUM — two tests did not test what they said — confirmed and replaced
Dropped only merge_how: left (config otherwise HEAD), #627's core, cold. Result: 2 failed, 8 passed — test_merge_how_is_left and nothing else that mattered; the built table is identical (1599 rows; 2011-12 at 270 clusters, 0 duplicate v, 0 null v). Exactly your structural explanation: the (t, v) collapse goes through groupby, which drops the NaN-key row regardless. The body's "checked … on the built table" is now explicitly retracted in the body, the ledger and CONTENTS.org.
Added test_2011_12_emits_no_nan_key_grain_warning, which does what you suggested: the module fixture builds the country inside warnings.catch_warnings(record=True) and the test asserts no GrainCollapseWarning naming cluster_features/2011-12. Without merge_how it fails with the real message (… 1 row(s) carry NaN in a declared index level and are DELETED OUTRIGHT …). It is scoped to 2011-12 on purpose — 2014-15 emits its own unrelated warning, and asserting silence country-wide would make this test about someone else's bug. Two notes on it: the grain report is stamped into the parquet and re-emitted on read, so it works warm or cold (verified both); and it skips on a core that hardcodes how='outer', with that reason spelled out, since on development the nan-key row is unavoidable and the test would otherwise be red for the wrong reason.
test_2011_12_is_at_cluster_grain and test_no_phantom_null_key_cluster are kept as shape floors, with docstrings that say plainly they pass either way and name the test that discriminates.
MEDIUM — the fixtures disarmed themselves — confirmed, both numbers
Reproduced exactly: old file + LSMS_GRAIN_STRICT=1 at HEAD → 6 passed, 3 skipped; and worse, old file + reverted config on #627's core → 3 failed, 3 passed, 3 skipped, i.e. green-by-skip on the precise regression the file exists to catch. Both except Exception: pytest.skip(...) blocks are gone. tests/conftest.py's missing-credentials net now carries the data-free CI job (note: from conftest import requires_s3 does not work — the repo's root-level conftest.py shadows tests/conftest.py on sys.path; the hook applies without an import, so the module relies on that and says so in a comment). Same revert now gives 3 failed + 4 errors on #627's core: errors, not skips.
The module also drops LSMS_GRAIN_STRICT for its own duration, documented: the strict condition is asserted directly (as the absence of the warning), so the file neither skips nor aborts on 2014-15's unrelated conflict, and it is green under both modes on both cores.
LOW — both taken
<= 1 on the trailing null-key row, with the reason in a comment. test_merge_how_is_left now carries the "inert on development until #627 lands" note. I did not edit the wave's YAML comment: it would invalidate that wave's cache hash for a comment, and the test docstring is the better home for the caveat.
Disputed: one, and it is minor
Your discrimination count of 4 is right and the ledger's 3 was wrong — the fourth is the end-to-end test_2011_12_clusters_all_have_coordinates, which I have now re-measured on both cores (4 failed / 5 passed / 1 skipped on development; 3 failed + 4 errors on #627's, where the required-column raise reaches the fixture first). Corrected in the ledger rather than defended. Nothing else in the review is disputed — the two checks you added (the value-level join, max|Δlat| = max|Δlon| = 0.0, and the losslessness of the 2011-12 collapse from source) are strictly better evidence than what the PR shipped, and my own build corroborates the second independently: the 2011-12 grain report in the outer counterfactual shows nan_key_rows: 1 and zero destroyed rows.
Full test state now: 10 passed on #627's core (strict and non-strict), 9 passed / 1 skipped on development's.
…tests Dropping the blanket `except Exception: skip` left the data-dependent tests resting entirely on tests/conftest.py's missing-credentials NET, which fires only on a `NoCredentialsError`-shaped failure. If the data-free CI job fails some other way -- a RuntimeError out of `data_access` under LSMS_SKIP_AUTH=1, say -- the net does not catch it and the job goes red for an environmental reason. So the six data-dependent tests now carry `requires_s3` explicitly, which is what the other data-touching modules do. `from conftest import requires_s3` does NOT work: the repo has a root-level `conftest.py` and it wins on sys.path, so the plain import raises ImportError (measured). Rather than grow yet another private `_aws_creds_available` copy -- the duplication PR #648 exists to end -- `tests/conftest.py` is loaded by path under its own module name. Unchanged: 10 passed on #627's core, 9 passed / 1 skipped on `development`'s, and dropping only `merge_how: left` still fails exactly two. Refs #323, #627, #648. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Su5JKX3wKChyfMAdXrdCTr
|
Follow-up ( I wrote that the module "relies on the hook, and says so in a comment". On reflection that is too thin a thread: So the six data-dependent tests now carry Nothing else moved: 10 passed on #627's core, 9 passed / 1 skipped on |
|
CI settled it, and it is worth recording which way, because the intermediate commit was a live experiment.
Exactly the hole I described above: the data-free job fails with a
|
Independent verification of the remediation — every review finding re-derived, not taken on trustI re-ran the whole discrimination matrix myself, on my own worktrees, cold. All four findings are genuinely fixed. One false claim survives in a git-tracked file, and it is the one the remediation explicitly declined to touch. Method. Two fresh worktrees of my own (not the remediation agent's): One trap I walked into and record for the next person: my first Discrimination matrix — reproduced row for row
Every number in the PR body and the ledger is correct as written. HIGH — the strict-mode correction is accurate ✅Censused every Same ten tables, same waves, and 23 is the right denominator. The corrected two-mode table is now in the PR body, Cosmetic only: the ledger's non-strict cell says "10 of them emit a MEDIUM — the tautology is genuinely fixed ✅I removed only Byte-identical built table — the retraction is correct and the original "phantom cluster on the built table" claim was indeed false. MEDIUM — the disarm is genuinely fixed ✅Ran the old shipped file ( Both Observation, not a finding against this PR: LOW — both taken ✅
Scope ✅Three files vs. The one thing still outstandingThe retracted claim survives verbatim in a git-tracked source comment, in the file most likely to be read by whoever next edits this wiring — # `left` is load-bearing: the offsets file has ONE trailing row with a
# null grappe (and null coordinates). Under the default `outer` that row
# arrives as a phantom cluster with a null v; `left` drops it, since
# df_main is authoritative for which clusters exist.
merge_how: leftBy my own measurement above, under The stated reason for declining — a comment-only edit invalidates that wave's content hash — is real but small: I rebuilt this exact cell cold repeatedly today in ~1.6 s. It is also the reason Fair note in the other direction: this line is pre-existing on Verdict: fix that comment (three lines) and this is done. Everything the review actually asked for is correct, verified independently, and better evidenced than it was. |
1 participant
Clears the Niger blocker on #627 — and pins it, so it cannot come back.
#627's body lists Niger's fix as "not yet written". It has been written:
3488b791("fix(#323): geo config for Ethiopia + Niger") landed ondevelopmentafter that body was authored. I re-derived the diagnosis independently from the source data, reached the same answer, and verified cold against #627's core that Niger is genuinely cleared. So this PR lands no config change. What it lands is the regression test the fix did not carry, plus the ledger.The failing cell, exactly
Niger / 2011-12 / cluster_features. Under #627's core, with the pre-3488b791config:One cell. No others.
The Latitude/Longitude question — and the trap in it
#627 describes this as "Niger's geo file has no lat/lon at all", which invites the honest-looking fix:
optional: true. That is wrong, and it is wrong twice.First, the premise is half true.
NER_HouseholdGeovars_Y1.dtareally has no coordinates — 4051 × 43 at household grain, carrying only derived raster covariates (dist_road,dist_market,af_bio_*,srtm,twi,sq1…sq7, the EVI/NDVI series). Nolat, nolon, under any casing. Withholding the coordinates is what a geovariables extract is for.But the coordinates ship in the sibling file in the same directory, already DVC-tracked:
NER_EA_Offsets.dta, the WB's standard offset-EA-centroid release — 271 × (grappe,LAT_DD_MOD,LON_DD_MOD), 270 non-null grappe (+1 trailing null-key row), 0 duplicates, lat 11.876–18.747, lon 0.405–13.698, both inside Niger's bounding box.The names the YAML asked for —
lat_dd_mod/lon_dd_mod— are the LSMS-ISA EA-offset names. They were the right names, in the wrong case, pointed at the wrong file. Not missing data.Key alignment measured:
ecvmamen_p1.dtaandNER_EA_Offsets.dtashare exactly 270 grappe with no side-only values either way; all 3968 households fall in a grappe that has coordinates. So the merge onvis 1:many — not cartesian.Second,
optional: truewould have been wrong in a way nobody would have noticed.data_scheme.ymlis country-grain, not wave-grain. Silencing 2011-12 disarms the required-column guard for the three waves that do carry coordinates:NER_EA_Offsets.dtaLAT_DD_MOD/LON_DD_MODgrappe_gps_ner2018.dtacoordonnes_gps__Latitude/__Longitudes00_me_ner2021.dtaGPS__Latitude/GPS__Longitude2014-15 is the one genuinely honest absence: the ECVMA-II distribution ships no geovariables and no offsets file of any kind, and the cover page
ECVMA2_MS00P1.dta(30 columns) has none. It is not wired, and that is correct. It is also invisible to the #323/#515 guard, which fires only on a dropped sub-df. No absent-verdict is filed: the ECVMA-II questionnaire has not been read, and an unevidenced closing verdict is worse than an open cell.Verification
Method: #627's core (
origin/fix/323-site4-dfs-merge) withlsms_library.__file__asserted to resolve there; this config tree viaLSMS_COUNTRIES_ROOT, asserted viapaths.countries_root(); an isolatedLSMS_DATA_DIRwhose only pre-existing content is a symlinkeddvc-cache,Niger/wiped before every run — cold, becauseLSMS_NO_CACHE=1alone is soft for script-path L2-wave parquets. NodvcCLI at any point.Negative control (same core, config reverted to pre-
3488b791): raises, as quoted above.After: builds, 1599 rows.
2011-12: 0 duplicate
v, 0 nullv, coordinates inside Niger's bounding box.Niger is NOT strict-clean — correcting this PR's own false claim
The first version of this body, and of the ledger, said "all 23 Niger tables build cold under
LSMS_GRAIN_STRICT=1with 0 raises and 0 cartesian warnings." That is false. Re-measured twice, cold, #627's core, everydata_schemeentry plus the runtime-derived tables:GrainCollapseWarning; 0 cartesian warningsLSMS_GRAIN_STRICT=1All ten are pre-existing on
development, unrelated to the geo wiring (none is adfs:merge or a coordinate column), and remain open — GH #614 / #637 territory. The corrected statement is in.coder/ledger/323-niger-config.mdand inNiger/_/CONTENTS.org, because a git-tracked file asserting "Niger needs no grain work" would suppress ten cells of it.I did not lean on the suite's green: #627 is right that
test_table_structurereadsvar/*.parquetdirectly and never rebuilds. Every number above is from a cold build in a wiped data root.What this PR contains
tests/test_niger_cluster_features_geo.py— 10 tests. Nothing intests/mentionedEA_Offsets,LAT_DD_MOD, or Nigercluster_features; the reasoning lived only in a YAML comment, and prose is not enforcement. They pin:merge_how: left— and its measurable effect. Precisely: under the defaultouterthe offsets file's trailing null-key row does not reach the built table either (the(t, v)collapse goes throughgroupby, which drops NaN-key rows), so the returned frame is identical. Whatleftremoves is thenan_key_rows: 1grain report — aGrainCollapseWarning, and fatal underLSMS_GRAIN_STRICT=1.test_2011_12_emits_no_nan_key_grain_warningasserts that, and is the only test that sees the difference. (The earlier body claimed the phantom cluster was visible "on the built table". It is not.)NER_HouseholdGeovars_Y1.dtacarries no coordinate and is household-grain — the negative control, made permanent;Latitude/Longitudestay required indata_scheme.yml— i.e. that nobody "fixes" a future raise by deleting a real column and calling it a cleanup;Discrimination, measured (each row a separate cold run in a wiped data root):
developmentmerge_how-effect test — this core ignores the key)LSMS_GRAIN_STRICT=1)2011-12@3488b791^development2011-12@3488b791^merge_how: leftThe earlier "3 of the 4 config-level tests fail" undercounted: on
development's core it is 4, the fourth being the end-to-endtest_2011_12_clusters_all_have_coordinates. Two tests (test_2011_12_is_at_cluster_grain,test_no_phantom_null_key_cluster) pin invariants rather than the fix; their docstrings now say so and name the test that discriminates.The end-to-end fixture no longer disarms itself. It was
except Exception: pytest.skip(...); measured, that turned the reverted-config run into 3 failed, 3 passed, 3 skipped and the strict run at HEAD into 6 passed, 3 skipped — green-by-skip on the exact regression the tests exist to catch. The fixture now catches nothing:tests/conftest.py's missing-credentials net (#648, merged in here) covers the data-free CI job, and aGrainCollapseError/RuntimeErrorfails the file. The module dropsLSMS_GRAIN_STRICTfor its own duration and asserts the strict condition directly instead, so it neither skips nor trips over 2014-15's unrelated pre-existing conflict..coder/ledger/323-niger-config.md— the ledger, with the false strict-clean claim replaced by the table above.lsms_library/countries/Niger/_/CONTENTS.org— two corrections: themerge_howsentence (it claimed the phantom cluster reached the built table), and a new section recording the ten open strict-mode raises.Two things worth knowing that fell out of this
merge_how:does not exist ondevelopment— fix(#323) Site 4: the dfs: merge MANUFACTURES the duplicates — 4.9M phantom rows (UNBLOCKED: Ethiopia/Niger/Nigeria configs merged) #627 introduces it (grep -n merge_how lsms_library/country.pyondevelopment→ nothing). Somerge_how: leftin Niger's config is currently inert, and the wave's YAML comment reads as though the behaviour is live today. The comment is left alone deliberately: editing it would invalidate that wave's cache hash for no behavioural gain.test_merge_how_is_leftcarries the note instead, and the effect test skips on a core that ignores the key.Reported, not fixed:
Niger/cluster_features/2014-15projects a household-grain frame onto(t, v)and destroys 42 of 3,617 rows across 4 conflicting clusters — the head of the ten-table list above. Present ondevelopmenttoday; it isorigin/fix/323-nigeritem B (within-cluster majority), Site 1/2 work routing throughNiger/_/niger.py. Left for fix(#323): close the grain-collapse CLASS — audit before collapse, persist the signal through the cache #614 / bug: groupby().first() is not first_row() — skipna=True fabricates composite rows (49 sites) #637.Deliberately not included
origin/fix/323-niger's 3aggregation:keys — dead config, forbidden by D1. Discarded.cluster_features, and plot_inputs / crop_production reductions — all Site 1 (fix(#323): close the grain-collapse CLASS — audit before collapse, persist the signal through the cache #614) work, all routing throughNiger/_/niger.py, which the GH bug: groupby().first() is not first_row() — skipna=True fabricates composite rows (49 sites) #637 agent owns. Deferred, not lost: the ledger records where they live and why they were not taken.lsms_library/*.py.Niger/_/niger.pyuntouched. No wavedata_info.ymledited.Refs #323, #515. Unblocks #627.
🤖 Generated with Claude Code