Follow up items for the week of June 23, 2026

[espg]

🤖 from Claude

Sweep of closed PRs from the last 10 days (June 16–25, 2026): #41, #43, #44, #49, #51, #52, #53, #55, #57, #58, #59, #70. Items already tracked in open issues (#54, #61, #68, #48) are excluded. This covers the gaps.

---

Items

(1) on_minor_arc FP sensitivity in robust_crossing — PR #44 (hemisphere+ PIP)

The Phase-7 SoS hardening covers robust_crossing's four straddle gates but not its antipodal-disambiguation on_minor_arc, which still uses raw f64 signs. A probe point lying exactly on a polygon edge's great circle can flip on floating-point noise, silently producing incorrect PIP results with no error raised. PR #44's author explicitly recommended opening a follow-up issue for this. Not a known active bug, but a latent correctness risk on edge-great-circle inputs.

(2) Versioning automation in CI — PR #55 / commit 1cf29c2

Manual Cargo.toml version bumps are the current release path. Both the PR body ("...needs to get fixed and automated in a workflow...") and the merge commit message ("Update Cargo.toml... REALLY needs to be automated!!!") flag this as an explicit pain point. Risk: version drift between the tag that triggers build-wheels.yml and the Cargo.toml that sets the wheel version. A CI workflow or pre-release script that bumps the version and opens a PR would close this.

(3) mort2norm FORCE_PYTHON fallback remnant — PR #49 (Closes #37)

PR #49 removed four of the five MORTIE_FORCE_PYTHON-gated Python parity twins. mort2norm's _python_mort2norm fallback, the env-var switch, and the os import remain in tools.py because mort2norm was outside #37's stated scope. CLAUDE.md §7 states the Rust extension is the sole runtime path with no Python fallbacks; this remnant is inconsistent with that guarantee. Scope: one function + ~5 lines of cleanup.

(4) from_latlon point-encode path not surfaced in the morton_index skin — PR #51

The pandas ExtensionArray and pyarrow ExtensionType skin only produces area cells (Kind::Area). The Rust kernel also supports Kind::Point encoding, but there is no points=True constructor parameter or any other public API surface for it. Users who want point-precision encoding (e.g. for observation-location indexing) have no public path. PR #51 flagged this explicitly.

(5) Arrow → pandas __from_arrow__ hook not wired — PR #51

table.to_pandas() on a table with a MortonIndexDtype Arrow column yields a plain int64 Series, not a MortonIndexArray. The __from_arrow__ hook on the dtype was deliberately skipped to stay in scope. This breaks round-tripping through Arrow-typed interchange (e.g. Parquet → pandas). PR #51 flagged it as a known gap.

(6) Pre-emptive flat-cover size guard — PR #70 (order-29 lift, Closes #60)

The current implementation warns post-hoc when a flat cover exceeds 1<<20 cells. A hard pre-emptive guard that estimates the densified cell count from the cheap MOC representation before materializing would prevent OOM on very high-order covers. PR #70 described this as "a larger, separate change" and did not implement it.

(7) smallvec dependency sign-off for Node.relevant — PR #41 (perf cluster, Refs #34)

PR #41 held item (3) — SmallVec<[usize; 8]> for Node.relevant, eliminating per-child Vec reallocations the perf audit flagged — pending explicit approval to add the smallvec crate. It is MIT/Apache-2.0, ~500 lines, no transitive deps, and ubiquitous in the Rust ecosystem. The change is mechanical; the blocker is the dependency sign-off per §4.

(8) Clippy useless_conversion 27 warnings — decision pending — PR #57 (fmt/clippy sweep, Refs #34)

27 pre-existing clippy warnings exist on main: the pyo3/numpy ? idiom over Result types triggers clippy::useless_conversion even though the conversion is load-bearing (false positive). PR #57 did not add a blanket #[allow] and left the decision open: keep as-is (consistent with main, noisy clippy output) or add #[allow(clippy::useless_conversion)] at the crate root.

