sourcecode 5.9.27__tar.gz → 5.9.28__tar.gz

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

@@ -1,5 +1,81 @@
 # 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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sourcecode
-Version: 5.9.27
+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.27-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.27 — 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.27 → 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.27-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.27 — 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.27 → sourcecode-5.9.28}/docs/DEFECT-LEDGER.md

@@ -14,8 +14,127 @@ 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

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

@@ -1,5 +1,55 @@
 # 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
@@ -11,12 +61,12 @@ 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 |
-|---|---|
-| 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. |
-| 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. |
-| 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. |
-| 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. |
+| 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

{sourcecode-5.9.27 → sourcecode-5.9.28}/docs/EXECUTIVE-ROADMAP.md

@@ -5,6 +5,47 @@
 > `pack assessment` and `pack gate`, and make evidence and safe change the
 > product surface. This roadmap must not introduce a competing product thesis.
 
+> **RELEASE 5.9.28 — the pool question is answered, and the answer was
+> "exclusive use".** The audit asked engineering a direct question
+> instead of reporting another symptom, and reading the source settled it: the
+> parse worker pool sized itself as if every run owned the whole machine, so
+> two concurrent runs asked for twice the machine and nothing in either
+> answer said so. Runs now count each other, divide the worker budget between
+> them, and publish whether the machine was shared — the per-process variable
+> four audit rounds did not have. Eight further rows closed with it, each with
+> its own regression battery: the memory ceiling now stops a run where it is
+> crossed instead of after the phase that crossed it; a repository routed by a
+> framework this product does not model is told so instead of being reported
+> as having no HTTP surface; overloaded handlers publish that their line is one
+> of several rather than guessing one; `selftest` refuses to run against a
+> whole workspace by accident; and every cache store states what evicts it.
+> Suite: 13 710 tests, the same 22 pre-existing failures before and after —
+> zero regressions. The release gate is unchanged until the field re-measures.
+
+> **5.9.27 RE-AUDIT — shared-machine contention confirmed, first score uptick
+> in four rounds (3.8 → 4.6/10).** The native-Windows auditor found the audit
+> machine shared with a second, independent `ask` test harness — a shared
+> diagnostic log grew with invocations they never launched, against five OSS
+> repositories, and a live foreign process was confirmed under their own
+> Windows user via `Get-CimInstance Win32_Process`. This reframes, without
+> resolving, the four-round pattern of the same command sometimes hanging and
+> sometimes returning empty near-instantly with nothing to distinguish the
+> two: if ASK's shared worker pool and cache assume exclusive machine use
+> rather than tolerating concurrent invocations, that is one architectural
+> answer to what has looked like several unrelated command bugs. Separately,
+> last release's entry-point trace fix is confirmed working on native
+> Windows — the auditor's own failing runs now appear in it, proving the
+> process reaches this product's entry point before going silent, which
+> narrows the remaining search to a small, specific span of code. The release
+> gate is unchanged: do not use the audit-command family for unattended CI.
+> This round also surfaced a provenance question about the prior release's
+> own audit record — see
+> [`DEFECT-LEDGER.md`](DEFECT-LEDGER.md) for the correction — and a distinct,
+> materially higher score (8.1/10) from a separate audit lineage on clean OSS
+> reference repositories, consistent with the repository itself being a
+> variable worth isolating. See
+> [`AUDIT-2026-09-02-ALTERNATIVE-5.9.27.md`](AUDIT-2026-09-02-ALTERNATIVE-5.9.27.md).
+
 > **5.9.26 RE-AUDIT — self-contradictory session, sharpest lead in four
 > rounds.** A 129-invocation pass reproducing the exact 5.9.25 empty-answer
 > methodology found zero empty answers; a second, larger pass in the same

{sourcecode-5.9.27 → sourcecode-5.9.28}/docs/USER_GUIDE.md

@@ -279,7 +279,7 @@ pipx install sourcecode   # isolated install, no venv needed
 
 # Verify
 ask version
-# ask 5.9.27
+# ask 5.9.28
 ```
 
 Requires Python 3.9+.

{sourcecode-5.9.27 → sourcecode-5.9.28}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "sourcecode"
-version = "5.9.27"
+version = "5.9.28"
 description = "Persistent structural context and ultra-fast repeated analysis for AI coding agents"
 readme = "README.md"
 requires-python = ">=3.9"

{sourcecode-5.9.27 → sourcecode-5.9.28}/src/sourcecode/__init__.py

@@ -4,4 +4,4 @@ ASK Engine is the product. ``ask`` is the canonical CLI command; ``sourcecode``
 the legacy compatibility alias and the Python/PyPI package name. See
 docs/PRODUCT_IDENTITY.md (normative)."""
 
-__version__ = "5.9.27"
+__version__ = "5.9.28"