diff --git a/CLAUDE.md b/CLAUDE.md index be65bf08..37dafd8b 100644 --- a/CLAUDE.md +++ b/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) diff --git a/docs/open-questions.md b/docs/open-questions.md index 8d34b708..6dec7456 100644 --- a/docs/open-questions.md +++ b/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.