(9) prefix_trie.morton_polygon tie-break non-determinism — PR #57

The max-heap refactor changed which equal-efficiency cell is selected on ties — the result is still a valid cover, but the exact returned cell set can differ from the old index-scan on tie inputs and is not reproducible across runs. No test pins tie-break order. Worth deciding: document as implementation-defined, add a determinism pass, or pin the order in a test.

(10) Benchmark scripts reference removed MORTIE_FORCE_PYTHON functions — PR #49

benchmarks/benchmark_rust_vs_python.py and benchmark_morton_bbox.py still set MORTIE_FORCE_PYTHON. For the four removed functions the env var is now a no-op; the benchmarks silently measure only the Rust path rather than the comparison they advertise. Not run by CI so no failure, but they are misleading. Scope: small update or deletion.

---

Priority / severity table

Priority	Item	Severity	Source PR
1	on_minor_arc FP sensitivity — silent wrong PIP on edge-great-circle probes	High	#44
2	Versioning automation — repeated manual pain, explicit committer flag	Medium-High	#55
3	mort2norm FORCE_PYTHON remnant — violates §7 Rust-only guarantee	Medium	#49
4	from_latlon point-encode path missing — API surface gap in morton_index skin	Medium	#51
5	__from_arrow__ hook not wired — breaks Arrow → pandas round-trip	Medium	#51
6	Pre-emptive flat-cover size guard — prevents OOM at high order	Medium	#70
7	smallvec sign-off — perf win blocked on dependency approval	Low-Medium	#41
8	Clippy useless_conversion 27 warnings — decision pending, clippy noise	Low	#57
9	morton_polygon tie-break non-determinism — undocumented behavior change	Low	#57
10	Benchmark scripts reference removed FORCE_PYTHON functions — misleading dead code	Low	#49

[espg]

🤖 from Claude

One-time backfill: follow-up items from PRs closed more than 10 days ago (April 27 – June 15, 2026) not yet tracked in open issues. Four PRs had substantive follow-ups: #40 (MIT relicense + ruff lint workflow), #33 (near-pole densification fix). PRs #29, #31, #42 had no untracked follow-ups.

---

Items

(A) .github/workflows/lint.yml was never created — PR #40 (June 14)

PR #40 added [tool.ruff] to pyproject.toml and was merged. However, the .github/workflows/lint.yml file could not be pushed — the session token lacked the GitHub workflows OAuth scope. The workflow content is embedded in the PR #40 body (uses benny123tw/action-ruff@v1, reporter: github-pr-review, filter_mode: diff_context, fail_level: none, --select=E,F,W,I --ignore=E501, actions/checkout@v4). As of today, mortie has ruff configured but no CI workflow running it — the ruff bot that CLAUDE.md §2 instructs Claude to respond to has never fired on any mortie PR.

(B) ruff fail_level decision — PR #40

The proposed workflow uses fail_level: none (non-blocking annotations, same as zagg). PR #40 left open whether ruff failures should block merge instead. Decision needed when item (A) is resolved.

(C) ruff --select N (naming conventions) — PR #40

zagg's ruff config includes N (PEP 8 naming). mortie's current pyproject.toml ruff config uses E,F,W,I only, without N. PR #40 flagged that enabling N now might surface naming violations across the existing codebase. Decision: add N to stay in sync with zagg, or keep it out?

(D) 2 systematic extra coverage cells vs S2 ground truth — PR #33 (June 6)

After the near-pole densification fix, the ATL06 cycle-22 validation shows mortie with 0 missed + 2 extra cells vs S2 (spherely). These 2 extra are acceptable under the "superset" contract (mortie ⊇ S2), but they are a systematic over-inclusion at near-pole boundaries, not random noise. The fix characterizes which cells densify via a self-similar empirical threshold (min(0.03, 0.02·4^(6−depth))) rather than a formal bound. Not tracked as a separate issue; worth confirming whether the known 2-cell over-inclusion is the documented steady state or a target for future tightening.

---

Priority / severity table (backfill items)

