Follow up items for the week of July 11, 2026

[espg]

🤖 from Claude

Sweep of closed PRs from the last 10 days (July 1 – July 11, 2026): #94, #95, #100, #101, #102, #105, #106, #109, #110. PRs #94/#95 were already surfaced by the prior sweep (#97, now closed and consolidated into #108). This issue covers new gaps from #100–#110, plus a status check on #97's 9 carry-forward items against current main.

Of #97's 9 items: (1) the res2display() order cap and (2) the arro3-core CI leg are now resolved (closed via issue #99 / PR #102, and issue #98, respectively). The remaining six — __floordiv__ coarsening operator, Earthdata-gated notebooks, dissolve winding-sign hemisphere guard, clippy useless_conversion warnings, from_geometry(normalize=False) no-op, and the moc_to_order size-guard design questions — are still open but already consolidated and tracked in #108 ("Consolidated follow-ups from the June/July sweeps"), so they are not repeated here. Item (9) (mktemp+mv vs. sed -i) was confirmed moot.

Also note: #107 (descent-parity desync on hemisphere+ rings with a collinear edge) is a distinct, already-filed correctness bug — not a new gap from this sweep.

Items

(1) Vertex-point-touch closed-set nuance never got a maintainer decision — PR #106

Phase 5's perf-recovery fast-exit in edge_hits_cell_edge has a documented gap: a polygon vertex-point touching a cell edge, with the polygon strictly outside, is only guaranteed detected for the vertex's own leaf-owning cell — not its neighbor cell. PR #106's body posed this explicitly as question 4 ("is the vertex-point-touch nuance above acceptable as the closed-set contract's fine print, or do you want the neighbor cell guaranteed too?"). The other three questions in that PR got real espg replies; this one has none. Confirmed current: src_rust/src/coverage.rs still carries the same documenting comment with no code change since, and no tracking issue exists for it (unlike the sibling limitation, filed as #107).

(2) MortonIndexArray.__getitem__ breaks the pandas ExtensionArray NA contract — PR #105

__getitem__ on the empty-sentinel word returns MortonIndexScalar(0) (renders as <NA>) instead of self.dtype.na_value (pd.NA), so pd.isna() returns False on an element that visually looks missing. Flagged as one of four "Questions for review" in the PR body and in an inline review comment (morton_index.py:351); the only reply is Claude's own self-review response recording it as "deliberate... out of scope to change," which is not a genuine espg decision. Verified still live in current mortie/morton_index.py — no sentinel special-case in __getitem__. This is a real correctness trap for downstream pandas NA-propagation (pd.isna(), .dropna(), .fillna()) — exactly the kind of thing zagg, a stated downstream consumer, could hit silently.

Priority / severity table

Priority	Item	Severity	Source
1	Vertex-point-touch closed-set nuance — unresolved correctness/completeness question, no tracking issue, no maintainer sign-off	Medium	#106
2	MortonIndexArray.__getitem__ NA-contract deviation — silent pd.isna() false-negative on the empty sentinel	Medium	#105

Status of #97's carry-forwards (not repeated as new items)

Item	Status
res2display() order cap	Resolved — #99 / PR #102
arro3-core CI leg	Resolved — #98
// floor-division operator	Open, tracked in #108
Earthdata-gated notebooks	Open, tracked in #108
Dissolve winding-sign hemisphere guard	Open, tracked in #108
Clippy useless_conversion warnings	Open, tracked in #108
from_geometry(normalize=False) no-op	Open, tracked in #108
moc_to_order size-guard design questions	Open, tracked in #108
mktemp+mv vs. sed -i sign-off	Moot, no action needed

[espg]

🤖 from Claude

Both items confirmed live against current main. This is discuss, so no code/branch — laying out the decision surface for each.

