[jdsika]

What

Moves the documentation-only detector into a reusable workflow and gates the six-job installation matrix on it, so a pull request that touches only Markdown stops paying for pip install on six runners.

Why

#15 skipped CI's five heavy jobs on documentation-only pull requests, but left the installation matrix running. This finishes the job.

Notes

This PR is parked. It cannot pass Fork gates until upstream merges Emerge-Lab#602, and that is a correct result rather than a defect in the change. See below.

Gate 2 cannot pass yet, and the reason is structural

Gating the installation matrix means editing its Install pufferlib (Linux) and Install pufferlib (macOS) steps. Those two steps exist only because of our fix(ci): install CPU-only torch wheels commit — upstream still has a single, undivided Install pufferlib step. The commit therefore depends on a fork feature that upstream has not merged, and cherry-picking it onto pure upstream/3.0 conflicts.

Measured directly, by cherry-picking onto upstream/3.0 (73ffdcbbe):

Content	Applies to pure upstream
reusable detector + ci.yml call	clean
the same, plus the install.yml gating	conflict in install.yml

So the detector refactor is upstream-ready; only the installation gating is entangled. Splitting them is not worth it — the reusable workflow exists to serve the second caller, and with one caller it is pure overhead.

Per .github/copilot-instructions.md §4.8, a feature that is good but not yet upstream-ready does not go on the stack. The branch stays as-is and is ready to merge the moment Emerge-Lab#602 lands upstream; re-run Fork gates then.

A second defect, found and fixed here

The first revision gated the matrix at job level. That would have deadlocked every documentation-only pull request: GitHub evaluates a job-level if before expanding the matrix, so a skipped matrix job reports a single check with the raw, uninterpolated name and the six required contexts never appear at all. Branch protection would wait at Expected forever.

Verified empirically in #24, which ran both styles side by side on a real pull request:

• job-level gating produced one check literally named probe joblevel ${{ matrix.py }} - ${{ matrix.os }};
• step-level gating emitted both expanded names and passed with the work skipped.

The matrix job now carries if: always() and the predicate sits on its steps, written once as a step output so the five steps cannot drift apart.

Non-matrix jobs are unaffected — #22 confirmed CI's ordinary jobs report a proper skipped check and leave mergeStateStatus at CLEAN.

Validation

• pre-commit run --all-files — passed (all 5 hooks)
• all three workflow files parse as YAML, and the step conditions were read back from the parsed tree
• install.yml gating behaviour proved by probe [probe] how does a skipped matrix job report its checks #24; ci.yml skip behaviour proved by probe [probe] docs-only CI skip #22
• Track B (forkctl track): workflow files only, nothing sim-affecting

Upstream readiness

Not ready, and deliberately so. Blocked on Emerge-Lab#602.

[jdsika]

Fork gates failed, and it is right

Gate 2:

== mirror/share-change-detector
        feature commit 335e2945b  ci: share the documentation-only detector with the install workflow
  FAIL  cherry-pick onto pure upstream failed -- the commit is entangled with fork-only state

Reproduced locally in a scratch worktree on pure upstream/3.0 (73ffdcbbe):

CONFLICT (content): Merge conflict in .github/workflows/ci.yml

The diagnosis in the message is slightly off — nothing here is entangled with fork-only state — but the failure is real and the gate is doing its job. This commit replaces the inline detector block in ci.yml, and that block exists only because of #15. Upstream has never seen it, so there is nothing to replace and the hunk cannot apply.

That is exactly the §4.8 rule:

Never branch a feature off another unmerged feature. Each feature must apply to pure 3.0.

#15 is merged into integration/3.0, but it is not upstream, so for Gate 2's purposes it does not exist. This is the first commit on the stack to depend on an earlier fork feature, which is why the rule has not bitten until now.

Resolution

#15 and this change are not two ideas; this is the completion of one. #15 skipped the test jobs on documentation-only PRs and left the six-job install matrix running — a half-delivered feature that probe #22 exposed. The right shape on the stack is a single commit.

Verified in the scratch worktree that the combined form is upstream-clean, which neither half is on its own:

cherry-picked onto 73ffdcbbe	result
335e2945b alone (this PR)	conflict in ci.yml
351531d89 then 335e2945b	clean
the two squashed into one commit (65982e460)	clean — ci.yml, install.yml, detect-code-changes.yml

So the content is good and upstream-ready; only the commit boundary is wrong.

This will be folded into the ci: skip the test jobs on documentation-only pull requests commit on the stack, in the same way a chore(fork) change is folded into the fork base, and this PR closed unmerged. The merged result is byte-identical to what is on this branch.

Worth recording

No human review would have caught this. The diff is clean, the YAML is valid, every test passes, and the change is plainly correct against integration/3.0. The defect is only visible against a tree nobody had locally. One automated cherry-pick onto pure upstream found it in 26 seconds — concrete evidence for Gate 2 earning its place when the rest of the ceremony was removed.

[jdsika]

Parked as a draft. Both review findings are fixed (step-level matrix gating, proved by #24; rename detection and fail-safe predicates carried over from #15), but Gate 2 is blocked on Emerge-Lab#602 for the structural reason now written up in the description. Nothing to do here until that lands upstream.