sourcecode 5.9.29__tar.gz → 5.9.30__tar.gz

{sourcecode-5.9.29 → sourcecode-5.9.30}/CHANGELOG.md

@@ -1,5 +1,72 @@
 # Changelog
 
+## [5.9.30] — 2026-09-02
+
+*A full pass over the open queue from the two 5.9.29 field audits. Nine rows
+closed or materially narrowed, one commit each, every change carrying its own
+test.*
+
+### Fixed
+
+- **A run nobody is watching now leaves the same forensic trail a watched
+  one does.** The in-flight marker's stage field went blank in exactly the
+  environment it exists to observe -- off a TTY, in CI, under `NO_COLOR`,
+  piped through `timeout` -- because the code path that records a stage was
+  only ever built when the visible progress line was displayed. It no longer
+  is: the forensic write and the visible display are now independent, and the
+  auditor's own captured hang is the regression test.
+- **`ask endpoints` names a file it could not fully parse, at any answer
+  size.** A file whose extracted symbols were not trustworthy -- a type
+  declaration that produced none, or a syntax error the extractor's
+  brace/paren check catches -- was already disclosed by `spring-audit`/`risk`
+  and silently dropped by `endpoints`, because the two commands parse the
+  same sources through two independent code paths and only one of them ran
+  the check. One shared authority now backs both.
+- **`ask plan` refuses an unscoped run over a workspace before doing any
+  work**, the same guard `selftest` shipped last release, applied to the
+  same class of defect: a lone positional argument silently left the
+  repository path at its default `.`, and an implicit `.` covering nested Git
+  repositories used to drive a full, unvalidated analysis.
+- **Every command that names "the repository" accepts every spelling of the
+  flag**, including the ones that declare it as an option rather than a
+  positional argument -- `compare A B --repo <path>` now works, where it used
+  to demand `--path` specifically.
+- **The Spring-density statement names the actual number.** A repository
+  where Spring is present but marginal already got a correctly bounded
+  answer; the sentence explaining why now states the measured percentage
+  instead of leaving the reader to divide two raw counts themselves.
+- **`--detach`'s envelope reports an absolute output path.** A relative
+  `--output` used to come back exactly as typed, unusable from outside the
+  invocation's own working directory.
+- **Vert.x's fluent router chain is recognized as unmodeled routing
+  evidence**, closing the one framework of eleven surveyed that fell through
+  to a generic disclaimer with no file named -- `router.get("/x").handler(...)`
+  carries no annotation for the existing detection rule to match, so a second,
+  equally vendor-neutral rule was added for the call-chain shape specifically.
+- The root `ask` command's asynchronous cache write no longer re-joins its own
+  daemon thread at process exit, which could delay returning control to the
+  caller for up to 30 seconds after the answer had already been delivered.
+
+### Added
+
+- `tests/test_new01_silent_empty_success_regime.py`: an automated, real-CLI
+  battery over every command that must never report success with nothing to
+  show, closing the standing request behind four consecutive rounds of
+  103-for-103 external verification.
+
+### Investigated, Left Unchanged
+
+- The specific mechanism behind a `verify` invocation that produced a
+  complete answer and was still killed by an external timeout remains
+  unconfirmed; one independently-discovered instance of the same failure
+  shape elsewhere in the codebase is fixed above, but `verify` does not share
+  that code path.
+- `pack assessment`'s unbounded default output was reproduced and understood,
+  not changed: `--compact` already bounds it correctly (a prior round's own
+  fix), and the unbounded default is a deliberate, tested, opt-in answer
+  rather than an oversight. Flipping it would be a product decision affecting
+  every existing caller, not a bug fix.
+
 ## [5.9.29] — 2026-09-02
 
 *The 5.9.28 field round's two P0s and its P1, plus the suite's first green run

{sourcecode-5.9.29 → sourcecode-5.9.30}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sourcecode
-Version: 5.9.29
+Version: 5.9.30
 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.29-blue)
