From efc3721b50df3546ae054c57e1e666e29d8f73c8 Mon Sep 17 00:00:00 2001 From: Polichinl Date: Sun, 28 Jun 2026 02:03:26 +0200 Subject: [PATCH] docs(risk-register): C-45/C-46 (repo-assimilation) + C-19 re-scope (base-docs audit) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - C-45 (Tier 4): unfao/frames.py is an unused views-frames conformance adapter on no live path — forward-looking scaffolding for the C-40 migration; maintenance/ confusion surface (hardcodes S=1). Cross-ref C-40, #45. - C-46 (Tier 4): tests/test_datafactory_deploy_readiness.py is hardcoded to a local datafactory path → skipped in CI, and currently failing on the one machine that runs it (its strict-xfail flipped when datafactory advanced to 1.5.0-dev). Test hygiene, no correctness impact. Cross-ref C-36, C-44. - C-19 re-scoped: the unfao.py ADR-008 residual is resolved (#13); the live residual moved to enrichment.py (:42,:50,:103) + extraction.py:39 (raises without log-before). Trigger + Location rewritten; stays Tier 3. Header 44/24/20 -> 46/26/20. Register-only; ruff clean, suite green. Co-Authored-By: Claude Opus 4.8 --- reports/technical_risk_register.md | 42 +++++++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 4 deletions(-) diff --git a/reports/technical_risk_register.md b/reports/technical_risk_register.md index e112763..f41341e 100644 --- a/reports/technical_risk_register.md +++ b/reports/technical_risk_register.md @@ -5,8 +5,8 @@ | Project | views-postprocessing | | Owner | Dylan Pinheiro / PRIO MD&D Team | | Last Updated | 2026-06-26 | -| Total Concerns | 44 | -| Open Concerns | 24 | +| Total Concerns | 46 | +| Open Concerns | 26 | | Resolved Concerns | 20 | --- @@ -183,8 +183,8 @@ See also C-14 (stale cache without version tracking), C-22 (no post-delivery cor | ID | C-19 | | Tier | 3 | | Source | `falsification-audit` (2026-06-02) | -| Trigger | When a structural failure occurs in `PriogridCountryMapper` and the operator searches logs for context, verify that the exception was preceded by a `logger.error` — currently 20 of 24 raises in mapping.py and 3 in unfao.py have no preceding log | -| Location | `views_postprocessing/unfao/mapping/mapping.py` (20 raises), `views_postprocessing/unfao/managers/unfao.py:70,80,230` | +| Trigger | When a structural failure occurs in `GaulLookupEnricher` (lookup missing/incomplete, or an absent gid column) or in the `extraction` seam and the operator searches logs for context, verify the exception was preceded by a `logger.error` — these raises currently have none | +| Location | `views_postprocessing/unfao/enrichment.py:42,50,103`; `views_postprocessing/unfao/extraction.py:39` | ADR-008 requires structural failures to be both logged persistently AND raised explicitly. Three validation methods in mapping.py and the C-01 fix in unfao.py were fixed with log-before-raise. 20 raises in mapping.py and 3 in unfao.py remain unfixed. @@ -192,6 +192,8 @@ Part of Cluster B (expanded scope). **Update 2026-06-24:** the mapper portion (20 of the 23 raises, in `mapping.py`) is gone with the deleted runtime mapper (C-39); the **3 raises in `unfao.py`** remain (tracked by issue #13). Narrowed to the manager. +**Update 2026-06-28 (re-scoped after `review-base-docs`):** the `unfao.py` residual is **resolved** — the 3 manager raises got log-before-raise in #13 (`unfao.py:72,84,293`), and the `FileNotFoundError` at `:112` is logged by its enclosing `_read_forecast_data` try/except. So both historical locations (mapper, manager) are now clear. **The live ADR-008 residual moved to two modules the original audit never covered:** `enrichment.py` (`:42` lookup-missing, `:50` lookup-missing-columns, `:103` absent gid column) and `extraction.py:39` (the seam's index/column `KeyError`) — these raise without a preceding `logger.error`. Practical risk is low (the raises are loud, not swallowed — the messages are descriptive); the gap is uniform log-before-raise convention in live code. Stays **Tier 3** (observability/maintainability, no silent corruption). The manager CIC §3 already notes the enricher's call-site raises are not individually logged. + --- ### C-22: No post-delivery correction process for wrong assignments @@ -509,6 +511,38 @@ No silent corruption and no current breakage (development is green on 2.3.0) → --- +### C-45: `unfao/frames.py` is an unused views-frames conformance adapter carried on no live path + +| Field | Value | +|-------|-------| +| ID | C-45 | +| Tier | 4 | +| Source | `repo-assimilation` (2026-06-27) | +| Trigger | When the C-40 representation migration (pandas → views-frames) begins — confirm whether `frames.py` becomes the live conversion seam or should be removed; or when a contributor assumes it is on the delivery path (its own docstring says it is not) | +| Location | `views_postprocessing/unfao/frames.py` (the only `views_frames` importer); exercised solely by `tests/test_views_frames_conformance.py` | + +`unfao/frames.py` (`to_prediction_frame` / `to_target_frame`) converts the repo's pandas tables into views-frames `PredictionFrame`/`TargetFrame` `(N, 1)` value objects to prove they satisfy the published views-frames contract. It is the **only** module importing `views_frames`, and **no live path calls it** — its sole consumer is the conformance test (the module's own docstring states "nothing in the live delivery path calls it yet"). It is forward-looking scaffolding for the C-40 frame migration: harmless, but a maintenance/confusion surface (a reader can mistake it for an active code path, and it hardcodes `S=1`, i.e. point-only, which will need revisiting for the draws/uncertainty work). No correctness or reliability impact → **Tier 4**. + +See also C-40 (the pandas gate this adapter anticipates), #45 (the draws carrier that will need the `S>1` version). + +--- + +### C-46: `test_datafactory_deploy_readiness` is hardcoded to a local path — CI-skipped, and currently failing on the one machine that runs it + +| Field | Value | +|-------|-------| +| ID | C-46 | +| Tier | 4 | +| Source | `repo-assimilation` (2026-06-27) | +| Trigger | When treating `test_datafactory_deploy_readiness` as a release gate (it never runs in CI), or when a contributor's local `pytest` fails on it — re-promote / re-pin the strict-xfail now that views-datafactory has advanced to `1.5.0`-dev past its `v1.4.0` tag | +| Location | `tests/test_datafactory_deploy_readiness.py` (`_DF = Path("/home/simon/.../views-datafactory")`, `skipif(not _DF.exists())`) | + +The cross-repo deploy-readiness gates introduced under C-36 are guarded by `skipif` on a **hardcoded local datafactory checkout path**, so they are **skipped in CI** and only ever execute on one developer's machine. There, `test_version_bumped_past_latest_tag` is currently **failing**: it is an `xfail(strict)` that flipped to XPASS because datafactory moved to `1.5.0`-dev past its `v1.4.0` tag — exactly the auto-flip C-36's resolution anticipated, but because of the hardcoded path the flip surfaces as a **local red** rather than a CI signal, and breaks local `pytest` runs (the suite is run with this test deselected). No correctness/reliability impact on the delivery → **Tier 4** (test hygiene). C-36 (resolved) converted these gates to strict-xfail but did not capture the local-path / CI-skip dimension. + +See also C-36 (the resolved strict-xfail conversion this extends), C-44 (the datafactory version-state coupling). + +--- + ## Disagreements ### D-09: Multi-store support — parameterize the manager now vs after the FAO global delivery