(1) Vertex-point-touch closed-set nuance (PR #106, edge_hits_cell_edge)

Confirmed still present: src_rust/src/coverage.rs:524-531 carries the documenting comment verbatim, and the hot fast-exit (corners strictly one side ⇒ return false, :541-543) is unchanged since #106. Restating the exact gap so the decision is crisp:

• Already guaranteed. An edge-collinear touch — the systematic on-grid family the closed-set contract (morton_coverage / from_wkt mis-fill polygons whose edges lie on base-cell boundaries (lon ≡ 0 mod 45°, lat = 0) #103) exists for — always drives d1/d2 degenerate and is fully honored. A vertex-point touch is also caught for the one cell that owns the vertex as an interior point (the vertex-in-cell clause).
• The single uncovered case. A polygon vertex landing bit-exactly on a cell edge, polygon strictly outside, for the neighbor cell that shares that edge but does not own the vertex. That neighbor sees "all corners strictly one side, no crossing" and fast-exits false, so it isn't included even though the boundary grazes its edge.

Approaches:

• (a) Accept as documented fine print (status quo + tightened contract wording). The closed-set promise reads "edge-collinear touches always included; a bare vertex-point touch is guaranteed only for the vertex-owning cell." Zero perf cost; no code beyond tightening the coverage docstring and morton_coverage / from_wkt mis-fill polygons whose edges lie on base-cell boundaries (lon ≡ 0 mod 45°, lat = 0) #103's contract note. Risk: a downstream expecting every cell whose closed boundary the polygon meets will see a one-cell omission on exact vertex-on-edge inputs — rare off-grid, but on-grid vertex coordinates make it reachable.
• (b) Guarantee the neighbor cell too. Include the edge-sharing neighbor on a detected vertex-point-on-edge. Restores the "any boundary contact ⇒ included" reading in full. The catch: a bare vertex-point touch does not make d1/d2 degenerate for the neighbor (its corners are strictly one side), so this is not a cold-path tweak — it needs a new vertex-incidence probe against the edge, adjacent to the hot path. Since the fast-exit was the ~19% CodSpeed recovery in Uniform symbolic crossing predicate: fix base-cell-boundary mis-fill #106, (b) can only be accepted behind a benchmark proving it stays off the hot path.
• (c) Track and defer. Treat like Descent parity desynchronizes on hemisphere+ rings with a long edge collinear to the probe lattice #107's sibling limitation (which got its own issue): file it, decide against real coverage numbers later, gate nothing on it now.

Clarifying questions:

1. Is "every cell whose closed boundary the polygon touches is included" a hard contract the 1.x freeze (Version 1.0 Sweep (Follow up to new morton datatype) #48) commits to, or is the honored guarantee specifically the edge-collinear on-grid family (which is fully covered)? That answer decides (a) vs (b) directly.
2. Do you have — or can you sketch — a realistic input that hits a bare vertex-on-edge touch with the polygon strictly outside? If it only arises from synthetically snapped coordinates, (a)/(c) look right; if a real polygon class produces it, (b) earns its cost.

My lean: (a) if the contract is the on-grid collinear family (what #103 actually built), with the wording promoted from a buried nuance to an explicit limit — escalate to (b) only behind a concrete failing input, since neighbor-detection can't be shown free without a benchmark.

(2) MortonIndexArray.__getitem__ NA-contract deviation (PR #105)

Confirmed live: morton_index.py:348-352 — scalar __getitem__ returns MortonIndexScalar(result) unconditionally, so indexing an empty-sentinel element yields MortonIndexScalar(0) (renders "<NA>") rather than self.dtype.na_value (pd.NA). Array-level isna() is correct (self._data == self._SENTINEL, :375), so the deviation is scalar-access only: pd.isna(arr[i]) returns False on an element that both displays as <NA> and reports missing under arr.isna()[i]. That inconsistency is the trap for scalar pd.isna() / .dropna() / .fillna().

Approaches:

• (a) Return self.dtype.na_value from scalar __getitem__ when the word is the sentinel. The canonical pandas EA pattern (IntegerArray/BooleanArray do exactly this). One conditional; restores scalar pd.isna/dropna/fillna. Risk: arr[i] for a missing element becomes pd.NA, so downstream int(arr[i]) on a missing slot now raises rather than yielding 0 — but that is the NA contract, and such code should gate on isna first. Needs an audit that nothing internal (_formatter :646, take's fill, factorize) assumes scalar getitem is always a MortonIndexScalar.
• (b) (a) + align iteration/listing. Make __iter__/tolist/_formatter present missing elements consistently. The formatter already renders the sentinel as <NA>, so the visible change is only in the typed scalar path — this just removes any residual "getitem says NA, iteration says 0" skew.
• (c) Status quo + document + steer to .isna(). Keep MortonIndexScalar(0) (scalar access stays uint64-typed for hot loops) and document that scalar missingness must be checked via arr.isna(), not pd.isna(arr[i]). Weakest — it leaves pd.isna(arr[i]) silently wrong, which is exactly the downstream surprise the item flags.

Clarifying questions:

1. Does any hot path rely on arr[i] / iteration always returning an int-like MortonIndexScalar (so missing → 0 rather than pd.NA is load-bearing)? If yes, (a) has a real cost; if not, (a) is a clean one-liner.
2. Vehicle: ride the Decimal-string display & casting layer: element repr, vectorized to_decimal, scalar wrapper, legacy i64 emit, hive_path #104 display/casting follow-ups, or land as its own small-fix? It's a frozen-API-behavior correctness item, so I'd fix it before the 1.x freeze regardless of vehicle.

My lean: (a) — it's the standard EA contract and the fix is minimal; the only real work is question 1's audit, done as part of implementation.

---

If you want either turned into work, relabel to implement/small-fix (item 2 is small-fix-sized; item 1 is either a doc tightening or a benchmarked coverage change). Marking waiting on your read.

---

Generated by Claude Code