+![Version](https://img.shields.io/badge/version-5.9.30-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.29 — and, on a build that has aged,
+ask version                    # ask 5.9.30 — and, on a build that has aged,
                                # how many releases have probably shipped since
 ```
 

{sourcecode-5.9.29 → sourcecode-5.9.30}/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.29-blue)
+![Version](https://img.shields.io/badge/version-5.9.30-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.29 — and, on a build that has aged,
+ask version                    # ask 5.9.30 — and, on a build that has aged,
                                # how many releases have probably shipped since
 ```
 

sourcecode-5.9.30/docs/AUDIT-2026-09-02-ALTERNATIVE-5.9.29.md

@@ -0,0 +1,143 @@
+# Alternative External Audit - 5.9.29
+
+*The audited repository is referred to neutrally (3,342 Java files, `repo_id
+7fced5c877cacfc5`, dirty working tree) — the same subject as every prior round
+in this lineage.*
+
+## Scope And Verdict
+
+Native-Windows re-audit, seventh round. Score **7.8/10** (5.9.22 6.6, 5.9.23
+4.9, 5.9.25 4.3, 5.9.26 3.8, 5.9.27 4.6, 5.9.28 6.2, 5.9.29 7.8) — the largest
+jump of the seven, and the first with a root cause found and fixed rather than
+mitigated. Build `6df1bd2436f8b562ee173fbaf7ba499ee783f0f8`, Windows 11 Pro
+10.0.26200, Python 3.10.0, pipx, `ask.EXE`.
+
+**All six audit-family commands answered in this session.** The auditor's own
+sentence: *the first time in seven rounds I can write that.*
+
+| Invocation | 5.9.23 | 5.9.25 | 5.9.26 | 5.9.27 | 5.9.28 | 5.9.29 |
+|---|---:|---:|---:|---:|---:|---|
+| `spring-audit . --compact` | 0/24 | 0/18 | 0/8 | 0/5 | 0/4 | **3/4** |
+| `verify .` | 0/24 | 0/18 | 0/5 | 0/1 | 0/1 | **2/2** (one killed at 200 s despite a complete answer — see `R-02`) |
+| `migrate-check . --compact` | 7/12 | 4/26 | 0/5 | 1/1 | 1/1 | 1/1 |
+| `migrate-apply .` | 14/24 | 0/26 | 0/5 | 1/1 | 1/1 | 1/1 |
+| `risk . --limit 20` | 0/13 | 0/7 | 0/4 | 0/1 | 0/1 | **1/1**, first in six sessions |
+| `audit-report . --format markdown` | 0/7 | 0/7 | 0/4 | 0/1 | 0/1 | **1/1**, first in six sessions |
+| `remediate .` | — | — | hung | hung | — | **1/1**, 74.8 s, first ever |
+
+`onboard` answered in 691 ms. `selftest` with an explicit path rose from 1/12
+to **6/12** passing rows, which the auditor attributes to the `SEC-010` work:
+the `ASK-16` row — does `spring-audit` publish its own timings — now passes
+clean.
+
+## Confirmed With The Auditor's Own Data
+
+- **The `SEC-010` fix is real and measured.** Three successive `spring-audit`
+  runs, identical `content_id` (`4a0429c7784da360`), 385 findings each, with
+  the family's own time falling as the cache warmed: **42.8 s → 25.4 s →
+  20.0 s**. The whole command went 73.9 s → 46.9 s → 35.9 s. This is the
+  warm-cache benefit the product had promised and no session had been able to
+  observe.
+- **`ALT-08` closed, byte-exact, with the right command this time.**
+  `ask prepare-context review-pr` — not `ask review-pr`, the confusion that
+  left the row unverified last round — gives `final_size_bytes: 93,462`,
+  matching `len(json.dumps(payload without _meta))` exactly.
+- **The in-flight marker works, and works on the case it was built for.** It
+  captured the auditor's own hung process with phase and timestamps. It had
+  also preserved a genuine *foreign* orphan from an earlier session
+  (`audit-report thingsboard`, phase `packaging audit evidence`) that predated
+  their run — the mechanism persists orphans exactly as documented.
+- `migrate-check`/`migrate-apply` reliable for a third consecutive session
+  (15.9 s and 14.7 s, faster than either previous round).
+
+## `R-01` — New, Precise Evidence: The Hang Happened Before The Rules Phase
+
+One of four `spring-audit` runs hung (200 s, 0 bytes). For the first time the
+process left a record:
+
+```json
+{"argv": ["spring-audit", ".", "--compact"],
+ "started_at": 1788411595.5325525,
+ "last_phase": "applying all rules over 3342 Java files [population=production_java_sources]",
+ "phase_entered_at": 1788411734.8912373,
+ "last_stage": null, "stage_entered_at": null}
+```
+
+`1788411734.89 − 1788411595.53 = 139.36 s` spent **before** the run entered
+the phase that holds the rules — roughly 70 % of the time it lived. The stderr
+heartbeat agrees: two warnings naming `auditing 3342 Java files` at one and
+two minutes, then `applying all rules … for 41.4s` at three. On the successful
+runs of the same session the same stretch took ~72.7 s in total, so this was
+not a slow phase, it was an outlier by a factor the bisection never saw.
+
+Two readings follow, and they belong to different owners:
+
+**The auditor's inference is refutable in source.** They suspected the new
+`seeds()` pre-index shipped for `SEC-010` had moved the cost earlier.
+It cannot have: `_http_input_query_sinks` is called from `SEC-010`'s
+`analyze`, which runs inside the `security_rules` phase — that is, *inside*
+"applying all rules", after the point their marker recorded. What lives in the
+139 s is the phase before it: the CIR build, the XML security-configuration
+scan and the start of the semantic model, all published under one heartbeat
+label.
+
+**Their evidence exposes a real defect in the marker.** `last_stage: null`
+should not have happened: the run was in a phase whose stages the heartbeat
+does name (`parsing`, `linking`, `assembling the IR`, `scanning XML security
+configuration`). It is null because stage capture rides on `Progress.work`,
+and the sink that calls it is created only when the heartbeat is *enabled* —
+which it is not off a TTY, in CI, under `NO_COLOR`, or piped through
+`timeout`, which is the field's configuration in every one of these seven
+sessions. The marker's most useful field is therefore blank in exactly the
+environment it was built for. That is ours, and it is the first thing to fix.
+
+The auditor's three instrumentation requests stand and are adopted: split the
+`auditing N Java files` phase into visible sub-stages, publish the pre-index
+as its own timing entry, and repeat the bisection measuring that phase
+separately from the rules phase rather than only the total.
+
+## `R-02` — New: A Complete Answer From A Process That Did Not Exit
+
+```
+timeout -k 5 200 ask verify .
+# rc=124 · 200,183 ms · 5,333 bytes of stdout
+```
+
+Unlike every hang in six previous sessions, this one **produced a full,
+valid answer**: `verdict: "pass"`, `contract_count: 14`,
+`content_id: ca00e3a40668e5bf`, `answer_bounds.complete: true`. The analysis
+finished; the process did not leave. This is a different failure class from
+"no answer": the work is done and the exit is late.
+
+The auditor's own hypotheses — a non-daemon thread outliving the answer (the
+parse worker pool, the heartbeat thread, or the concurrency lease) — are the
+right place to look, and the last of those is this product's own recent
+addition. Verifying that nothing this codebase starts can delay interpreter
+shutdown after the answer is written belongs in the next round.
+
+## Open, Unchanged
+
+`REG-02` (`--agent` fails by default on large repositories: 1,623 MB and
+2,572 MB observed, in the same range as three prior rounds — fourth
+consecutive report with no functional change), `BUG-02`, `BUG-12`, `BUG-09`,
+`BUG-23`. `pack gate --since` and `pack assessment` still do not complete
+inside the auditor's budget, though `pack assessment` now shows granular
+progress (`5/6 components`) where it used to fail with no sign of internal
+movement.
+
+## Verification Boundary
+
+`3/4` and `1/1` are not the 25–30 repetitions per command this ledger's own
+closure criterion requires for `ALT-01`/`ALT-03`. The auditor states plainly
+that `R-01` leaves open the possibility that the bottleneck was moved rather
+than removed. Their recommendation for the next round: repeat this battery at
+that repetition count, and split the phase timings first so the answer is
+attributable when it comes.
+
+## Commercial Position
+
+First report of seven where the auditor recommends *starting to evaluate*
+`spring-audit`/`risk`/`audit-report`/`remediate` as part of a CI gate for this
+repository, with the reservation above. Price raised to **25–30 €/dev/month**
+for the full command set, conditional on the next session sustaining an
+audit-family success rate above 80 %. Upgrade recommended without conditions.

