docs/fix: console-message audit, two backlog fixes, backlog-numbering cleanup

.github/workflows/batch-check.yml

@@ -331,8 +331,9 @@ jobs:
         # producing a circular self-skip: confirmed via the GitHub Actions API against the CI runs
         # for two real commits on PR #390 (efd7a5c, fd7a046) that ~27 real/conda-full-only self-
         # tests silently "skipped" every run while the job still reported overall SUCCESS. See
-        # CLAUDE.md's Active Backlog item 7 for the full incident writeup and PR #391 for the
-        # revert that restored those steps to unconditional (matrix.mode == 'conda-full') form.
+        # docs/agent-closed-backlog.md's Active Backlog item 7 for the full incident writeup and
+        # PR #391 for the revert that restored those steps to unconditional (matrix.mode ==
+        # 'conda-full') form.
         #
         # This step is now positioned right after "Self-test: real env smoke (CI-only)"
         # (selfapps_envsmoke.ps1) instead -- traced 2026-07-27 as the genuine first selfapps step
@@ -345,8 +346,9 @@ jobs:
         # own script would otherwise allow, so a nonzero exit there can only mean the conda install
         # itself failed -- making this the correct point to sample "is conda now really available."
         #
-        # Re-wired 2026-07-27 (owner sign-off, full risk/benefit assessment in chat -- see CLAUDE.md
-        # Active Backlog item 7's own closing entry for the summary) after the corrected POSITION
+        # Re-wired 2026-07-27 (owner sign-off, full risk/benefit assessment in chat -- see
+        # docs/agent-closed-backlog.md's Active Backlog item 7 entry for the summary) after the
+        # corrected POSITION
         # above was empirically confirmed working across two real conda-full runs (PR #395, #396:
         # `available` correctly read `true` both times). The 27 downstream conda-full-only self-test
         # steps below now gate on `steps.conda_avail.outputs.available == 'true'` -- BUT this alone

CLAUDE.md

@@ -534,28 +534,6 @@ number) in `docs/agent-closed-backlog.md`, which is why the numbering below does
      `docs/demo-bootstrapper-output.md`'s new default-happy-path scenario as an observed,
      unexplained anomaly rather than either asserting it's harmless or that it's a bug.
 
-- **9. README.md's `[REQ-018]` bullet describing the mandatory verification run as
-   "force-stopped after a short interval even if running fine" is stale relative to the
-   activity-aware-kill behavior actually shipped later -- found 2026-07-29 via a CodeRabbit review
-   comment on PR #400 that (correctly) flagged a possible mismatch between README's REQ-018 prose
-   and `docs/demo-bootstrapper-output.md`'s new Scenario 11.** Traced it down: the real, current
-   WARN text (quoted verbatim in Scenario 10 from a real CI capture) says the opposite of what
-   README currently claims -- "if it stays completely silent for about 30 seconds it will be
-   force-stopped, but any output (including a prompt waiting on your input) keeps it running as
-   long as needed" -- matching CLAUDE.md's own already-documented Closed Backlog entry,
-   "Activity-aware EXE-smoke kill (docs/plan-cli-interactive-verification.md P0, requirement 3) --
-   resolves Open Question 1." That feature shipped after README's REQ-018 section was last written
-   and the corresponding bullet was apparently never updated to match. **Not fixed in this pass**
-   -- deliberately left for its own small, dedicated pass rather than edited as a side effect of an
-   unrelated docs-only PR (`docs/demo-bootstrapper-output.md`'s own scope): README.md is this
-   repo's authoritative PRD, and CLAUDE.md's own instruction is to reference it, not duplicate or
-   casually rewrite it. `docs/demo-bootstrapper-output.md`'s Scenario 11 already carries an inline
-   note explaining the discrepancy so a reader isn't left confused between the two docs in the
-   meantime. Suggested fix shape: update the REQ-018 bullet's "force-stopped after a short interval
-   even if running fine" clause to describe the activity-aware condition instead (only a
-   completely silent process is force-stopped; any output at all keeps the run alive
-   indefinitely).
-
 - **10. Two of the five `PVW_*` super-user override variables (`PVW_PYTHON_EXE`, `PVW_WORKSPACE`)
    have ZERO test coverage of any kind, and ALL FIVE have zero coverage of their invalid-value
    behavior -- found 2026-07-29 while documenting them for `docs/demo-bootstrapper-output.md`'s
@@ -587,30 +565,6 @@ number) in `docs/agent-closed-backlog.md`, which is why the numbering below does
      so 2-3 representative invalid-value cases would likely cover the real risk without a
      combinatorial test matrix).
 
