Increment E: described in segments, ticketed, and scoped by outcome

[turner]

Two commits out of a grilling session on increment E. No code changes — documents and tickets.

1. Increment E is described in segments, which is what it reads

CONTEXT.md rules bare node out for the fine vertices inside a tube map, and increment E was written entirely in it: a per-node tabix loop, 65-79 ms per node, whether the per-node fetch can be batched. Those are segments. A node is the coarse vertex pgb draws in 3D and addresses as 141452+ — one per tube map. The loop reads S lines, hundreds per tube map. main.py names the variable node_id because GFA and vg spell it that way, and the spelling travelled from there into four documents.

Eleven sites, including four in docs/perf/seqtubemap-latency.html that had drifted from its .md twin because only one of the two was swept the first time.

Six uses of "node" are correct and untouched — which nodes will work, makes large nodes fetchable, scientists poke arbitrary nodes, 43% of catalogued nodes fail. All four are about clicking things in the 3D view. Three more are quoted program output (Subgraph contains 381 nodes and 464 paths) or another tool's flag name, and stay verbatim under CONTEXT.md's own rule that a spelling stays correct inside the tool that uses it.

No measurement moved. The perf documents remain dated records; a word was wrong in them, not a number.

One reword rather than a respelling: the Still open bullet asked whether the fetches can be batched. They can — the v1 path at main.py:231-244 already groups ids into contiguous runs, and two of the five committed fixtures are consecutive integers. What is open is whether batching helps, or whether the cost is the parse.

2. Increment E has tickets, a scope, and a line it must not cross

#74 — measure the lookup/parse split. ready-for-human; needs the real derivative on the server.
#75 — stop the per-segment reads. ready-for-agent, blocked-by #74 through GitHub's native dependency, which is what the roadmap's graph claims its edges are.
#76 — the duplicate-entry filter, needs-info.

Scoped by outcome, not mechanism. A measurement saying the cost is the parse would answer "can it be batched?" with no and leave the 30 seconds exactly where it is — which is not a finished increment. Every other increment here is named for a result.

#74 decides whether E wants an ADR. Batching behind a byte-identical oracle is local and reversible and wants none. Moving the parse out of the interpreter would add numpy or a C extension to a project with neither, and that wants one before the code is written.

#75's acceptance is the W lines byte-identical across the five committed fixtures — the oracle is why E can be small. It pins the duplicate-handling quirks in place deliberately; they are #76's business, and #76 cannot yet say whether it is a data defect or a code defect because the filter at main.py:373 drops entries silently and nobody has counted them.

The Closed entry on haplotype collapsing is reworded to say what it protects. "The ~464 strands are fixed input, not a variable" reads as a ban on the input side, which would forbid parsing the same coordinates faster — and that cannot have been the intent. It protects the picture: every strand appears, nothing merges, drops or samples them. The line is the output.

E sits before D. Disjoint code, neither blocks the other, but D is 0.63 s of a 38.9 s request and E is 30.

seqtubemap-plan.md gets a dated amendment rather than an edit — it says E "has not been grilled", which was true of the phase it records, and the document declares it does not carry status.

🤖 Generated with Claude Code

https://claude.ai/code/session_01J2Fbzw5Nq18SKvfKhDfdxA