sourcecode-5.9.30/docs/AUDIT-2026-09-02-EXTERNAL-5.9.29.md

@@ -0,0 +1,112 @@
+# External Audit - 5.9.28 and 5.9.29
+
+*The multi-repository lineage: 57 commands, no additions or removals, 127
+recorded invocations plus a full flag/alias sweep, 21 repositories. Two rounds
+arrived together and are recorded together.*
+
+## Verdicts
+
+| Round | Score | Character |
+|---|---:|---|
+| 5.9.28 | **8.4/10** (from 8.1) | One bug closed, one structural correction |
+| 5.9.29 | **8.5/10** | Consolidation — nothing closed, nothing regressed |
+
+Weighted axes for 5.9.29: precision 9.5, recall 7.5, epistemic honesty 9.5,
+determinism 9.5, robustness 9.5, performance 7.0, CLI ergonomics 7.0,
+CI/agent integration 8.5, functional breadth 9.0.
+
+## 5.9.28 — Two Closures Worth Recording
+
+**`BUG-13` closed, and the auditor names it the pattern to replicate.**
+`ask selftest` in a workspace of 31 nested repositories went from `rc=124`
+after 45 s of unvalidated work to `rc=2` in 41 ms with `INVALID_USAGE`, the
+nested count, and `--allow-nested` as the stated escape. Their words: *exactly
+the correction I asked for in the 5.9.22 report — validate before starting,
+count the nested repositories, offer a conscious way through.*
+
+**`BUG-10`/`BUG-23` received the most substantial structural correction of the
+five audited versions.** `zero_result_reason` and `unmodeled_routing_evidence`
+were verified across 11 heterogeneous repositories: 198 files of Micronaut
+annotations in one, 52 of Servlets in another (with a third prose `warnings`
+field), 6 of `@Route`/`@WebSocket` in a third; `null` where a repository has
+endpoints, confirmed explicitly. The auditor's summary: *you cannot promise
+detection of a framework you have not implemented, but you can stop pretending
+absence of detection is absence of surface.*
+
+**The residual they name:** a fluent router DSL (`router.get(...).handler(...)`)
+carries no annotation and no path literal, so it produces neither evidence nor
+a declared gap — one repository of the eleven is left with the generic
+disclaimer alone. `BUG-10` moves from *open, dangerous silence* to *partially
+closed, with a known and now explicitly flagged residual case*.
+
+## 5.9.29 — A Consolidation Round
+
+Nothing from the ledger closed, nothing regressed. The auditor calls this out
+as a different kind of good news: everything corrected in 5.9.26–5.9.28
+(`BUG-13`, `BUG-15`, `BUG-17`, `BUG-21`, `BUG-10`/`BUG-23`) holds under
+repetition, and the coverage sweep's figures are **byte-identical** to the
+previous session across the eleven repositories — evidence the corrections are
+stable rather than one-build accidents.
+
+`NEW-01` (silent empty success): fourth consecutive clean version, **103/103
+cumulative** since 5.9.26, this time with both `--agent` runs in parallel and
+another session working the same directory. The standing request is unchanged
+and is not about more measurement: *publish the regime row in the ledger — the
+explanation of what fixed it and an automated assertion — so closure does not
+depend on a recurring external audit.*
+
+## Performance, And A Retraction The Auditor Makes Themselves
+
+A general speed-up across the critical battery: `risk` on a 4,772-file
+repository 110.7 s → 45.4 s (−59 %), `spring-audit` on a mid-size one
+99.6/95.0/102.4 s → 19.7/17.9/19.1 s (−80 %), `audit-report` 99.6/95.0/102.4 s
+→ 89.9/63.0/35.8 s.
+
+`REG-03` — the warm-path measurement — moved the other way on the same pair of
+consecutive invocations: −22.4 % (5.9.27), −9.2 % (5.9.28), **+24.0 %**
+(5.9.29), while the absolute cold time fell 69.1 s → 21.9 s. Their conclusion,
+stated as a correction of their own earlier report: *the variable that
+dominates `spring-audit` time on this machine is system load at the moment of
+measurement, not ASK's cache state.* They withdraw their 5.9.27 claim of *the
+first real warm-cache gain ever observed* to **possible, not confirmed**, and
+recommend the team not treat external performance measurements on this metric
+as benchmarks without load control.
+
+## Open, With Their Priority Order
+
+| # | Row | State |
+|---|---|---|
+| 1 | `NEW-01` regime row | 103/103 is extremely strong evidence; the product's own systematic guarantee is what is missing |
+| 2 | `REG-02` | `--agent` fails by default, fourth consecutive version |
+| 3 | `BUG-14` | `ask plan <repo>` still hangs 45 s with no validation and an empty stderr — the same class as `BUG-13`, documented for four rounds, and the fix pattern now exists in the product |
+| 4 | `BUG-01` | A file with a parse error disappears with no signal (`total: 1`, only `/ok`). `zero_result_reason` only fires at `total: 0`, so the honesty pattern needs extending to per-file parse failures at any total |
+| 5 | `BUG-03` | `spring_detected: true` and 0 defects over 2,340 files at 5 % Spring density |
+| 6 | Vert.x / Ktor evidence | The one residual case of `BUG-10` with no evidence at all |
+| 7 | `BUG-11` | `pack assessment` returns `OUTPUT_TOO_LARGE` by default |
+| 8 | Remainder | `BUG-09` flag vocabulary, `BUG-20` unresolved POSIX path under `--detach`, polish |
+
+`BUG-16`: `~/.sourcecode/` measured at 2.4 GB (context cache 1.8 GB). The
+eviction contracts published in 5.9.29 are confirmed present via `cache
+status`; what the auditor still records as open is the size itself, not the
+disclosure. `diagnostics/` grew to 30 KB across three consecutive releases of
+internal instrumentation (`entry-trace.jsonl`, `live/`, `inflight/`) — noted
+explicitly as observability, not a problem.
+
+## What Held
+
+Exact endpoints (17/17 on a reference repository), the security chain 3/3, the
+`verify` gate through pass → injected regression → fail without a miss in six
+audits, `SEC-010` stable for a sixth consecutive version with no false
+positives, byte-identical determinism apart from `peak_rss_mb`, benign
+concurrency 6/6, and 91 command/variant combinations in the surface sweep with
+no empty answer and no correctness regression.
+
+## Commercial Position
+
+**$750 / developer / year**, raised from $650 in 5.9.28 and unchanged in
+5.9.29 — no new correction to justify a rise, no regression to justify a fall.
+Held below the $900 ceiling by `REG-02` and the routing-DSL gap. Worth buying,
+*with the highest confidence of the five audits*. `spring-audit`/`risk`/
+`audit-report` are considered reasonable CI-gate candidates keeping
+`len(stdout) > 0` as a cheap safety net; `--agent` on large repositories still
+needs `ASK_MAX_RSS_MB=0` or `≥3072`.