-- **11. `:tci_justme`'s `[WARN] Miniconda AllUsers install failed; retrying with JustMe.` log line
-   fires unconditionally, even when AllUsers was never actually attempted -- found 2026-07-29
-   while documenting the Miniconda install chain for `docs/demo-bootstrapper-output.md`'s Part VI,
-   flagged by a CodeRabbit review on PR #401 and verified against real CI evidence and the actual
-   `run_setup.bat` source before acting.** `:try_conda_install` has three distinct paths into the
-   shared `:tci_justme` label: (a) `HP_TEST_NOT_ELEVATED=1` (test-only, simulates a non-admin
-   environment) skips straight to `:tci_justme` with no AllUsers attempt at all; (b) a real
-   `fsutil dirty query %systemdrive%` failure (the genuine non-elevated-process detection) does
-   the same; (c) a real, genuine AllUsers installer failure (`:run_installer_timeout` returning
-   nonzero) also falls through to `:tci_justme`. All three paths log the identical
-   `[WARN] Miniconda AllUsers install failed; retrying with JustMe.` line at `:tci_justme` itself,
-   regardless of which path got there -- so on the common non-elevated real-world machine (paths a
-   or b), the WARN text is a misnomer: AllUsers was never launched, only skipped, yet the log
-   claims it "failed." Confirmed directly against real CI capture (run `30328748330`, `justme-test`
-   and `uv` lanes): both the `[INFO] Not elevated; skipping AllUsers Miniconda install.` line and
-   the `[WARN] ... AllUsers install failed ...` line appear back-to-back for the identical
-   non-elevated test run, with no genuine AllUsers attempt in between. **Not fixed in this pass**
-   -- this PR is documentation-only (see this file's own standing policy on scope); the doc itself
-   was corrected to explain the shared-label/unconditional-wording behavior accurately rather than
-   presenting the two log lines as if AllUsers were genuinely attempted-then-failed. Suggested fix
-   for a future pass: track whether AllUsers was actually launched (e.g. a flag set only inside
-   the real `:run_installer_timeout` call, checked at `:tci_justme` to select between "skipping"
-   and "failed" wording) rather than a single unconditional message covering all three paths.
-
 - **12. `:embed_dl_retry`'s genuine mid-download-failure-then-retry-once path (REQ-009 Tier 5) has
    no CI test hook at all -- found 2026-07-29 while documenting the embed-tier download for
    `docs/demo-bootstrapper-output.md`'s Part VI, Scenario 20.** Confirmed via `run_setup.bat`
@@ -732,6 +686,41 @@ number) in `docs/agent-closed-backlog.md`, which is why the numbering below does
    of what's shown) -- but a future pass fixing this should also confirm no currently-passing test
    silently relies on the unbounded behavior before adding a timeout.
 
