Spike: settle the two gate-mechanism assumptions before building for them

Two cheap experiments decide the shape of the release gate. Both are blockers in the sense that building for the wrong answer wastes the build — #136's 0a should not start until they are settled.

1. Does a local uses: ./path composite action work inside a container: job?

This determines whether one repo can hold both the sandbox and the gate role, which is the question #136 turns on.

If a workflow can actions/checkout this repo at an arbitrary ref into a path and then call uses: ./path/build-lectures, a single gate.yml in the existing canary — carrying a workflow_dispatch input for the candidate ref and a digest-pinned container — holds every property #136 asks for, with no second repo and no v0-next tag. GitHub forbids expressions in uses:, but a checked-out path is not a ref, so the constraint does not apply.

The reason this is not obvious is #83. ${{ github.action_path }} expands to the runner's path, while inside a container: job the action is mounted at /__w/_actions/... — so bash received a nonexistent path and exited 127 before the script ran. That is documented at build-jupyter-cache/action.yml:361-365, and it is the same host-vs-container path-mapping class that local uses: would exercise.

• In a throwaway branch of QuantEcon/test-actions-lecture-intro, add a workflow with a container: block that checks this repo out into ./actions-repo and calls uses: ./actions-repo/build-lectures on the trimmed toc
• Record whether the composite resolves, and whether anything inside it that reaches for github.action_path still breaks

Works → harden the canary with a gate.yml; #136 can close as superseded and 0b loses the v0-next tag entirely. Fails → a second ref namespace is genuinely required, #136 stands, and the v0-next design in #135 is the right one.

2. Would a dispatch-driven gate be vacuously green on the preview path?

Both preview actions gate three steps on github.event_name == 'pull_request':

• preview-netlify/action.yml:48, :63, :101
• preview-cloudflare/action.yml:60, :75, :148

So a gate run triggered by workflow_dispatch or repository_dispatch skips the build, the deploy and the comment, and reports green having deployed nothing. This is inherited unchanged by a new fixture repo, so it is not an argument for either option — it is a prerequisite for both, and precisely the "test that cannot fail" pattern of #108.

• Confirm the skip behaviour on a dispatch run
• Decide the fix: widen the condition to accept the gate's trigger, or give the gate an explicit input that satisfies it — without weakening the fork trust-check the same condition provides (see #105)

Related: the canary's publish.yml has no workflow_dispatch at all (on: push: tags: 'publish*'), so the publish path cannot currently be driven by a gate either. It has run 9 times ever, last on 2026-02-10 — publish-gh-pages has had zero end-to-end exercise across v0.7.0 → v0.11.1, which is the strongest standing argument for doing this work.

Why this is separate

#135 and #136 both assume a design. These two checks test the assumptions underneath both, cost well under a day, and one of the outcomes removes a repo and a tag from the plan. Blocks #138 item 0a.

Start with a throwaway branch in QuantEcon/test-actions-lecture-intro and test a container job that checks out this repo and calls ./actions-repo/build-lectures. Then inspect the conditions in preview-netlify/action.yml and preview-cloudflare/action.yml and run a dispatch-triggered gate. Done means both experiments are recorded, including action_path behavior and dispatch skip behavior, with the resulting choice for #136 and #135 documented.