Repository navigation
fix(telemetry): a turn end is a pause for a flow too - #763
Merged
Merged
Conversation
buildFlowIntervals closed a flow at the first turn_end after it opened. The task axis stopped doing exactly that on 2026-09-04 - "a turn_end is a pause, not a change of subject" - and the flow axis never followed, though it is where the error is largest: on the one orchestrated session in this machine's sink, the flow opened at 05:56:27, the first pause fell at 06:02:34, and the same orchestration went on writing into the same task folder until 09:27:21. The step axis named 2,220 requests for that skill while the flow, the wider concept, named 56. A flow now closes on a step_end naming its own skill, or on the next orchestrating step_start - the same rule buildStepIntervals adopted when step_end was introduced. A step_end naming another skill never closes a flow it has no claim on. buildClosedIntervals gains an opener-aware isCloser, which cannot be expressed otherwise: "a step_end naming this flow's skill" is a fact about the pair. The walk becomes a forward scan from each opener and answers exactly as before for an opener-independent closer, which is what buildTaskIntervals passes. Measured back to back against the same sink: by_flow 56 -> 1052 for aidd-orchestrator:01-sdlc, every breakdown still summing to 30,222, and ten of the eleven breakdowns byte-identical between the two reports. cost_report_version stays 15: no field changes shape or vocabulary. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01VWNxk63AGKkqE8HRqHLjGp
blafourcade
force-pushed
the
fix/a-turn-end-is-a-pause-for-a-flow-too
branch
from
September 4, 2026 21:23
73a7c96 to
5d3dd77
Compare
This was referenced Sep 4, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
buildFlowIntervalsclosed a flow at the firstturn_endafter it opened. The task axis stopped doing exactly that on 2026-09-04 — "aturn_endis a pause, not a change of subject" (task-attribution.ts:28) — and the flow axis never followed.It is the axis where the error is largest. On this machine's sink, period
2026-08-01..2026-09-04:aidd-orchestrator:01-sdlcby_stepby_flowA flow is the wider concept — the orchestration and everything it drove — yet it named 40× fewer requests than the step inside it. The journal shows why: the flow opened at 05:56:27, the first
turn_endclosed it at 06:02:34, and the same session went on writing into the same task folder until 09:27:21.Change
A flow closes on a
step_endnaming its own skill, or on the next orchestratingstep_start. The same rulebuildStepIntervalsadopted whenstep_endwas introduced; astep_endnaming a different skill never closes a flow it has no claim on.buildClosedIntervalsgains an opener-awareisCloser— "astep_endnaming this flow's skill" is a fact about the pair, which a pre-filtered closer list cannot express. The walk becomes a forward scan from each opener and answers identically for an opener-independent closer, which is whatbuildTaskIntervalspasses.cost_report_versionstays 15: no field changes shape or vocabulary, and the task axis changed its own closer under the same rule without a bump.Proof
Both binaries run back to back, same sink, same instant:
by_flowsdlcby_flowunnamedorigin/nextAll eleven breakdowns sum to 30,222 on both runs, and ten of the eleven are byte-identical between the two reports — the change moved the axis it names and nothing else.
turn_endback in the closerstep_endguards (2)step_endThe residue this does not close
After the fix the flow still names fewer requests than the step inside it — 1,052 against 2,220 — and the reason is not the closer. A
StepIntervalis deliberately left open (POSITIVE_INFINITY), so about 1,168 of the step's requests fall after the journal stopped witnessing anything. That is a separate defect with its own reasoned defence atstep-attribution.ts:37-52, tied totelemetry check'srecords-joinclaim; it is filed in the plan, not touched here.Cost, stated
Only
aidd-dev:01-planemitsaidd:step-endtoday, so a flow still usually closes on the next orchestratingstep_startor the journal's own last witnessed moment. Making the three orchestrators emit the marker is a separate change in the plugin tree.The axis also gained the end-to-end guard it lacked:
telemetry-flow-axis.e2e.test.tspassed unchanged through this diff because its fixture ended on aturn_endwith nothing witnessed after it — the coincidence class the unit fixtures were rewritten to escape. One record at 09:55, between the pause and the next opener, now separates the two rules, and puttingturn_endback turns three of its five cases red.Gates: 3416 tests / 306 files,
tsc,biome ci, knip, jscpd, bundle within budget, 368 repository script tests, 0 broken links, cli layering clean.🤖 Generated with Claude Code
https://claude.ai/code/session_01VWNxk63AGKkqE8HRqHLjGp