Priority	Item	Severity	Source PR
A	Lint workflow never created — ruff CI absent despite being configured	High	#40
B	fail_level decision — blocks finalizing item A	Medium	#40
C	--select N naming conventions — minor config alignment question	Low	#40
D	2 extra coverage cells vs S2 — systematic over-inclusion, documented but not formally bounded	Low	#33

---

Generated by Claude Code

[espg]

Please batch the above into sensible PR groups -- i.e., what can go under a batch 'small fix' PR, what needs it's own PR, etc. Note Priority 2 in the summary already has it's own issue thread #67 (and will have it's own PR).

[espg]

🤖 from Claude

Batching the follow-ups into PR groups. Grouping rule: bundle only mechanical, decision-free, same-theme cleanups into a small-fix PR; give anything with real code+tests or a design choice its own PR; and split out the items that need a decision or a workflow-scope before any code. Item (2) is excluded — it's #67 (and now greenlit there).

A) small-fix bundle — one PR (claude/small-fixes-<date>)

Mechanical, low-risk, same theme (finishing the #49 MORTIE_FORCE_PYTHON removal so §7's "Rust is the sole runtime path" holds end-to-end):

• (3) mort2norm FORCE_PYTHON remnant — drop _python_mort2norm, the env switch, the now-unused os import (~5 lines).
• (10) benchmark scripts still setting MORTIE_FORCE_PYTHON for the removed functions — update or delete the dead comparison.

These two Closes cleanly and touch nothing behavioral; natural single small-fix PR.

B) Own PR each (real code + tests / design care)

• (1) on_minor_arc FP/SoS hardening — correctness-sensitive Rust geometry (the one High item). Own PR, its own fixtures.
• (4) + (5) the two morton_index-skin gaps from morton_index datatype skin: pandas + Arrow (phases 4 & 5 of #35) #51 — points=True point-encode constructor (4) and the __from_arrow__ hook (5). Same file/area, both public-API round-trip behavior → one "skin gaps" PR covering both.
• (6) pre-emptive flat-cover size guard — Lift coverage/MOC/set-op order cap from 18 to 29 #70 itself called this "a larger, separate change." Own PR.

C) Decide first, then (mostly) tiny PRs — no code yet

• (7) smallvec for Node.relevant — §4 blocks adding the crate until you sign off. It's MIT/Apache-2.0, ~no transitive deps; the change is mechanical. Needs your yes/no, then a one-file PR.
• (8) clippy useless_conversion (27 false positives from the pyo3 ? idiom) — decide: crate-root #[allow(clippy::useless_conversion)] vs leave as-is. If "allow," it's one line and folds into a fmt/clippy sweep PR.
• (9) morton_polygon tie-break non-determinism — decide: document as implementation-defined vs pin order in a test. If "pin," it's a small test-only PR.
• (D, from the backfill) 2 extra coverage cells vs S2 — confirm whether the 2-cell over-inclusion is the documented steady state or a tightening target. Resolve on-thread; no PR unless you want it tightened.

D) CI / ruff — one PR, but gated

• (A) + (B) + (C-backfill) create .github/workflows/lint.yml, plus the fail_level and --select N decisions. Two flags to note: (i) this needs your call on fail_level: none vs blocking and on adding N; (ii) the routine's push-scoping (claude/*) and the missing workflows OAuth scope mean an agent likely cannot push .github/workflows/ at all — the file content is captured in small fixes: relicense to MIT, ruff lint workflow #40's body, but a human (or a scope-granted run) may have to land it. Flagging so it isn't silently dropped again.

What I need from you to proceed

Opening issues / applying labels is side-effecting, so I won't spawn the small-fix/implement issues myself. If you label the items the way you want them grouped (e.g. apply small-fix to (3)+(10), implement to (1) / (4)+(5) / (6), and answer the (7)/(8)/(9)/(D) decisions), the next sweep will pick them up in exactly these batches. Want me to proceed on this grouping, or regroup any of them?

---

Generated by Claude Code