python/tan/planner/zephyr_board.py is a hand-port outside PINNED_HASHES, so it drifts from alp-sdk silently

[alpCaner]

Found while moving PINNED_SDK_TAG to alp-sdk v0.15.0-rc1 for the v0.5.0-rc1 RC. This one nearly shipped.

What happened

alp-sdk#1068 added CONFIG_USE_DT_CODE_PARTITION=y to the AEN board _defconfig, emitted by scripts/gen_zephyr_board.py::_aen_defconfig(). That is the fix that makes a scaffolded AEN801 app link at its slot0 partition instead of the MRAM base — bench-proved on silicon (byte-matched readback, cold-cycle persistent, u VB in the SES boot header).

tan carries its own python/tan/planner/zephyr_board.py::_aen_defconfig(). It did not get the line, so tan generate for any AEN board emitted a _defconfig without it — i.e. the RC would have shipped the exact defect alp-sdk had just fixed, to the testers whose job is to exercise AEN flashing.

Caught only because the byte-parity gate went red on 100 board-tree parametrizations after the pin moved:

AssertionError: ...rpmsg-aen/board.yaml --core m55_he alp_e1m_aen801_m55_he_..._defconfig differs -- line 10:
    sdk: "# Link the image into the board's `zephyr,code-partition`"
    tan: '# Console: Alif UART5 ...'

The actual defect

zephyr_board.py is a hand-port, not a relocation, and it is not one of the 21 keys in PINNED_HASHES (python/tests/gates/test_planner_relocation_freshness.py). The freshness gate tracks scripts/alp_orchestrate/; this generator lives outside it. So the usual staleness check — git log <pinned>..<new> -- scripts/alp_orchestrate — comes back empty and reassuring while this file silently diverges.

Two independent things had to line up for it to be caught: someone moving the pin, and a byte-parity gate that happens to cover the emitted artefact. Neither is a check on the file itself. A hand-port with no freshness gate is a second, undeclared vendor point.

What to do

1. Bring zephyr_board.py under PINNED_HASHES (or an equivalent per-file freshness gate), so alp-sdk moving it reds a named gate instead of surfacing as a downstream artefact diff.
2. Audit for siblings. zephyr_board.py was found by accident; the question this raises is which OTHER generators were hand-ported rather than relocated and sit outside the gate the same way. That audit has not been done.
3. Consider whether the freshness gate should assert coverage — that every file under python/tan/planner/ is either in PINNED_HASHES or explicitly declared exempt — so a future hand-port cannot be added silently outside it.

The immediate line is ported and the gate is green; this issue is about the class, not the instance.

[alpCaner]

Second live instance found by the same method — and this one is still open

Auditing for siblings (per point 2 above) turned up a full inventory of files ported from outside scripts/alp_orchestrate/, i.e. structurally invisible to PINNED_HASHES regardless of whether they have drifted yet:

File	Ported from	Drift v0.14.0 → v0.15.0-rc1
python/tan/planner/zephyr_board.py	scripts/gen_zephyr_board.py	was stale — fixed (#1068)
python/tan/planner/project_loader.py	scripts/alp_project_loader.py	stale — see below
python/tan/planner/som_metadata.py	scripts/alp_project_loader.py (other half)	current
python/tan/planner/template.py	scripts/alp_template.py	current
python/tan/planner/project_emit/*.py (6)	scripts/alp_project_emit/	current

The second gap: an unknown hw_rev still emits for the wrong hardware

alp-sdk#1025 (0da1f1b4) fixed a silent wrong-hardware emit — an hw_rev absent from the resolved table resolved to empty per-rev overrides, so the build used base-revision pad routing and exited 0. On AEN, r1 and r2 genuinely differ (metadata/e1m_modules/aen/hw-revisions.yaml: IO8 → WIFI_GPIO30, IO10 → WIFI_GPIO35, IO21 unrouted).

alp-sdk fixed it in two places, and its commit message says why: "scripts/alp_project_loader.py carries its own copy because its --emit composed-route-table/carrier-netlist path resolves the tables independently of load_board_yaml."

tan carried the fix into loader.py / sdk_compat.py — both PINNED_HASHES-tracked, both correctly raising SdkRevisionUnknown. The second copy never came across. project_loader.py::_hwrev_pad_route_overrides() still returns empty for an unrecognised hw_rev, so tan generate --target carrier-netlist and --target composed-route-table retain the pre-#1025 silent fallback today.

Worth noting where the blind spot compounds: the freshness gate's own PINNED_SDK_COMMIT comment claims #1025 was "carried into tan/planner/" — true of the tracked half, false of this one, and nothing measures the difference.

Nothing in CI can see it: grep -rl "_hwrev_pad_route_overrides\|SdkRevisionUnknown" python/tests/ finds only test_sdk_revision_gate.py, whose every case drives the load_board_yaml path, and no example board.yaml carries an unknown hw_rev, so byte-parity is blind too.

Being fixed for v0.5.0-rc1, with a test that drives project_loader.py's own path rather than load_board_yaml — a test through the tracked path would recreate the exact blind spot that let this ship.

[alpCaner]

Fixed in 204c3a0, shipped in v0.5.0-rc2. zephyr_board.py is covered by HAND_PORT_HASHES against its own pinned alp-sdk vendor point.

Note for anyone touching that gate: it carries TWO audits at TWO different alp-sdk commits, and they need TWO checkouts. Wiring only one bound the hand-port audit to the planner-audit tree and made it report false drift (ba46a85), and the first correction -- hard-failing when the root is unbound -- then broke every ordinary suite run that binds no root at all. The enforcement now lives in seam1, which asserts both node ids report PASSED, so a skip there fails the job while pytest tests/ still skips quietly (2207965).