sourcecode 5.9.26__tar.gz → 5.9.28__tar.gz

{sourcecode-5.9.26 → sourcecode-5.9.28}/CHANGELOG.md

@@ -1,5 +1,121 @@
 # Changelog
 
+## [5.9.28] — 2026-09-02
+
+*Remediation batch on the 5.9.27 audit queue: nine rows, one commit each. The
+round's own P0 — "does the shared worker pool tolerate concurrent `ask`
+processes on one machine, or assume exclusive use?" — is answered here in
+source, and the answer was exclusive use.*
+
+### Fixed
+
+- **Concurrent invocations no longer size their worker pools as if each owned
+  the machine (`R-01`).** `parallel.default_jobs()` returned `cpu_count() - 1`
+  per process, so `k` concurrent runs started `k x (N-1)` parsing workers on
+  `N` cores and nothing in any payload said the machine had been shared. A
+  best-effort census of live invocations now divides that budget, and
+  `_meta.concurrency` publishes peers at start, whether the budget was shared,
+  and that a shared run is not an isolated-machine measurement. `cache._gc`
+  defers eviction while a peer is live, so a sweep cannot delete the working
+  set a concurrent run is reading. `ASK_NO_CONCURRENCY_CENSUS=1` restores the
+  previous behaviour.
+- **The RSS ceiling stops a run where it is crossed (`BUG-22`, `REG-02`'s
+  enforcement half).** The check ran at phase boundaries only, so a phase
+  could allocate without bound and be refused after it finished — the field's
+  2,029.92 MB peak under a 1,536 MB ceiling that was genuinely in force. The
+  ceiling is now sampled inside the parse loop (throttled to one footprint
+  sample per 0.5 s) and raises a typed refusal rendered as the same
+  `MEMORY_TOO_LARGE` envelope, instead of `EXECUTION_FAILED`.
+- **A routing style this model does not read is published rather than reported
+  as an absent surface (`BUG-10`).** `unmodeled_routing_evidence` names the
+  files declaring an annotation whose argument is a path-like string literal
+  that produced no endpoint — a rule that names no framework. Measured:
+  `struts` reports 4 files under `@Action`/`@Namespace` where the answer used
+  to say nothing was found.
+- **Overloaded handlers publish their ambiguity (`NEW-02`/`BUG-05`).** The
+  symbol index is keyed `Class#method` without parameter types, so every
+  overload collapsed onto the last declaration scanned. Entries now carry
+  `overload_count`, `anchor_ambiguity` and `anchor_candidate_lines`; an
+  unambiguous anchor carries none of it.
+- **`selftest` refuses an unscoped run over nested repositories (`BUG-13`).**
+  It warned and then ran the ledger against the whole workspace. The implicit
+  `.` now refuses with `INVALID_USAGE` before any row runs; `--allow-nested`
+  is there for a caller who means it.
+- **Every cache store publishes what evicts it (`BUG-16`).** The context
+  cache's 30-day TTL and 256-entry cap lived inside `_gc`, so ~1.7 GB of
+  growth had no readable contract. `cache status` now prints each store's
+  eviction contract, read from the same authority the sweep uses.
+- **`_truncation_summary` accounts for its own bytes (`ALT-08`).**
+  `final_size_bytes` was measured before the summary and note were attached;
+  it is now measured over the assembled payload, with `content_size_bytes`
+  keeping the trimmed-content figure under a name that says which it is.
+- **`impact-chain` publishes a null audit share when no audit ran
+  (`ALT-25`).** `metadata.audit_time_ms` was always ~0.0 on the default path —
+  the elapsed time of *not* running an opt-in repository-wide audit, under a
+  name readers compare against `query_time_ms`.
+- **`retrieve security-surface --target` says why it has no anchor.** Four
+  rounds were answered "No such option: --target". The refusal now states that
+  the intent is repository-wide and names `security-chain --target`, derived
+  from `intent_router.ANCHOR_KINDS`.
+
+### Known Limitations
+
+- `ALT-01`/`ALT-03` remain open. This release removes the contention mechanism
+  the 5.9.27 round evidenced; it does not explain the one hang observed with
+  nothing else running. The next field round should re-measure with
+  `_meta.concurrency` attached — `peer_invocations_at_start: 0` beside a
+  failure separates contention from whatever remains.
+- `BUG-02` (`rc=127` with no output) and `BUG-12` (multi-gigabyte RSS while
+  building a small answer) still need the field's own large repository.
+  `BUG-22`'s in-phase sampler bounds the second one's damage without closing
+  it.
+- `ask --help` measures 0.41-0.44 s on the engineering host against
+  14.4-14.7 s in the field under confirmed contention. Not a refutation — a
+  different machine — and a reason to re-measure before profiling it as a
+  standalone defect.
+- The release gate is unchanged: do not use the audit-command family to gate
+  unattended CI until the field re-measures.
+
+## [5.9.27] — 2026-09-02
+
+*Follow-up from the 5.9.26 re-audit — a sharper instrumentation lead and a
+CLI-ergonomics regression.*
+
+### Fixed
+
+- `remediation-report` still accepts any repository path for invocation
+  consistency, but now discloses `path_argument: {given, used: false}`
+  whenever one is passed, whether or not it exists — a real path, no path,
+  and a nonexistent path no longer produce byte-identical, silently
+  misleading output.
+
+### Changed
+
+- Added a bounded entry-point trace (`record_entry_reached`) as the literal
+  first statement of the CLI entry point, scoped to the six audit-family
+  commands the empty-`exit 0` defect affects. The follow-up audit's
+  forensic sidecar never fired across 32 observed empty answers; this
+  answers a narrower question directly — did the failing process reach
+  this product's own entry point at all — instead of leaving it inferable
+  only from an absent failure record.
+
+### Known Limitations
+
+- The empty-`exit 0` failure across `spring-audit`, `verify`, `risk`,
+  `audit-report`, `migrate-check` and `migrate-apply` (`ALT-01`/`ALT-03`)
+  remains open. The 5.9.26 re-audit found the diagnostic sidecar added to
+  instrument it never fired in 32 observed occurrences — evidence the
+  failure happens before this product's own entry-point wrapper runs, not
+  inside a caught exception. The new entry-point trace targets exactly that
+  question; the underlying mechanism is still unconfirmed.
+- `--agent`'s RSS ceiling enforcement timing (`REG-02`) and `spring-audit`
+  warm-path performance (`REG-03`) are unchanged and need the field's own
+  large repository to validate safely.
+- The re-audit's own report was internally inconsistent this round (an
+  initial pass found 0/23 empty answers, a later pass in the same session
+  found 0/35 successful answers); neither reading is treated as regime
+  evidence on its own.
+
 ## [5.9.26] — 2026-09-02
 
 *Fix queue from the two 5.9.25 re-audits (multi-repository and native-Windows).*