{sourcecode-5.9.29 → sourcecode-5.9.30}/docs/DEFECT-LEDGER.md

@@ -14,6 +14,76 @@ 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.30`, nine rows worked on the 5.9.29 queue (2026-09-02)
+
+**A full pass over the open queue from the two 5.9.29 audits, one commit per
+row, batteries run against every change.** Nine rows closed or materially
+narrowed; two — `R-02` and the `pack assessment` default — investigated and
+left open with the reasoning recorded, rather than guessed at.
+
+| ID | Severity | Status | Evidence and required closure |
+|---|---:|---|---|
+| `R-01-INFLIGHT` (stage capture) | High | **closed** | `Progress.work()`'s sink was built only when the visible heartbeat was *enabled* — false off a TTY, in CI, under `NO_COLOR`, and piped through `timeout`, the field's configuration in all seven sessions. `_work_sink`/`_rule_pass_progress` now build the sink whenever a `Progress`/deadline object exists at all: `Progress.work()` is cheap regardless of whether it prints (a lock, a tuple compare, `_beat()`'s own internal `enabled` check), so an unwatched run's hang now records its stage exactly as a watched one does. Two invariant tests that pinned the old contract are updated to the corrected one; two new tests assert the unwatched case directly. |
+| `R-02` (the process does not exit) | High | **one confirmed instance fixed, not proven to be the field's exact mechanism** | Auditing every background thread and process pool in this codebase found one genuine defect of this shape: the root `ask` command's async cache write started a `daemon=True` thread — specifically so an unfinished write could not hold up exit — and then registered `atexit.register(_cache_write_thread.join, 30.0)`, re-joining it anyway. Removed. `verify` itself does not go through this code path, so this is not asserted to be the auditor's exact mechanism; it is a real, independently confirmed instance of the same failure class, fixed on the same principle the codebase already states elsewhere (`parse_cache._delete_behind`): a daemon thread's unfinished work costs the next run a cache miss, not the caller a wait after their answer already arrived. |
+| `BUG-14` | High | **closed** | Same class as `BUG-13`, the pattern named by request: `plan TARGET [PATH]` read a lone positional as the change target, leaving `path` at its default `.` — over a workspace of nested repositories, that drove a full IR build with no validation. The same nested-repository guard now refuses before any build starts, naming the count, with `--allow-nested`, and the hint explicitly names the grammar confusion (`plan` reads a lone argument as the target, not the repository). |
+| `BUG-01` | Critical maximum | **widened, closed for `endpoints`** | `build_repo_ir` already detected a file whose extracted symbols are not trustworthy and published it as `parse_failures`; `extract_java_endpoints` parses the same sources through its own independent loop and never ran that check. The exact field shape (`total: 1`, one file silently missing) had no honesty pattern to catch it — `zero_result_reason` only fires when the whole answer is empty. `_parse_health_row` is now the one authority both extractors call (`build_repo_ir`'s own behaviour verified byte-identical against its existing battery); `endpoints` publishes `parse_failures`/`parse_failures_basis` whenever non-empty, at any total. |
+| `NEW-01` (regime row) | High | **closed** | 103/103 across four consecutive external rounds was never going to be closed by a fifth measurement — the ask was the product's own guarantee. `tests/test_new01_silent_empty_success_regime.py` runs the real CLI dispatch (not the guard functions mocked in isolation, which a separate existing file already covers) across the whole `REQUIRED_ANSWER_COMMANDS` population against a real fixture repository, and fails if any of them ever reports success with nothing behind it — verified non-vacuous before committing (5 of 6 commands exit 0 with 10-27 KB real payloads on the fixture; `verify` exits its own documented 2 for no contracts declared). |
+| `BUG-03` (statement half) | High | **closed** | The merge-half fix (previous round) already made every audit-family surface correctly classify a majority non-Spring stack as `fit: "partial"` — verified end to end on struts (1,488 Java files, 5 beans) across `spring-audit`, `risk`, `posture` and `audit-report` (inherits it via the other two). What the audit's "mismo stack_fit.statement sin proporción" still named: the statement said only "marginal" in prose, with the raw counts published beside it but not divided for the reader. It now states the density directly — "5 of 1488 Java files carry a Spring bean (0.34%)" — and a `spring_density_pct` field carries the same number for a machine reader, published only on the partial branch. |
+| `BUG-20` | Low | **closed** | The `--detach` envelope's `output` field carried whatever string the operator typed, with nothing saying which directory it was relative to — unusable from outside that invocation's shell. `_resolved_output_path` joins a relative path against the invocation's own root with `.absolute()`, not `.resolve()`: it states where the path points without canonicalising symlinks nobody asked to have normalised away, which is also what keeps the existing detach battery's exact-path assertions passing on macOS (`/var/...` vs `/private/var/...`). |
+| `BUG-09` | Medium | **closed** | AUD-597-D06 unified three repository-flag spellings across the catalogue, but its mechanism only ever moved an alias into an empty *positional* slot. `compare`'s repository is the declared option `--path`, not a positional, so `compare A B --repo <r>` was never recognised — four rounds hit this exact repro. `_normalise_repository_option_flag` covers the second shape: where a command declares its repository as an option named `path`/`repo`/`dir`, any other alias is rewritten to the declared one, in place, with the same duplicate-spelling guard the positional case already has. |
+| `BUG-10` (Vert.x residual) | Medium | **closed for Vert.x; Ktor stays out of scope** | The one repository of eleven left with only the generic disclaimer: Vert.x's Router is a fluent call chain (`router.get("/x").handler(...)`) with no `@` anywhere, structurally invisible to the annotation-shaped evidence rule. A second, equally vendor-neutral rule now catches it — an HTTP-verb method called with one path-like literal, chained into a handler-attachment call — guarded against firing on unrelated code (`Map.get("/key")` with no handler chain, a bare `.route().handler()` with no path). Ktor's routing DSL lives in `.kt` files, which this extractor never reads; extending file discovery to a second language is a different, larger change than this row. |
+| `pack assessment` default | — | **investigated, left unchanged, reasoning recorded** | Reproduced on spring-petclinic: the unbounded default is 68.5K estimated tokens (over the 50K ceiling), `--compact` brings it to 35KB (well under). `--compact` genuinely bounds it — this was AUD-600-B02's own fix, verified still holding. The unbounded default measuring 2.29M tokens on a larger repository (that round's own number) makes clear the full report is a deliberately unbounded, opt-in answer, not an oversight: flipping the default would need a `--compact/--no-compact` toggle pair (today only `--compact` is declared) and would change behaviour for every existing caller who relies on the current default producing the full report on a repository small enough not to hit the ceiling. Left as a product-default question rather than changed unilaterally. |
+
+Suite: run in full after the batch, same population as the last recorded
+green run — see the commit history for the exact count. One vacuous
+assertion introduced earlier in the session by this same battery (`or True`
+in a stage-capture test) was caught by the suite's own mutation-testing
+battery and fixed in the same pass, not left for an eighth round to find.
+
+## Current Synchronization — Two audits of `5.9.29`: the audit family answers, and the marker's own gap (2026-09-02)
+
+**Both lineages report the release positively and neither found a regression.**
+The multi-repository round scores **8.5/10** (8.4 for 5.9.28, from 8.1) and
+calls 5.9.29 a consolidation: nothing closed, nothing regressed, and the
+coverage sweep byte-identical to the previous session across eleven
+repositories — the 5.9.26–5.9.28 corrections hold under repetition rather than
+being one-build accidents. The native-Windows round scores **7.8/10**, its
+largest jump in seven, and reports the sentence six sessions could not
+produce: **all six audit-family commands answered.** `spring-audit` 3/4,
+`verify` 2/2, `risk` 1/1 and `audit-report` 1/1 (both firsts in six sessions),
+`migrate-check`/`migrate-apply` 1/1 each, `remediate` 1/1 at 74,8 s after two
+rounds of hanging. Full evidence:
+[`AUDIT-2026-09-02-ALTERNATIVE-5.9.29.md`](AUDIT-2026-09-02-ALTERNATIVE-5.9.29.md)
+and [`AUDIT-2026-09-02-EXTERNAL-5.9.29.md`](AUDIT-2026-09-02-EXTERNAL-5.9.29.md).
+
+**The `SEC-010` work is confirmed from the field, with their numbers:** three
+successive runs, one `content_id` (`4a0429c7784da360`), 385 findings each, and
+the family's own clock falling 42,8 → 25,4 → 20,0 s as the cache warmed. The
+command went 73,9 → 46,9 → 35,9 s. `selftest` rose from 1/12 to 6/12 passing
+rows on the same deadline.
+
+**And the in-flight marker did its job on the first try — including against
+us.** It captured a hang, and what it captured contradicts part of what this
+ledger assumed. See `R-01` below.
+
+| ID | Severity | Status | Evidence and required closure |
+|---|---:|---|---|
+| `R-01` (phase attribution) | Critical maximum | **open, sharpest evidence in seven rounds** | The marker on the one hung run: `started_at` 1788411595,53 and `phase_entered_at` 1788411734,89 — **139,36 s spent before the run reached "applying all rules"**, about 70 % of the time it lived, with the stderr heartbeat agreeing (two warnings naming `auditing 3342 Java files`, then the rules phase for 41,4 s). The successful runs of the same session covered that whole stretch in ~72,7 s. The auditor's inference that the new `seeds()` pre-index moved the cost earlier is **refutable in source**: `_http_input_query_sinks` is called from `SEC-010`'s `analyze`, inside the `security_rules` phase — after the point their marker recorded. What sits in those 139 s is the CIR build, the XML security-configuration scan and the start of the semantic model, all published under one heartbeat label. Required work, adopted from their three requests: split that phase into visible sub-stages, publish the pre-index as its own timing entry, and repeat the bisection measuring that phase separately from the rules phase rather than only the total. |
+| `R-01-INFLIGHT` (stage capture) | High | **open, defect in what 5.9.29 shipped, found by their evidence** | Their capture reads `last_stage: null` for the ~60 s the run spent in the rules phase, and null through the 139 s before it — in a phase whose stages the heartbeat does name. The cause is ours: stage capture rides on `Progress.work`, and the sink that calls it is built only when the heartbeat is **enabled**, which it is not off a TTY, in CI, under `NO_COLOR`, or piped through `timeout` — the field's configuration in all seven sessions. The marker's most useful field is therefore blank in exactly the environment it was built for. Closure: record the stage regardless of whether anything is watching. |
+| `R-02` (the process does not exit) | High | **open, new failure class** | `timeout -k 5 200 ask verify .` returned `rc=124` with **5 333 bytes of a complete, valid answer** — `verdict: pass`, `contract_count: 14`, `content_id: ca00e3a40668e5bf`, `answer_bounds.complete: true`. Six sessions of hangs produced 0 bytes; this one finished the work and did not leave. Distinct from `ALT-01`/`ALT-03` and to be tracked apart: the analysis is not the problem here, the exit is. Candidates, one of them this product's own recent addition: a non-daemon thread outliving the answer — the parse worker pool, the heartbeat thread, or the concurrency lease. Closure: prove nothing this codebase starts can delay interpreter shutdown after the answer is written. |
+| `SEC-010` cost | Medium | **closed 5.9.29, confirmed in the field** | Three runs, identical `content_id`, 42,8 → 25,4 → 20,0 s with the cache warming. The warm-path benefit the product promised and no session had observed. |
+| `ALT-08` (arithmetic half) | Low | **closed, field verification received** | `ask prepare-context review-pr` — the correct command this time — gives `final_size_bytes: 93 462`, matching `len(json.dumps(payload without _meta))` byte for byte. |
+| `ALT-01` / `ALT-03` | Critical maximum | **open, materially narrowed** | 3/4 and six families answering is the best measurement of seven rounds and is not the 25–30 repetitions per command this ledger requires. `R-01` above leaves open that the bottleneck was moved rather than removed, and this ledger does not close a row on a hypothesis it has just been given evidence against. |
+| `NEW-01` (regime row) | High | **open, and the request is not for more measurement** | 103/103 across four consecutive versions in the multi-repository lineage. What is asked for is the product's own guarantee: the explanation of what fixed it, published in this ledger, plus an automated regime assertion, so closure stops depending on a recurring external audit. |
+| `BUG-14` | High | **open, fourth round, fix pattern already exists here** | `ask plan <repo>` still hangs to an external kill at 45 s with an empty stderr, because a repository path is accepted where the signature reads `TARGET [PATH]`. Same class as `BUG-13`, which 5.9.28 closed by validating before starting, counting what it found and offering `--allow-nested`. The auditor asks for that pattern, by name, on this row. |
+| `BUG-01` | Critical maximum | **open, and the honesty pattern needs widening** | A file with a parse error still disappears with no signal (`total: 1`, only `/ok`). `zero_result_reason` fires only at `total: 0`, so the disclosure that closed `BUG-10` does not reach this shape. Required: name files excluded by a parse failure at **any** total, not only when the answer is empty. |
+| `BUG-10` (routing DSL residual) | Medium | **partially closed, residual named** | `unmodeled_routing_evidence` verified across 11 repositories (198 files of Micronaut annotations, 52 of Servlets, 6 of `@Route`/`@WebSocket`) and `null` where a repository has endpoints. A fluent router DSL carries no annotation and no path literal, so it yields neither evidence nor a declared gap — one repository of eleven is left with the generic disclaimer alone. |
+| `REG-03` | Medium | **the auditor retracts their own claim** | The warm-path delta went −22,4 % → −9,2 % → **+24,0 %** on the same pair of consecutive invocations while absolute cold time fell 69,1 → 21,9 s. Their conclusion: system load at the moment of measurement dominates this metric, not ASK's cache state, and their 5.9.27 report of *the first real warm-cache gain ever observed* is withdrawn to "possible, not confirmed". Recorded here because a retraction by the party who made the claim is evidence, and because this product must not quote that figure as a benchmark either. |
+| `REG-02` | Critical | **open, fourth consecutive round** | `--agent` fails by default on large repositories (1 623 MB and 2 572 MB observed, same range as three prior rounds, no trend either way). |
+| `BUG-16` | Medium | **disclosure closed, size open** | The eviction contracts shipped in 5.9.29 are confirmed present through `cache status`. What the auditor still records is the size: 2,4 GB total, 1,8 GB of it the context cache. The contract this product publishes for that store is entry count and age, not bytes — which is honest and is also why the store can be this large. Whether it should have a byte budget is the open half. |
+| `BUG-13`, `BUG-15`, `BUG-17`, `BUG-21`, `BUG-08`, `BUG-10`/`BUG-23` | — | **closed, stable under repetition** | Re-verified across four to five consecutive versions with no sign of relapse, and byte-identical coverage figures between the last two sessions. |
+| `BUG-09`, `BUG-11`, `BUG-20`, `BUG-02`, `BUG-12`, `BUG-03` | — | **open, unchanged** | Flag vocabulary, `pack assessment` returning `OUTPUT_TOO_LARGE` by default (now with granular progress where it used to fail silently), an unresolved POSIX path under `--detach`, and the three rows that need the field's own large repository. |
+
 ## Current Synchronization — Release `5.9.29`, hardening pass and a green suite (2026-09-02)
 
 **The suite is green — 13 748 tests, 0 failures — for the first time in

{sourcecode-5.9.29 → sourcecode-5.9.30}/docs/DEVELOPMENT-ROADMAP.md

@@ -1,5 +1,47 @@
 # ASK — Development Roadmap
 
+### Release 5.9.30 — remediation batch on the 5.9.29 queue, nine rows worked
+
+Full pass over the two 5.9.29 audits' open queue. Closed or materially
+narrowed: `R-01-INFLIGHT` stage capture, `BUG-14`, `BUG-01` (widened to
+`endpoints`), the `NEW-01` regime battery, `BUG-03`'s statement half,
+`BUG-20`, `BUG-09`, and `BUG-10`'s Vert.x residual. Investigated and left
+open with the reasoning recorded: one confirmed-but-unproven `R-02` instance
+(a defeated daemon-thread join in the root command, fixed; not shown to be
+`verify`'s own mechanism), and `pack assessment`'s unbounded default (a
+deliberate, tested design per `AUD-600-B02`, not an oversight).
+
+| Priority | Required work and closure boundary |
+|---|---|
+| P0 | **Split the `auditing N Java files` phase into visible sub-stages, and publish the `seeds()` pre-index as its own timing entry.** Unchanged from last round — the stage-capture fix means this phase's *sub-stages* (`parsing`, `linking`, `assembling the IR`, `scanning XML security configuration`) now reach the marker, but the phase itself is still one `timings.phases` entry (`cir_build`) with no further breakdown published in the JSON payload. Worth doing only if a field round's marker still points at this stretch specifically. |
+| P1 | **`R-02`, still open.** The confirmed instance (root command's cache-write thread) is fixed; `verify` itself never went through that code path, so the field's exact mechanism is unproven. If a future round reproduces a complete-answer-but-no-exit shape again, get a thread dump or `py-spy dump` at the hang, not another timing measurement — this class of bug is invisible to anything that only reads stdout/exit code. |
+| P2 | `BUG-16`'s remaining half: the context cache's disclosed contract is entry-count-and-age, not bytes, and that is honest about what bounds *one repository's* directory — but the field measured `~/.sourcecode/` at 2.4 GB total across a whole audit campaign's worth of repositories, which no per-repo cap reaches. A cross-repository byte budget is a real feature (enumerate every per-repo cache directory under the context-cache root, evict globally by LRU) and deserves its own design pass, not a quick patch alongside nine other rows. |
+| — | `REG-02` unchanged: `--agent`'s 1,536 MB default ceiling refuses on repositories the field considers "large" (1.6-2.6 GB peaks measured). `BUG-22` (5.9.28) already made the ceiling's *enforcement* correct at any repository size; whether 1,536 MB is the right *default* for this product's target repository sizes is a product-policy question, not a code defect — raising it unilaterally was not done here. |
+
+### Audit Intake — two rounds on 5.9.29: the family answers, the marker exposes us
+
+Both lineages report positively and neither found a regression. The
+multi-repository round scores 8.5/10 and calls the release a consolidation —
+its coverage sweep is byte-identical to the previous session across eleven
+repositories. The native-Windows round scores 7.8/10, its largest jump in
+seven, with all six audit-family commands answering and the `SEC-010` work
+confirmed from the field (three runs, one `content_id`, 42,8 → 25,4 → 20,0 s
+as the cache warmed).
+
+The most valuable thing either round produced is the first captured hang, and
+it points at us twice.
+
+| Priority | Required work and closure boundary |
+|---|---|
+| P0 | **Record the stage regardless of who is watching.** The captured marker reads `last_stage: null` because stage capture rides on `Progress.work`, and that sink is built only when the heartbeat is *enabled* — false off a TTY, in CI, under `NO_COLOR`, and piped through `timeout`, which is the field's configuration in all seven sessions. The marker's most useful field is blank in exactly the environment it was built for. |
+| P0 | **Split the `auditing N Java files` phase into visible sub-stages, and publish the `seeds()` pre-index as its own timing entry.** The captured hang spent 139,36 s — ~70 % of its life — before reaching the rules phase, against ~72,7 s for that whole stretch on the session's successful runs. The auditor's guess that the new pre-index moved the cost there is refutable in source (it runs inside `security_rules`), but the phase they are pointing at is genuinely one label over the CIR build, the XML scan and the semantic model, and nothing published tells those apart. Then repeat the bisection measuring that phase separately from the rules phase. |
+| P0 | **`R-02`: a complete answer from a process that did not exit.** `verify` wrote 5 333 bytes — `verdict: pass`, `content_id`, `answer_bounds.complete: true` — and was still killed at 200 s. Prove nothing this codebase starts can delay interpreter shutdown after the answer is written: the parse worker pool, the heartbeat thread, and the concurrency lease, the last of which is ours from 5.9.28. |
+| P1 | **`BUG-14`, asked for by name for the fourth round.** `ask plan <repo>` hangs to an external kill with an empty stderr. `BUG-13` closed this exact class in 5.9.28 — validate before starting, count what was found, offer the conscious way through. Apply that pattern here. |
+| P1 | **`BUG-01`: widen the honesty pattern past `total: 0`.** A file with a parse error still vanishes with no signal at `total: 1`, because `zero_result_reason` only fires on an empty answer. Name files excluded by a parse failure at any total. |
+| P1 | **`NEW-01`: publish the regime row.** 103/103 over four versions is the strongest evidence an external audit can produce, and it is still external. What is owed is this product's own guarantee — the mechanism written into the ledger plus an automated assertion. |
+| P2 | `REG-02` (fourth consecutive round), the routing-DSL residual of `BUG-10` (a fluent router carries neither annotation nor path literal, so the evidence rule cannot see it), `BUG-11`, `BUG-09`, `BUG-20`. |
+| — | **Do not quote `REG-03` as a benchmark.** The auditor withdrew their own "first real warm-cache gain" claim after the same measurement inverted (−22,4 % → −9,2 % → +24,0 %) while absolute cold time fell 69,1 → 21,9 s. System load dominates that metric on their machine; this product should not cite it either. |
+
 ### Release 5.9.29 — hardening pass, green suite
 
 The suite is green (13 748 / 0) for the first time in several releases. Two of

{sourcecode-5.9.29 → sourcecode-5.9.30}/docs/EXECUTIVE-ROADMAP.md

@@ -5,6 +5,52 @@
 > `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.30 — nine rows from the 5.9.29 audit queue worked in one
