Update Item 61's blocker: probe workflow merged, dispatch needs manual run

CLAUDE.md

@@ -1249,11 +1249,17 @@ way (no live Windows execution available here), that is noted explicitly rather
   has now been wrong multiple times in this repo's history, per `docs/agent-lessons-learned.md`'s
   "`:log` echoes UNQUOTED" entry's own general warning).
 
-  **Blocked on how to get that live `cmd.exe` verification cheaply -- registered as
-  `docs/open-questions.md` item 5** (this sandbox has no Windows access at all; the only real
-  cmd.exe reachable is a GitHub Actions Windows runner, and the two existing ways to reach one both
-  run the full, expensive 8-lane matrix for what should be a few-seconds narrow parsing question).
-  Not actionable until the maintainer picks a path there.
+  **Probe workflow built and merged (PR #461, `.github/workflows/batch-paren-hazard-probe.yml` +
+  `tools/probe_paren_hazard.ps1`), per the maintainer's approval -- but dispatching it hit a
+  SECOND, narrower blocker: this session's own GitHub integration cannot call the
+  `workflow_dispatch` API (`403 Resource not accessible by integration`), confirmed against both
+  repo-name casings, so an agent in this session cannot fire the probe itself even though the tool
+  now exists on `main`.** Registered as `docs/open-questions.md` item 5 (updated to reflect this
+  narrower blocker, not the original "which unblocking mechanism" question, which the maintainer
+  already answered). Not actionable until either the maintainer manually runs the workflow from
+  the Actions UI (Actions tab -> "Batch paren-nesting hazard probe" -> "Run workflow" on `main`)
+  and shares the result, or the integration is granted the Actions write permission needed for
+  `workflow_dispatch` and a future agent retries the API call.
 
 ## Cold Storage (promising ideas, deliberately shelved -- revisit only if a named trigger fires)
 

docs/open-questions.md

@@ -103,43 +103,33 @@ Without an answer, Item 35's own soak-then-promote slices can get PREPARED (impl
 several green runs) but never actually CLOSED -- the last step structurally can't happen without
 this.
 
-## 5. CLAUDE.md Active Backlog Item 61: how should the agent get genuine cmd.exe verification for the remaining same-line-paren question, and is it worth a new CI surface to get it cheaply?
-
-Item 61's own "Revised item scope" note says the remaining question -- whether a SAME-LINE,
-self-contained `(`/`)` pair nested inside a real open `if`/`for` block is safe, the same way a
-top-level one is -- "likely requiring live `cmd.exe` verification per this repo's own established
-practice for this hazard class, not static reasoning alone." That practice exists for a reason:
-static reasoning about cmd.exe's own paren/quote parsing has been wrong THREE separate times in
-this exact hazard class already (see `docs/agent-lessons-learned.md`'s "A literal `(`/`)` inside
-`echo` text..." entry) -- reasoning alone is not trusted evidence here, only a real cmd.exe run is.
-
-**The actual hang-up: this sandbox has no Windows/cmd.exe access at all** (Linux-only environment)
--- the only place real cmd.exe exists for this repo is a GitHub Actions Windows runner, reached
-today only via `batch-check.yml`'s existing triggers (`push: branches: ['**']` or
-`workflow_dispatch`, confirmed by reading the file directly). Both existing triggers run the FULL
-8-lane matrix (conda/uv installs, PyInstaller builds, the whole self-test suite) -- historically
-50-90+ minutes wall-clock -- to answer one narrow batch-parsing question that needs maybe a few
-seconds of real cmd.exe time. A throwaway branch with no PR (pushing triggers the matrix via the
-`push` wildcard, no PR needed) WOULD get real cmd.exe verification, but at the cost of a full,
-expensive matrix run per iteration -- clumsy for something likely needing a few rounds to nail
-down exactly which factor (nesting depth vs. the `>>`-redirection prefix, per Item 61's own
-still-unresolved "which factor actually matters was not isolated" note) is the real trigger.
-
-**Recommended alternative, not yet built or agreed to**: a new, SEPARATE workflow file,
-`workflow_dispatch`-only (matching this repo's own `workflow-lint.yml` precedent -- a workflow
-that exists but is not wired to `push`/`pull_request`), whose one job runs on a Windows runner and
-does nothing but execute a handful of crafted `.bat` fixtures (varying nesting depth, with/without
-the `>>` redirection prefix) and report cmd.exe's actual parsing behavior for each. This would be
-much cheaper per iteration (no conda/PyInstaller/pytest involved, likely under a minute) and
-reusable for any future instance of this same hazard class, not just Item 61 -- but it is still a
-new CI surface addition, which this repo's own coding guideline flags as something to be careful
-with ("Do not change workflow triggers, permissions, or retention settings" on the EXISTING
-`batch-check.yml` -- a new, separate file sidesteps that specific guideline, but adding any new
-workflow file is still a CI/CD change worth the maintainer's awareness before it's built).
-
-**Needs the maintainer's call**: build the dedicated `workflow_dispatch`-only probe workflow
-(reusable, cheap, but a new file in `.github/workflows/`), or use a throwaway branch against the
-existing full matrix (no new file, but ~1hr+ per iteration and likely needs a few iterations), or
-something else (e.g. asking the maintainer to test a small script by hand on a real Windows
-machine, if one is available to them)? Once picked, Item 61's own remaining scope becomes
-actionable without further discussion.
+## 5. CLAUDE.md Active Backlog Item 61: the probe workflow is built and merged, but this session's GitHub integration cannot dispatch it -- need it run manually (or the integration re-permissioned)
+
+**Original question (which unblocking mechanism) is answered and done**: the maintainer approved
+building a dedicated `workflow_dispatch`-only probe workflow (2026-08-23), which shipped and
+merged as PR #461 -- `.github/workflows/batch-paren-hazard-probe.yml` (a new, separate file, not
+wired to `push`/`pull_request`, matching the existing `workflow-lint.yml` precedent) plus
+`tools/probe_paren_hazard.ps1` (generates a same-line paren-nesting fixture matrix -- depth 1-4,
+with/without a `>>` redirection prefix -- plus a positive control using the already-confirmed
+-broken cross-line shape from PR #408/#445, executes each via real `cmd.exe`, reports which
+fixtures "survived"). Both are now on `main`.
+
+**New, narrower blocker found while trying to actually fire it**: this session's own GitHub
+integration/token cannot call the `workflow_dispatch` API --
+`POST .../actions/workflows/batch-paren-hazard-probe.yml/dispatches` returns
+`403 Resource not accessible by integration`, confirmed against both `python_vs_windows` and
+`Python_vs_Windows` casing (ruling out a naming issue). The same session CAN read check runs,
+read/merge PRs, and push commits -- so this is specifically a missing Actions-write permission on
+whatever GitHub App/token backs this integration, not a broader access problem.
+
+**Needs one of**:
+- The maintainer manually runs the workflow from the GitHub UI (repo -> Actions tab -> "Batch
+  paren-nesting hazard probe" -> "Run workflow" -> branch `main`) and shares the resulting job's
+  step summary/log with the agent, or
+- The integration is granted whatever Actions permission (`actions: write`, or the GitHub App's
+  equivalent "Actions" repository permission) is needed for `workflow_dispatch`, so a future agent
+  session can just call it directly.
+
+Once either happens, folding cmd.exe's real answer into CLAUDE.md's Item 61 entry and closing this
+question out is a small, mechanical follow-up -- the hard part (building a trustworthy, cheap
+probe) is already done.