test(ci): fork-tail packing measured and rejected - and why the gate only became measurable after astubbs#106

AGENTS.md

@@ -584,6 +584,11 @@ between two of *your own* commands. Work only under `.claude/worktrees/<name>`,
 none does. Commit with `git -C <worktree> commit ...` spelled as a **literal path, not a variable**:
 the pre-commit hook reads the command before the shell expands it, and refuses a `-C "$W"` rather
 than gating a tree the command never named (`.claude/hooks/pre-commit-gate.sh` owns the why).
+**Name the tree on EVERY commit, not just the first** - a bare `git commit` resolves against the
+session root, which is some *other* worktree. Do not lean on having `cd`-ed there earlier: the
+shell's working directory is **not reliably** carried between commands (it survives some and not
+others, and when it resets you are in a different worktree, not an error). A leading literal
+`cd <worktree> &&` on the commit itself works as well as `-C`.
 
 **Reaching for `git checkout <branch>` is the tell that you are in the wrong directory** - and it is
 how the rule gets broken silently. Git refuses to check out a branch another worktree already holds,

docs/inflight/branch-parallel-measurement-contamination.md

@@ -5,15 +5,25 @@
 <!-- inflight-state: deferred - after v6, the affected branches are not in the merge order -->
 
 
-`ci/reenable-parallel-tests` and `optimize/unit-gate` both measure JUnit execution parallelism. Any numbers
-they gathered before core stopped configuring the other modules' runners were taken against an "off" arm that
-was not off everywhere: core's `src/test/resources/junit-platform.properties` was packaged at the root of the
+<!-- post-merge: checked -->
+`ci/reenable-parallel-tests` and astubbs/parallel-consumer#105 both measure JUnit execution parallelism. Any
+numbers they gathered before core stopped configuring the other modules' runners were taken against an "off"
+arm that was not off everywhere: core's `src/test/resources/junit-platform.properties` was packaged at the root of the
 core **tests** jar, so the eight modules depending on that jar (the four integrations plus every example) ran
 at `factor=20` regardless of their own `${parallel-tests}` setting.
 <!-- file-refs: N/A - describes where the file WAS when it caused the contamination -->
 
-Re-take any measurement from before that, or confirm the arm it used was unaffected. Neither branch had an
-open PR when this was written, which is why the note is here rather than in a review comment.
+Re-take any measurement from before that, or confirm the arm it used was unaffected. This was written before
+either had an open PR, which is why it is here rather than in a review comment.
+
+<!-- post-merge: checked -->
+**Settled for astubbs/parallel-consumer#105: its arm WAS affected.** The leak was closed by
+astubbs/parallel-consumer#265, which deletes `parallel-consumer-core/src/test/resources/junit-platform.properties`;
+that PR's wall-clock figures were all taken before it, so they describe a gate whose non-core modules were
+thread-parallel despite `parallel-tests=false`. The fork-ORDERING statistics that PR ships are unaffected -
+they were regenerated against the merged tree - but its headline seconds need re-taking before anyone cites
+them. `ci/reenable-parallel-tests` is still unchecked.
+<!-- file-refs: N/A - names the file the fix DELETED, so it is deliberately gone from the tree -->
 
 Worth knowing before re-running either: `docs/solutions/test-flakiness/unit-tests-parallelise-by-forking-not-threading-2026-07-29.md`
 already measured the choice - forking x12 gives a reliable 1:38, thread parallelism x20 gives an intermittent

docs/inflight/ci-codecov-flags-not-like-for-like.md

@@ -41,6 +41,46 @@ un-cover anything - which is why this was left alone rather than guessed at. Nar
 per-suite `files` value in the matrix, and three of the five suites (`performance`, `lincheck`,
 `chaos`) would need their report shape established first rather than assumed.
 