+> batch, each with its own commit and its own test.** The field's exact repro for a file that
+> silently vanishes from an endpoint count now names the file, at any answer
+> size, not only when the whole answer was empty. A four-round-old CLI
+> ergonomics complaint (`compare A B --repo <r>` refused, demanded `--path`
+> instead) is fixed the same way the product already fixed its sibling case.
+> A command asked for by name for the fourth straight round now refuses an
+> unscoped run over a workspace before doing any expensive work, instead of
+> hanging for 45 seconds with nothing on the screen. And the forensic marker
+> shipped last release — which a field auditor used to catch its first real
+> hang — had a blind spot of its own: it went silent in exactly the
+> environment it exists to observe. Fixed, with the auditor's own capture as
+> the regression test.
+>
+> Two items were investigated and deliberately left alone, with the reasoning
+> written down rather than guessed at: a process that finishes its work but
+> is slow to exit (one confirmed, related defect fixed elsewhere; the
+> specific command reported is not proven to share it), and a command whose
+> default output is large by design, per an earlier round's own testing —
+> changing that default would be a product decision, not a bug fix, and was
+> left to be made deliberately rather than as a side effect of this pass.
+
+> **TWO INDEPENDENT AUDITS OF 5.9.29 — the audit commands answer, and the
+> forensic record we shipped paid for itself immediately.** The
+> multi-repository reviewer scores the release 8.5/10 and calls it a
+> consolidation: nothing regressed, and the coverage figures across eleven
+> repositories are byte-identical to the previous session, which is the
+> evidence that the last three releases' corrections hold rather than being
+> lucky builds. The native-Windows reviewer — the one whose repository has
+> failed for seven rounds — scores it 7.8/10, their largest jump, and reports
+> for the first time that **every command in the security-audit family
+> answered**. The performance fix from last release is confirmed with their own
+> numbers, three runs producing an identical answer while the cost fell by half
+> as the cache warmed.
+>
+> The instrument added last release captured its first real hang, and what it
+> captured argues against part of our own diagnosis: most of that run's life
+> was spent before the phase we had profiled. It also exposed a defect in the
+> instrument itself — the field it was built for is blank in precisely the
+> environment it was built for, because it only fills in when a progress
+> display is switched on, and in the customer's setup it never is. Both are now
+> the top of the work queue, along with a new and narrower failure the same
+> session found: a command that produced a complete, correct answer and then
+> failed to exit. That is a better problem than the one this product started
+> the month with.
+
 > **RELEASE 5.9.29 — the regression battery is fully green again, and it
 > caught two real defects on the way.** The test suite had carried twenty-one
 > permanent failures for several releases; a permanent failure is background

{sourcecode-5.9.29 → sourcecode-5.9.30}/docs/USER_GUIDE.md

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

{sourcecode-5.9.29 → sourcecode-5.9.30}/pyproject.toml

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

{sourcecode-5.9.29 → sourcecode-5.9.30}/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.29"
+__version__ = "5.9.30"