@ascenda-one/history-import 0.1.24 → 0.1.26

package/README.md

@@ -152,6 +152,47 @@ line that closes the turn. The rule is in
 [`src/interruptedRuns.ts`](./src/interruptedRuns.ts), and the desktop app's
 importer counts by the same one.
 
+A cut counts in the session you pressed Escape in, and in no other. Resuming
+a session copies the history it inherits, markers included, so before this
+rule every resume in a lineage reported its ancestors' interruptions as
+well — a fifth of the counted total on the store this was measured against.
+The same ownership rule as the minutes (`minutesBasis: owned_lines`).
+
+### When two files both say a line is theirs
+
+Most copies keep the session id the line was written with, which is how the
+import tells a copy from the real thing. Some rewrite it to the file the copy
+now sits in, keeping the line's own id and its original timestamp — so the
+test that settles every other copy answers "written here" in both places, and
+both sessions counted the line. Nothing on the line says which of the two
+wrote it: the two records are identical apart from the fields the copy
+rewrote.
+
+Where the line sits is what settles it. A line two files claim is contested.
+Inside a file, the run of contested lines at the top is the history it
+inherited, and it ends at the first line that file claims and nobody else
+does — from there on, what it holds it wrote. So a contested line belongs to
+the file still holding it after its own history has started.
+
+Not simply the first file the import reaches, which would be the easy rule and
+the wrong one: on the store this was measured against it would hand two fifths
+of these lines to the copy instead, which is the error this whole rule exists
+to remove.
+
+**What that leaves.** A lineage whose earliest file the 30-day cleanup has
+already taken has no file that wrote those lines — every one still holding
+them holds them in its inherited head, and nothing left on disk says which
+session did the work. The line is still counted once, by the first file the
+import reaches, the same answer any orphaned line gets. The total is right and
+the session it lands on is a guess. That was 16.1% of contested lines here.
+
+Sizes, on the same store: 3.7% of the lines claiming their own file were
+claimed by two of them, and counting each once takes 3.9% off the summed
+active minutes. **Your week doesn't move** — the union of your active time
+holds to a minute, because a line counted twice was one minute counted twice.
+Hands-on shifts a little more than that: a span changes sides when the lines
+around it move, so the unioned hands-on figure moved by 19 minutes in 6,734.
+
 ### What counts as a prompt
 
 `promptCount` on a Claude Code session counts the prompts you typed. Claude
@@ -170,9 +211,6 @@ Code also writes `user` lines on your behalf, and none of these count:
   variant.
 
 Each session carries `syntheticPromptLines`, the number of lines it left out.
-The handoff stamps `promptBasis: "typed"`. A handoff without the stamp counted
-every `user` line that wasn't a tool result, so its prompt counts run higher for
-the same week. The schema number doesn't move.
 
 These lines aren't you, and they aren't the agent, so they don't start or end a
 hands-on span. Prompt events, after-hours prompts and quick re-prompts all
@@ -180,6 +218,72 @@ follow the same count. The desktop app's importer declines the same lines; the
 test is `isTypedPromptLine` in
 [`src/interruptedRuns.ts`](./src/interruptedRuns.ts).
 
+Two more rules need the whole store, so the extractor reads every transcript
+once before it folds any session ([`src/promptLedger.ts`](./src/promptLedger.ts)):
+
+- **Each line belongs to one session.** Resuming or forking a session writes a
+  new transcript that copies the history it inherited, line ids and timestamps
+  included. Each copy has one owner: the transcript the line's `sessionId`
+  names, or, where the purge took that file, the first in the walk's sorted
+  order. The owner counts the prompt, and the owner's timeline carries the
+  instant — so `activeMinutes`, the hands-on split, the day slices and
+  `startedAt` describe the session you resumed rather than everything behind
+  it. Two files can both name themselves on one line, which "When two files
+  both say a line is theirs" above settles. A line with no id is counted
+  wherever it appears; on the reference store that's `queue-operation` lines
+  and nothing else.
+- **A chip's prompt isn't typed.** A session launched from a `spawn_task` chip
+  opens on the chip's prompt. When a line's text, wrappers stripped, matches a
+  chip that some session in the store offered, it counts in
+  `dispatchedPromptLines`, not `promptCount`. The agent still runs on it, so an
+  interrupt during that first turn is still a cut-short run. Only hashes of
+  chip prompts are kept, and only for the run. If the store's cleanup has
+  already removed the session that offered the chip, there's nothing to match
+  and the opener counts as typed.
+
+The handoff stamps `promptBasis: "typed_once"`. `"typed"` means the rules above
+the list, with every resumed copy counted again and chip prompts counted as
+typed. A handoff without the stamp counted every `user` line that wasn't a tool
+result. Prompt counts for the same week run highest under that rule and lowest
+under `typed_once`. The schema number doesn't move.
+
+Beside it, `minutesBasis: "owned_lines"` says the minutes were cut the same
+way. `"every_line"` — and an absent stamp — means a transcript's whole
+contents counted there, inherited history included. Gate on this before
+comparing minutes across two handoffs: a store's figures drop when it changes,
+and nothing else in the file says so.
+
+### How much history a resume carries
+
+Enough to matter, which is why the rule above covers the minutes and not only
+the counts. On one real store of 984 transcripts, 151 carried inherited lines:
+275,801 of them, 29% of every dated line in the store. They held the whole of
+the gap between what the sessions claimed and what the clock allowed. Both
+columns are the same 983 sessions, read from one snapshot:
+
+| | Every line | Owned lines |
+|---|---|---|
+| Summed active minutes | 70,212 | 53,600 |
+| Summed hands-on minutes | 12,238 | 8,006 |
+| Union of every active interval | 25,078 | 25,077 |
+| Exact-duplicate spans | 262,500 of 873,599 | 21,982 of 635,126 |
+| Sessions apparently spanning over a day | 158 | 154 |
+
+The union is the control. It holds to the minute, so no work anyone did was
+dropped: what went was the copy of it. Duplicate spans fell from 30% of the
+store to 3.5%, which matters to any count of how many agents were running at
+once, since a duplicate reads as a second agent. 127 sessions now start when
+they were resumed, 13 of them more than an hour later than they used to.
+
+That 3.5% was not the floor, and it was not coincidence: four fifths of it was
+the copy path settled above. On a later and slightly larger snapshot of the
+same store, the duplicate spans go from 21,982 to 4,087 once contested lines
+are settled.
+
+An earlier reading of this exposure put it at 0.72% of sessions. It counted
+repeated `sessionRef`s, and a resumed transcript carries a fresh one, so it saw
+three sessions where 151 transcripts were affected.
+
 ### Autonomy bands
 
 `permissionMode` is on the transcript's human-prompt lines and nowhere else —