+- **18. Active Backlog items 8, 10, 12, 13, 14, and 15 all appear to reuse item numbers already
+   permanently retired by older, unrelated closed items -- found 2026-07-31 while closing out
+   items 9 and 11 during a `/goal`-directed backlog-fix pass, both of which turned out to have the
+   identical problem (fixed for those two; this item tracks the rest).** The batch of findings
+   filed 2026-07-29 while documenting the bootstrapper for `docs/demo-bootstrapper-output.md`
+   (this file's current items 8, 10, 12, 13, 14, 15, plus the now-fixed 9 and 11) appears to have
+   picked its numbers by eyeballing what looked unused in THIS file at the time, without checking
+   `docs/agent-closed-backlog.md`'s own "Closed Backlog" changelog section (2026-07-25 through
+   2026-07-27 work) for numbers already retired there. Confirmed for 9 and 11 specifically (both
+   collided with real, already-closed, differently-numbered items -- see
+   `docs/agent-closed-backlog.md`'s Item 16 and Item 17 entries for the full trace of each) and
+   both renumbered to 16/17 when moved out of this file in the same pass that found this. A quick
+   grep-based check (`grep -n "item N\b"` across `docs/agent-closed-backlog.md`, `docs/agent-
+   ndjson.md`, `docs/agent-interconnect.md`, `docs/agent-lessons-learned.md` for each of N in
+   8, 10, 12, 13, 14, 15) shows a same-number hit in the older Closed Backlog section for every
+   single one of them, strongly suggesting the same mistake repeats across the whole batch --
+   but each was only confirmed by number match, not individually read and verified the way 9 and
+   11 were, so **treat this as a strong lead, not a certainty, until each one gets the same
+   individual check.** Notably, item 14's collision is NOT purely a docs problem: `run_setup.bat`
+   itself has a live `rem derived requirement: [Active Backlog item 14]` comment (in
+   `:try_conda_install`, next to the Miniconda installer timeout) that refers to the OLDER,
+   already-closed item 14 (the 60-minute installer-timeout work), not the current active item 14
+   (the misleading post-exhaustion syntax-error message) -- so fixing this properly means checking
+   inline source comments too, not just docs. **Not fixed in this pass** -- renumbering the
+   remaining six items correctly requires reading each one's full closed-backlog collision
+   individually (to write an accurate, non-templated "renumbered from X because Y" note the way
+   16/17 got), then re-numbering every cross-reference to each (docs and, per the item-14 finding
+   above, possibly `run_setup.bat`'s own comments) -- real, careful work, not a batch find-replace,
+   and disproportionate to fold into an unrelated backlog-fix pass. Suggested approach for a
+   future pass: process one item at a time (matching this repo's own iteration discipline), confirm
+   its collision, pick the next genuinely-unused number (19 is next after this item, assuming no
+   further items get filed first), update its own text plus every cross-reference, and move it to
+   `docs/agent-closed-backlog.md` only if it was ALSO independently resolved -- an item can be
+   renumbered without being closed, if its underlying finding is still open.
+
 ## Cold Storage (promising ideas, deliberately shelved -- revisit only if a named trigger fires)
 
 Moved to `docs/agent-cold-storage.md` (2026-07-31, to reduce this file's per-session context

README.md

@@ -460,7 +460,7 @@ At completion:
 Running the user's program IS the goal -- a beginner who cannot launch it themselves is exactly who this tool serves -- but each run must be treated as potentially destructive: a program is not guaranteed to be idempotent, and one run can overwrite files, send network requests or email, mutate a database, or actuate connected hardware (e.g. a VISA/serial instrument). The bootstrapper therefore runs the user's code purposefully and at most once per invocation, never repeatedly and never via two launch methods in the same run.
 
 - **Fast path is the user's run (frictionless).** When a current, already-verified EXE exists (sources unchanged since it was built), double-clicking the batch runs it directly and untimed, with no prompt and no console interaction -- the double-click is the user's intent to run, and this is the session's single run. A fast non-zero exit is still treated as a stale/broken EXE and triggers a rebuild (REQ-007); a program that keeps running is the user's app, left to run.
-- **Verifying a fresh build is time-boxed and announced.** When the bootstrapper builds or rebuilds the EXE, it runs it once to verify, force-stopped after a short interval even if running fine, and preceded by a clear warning that this is a throwaway check so the user does not start real work in it. This is the only run that is killed on a timer.
+- **Verifying a fresh build is activity-aware and announced.** When the bootstrapper builds or rebuilds the EXE, it runs it once to verify, preceded by a clear warning that this is a throwaway check so the user does not start real work in it. This run is only force-stopped if it stays completely silent for about 30 seconds; any output at all -- including a prompt waiting on input -- keeps it running for as long as needed, so an interactive program gets a real chance to be exercised. (A separate, narrower re-verification inside the `--hidden-import` auto-recovery loop remains unconditionally time-boxed at ~30 seconds, since it exists only to confirm one specific repair worked.) This is the only primary verification run that can be force-stopped at all.
 - **After a build, the real run is offered, not forced.** Following a successful build and verification, the bootstrapper offers to launch the app untimed for real, so a beginner need not launch it manually. The offer is consent-gated and names the side-effect/idempotency risk; declining leaves the verified EXE plus the post-flight guidance.
 - **Consent before any extra run.** Beyond the single automatic run, any further execution -- re-running, or running via the other launch method -- requires explicit consent that names the risk that the program may not be safe to run twice.
 - **Non-interactive and CI** resolve every gate without hanging: no untimed run, and offers auto-decline.

docs/agent-closed-backlog.md

@@ -473,6 +473,81 @@ further.)*
 
 ---
 
+### Item 16 (closed 2026-07-31; moved here same pass; renumbered from 11)
+
+**Renumbered from 11 to 16 when moving here** -- this finding was originally filed in CLAUDE.md's
+Active Backlog as "item 11," but that number was already permanently retired by the older
+"Hidden-import auto-recovery exhaustion coverage" entry in this file's own Closed Backlog section
+below (closed 2026-07-25, still correctly cited as "item 11" by `docs/agent-ndjson.md`'s
+`self.exe.hidden_import.exhaust` entry) -- a genuine number reuse that must have slipped in when
+this finding was first logged. Renumbered to 16 and 17 respectively (see the sibling entry right
+after this one) -- the next two numbers never used anywhere in this repo's docs -- rather than
+leaving the collision in place; no other doc referenced this finding as "item 11" before this
+move, so the renumber is clean. **This is one instance of a wider, unrelated bug** -- see the new
+Active Backlog entry filed in the same pass for the full scope (items 8, 9, 10, 12, 13, 14, and 15
+all appear to reuse numbers already retired the same way; only 9 and 11 were actually renumbered
+here, since those were the two items this pass touched for unrelated reasons).
+
+- **`:tci_justme`'s `[WARN] Miniconda AllUsers install failed; retrying with JustMe.` log line
+   fired unconditionally, even when AllUsers was never actually attempted -- found 2026-07-29
+   while documenting the Miniconda install chain for `docs/demo-bootstrapper-output.md`'s Part VI,
+   flagged by a CodeRabbit review on PR #401 and verified against real CI evidence and the actual
+   `run_setup.bat` source before acting.** `:try_conda_install` has three distinct paths into the
+   shared `:tci_justme` label: (a) `HP_TEST_NOT_ELEVATED=1` (test-only, simulates a non-admin
+   environment) skips straight to `:tci_justme` with no AllUsers attempt at all; (b) a real
+   `fsutil dirty query %systemdrive%` failure (the genuine non-elevated-process detection) does
+   the same; (c) a real, genuine AllUsers installer failure (`:run_installer_timeout` returning
+   nonzero) also falls through to `:tci_justme`. All three paths logged the identical
+   `[WARN] Miniconda AllUsers install failed; retrying with JustMe.` line at `:tci_justme` itself,
+   regardless of which path got there -- so on the common non-elevated real-world machine (paths a
+   or b), the WARN text was a misnomer: AllUsers was never launched, only skipped, yet the log
+   claimed it "failed." Confirmed directly against real CI capture (run `30328748330`, `justme-test`
+   and `uv` lanes): both the `[INFO] Not elevated; skipping AllUsers Miniconda install.` line and
+   the `[WARN] ... AllUsers install failed ...` line appeared back-to-back for the identical
+   non-elevated test run, with no genuine AllUsers attempt in between.
+   **Fixed 2026-07-31.** `:try_conda_install` now sets `HP_CONDA_ALLUSERS_ATTEMPTED=1` (reset
+   defensively at subroutine entry) immediately before the real AllUsers install attempt, and
+   `:tci_justme` branches its log line on whether that flag is defined: the genuine-failure path
+   keeps the original WARN wording unchanged, while both skip paths now log
+   `[INFO] Miniconda AllUsers install skipped (not elevated); trying JustMe install instead.`
+   instead. Confirmed safe against all three existing tests that reach this code path
+   (`tests/selfapps_justme.ps1`, `tests/selfapps_conda_bothfail.ps1`) -- none asserted on the old
+   WARN text for the skip-path scenarios they exercise. Added a new regression assertion to
+   `tests/selfapps_justme.ps1` (`skippedWordingCorrect`/`failedWordingAbsent`) confirming the new
+   INFO wording fires and the old WARN wording does NOT, in the non-elevated simulation this test
+   already runs.
+
+---
+
+### Item 17 (closed 2026-07-31; moved here same pass; renumbered from 9)
+
+**Renumbered from 9 to 17 when moving here** -- filed in CLAUDE.md's Active Backlog as "item 9,"
+but that number was already permanently retired by the older "Cascade-vs-postexec fix" entry in
+this file's own Closed Backlog section below (closed 2026-07-25, still correctly cited as
+"item 9" by both `docs/agent-ndjson.md` and `docs/agent-interconnect.md` -- both auto-loaded into
+every session). Nothing outside CLAUDE.md's own now-removed entry referenced this finding as
+"item 9," so the renumber is clean (see the preceding item's own header for the wider collision
+this belongs to).
+
+- **README.md's `[REQ-018]` bullet describing the mandatory verification run as
+   "force-stopped after a short interval even if running fine" was stale relative to the
+   activity-aware-kill behavior actually shipped later -- found 2026-07-29 via a CodeRabbit review
+   comment on PR #400 that (correctly) flagged a possible mismatch between README's REQ-018 prose
+   and `docs/demo-bootstrapper-output.md`'s new Scenario 11.** Traced it down: the real, current
+   WARN text (quoted verbatim in Scenario 10 from a real CI capture) said the opposite of what
+   README claimed -- "if it stays completely silent for about 30 seconds it will be
+   force-stopped, but any output (including a prompt waiting on your input) keeps it running as
+   long as needed" -- matching this file's own "Activity-aware EXE-smoke kill
+   (docs/plan-cli-interactive-verification.md P0, requirement 3) -- resolves Open Question 1"
+   entry below. That feature shipped after README's REQ-018 section was last written and the
+   corresponding bullet was never updated to match.
+   **Fixed 2026-07-31**, in the same pass as the bottom-up console-message audit: the bullet now
+   reads "Verifying a fresh build is activity-aware and announced," describes the actual
+   silent-vs-any-output condition, and separately notes that the narrower re-verification inside
+   the `--hidden-import` auto-recovery loop remains unconditionally time-boxed (unaffected by this
+   fix, by design -- see this file's own entry on that loop for why). No behavior changed; this
+   was a documentation-only correction.
+
 ## Closed Backlog
 
 - **Cascade-vs-postexec fix (Active Backlog item 9), 2026-07-25, owner-directed follow-up to a