{sourcecode-5.9.26 → sourcecode-5.9.28}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sourcecode
-Version: 5.9.26
+Version: 5.9.28
 Summary: Persistent structural context and ultra-fast repeated analysis for AI coding agents
 Project-URL: Homepage, https://github.com/HarounDominique/sourcecode
 Project-URL: Repository, https://github.com/HarounDominique/sourcecode
@@ -59,7 +59,7 @@ Description-Content-Type: text/markdown
 > question. All analysis is local and deterministic; see [Privacy](#configuration--privacy)
 > before inspecting a repository whose telemetry policy you need to control.
 
-![Version](https://img.shields.io/badge/version-5.9.26-blue)
+![Version](https://img.shields.io/badge/version-5.9.28-blue)
 ![Python](https://img.shields.io/badge/python-3.9%2B-green)
 
 Copyright (c) 2026 Dominique Haroun. All rights reserved. ASK Engine 5.7.0 and
@@ -290,7 +290,7 @@ brew tap haroundominique/sourcecode && brew install sourcecode
 # pip / pipx
 pipx install sourcecode        # or: pip install sourcecode
 
-ask version                    # ask 5.9.26 — and, on a build that has aged,
+ask version                    # ask 5.9.28 — and, on a build that has aged,
                                # how many releases have probably shipped since
 ```
 

{sourcecode-5.9.26 → sourcecode-5.9.28}/README.md

@@ -10,7 +10,7 @@
 > question. All analysis is local and deterministic; see [Privacy](#configuration--privacy)
 > before inspecting a repository whose telemetry policy you need to control.
 
-![Version](https://img.shields.io/badge/version-5.9.26-blue)
+![Version](https://img.shields.io/badge/version-5.9.28-blue)
 ![Python](https://img.shields.io/badge/python-3.9%2B-green)
 
 Copyright (c) 2026 Dominique Haroun. All rights reserved. ASK Engine 5.7.0 and
@@ -241,7 +241,7 @@ brew tap haroundominique/sourcecode && brew install sourcecode
 # pip / pipx
 pipx install sourcecode        # or: pip install sourcecode
 
-ask version                    # ask 5.9.26 — and, on a build that has aged,
+ask version                    # ask 5.9.28 — and, on a build that has aged,
                                # how many releases have probably shipped since
 ```
 

sourcecode-5.9.28/docs/AUDIT-2026-09-02-ALTERNATIVE-5.9.27.md

@@ -0,0 +1,102 @@
+# Alternative External Audit - 5.9.27
+
+## Scope And Verdict
+
+Native-Windows re-audit on the same MSAS repository (3,342 Java files) used
+in every prior round. Score **4.6/10**, the first uptick in four rounds (5.9.22
+6.6, 5.9.23 4.9, 5.9.25 4.3, 5.9.26 3.8). The uptick carries a large
+qualification discovered mid-session: this audit's own machine was shared
+with a second, independent automated process, and that materially changes
+how the four-round erratic-failure pattern should be read.
+
+## Priority Finding — Confirmed Shared-Machine Contention
+
+The auditor found the shared `entry-trace.jsonl` diagnostic file (added in
+5.9.27 to answer whether audit-family commands reach `main_entry`) growing
+with invocations they never launched, against five OSS reference
+repositories (`thingsboard`, `mall`, `struts`, `spring-petclinic`,
+`jhipster-sample-app`) under the same `timeout N ask ...` harness pattern the
+auditor uses. `Get-CimInstance Win32_Process` confirmed a live process under
+the same Windows user actively running `ask.exe risk mall --limit 20` at the
+time of inspection — not background noise, a second real test harness on the
+same machine, same user, same shared `~/.sourcecode` cache and diagnostics
+directory. Two of the auditor's own `spring-audit . --compact` hangs
+overlapped a 525-second window in which 34 foreign invocations were traced.
+
+This reframes, but does not resolve, the standing question. If ASK's shared
+worker pool and cache do not isolate concurrent `ask` processes on one
+machine, contention could produce exactly the observed pattern — the same
+command sometimes hanging, sometimes returning empty near-instantly, with no
+per-process variable distinguishing the two. It does not explain everything
+(one hang occurred right after the trace went quiet for 20 seconds with
+nothing else running), so contention is documented as a real, evidenced
+contributing factor, not a proven sole cause.
+
+## Integrity Note
+
+This round's ledger entry for 5.9.26 described a two-pass, self-contradictory
+session ("an initial 129-invocation pass ... 0/23 ... 7.4/10, then a second
+pass ... 0/35 ... 3.8/10"). This auditor states plainly that the first pass
+and its 7.4/10 score do not correspond to anything they ran or reported. Given
+the newly confirmed shared-machine contention, the likely explanation is that
+5.9.26's report mixed observations from two concurrent, independent audit
+sessions on the same machine (the MSAS/native-Windows lineage and a
+multi-repository "testing/" corpus lineage matching the five OSS repos found
+in the trace this round) rather than one evaluator's two passes. Recorded as
+an open provenance question, not resolved either way — see
+[`DEFECT-LEDGER.md`](DEFECT-LEDGER.md) for how this changes the 5.9.26 record.
+
+## Priority Regressions
+
+None newly introduced. The audit-command family remains the standing issue:
+`spring-audit`, `verify`, `risk`, `audit-report` stayed at 0 successful
+answers in this session's isolated (non-overlapping) invocations;
+`migrate-check` and `migrate-apply` each answered once, both immediately
+after the foreign trace activity appeared to quiet down — noted as a
+correlation worth cross-referencing against `entry-trace.jsonl`, not asserted
+as causal.
+
+## Verified Improvements
+
+- **The entry-point trace (5.9.27's response to last round's `R-01`) works as
+  designed**: the auditor's own invocations — `verify .`, `migrate-apply .`,
+  `risk . --limit 20`, `audit-report . --format markdown`, `risk . -o
+  promise.json` — now appear in `entry-trace.jsonl` even when they return
+  empty or hang. This confirms `main_entry` is reached on the failing runs,
+  closing the question the previous round's diagnostic gap left open. The
+  `empty_answer_diagnostics.record()` sidecar still never fires on any
+  observed failure, which narrows the search specifically to somewhere
+  between `main_entry` and the output-promise guard — a materially smaller
+  surface than "somewhere in the process" three rounds ago.
+- `selftest`'s itemized gaps (last round's fix) confirmed: `"10 ledger row(s)
+  could not run: ASK-16, B6, E-37, ..."` replaces the prior generic slug.
+- `ALT-09` (piped refusal on `cache clear`) reconfirmed a third consecutive
+  session.
+- `BUG-15`/`BUG-21` (markup leak, `--jobs` range) reconfirmed.
+- `migrate-check`/`migrate-apply` produced complete, reasonably sized
+  payloads (37.5 KB/41s and 9.5 KB/46s) on the runs that did answer.
+
+## Open, Unchanged
+
+- `onboard .` remains the single most erratic measurement across rounds:
+  904ms to a full 200-second external kill within the same session, same
+  invocation, same tree, no changes between runs.
+- `ask --help` measured 14.4-14.7s this session, worse than the 3-4s the
+  5.9.26 ledger entry flagged as worth its own row "if it persists" — it has
+  persisted across two rounds now. May share `R-01`'s contention signature;
+  not verified in isolation this session.
+- `watch`'s ~55s index-warm-before-first-tick is unchanged and correctly
+  understood as real cost, not a defect, per the prior round's correction.
+- `retrieve security-surface --target` still rejects `--target` as an unknown
+  option, unchanged across four rounds.
+
+## Verification Boundary
+
+Session ran on a machine independently confirmed to be shared with a second,
+concurrent `ask` test harness during at least part of the observation window.
+Reliability figures in this round should be read as measured under
+uncontrolled, real contention, not as an isolated single-process baseline.
+The auditor's own recommendation: repeat `spring-audit . --compact` x3 on
+both a reference repo and MSAS in the same clean window, nothing else
+running, to separate "the repository" from "the shared machine" as the
+variable.

sourcecode-5.9.28/docs/AUDIT-2026-09-02-EXTERNAL-5.9.26.md

@@ -0,0 +1,70 @@
+# External Audit - 5.9.26
+
+## Release Status
+
+This session is internally contradictory, and both halves are published rather
+than resolved into one number. An initial 129-invocation pass replicating the
+exact 5.9.23/5.9.25 methodology found **zero** empty-`exit 0` answers (0/23 on
+the precise invocations that gave 18.4% in 5.9.25), scoring the release
+**7.4/10**. A second, larger pass in the same session — prompted by trying to
+find the forensic sidecar `ALT-01`'s fix is supposed to write on every guard
+trip — found **zero successful answers** across 35 further invocations of the
+same command family, and revised the verdict down to **3.8/10**, the lowest of
+four audited releases. The auditor's own final position is the second number;
+the first is published as a retracted intermediate reading, not a competing
+conclusion.
+
+## Priority Finding — the diagnostic guard is not being reached
+
+`empty_answer_diagnostics.record()` is documented to write a sidecar and stamp
+`diagnostics_path` in the error envelope every time either exit guard fires.
+Across 32 empty `exit 0` answers this session (stdout **and** stderr both at 0
+bytes), no sidecar file exists anywhere on the audited machine, and no error
+envelope was ever printed. This does not mean the guard is miscalibrated — it
+means the failing runs are not reaching `main_entry`'s wrapper at all. A
+one-line "reached the guard" debug log at that entry point would confirm this
+directly and is the most actionable next step across four audit rounds.
+
+## Priority Regressions
+
+1. `NEW-01`/`ALT-01`/`ALT-03` (the audit-command family): 0 of 35 invocations
+   answered this session, the worst of four rounds, and for the first time a
+   single batch of identical `spring-audit . --compact` calls produced both
+   failure shapes — a 200s hang and a near-instant empty answer — without
+   changing anything between them.
+2. `ALT-10`/onboard: a cold run hit the external 200s kill entirely (worse
+   than 5.9.25's 164.9s worst case); a second, untouched run answered in
+   83.5s — still roughly 120x the historical 681-780ms baseline.
+3. `BUG-17` regression, reconfirmed: `remediation-report` with no path, a
+   real path, and a nonexistent path all return byte-identical output. This
+   is not a false claim about a repository (the command never claims to
+   have read one) but is CLI-ergonomics regression from an explicit
+   `INVALID_USAGE` in 5.9.22/23/25.
+
+## Verified Improvements
+
+- `ALT-09` (piped refusal on `cache clear`) confirmed working exactly as
+  fixed: `echo n | ask cache clear .` now aborts with `rc=1` and leaves the
+  cache untouched.
+- `ALT-04`/`ALT-05` (content-id stability, findings reconciliation) both
+  reconfirmed with fresh measurements.
+- `BUG-01` (unbalanced-parens parse-structure signal) verified with the
+  auditor's own constructed fixture, not just the shipped test suite.
+- `BUG-15`/`BUG-21` (markup leak, `--jobs` range) both reconfirmed.
+- `ALT-11` (`watch` startup event): confirmed working, with a measurement
+  correction — the auditor's own first attempt used too short an observation
+  window (8-20s) and nearly mis-reported this as broken. The index warm on
+  the 3,342-file audited repository takes 51.7s before the first NDJSON
+  line, which is real and not a defect, but is long enough to still read as
+  hung without foreknowledge.
+
+## Verification Boundary
+
+This session ran under heavier contention than any prior round: up to five
+concurrent ASK processes on the same machine and cache directory (the
+auditor's own batches plus a second, independent agent session exercising the
+same corpus in parallel), with system free RAM as low as 3.4-4.6 GB of 32 GB.
+The audit-family failure did not correlate cleanly with this contention in
+either direction this session — it was both absent (first pass, under the
+heaviest contention observed) and total (second pass). No stable trigger
+variable has been isolated in four audit rounds.

{sourcecode-5.9.26 → sourcecode-5.9.28}/docs/DEFECT-LEDGER.md

@@ -14,6 +14,180 @@ Status values: `open` · `in-progress` · `closed <version>` · `by-design` (wit
 The facts these rows are keyed to are published: `ask schema facts-v1` prints the registry
 (authority, definition, consumers, parity test) that the release battery enforces.
 
+## Current Synchronization — Release `5.9.28`, nine rows closed on the 5.9.27 queue (2026-09-02)
+
+**`R-01`'s architectural question is answered in source, and the answer was
+"exclusive use".** `parallel.default_jobs()` returned `cpu_count() - 1` for
+each process independently, so `k` concurrent `ask` invocations started
+`k × (N-1)` parsing workers on `N` cores — and no field in any payload said the
+run had been sharing the machine. That is what four rounds of "same command,
+sometimes fast, sometimes hung, no per-process variable distinguishing the two"
+looks like from outside. The cache was *not* the same kind of defect: writes
+are unique-temp + `os.replace` with retry and every read is guarded, so a
+concurrent writer degrades a peer to a cache miss; the one operation that hurt
+a peer was eviction, which now defers while a peer is live.
+
+Every row marked **fixed** below is closed in release `5.9.28`; the two
+open rows say what closure still needs. This batch does not claim to close
+the erratic-failure row — one hang was
+observed with nothing else running, and that is unexplained. It removes the
+mechanism the 5.9.27 round evidenced, and gives the next round the variable it
+did not have: `_meta.concurrency` on every answer.
+
+**Measured here, for the two latency rows:** `ask --help` is 0.41–0.44 s on
+this machine over three consecutive runs (the audit measured 14.4–14.7 s under
+confirmed contention). That is not a refutation of the field figure — it is a
+different machine — but it does put the row behind `R-01` rather than beside
+it, and the next round can separate them with the disclosure block above.
+
+| ID | Severity | Status | Evidence and required closure |
+|---|---:|---|---|
+| `R-01` (contention) | Critical maximum | **mechanism removed, row open pending field re-measure** | `concurrency.py` keeps a best-effort census of live invocations (one lease per process, swept by pid liveness on POSIX and lease age everywhere — never `os.kill(pid, 0)` on Windows, where CPython maps a non-console signal onto `TerminateProcess` and the POSIX idiom would kill the peer it was counting). `parallel.default_jobs()` divides the worker budget by that census; `cache._gc` defers eviction while a peer is live; `_meta.concurrency` publishes peers at start, whether the budget was shared, and that a shared run is not an isolated-machine measurement. `ASK_NO_CONCURRENCY_CENSUS=1` restores the previous behaviour. Closure needs a field round measuring the same commands with the block attached. |
+| `BUG-22` / `REG-02` (enforcement half) | High | **fixed** | The ceiling was checked at phase boundaries only, so a phase could allocate without bound and be refused once it finished — the 2 029.92 MB peak under a 1 536 MB ceiling that was genuinely in force. `resource_budget` now arms a ceiling, samples it inside the parse loop (throttled to one footprint sample per 0.5 s; a per-file call costs one clock read) and raises a typed `CeilingExceeded` that the CLI renders as the same `MEMORY_TOO_LARGE` refusal the boundary check emits. Deliberately not a sampler thread: a thread can see the crossing but cannot unwind the main thread anywhere safe. `_meta.memory.enforcement` publishes when the ceiling is checked. |
+| `BUG-10` | High | **fixed** | The zero-endpoint answer had four named detections and everything else fell through to "no recognized routing construct was found", which reads as *no HTTP surface*. `unmodeled_routing_evidence` now publishes files declaring an annotation whose argument is a path-like string literal that produced no endpoint — a rule that names no framework, per this repository's vendor-agnostic convention. Measured: `struts` reports 4 files under `@Action`/`@Namespace` where the answer used to say nothing was found; `spring-petclinic` reports none. |
+| `NEW-02` / `BUG-05` | High | **fixed** | Overloaded handlers all inherited the final overload's line because the symbol index is keyed `Class#method` with no parameter types. The extractor has no signature to disambiguate with, so the row's other branch applies: `overload_count`, `anchor_ambiguity` and `anchor_candidate_lines` are published per entry, with `anchor_ambiguity_note` once beside the list, and an unambiguous anchor carries none of it. |
+| `BUG-13` | High | **fixed** | `selftest .` over nested repositories warned and then ran the ledger against the workspace — the shape behind `selftest` falling from 9/12 to 1/12 rows inside one 120 s deadline. The implicit `.` now refuses with `INVALID_USAGE` before any row runs, naming the count, with `--allow-nested` for a caller who means the workspace. |
+| `BUG-16` | High | **fixed** | The context cache's caps (30-day TTL, 256 entries) were real and lived inside `_gc`, so ~1.7 GB of growth had no readable contract. `cache.eviction_contract()` and `context_cache.eviction_contract()` are now the one authority each `_gc` reads, and `cache status` publishes them per store in JSON and text. The parse store already published its budget; its block projects those same figures rather than measuring them again. |
+| `ALT-08` (arithmetic half) | Low | **fixed** | `_truncation_summary.final_size_bytes` was measured before the summary and `_budget_note` were attached, so the one part of the payload the accounting omitted was the accounting. It is now measured over the assembled object and republished to a fixed point, with `final_size_basis` written before the fixed point is sought and `content_size_bytes` keeping the trimmed-content figure under a name that says which it is. |
+| `ALT-25` (`impact-chain` audit clock) | Low | **fixed** | `metadata.audit_time_ms` was always ~0.0 on the default path and the 5.9.25 round read it as a security phase skipped by `ALT-03`. It is not: `include_findings` is opt-in, so the clock measured the elapsed time of *not* running an audit. It is `null` when `findings_status` is `not_computed`, and `query_time_basis` states the rule. |
+| `retrieve security-surface --target` | Low | **fixed** | Four rounds tried it and got "No such option: --target". The intent is repository-wide by construction, and the refusal now says so and names `security-chain --target`, derived from `intent_router.ANCHOR_KINDS` rather than a second list. |
+| `ask --help` latency | Low | **open, not reproduced here** | 0.41–0.44 s over three runs on the engineering host against 14.4–14.7 s in the field under confirmed contention. Re-measure with `_meta.concurrency` attached before treating it as its own row. |
+| `ALT-07` (`remediate` hang), `ALT-10` (`onboard`) | Medium | **open, unchanged** | Both share the erratic signature `R-01` now instruments. No separate mechanism found in source this round; neither reproduces on the engineering host. |
+| `BUG-02`, `BUG-12` | Critical maximum | **open, unchanged** | Both need the field's own large repository to reproduce (`rc=127` with no output; multi-gigabyte RSS while building a small answer). `BUG-22`'s sampler bounds the second one's damage without closing it. |
+
+## Current Synchronization — Alternative External Audit `5.9.27`, shared-machine contention confirmed (2026-09-02)
+
+**First score uptick in four rounds (3.8 → 4.6/10), with a large
+qualification found mid-session: the audit machine was shared with a second,
+independent `ask` test harness.** The native-Windows auditor found
+`entry-trace.jsonl` (this ledger's own diagnostic, added last round) growing
+with invocations they never launched, against five OSS reference
+repositories under the exact same `timeout N ask ...` harness pattern they
+use, and confirmed a live foreign `ask.exe` process via `Get-CimInstance
+Win32_Process` under their own Windows user. Two of their own `spring-audit`
+hangs overlapped a 525-second window of 34 foreign invocations. Full
+evidence:
+[`AUDIT-2026-09-02-ALTERNATIVE-5.9.27.md`](AUDIT-2026-09-02-ALTERNATIVE-5.9.27.md).
+
+**`R-01` (new, highest priority):** if ASK's shared worker pool and cache do
+not isolate concurrent `ask` processes on one machine, contention could
+produce exactly the pattern reported since 5.9.23 — the same command
+sometimes hanging, sometimes returning empty near-instantly, no per-process
+variable distinguishing the two. This is a real, evidenced contributing
+factor, not a proven sole cause (one hang occurred after 20 seconds of no
+foreign activity at all). The open question for engineering: is ASK's worker
+pool designed to tolerate concurrent `ask` invocations on one machine, or
+does it assume exclusive use? If the latter, that is an architectural
+constraint, not a series of unrelated command bugs, and changes where the
+fix belongs.
+
+**Entry-point trace progress, confirmed:** the auditor's own invocations —
+including ones that returned empty or hung — now appear in `entry-trace.jsonl`
+(the fix from last round's `R-01`). This confirms `main_entry` is reached on
+the failing runs. `empty_answer_diagnostics.record()` still never fired on
+any observed failure this session, which narrows the search specifically to
+somewhere between `main_entry` and the output-promise guard — a materially
+smaller surface than "somewhere in the process," three rounds ago.
+
+| ID | Severity | Status | Evidence and required closure |
+|---|---:|---|---|
+| `R-01` (contention) | Critical maximum | **open, new evidenced hypothesis** | Confirmed shared-machine contention during this audit session (foreign `ask` process, matching harness pattern, overlapping timing with 2 of the auditor's own hangs). Needs an internal answer, not more external symptom-chasing: does the worker pool serialize or isolate concurrent invocations, or assume exclusive use? If it assumes exclusive use, `ALT-01`/`ALT-03`/`NEW-01` may be one architectural defect, not several. |
+| `R-01` (entry trace) | — | **confirmed working, narrows the search** | The auditor's own failing invocations now appear in `entry-trace.jsonl`. `main_entry` is reached; the gap is between there and `_fail_on_missing_required_answer`/`_fail_on_unkept_output_promise`, which still never fire. |
+| `ALT-09` | Critical | **fixed, reconfirmed a third session** | Piped `n` to `cache clear` aborts correctly. |
+| `BUG-15` / `BUG-21` | Low | **fixed, reconfirmed** | No markup leak; `--jobs` range validated. |
+| `R-05` from last round (`selftest` itemization) | High | **fixed, reconfirmed** | `"10 ledger row(s) could not run: ASK-16, B6, E-37, ..."` replaces the prior generic slug. |
+| `onboard` | Medium | **open, still the most erratic single measurement** | 904ms to a full 200s external kill, same invocation, same tree, within one session. Cross-reference against `entry-trace.jsonl` timing before assuming a cold/warm explanation. |
+| `ask --help` latency | Low | **open, persisted a second round** | 14.4-14.7s this session (was 3-4s last round, flagged then as "worth its own row if it persists"). It has persisted. Not verified in isolation from `R-01`'s contention this session. |
+
+The remaining rows (`BUG-01`, `BUG-03`, `BUG-06`, `BUG-08` through `BUG-23`,
+`REG-02`, `REG-03`, `NEW-02`) were not relaunched this round for time budget;
+no regression signal against them. `watch`'s ~55s warm-before-first-tick and
+`retrieve security-surface --target` remain unchanged, correctly understood
+as real cost and a known gap respectively, not new defects.
+
+**Corroborating data point, unverified in detail:** a separate exchange the
+same session referenced a distinct "External" lineage audit of 5.9.27 scoring
+**8.1/10** on the five OSS reference repositories found in the trace above —
+consistent with the shared-machine hypothesis (two lineages, two repo
+populations, one machine) but not independently confirmed here; the
+transcript fragment available was too corrupted to verify its table in
+detail and is not published as a standalone audit document.
+
+## Current Synchronization — External Audit `5.9.26`, self-contradictory session (2026-09-02)
+
+> **Provenance correction, added during the 5.9.27 round.** The
+> native-Windows auditor for 5.9.27 states plainly that the "initial
+> 129-invocation pass ... 0/23 ... 7.4/10" described below does not
+> correspond to anything they ran. The 5.9.27 round independently confirmed
+> the audit machine was shared with a second, concurrent `ask` test harness
+> exercising five OSS reference repositories (`thingsboard`, `mall`,
+> `struts`, `spring-petclinic`, `jhipster-sample-app`) — a repo set and
+> pattern that matches the "External" multi-repository lineage this ledger
+> has tracked separately since 5.9.22 (`AUDIT-2026-09-02-EXTERNAL-5.9.26.md`
+> below, and the 6.3→3.8 scores it reflects). The likely explanation is that
+> the two-pass narrative below mixed observations from two independent,
+> concurrent sessions on one shared machine rather than being one
+> evaluator's self-revision. Left as written below rather than rewritten,
+> with this correction attached, per this ledger's own discipline of
+> recording when it got something wrong rather than quietly fixing the
+> record. See
+> [`AUDIT-2026-09-02-ALTERNATIVE-5.9.27.md`](AUDIT-2026-09-02-ALTERNATIVE-5.9.27.md)
+> for the evidence (`entry-trace.jsonl` cross-contamination, a live foreign
+> process confirmed via `Get-CimInstance Win32_Process`).
+
+**The 5.9.26 fix batch did not close the release gate, and new evidence
+narrows the failure to before the guard rather than inside it.** This audit
+round is internally contradictory and both halves are published rather than
+resolved: an initial 129-invocation pass replicating the exact 5.9.25
+methodology found zero empty answers (0/23) and scored 7.4/10; a second,
+larger pass in the same session found zero *successful* answers across 35
+further invocations of the same command family and revised the verdict to
+**3.8/10**, the lowest of four rounds. The auditor's own final position is the
+second number. Full evidence:
+[`AUDIT-2026-09-02-EXTERNAL-5.9.26.md`](AUDIT-2026-09-02-EXTERNAL-5.9.26.md).
+
+**New finding, most actionable in four rounds (`R-01`):** across 32 empty
+`exit 0` answers this session, stdout **and** stderr were both empty and no
+`empty_answer_diagnostics` sidecar file exists anywhere on the audited
+machine — the guard that is supposed to write one on every trip did not fire.
+This does not mean the guard added in 5.9.26 is miscalibrated; it means the
+failing runs are not reaching `main_entry`'s wrapper at all, which rules out
+"a caught exception inside command logic" as the mechanism and points instead
+at something that terminates the process before Python's own `try`/`except`
+around `app(prog_name="ask")` ever regains control — an external kill, a
+native crash, or an `os._exit()`-shaped exit somewhere in a dependency. A
+one-line "reached the guard" debug log at the top of `main_entry` would
+confirm this directly without needing native Windows to interpret.
+
+Other updates this round: `BUG-17` reconfirmed with a more precise repro
+(no path, a real path, and a nonexistent path are all byte-identical, not
+merely "an extra argument is now accepted"); `ALT-10`/`onboard` got worse (a
+cold run hit the external 200s kill entirely, worse than 5.9.25's 164.9s
+worst case); `ALT-11`/`watch` reconfirmed working, with a correction — the
+3,342-file audited repository's index warm takes 51.7s before the first
+NDJSON line, real and not a defect, but long enough to still read as hung
+without foreknowledge; and `ask --help` costs 3-4s even warm, which `REG-01`
+never claimed to fix (`REG-01` was specifically the 82-120s hang in a nested
+workspace, now resolved) but is worth its own row if it persists.
+
+| ID | Severity | Status | Evidence and required closure |
+|---|---:|---|---|
+| `NEW-01`/`ALT-01`/`ALT-03` | Critical maximum | **open, contradictory session, worst round measured** | 0 of 35 invocations answered in the second pass of this session (vs. 0 of 23 *empty* in the first pass of the same session) — do not average the two into a rate; neither is regime evidence. First round where a single batch of identical `spring-audit . --compact` calls produced both failure shapes (a 200s hang, then a near-instant empty answer) with nothing changed between them. `R-01` above is the actionable lead. |
+| `R-01` | Critical maximum | **instrumented, not yet closed** | The `empty_answer_diagnostics` sidecar added for `ALT-01`/`ALT-03` did not fire in 32 observed empty answers this session — no file, no error envelope. `record_entry_reached` now appends one line to `entry-trace.jsonl` as the very first statement of `main_entry`, argv-gated to `REQUIRED_ANSWER_COMMANDS` so `--help` and other latency-sensitive commands are not charged for it. The next native occurrence answers directly whether the failing run reached this product's own entry point at all, rather than requiring inference from the absence of a failure record. This does not close the row — it is the instrumentation the row asked for, not a fix for whatever is upstream if the trace turns out empty too. |
+| `ALT-10` | Medium | **open, worse** | A cold `onboard .` hit the external 200s kill entirely this session (5.9.25's worst case answered at 164.9s); a second, untouched run answered in 83.5s — still ~120x the 681-780ms historical baseline. Shares `R-01`'s erratic shape, not a simple cold/warm split. |
+| `BUG-17` | Low | **fixed** | `remediation-report` still accepts any `path` value (5.9.24's deliberate CLI-consistency choice, kept — a caller that always passes a repository path needs no special case for the one command with none to say about it), but the payload now carries `path_argument: {given, used: false, note}` whenever one is given, in both JSON and Markdown, whether or not the path exists. `rows.pop("path_argument")` still equals the no-path payload exactly — nothing else changed. |
+| `ALT-09` | Critical | **fixed, reconfirmed** | A piped `n` answer to `ask cache clear .` aborts with `rc=1`, `"Aborted."` on stderr, cache untouched. |
+| `ALT-04` | High | **fixed, reconfirmed** | `impact-chain` gave the same `content_id` across 3 repeated runs again this session. |
+| `BUG-01` | Critical maximum | **fixed, reconfirmed with an independent fixture** | The auditor built their own unbalanced-paren file (not the shipped test fixture) and got the expected `reason: "unbalanced_parens"` gap. The documented residual class (a syntax error that disturbs neither braces nor parens) is unchanged and expected. |
+| `BUG-15` | Low | **fixed, reconfirmed** | 0 Rich-markup occurrences across 3 repeated non-TTY `--help` runs. |
+| `BUG-21` | Low | **fixed, reconfirmed** | `--jobs 0` and `--jobs 999` both rejected with the stated `1<=x<=128` range. |
+| `ALT-11` | Low | **fixed, reconfirmed with a measurement correction** | `watch` emits its `status: "watching"` line at 51.7s on the 3,342-file audited repository — real index-warm cost, not a defect, but long enough that a short observation window (the auditor's own first attempt, 8-20s) reads it as still broken. No further action required by this row; `ALT-10`/onboard shares the same warm-up path and is where the latency itself belongs. |
+
+The remaining rows below this section (`BUG-03`, `BUG-09` through `BUG-23`,
+`REG-02`, `REG-03`, `REG-04`, `NEW-02`) were reconfirmed unchanged this round
+or not relaunched for time budget; none regressed. Full detail in the audit
+document.
+
 ## Current Synchronization — Alternative External Audit `5.9.25`, and External Audit `5.9.25` (2026-09-02)
 
 **Release `5.9.26` closes eight rows from this round with verified evidence**
@@ -75,7 +249,7 @@ and [`AUDIT-2026-09-02-EXTERNAL-5.9.25.md`](AUDIT-2026-09-02-EXTERNAL-5.9.25.md)
 | `BUG-01` | Critical maximum | **fixed, mechanism narrowed, not eliminated** | Reproduced directly: a missing `;` or a missing `)` on a method signature both extract a clean class+method symbol pair with balanced braces, so the E-10 brace-only check (`unbalanced_braces`) never fired and the file passed as clean. `repository_ir.py` now also masks and checks paren balance (`unbalanced_parens`), publishing the same `parse_structure` gap for that shape. This is a heuristic extractor without a real Java grammar, so a syntax error that disturbs neither braces nor parens (for example a missing operand with balanced punctuation on both sides) remains undetectable by construction — the row stays open at lower severity for that residual class, not closed. |
 | `BUG-02` | Critical maximum | **open, P0** | Large `risk` ended `rc=127` with no output or structured failure. Add fail-fast resource/process handling and durable partial checkpoints. |
 | `BUG-12` | Critical maximum | **open, P0** | Deep `--agent` output construction reaches multi-gigabyte RSS before a small answer. Bound projection while building. |
-| `BUG-03` | High | **fixed** | `non_coverage.stack_fit`'s marginal-detection disclosure (`fit: "partial"`, below 10% Spring-bean density) has existed since AUD-596-D13 but was unreachable from `risk` and `posture`: neither call site passed `spring_footprint`, so `java_files` stayed 0 and the branch that reads it could never fire regardless of the real ratio. Both now compute it the same way `spring-audit`'s own call already did (`sum(bean.spring for bean in graph.beans.values())` over `len(cir.files)`); verified end to end on a 1-bean/16-file fixture. |
+| `BUG-03` | High | **fixed** | `non_coverage.stack_fit`'s marginal-detection disclosure (`fit: "partial"`, below 10% Spring-bean density) has existed since AUD-596-D13 but was unreachable from `risk` and `posture`: neither call site passed `spring_footprint`, so `java_files` stayed 0 and the branch that reads it could never fire regardless of the real ratio. Both now compute it the same way `spring-audit`'s own call already did (`sum(bean.spring for bean in graph.beans.values())` over `len(cir.files)`); verified end to end on a 1-bean/16-file fixture. The 5.9.26 re-audit's own index table still lists this row `abierto` for both 5.9.25 and 5.9.26 without naming which command was tested or a repro that contradicts the fixture above; the fix stands on the passing regression tests until a command-specific repro says otherwise. |
 | `BUG-04` | High | **open, P1** | `selftest` publishes `complete=true` with five error rows. Derive bounds from actual results. |
 | `BUG-05` | High | **open, P1** | Overloaded endpoint handlers can receive the wrong declaration line. Resolve by mapping annotation or publish ambiguity. |
 | `BUG-07` | Closed 5.9.23, verification gap | Compact JVM inventory is bounded, but the audit notes no selftest row protects the correction. Add release-battery coverage before treating it as durable closure. |

{sourcecode-5.9.26 → sourcecode-5.9.28}/docs/DEVELOPMENT-ROADMAP.md

@@ -1,5 +1,77 @@
 # ASK — Development Roadmap
 
+### Release 5.9.28 — remediation batch on the 5.9.27 queue, the pool question answered in source
+
+The P0 below it asked whether the shared worker pool tolerates concurrent
+`ask` processes on one machine or assumes exclusive use. Read from source, it
+assumed exclusive use: `parallel.default_jobs()` returned `cpu_count() - 1`
+**per process**, so `k` concurrent invocations started `k × (N-1)` parsing
+workers on `N` cores, with no field in any payload saying the run had shared
+the machine. The cache was not the same kind of defect — writes are
+unique-temp + `os.replace` with retry and every read is guarded — except for
+eviction, which deleted the working set a live peer was reading.
+
+Nine rows closed in this batch, one commit each: `R-01` (census, divided
+worker budget, `_meta.concurrency`, deferred eviction), `BUG-22`/`REG-02`'s
+enforcement half (RSS sampled inside the phases, typed refusal), `BUG-10`
+(routing evidence this model does not read), `NEW-02`/`BUG-05` (overload
+anchor ambiguity), `BUG-13` (`selftest` refuses an unscoped workspace run),
+`BUG-16` (every cache store publishes its eviction contract), `ALT-08`'s
+arithmetic half, `ALT-25` (`audit_time_ms` null when the audit never ran) and
+the four-round `retrieve security-surface --target` refusal.
+
+| Priority | Required work and closure boundary |
+|---|---|
+| P0 | Re-measure the audit-command family in the field with `_meta.concurrency` attached. The census divides the pool and publishes whether the machine was shared; a round that still shows the erratic pattern with `peer_invocations_at_start: 0` separates contention from whatever else remains, which four rounds could not do. |
+| P0 | `ALT-01`/`ALT-03` stay open: one hang was observed with nothing else running, and this batch removed a mechanism, not the symptom. Keep narrowing between `main_entry` and the output-promise guard. |
+| P1 | `BUG-02` (`rc=127`, no output) and `BUG-12` (multi-gigabyte RSS for a small answer) need the field's own large repository. `BUG-22`'s in-phase sampler bounds the damage of the second without closing it. |
+| P2 | `ask --help` measured 0.41–0.44 s on the engineering host against 14.4–14.7 s in the field under confirmed contention. Re-measure with the disclosure block before profiling it as a standalone defect. |
+
+### Alternative Audit Intake — release 5.9.27, shared-machine contention confirmed
+
+First score uptick in four rounds (3.8 → 4.6/10), found alongside evidence
+that the audit machine was shared with a second, independent `ask` test
+harness: `entry-trace.jsonl` (added last release) grew with invocations the
+auditor never launched, against five OSS repositories, under the auditor's
+own exact harness pattern, and `Get-CimInstance Win32_Process` confirmed a
+live foreign `ask.exe` process under the same Windows user. This reframes,
+without resolving, the four-round pattern of the same command sometimes
+hanging and sometimes returning empty near-instantly with no per-process
+variable to distinguish the two.
+
+| Priority | Required work and closure boundary |
+|---|---|
+| P0 | Answer directly, with internal data (lock/semaphore metrics, not external inference): is ASK's shared worker pool and cache designed to tolerate concurrent `ask` processes on one machine, or does it assume exclusive use? If the latter, `ALT-01`/`ALT-03`/`NEW-01` may be one architectural defect — the shared pool not isolating or serializing concurrent access — rather than several unrelated command bugs, and the fix belongs at the pool/cache layer, not in each affected command. |
+| P0 | Continue narrowing between `main_entry` (confirmed reached, per `entry-trace.jsonl` now showing failing invocations) and `_fail_on_missing_required_answer`/`_fail_on_unkept_output_promise` (still never fire). The search surface has gone from "somewhere in the process" to "between these two specific points" in one release; keep closing it rather than re-verifying the entry-point question again. |
+| P1 | `onboard .` remains the most erratic single measurement across all rounds — 904ms to a full 200s external kill, same invocation, same tree, within one session. Cross-reference its timestamps against `entry-trace.jsonl` foreign-process activity before assuming a simple cold/warm split. |
+| P2 | `ask --help` costs 14.4-14.7s this round, worse than the 3-4s flagged last round as "worth its own row if it persists" — it has persisted across two rounds. Re-verify in a session confirmed free of the contention `R-01` found, before profiling it as a standalone defect. |
+
+Full evidence, including the entry-trace cross-contamination and process
+confirmation, is in
+[`AUDIT-2026-09-02-ALTERNATIVE-5.9.27.md`](AUDIT-2026-09-02-ALTERNATIVE-5.9.27.md).
+
+### External Audit Intake — release 5.9.26, the guard is not being reached
+
+A self-contradictory session (0/23 empty on one pass, 0/35 successful on a
+second, larger pass in the same session) produced the sharpest lead of four
+rounds: the `empty_answer_diagnostics` sidecar shipped in 5.9.26 to
+instrument `ALT-01`/`ALT-03` did not fire once across 32 observed empty
+answers — no sidecar file, no error envelope, stdout and stderr both empty.
+That rules out "an exception inside command logic reaches the guard and the
+guard mishandles it" and points at the failing runs never reaching
+`main_entry`'s wrapper at all.
+
+| Priority | Required work and closure boundary | 5.9.27 |
+|---|---|---|
+| P0 | Add a debug-level log line at the very top of `main_entry`, before `app(prog_name="ask")` is called, and confirm it fires on every invocation including the empty-answer ones. If it does not, the failure is upstream of Python's own entry point (an external kill, a native crash, an `os._exit()`-shaped exit in a dependency) and the whole `ALT-01`/`ALT-03` investigation must move there. This is answerable in one native debugging session and has not been tried in four audit rounds. | **Done and confirmed on native Windows.** `record_entry_reached` traces every audit-family invocation; the 5.9.27 audit's own failing runs appear in it. `main_entry` is confirmed reached — the search moves to the section above. |
+| P1 | `remediation-report` (`BUG-17`) now returns byte-identical output for no path, a real path, and a nonexistent path. Either declare and filter on `path`, or reject any positional explicitly with the `INVALID_USAGE` this command gave through 5.9.25 — "accept and silently ignore" is worse than either alternative. | **Done.** `path_argument: {given, used: false}` now discloses it in both formats; the path is still accepted, deliberately. |
+| P1 | `onboard .` hit the external 200s kill entirely in one run this session (worse than 5.9.25's 164.9s worst case) and answered in 83.5s in another, untouched run seconds later — the same erratic shape as `ALT-01`/`ALT-03`, not a simple cold/warm split. Bisect with the same instrumentation once the P0 above lands. | Open — still the most erratic single measurement across all rounds (904ms to a full 200s kill in 5.9.27). See the contention hypothesis above. |
+| P2 | `ask --help` costs 3-4s warm on the audited repository (14.4s cold), which `REG-01` did not claim to fix — that row closed the 82-120s nested-workspace hang specifically. Profile whether `--help`'s repository-profile hint line is re-scanning file counts that `cache status` already has cached. | Open, worse (14.4-14.7s in 5.9.27) — but measured on a machine confirmed to have contention this round; re-verify in isolation before profiling further. |
+
+The full measurement matrix, including the retracted 7.4/10 intermediate
+reading, is in
+[`AUDIT-2026-09-02-EXTERNAL-5.9.26.md`](AUDIT-2026-09-02-EXTERNAL-5.9.26.md).
+
 ### Alternative Audit Intake — release 5.9.25, closed in 5.9.26 where marked
 
 The 5.9.23 recovery sequence closed three rows with verified evidence