+## Sighting, 2026-09-07: the two sides still count different FILE SETS
+
+<!-- post-merge: checked-begin -->
+Observed on astubbs/parallel-consumer#105, check `codecov/project/unit`. That PR is the cleanest
+possible probe for this, and the reason is worth stating before the numbers: **its diff contained no
+Java at all** when the sighting was taken - a build property, a shell-script line, some documents and
+some checked-in data files. So any difference the comparison reports is the comparison's, not the
+change's. (That PR has since been re-scoped to documentation only, which does not weaken the probe -
+it strengthens it.)
+
+Reproduce the shape from that PR's codecov comment; the figures are deliberately not copied here,
+because they move at every re-upload and a stale one reads as current:
+
+- The base codecov chose was **an ancestor of the PR head**, provable with
+  `git merge-base --is-ancestor <base> <head>`. Everything in the base is therefore in the head.
+- Codecov nonetheless reported the head as carrying **more files and more lines than that base** -
+  double-digit files, hundreds of lines. With no Java in the diff and the base contained in the
+  head, no diff can produce that. **The two sides are measuring different file sets**, which is the
+  same defect as the `default`-versus-suite-flags case above, surviving the flag split.
+- `codecov/patch` passed and the whole-repository `project` number **rose**. Only the flag-scoped
+  `unit` gate was red, and it was red on a PR that changed no code.
+- `integration`, `chaos` and `performance` each showed **no base value at all** - codecov renders
+  them `(?)` - so `unit` was the only flag with two sides to compare.
+
+**Which half of this note that supports.** The first open item - "the fix cannot be verified by the
+change that makes it", expecting red-or-no-data on the first PRs after the split lands. Master has
+since run and uploaded, because `unit` had a base to compare against; `integration` did not, so that
+item is **partly** discharged and partly still live. The prediction that it "clears once master has
+re-uploaded under the new flags" did not hold for `unit`: master re-uploaded, the flag compared, and
+it was still wrong.
+
+**Which half it does NOT test, and must not be read as testing.** The shared-upload-glob mechanism -
+`files:` globbing both jacoco patterns for every suite - remains **unverified**. A file-set
+mismatch is *consistent with* that glob putting files in a PR's `unit` flag that master's `unit`
+upload never carried, but this sighting inspected no uploaded report and identified no specific
+file. It does not establish which side is wrong, whether the glob is the cause, or whether some
+other asymmetry between `ci-unit-test.sh` and `ci-build.sh`'s surefire half explains it. Settling
+that still needs the per-suite `files` work described above, or a diff of the two flags' file lists.
+<!-- post-merge: checked-end -->
+
 ## 2026-09-07: master's own `unit` history falsifies "so a drop there is a real drop"
 
 The `<!-- post-merge: checked -->` block above claims both sides of the `unit`/`integration` gates
@@ -57,15 +97,16 @@ genuine `failure` state - reproduce with the status command above - on commits t
 introduce a coverage regression: the very next master commit lands back in the other band. A gate
 whose own text says a drop on it is real, going red on master against master, is the falsification.
 
+<!-- post-merge: checked-begin -->
 **Not the same sighting as the two related ones already on file, and neither settles it.**
 astubbs/parallel-consumer#431's `ed6b8f461` documents a **verified, narrower** cause - a single base
 report short on files and lines because its upload was partial - which explains a one-off red on a
-PR compared against a specific truncated master commit. The `optimize/unit-gate` branch
-(astubbs/parallel-consumer#105) adds a sighting to this same file finding the PR and its base
-disagree on `unit`'s file set even though the base is a git ancestor of the head, and leaves the
-cause **explicitly unverified** - a candidate (the shared jacoco upload glob) named but not checked
+PR compared against a specific truncated master commit. The FILE SETS sighting above finds that a PR
+and its base disagree on `unit`'s file set even though the base is a git ancestor of the head, and
+leaves the cause **explicitly unverified** - a candidate (the shared jacoco upload glob) named but not checked
 against an actual file list. Neither is a same-commit-pair, master-vs-master comparison: both are a
-PR against one base at one point in time. A stable two-band oscillation across many consecutive
+PR against one base at one point in time.
+<!-- post-merge: checked-end --> A stable two-band oscillation across many consecutive
 master pushes, with no relation to diff content, is a different shape from either, and this note
 records it rather than folding it into theirs.
 
@@ -83,7 +124,8 @@ comparison yet.
 of this blocks a merge. The cost is upstream of blocking: astubbs/parallel-consumer#444 is a PR
 whose diff added no files under `src/main/java` and still read a real `unit` drop while the
 project-wide total rose, purely because its base happened to sit in the other band from its head -
-the same shape as the PR the `optimize/unit-gate` sighting describes. A gate that flips on
+<!-- post-merge: checked -->
+the same shape as the PR the FILE SETS sighting above describes. A gate that flips on
 roughly every other master commit, independent of content, cannot be told apart from a genuine
 unit-coverage regression by looking at the number alone - the noise band is wide enough to hide a
 real drop of the same size. "So a drop there is a real drop" is no longer a safe reading of this