sourcecode 5.9.26__tar.gz → 5.9.27__tar.gz

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

@@ -1,5 +1,45 @@
 # Changelog
 
+## [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.27}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sourcecode
-Version: 5.9.26
+Version: 5.9.27
 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.27-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.27 — and, on a build that has aged,
                                # how many releases have probably shipped since
 ```
 

{sourcecode-5.9.26 → sourcecode-5.9.27}/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.27-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.27 — and, on a build that has aged,
                                # how many releases have probably shipped since
 ```
 

sourcecode-5.9.27/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.27}/docs/DEFECT-LEDGER.md

@@ -14,6 +14,61 @@ 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 — External Audit `5.9.26`, self-contradictory session (2026-09-02)
+
+**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 +130,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.27}/docs/DEVELOPMENT-ROADMAP.md

@@ -1,5 +1,27 @@
 # ASK — Development Roadmap
 
+### 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 |
+|---|---|
+| 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. |
+
+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

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

@@ -5,6 +5,22 @@
 > `pack assessment` and `pack gate`, and make evidence and safe change the
 > product surface. This roadmap must not introduce a competing product thesis.
 
+> **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
+> session found zero *successful* answers across 35 further invocations of
+> `spring-audit`/`verify`/`risk`/`audit-report`/`migrate-check`/
+> `migrate-apply`, revising the score to 3.8/10 — the lowest of four rounds.
+> The finding that matters more than either number: the forensic sidecar
+> 5.9.26 added specifically to instrument this failure did not fire once
+> across 32 observed empty answers on the audited machine — no sidecar file,
+> no error envelope. That means the failing runs are not reaching this
+> product's own entry-point wrapper at all, which redirects the entire
+> investigation upstream of where four rounds of prior work assumed it was.
+> The release gate is unchanged: do not use the audit-command family for
+> unattended CI. See
+> [`AUDIT-2026-09-02-EXTERNAL-5.9.26.md`](AUDIT-2026-09-02-EXTERNAL-5.9.26.md).
+
 > **CURRENT UPDATE — release `5.9.26`, fix queue from both 5.9.25 re-audits.**
 > Eight rows closed with verified evidence, each with a regression test:
 > `cache clear`/`context-clear` now read a piped refusal instead of treating

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

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

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

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

{sourcecode-5.9.26 → sourcecode-5.9.27}/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.26"
+__version__ = "5.9.27"

{sourcecode-5.9.26 → sourcecode-5.9.27}/src/sourcecode/cli.py

@@ -17454,7 +17454,6 @@ def remediation_report_cmd(
     copy: bool = _copy_option(),
 ) -> None:
     """Publish a redacted remediation record for this ASK build."""
-    del path
     _enforce_format("remediation-report", format)
     from sourcecode import bundled_docs
 
@@ -17473,6 +17472,24 @@ def remediation_report_cmd(
     report = build_report(
         ledger_path.read_text(encoding="utf-8"), build=build_provenance()
     )
+    # BUG-17 (5.9.26 re-audit): a real path, no path and a nonexistent path
+    # all returned byte-identical output with nothing saying the argument was
+    # ignored — read as a confident answer about a repository this command
+    # never opens. This still accepts any value (5.9.24 kept it deliberately,
+    # so scripts that always pass a repository path do not need a special
+    # case for the one command that has none to say about it); what changes
+    # is that the payload now says so, whether the path exists or not.
+    if path is not None:
+        report["path_argument"] = {
+            "given": str(path),
+            "used": False,
+            "note": (
+                "This report always projects the ledger bundled inside this "
+                "build. The path argument is accepted for invocation "
+                "consistency with repository-scoped commands and is never "
+                "read, whether or not it exists."
+            ),
+        }
     output = render_markdown(report) if format == "markdown" else _serialize_dict(report, format)
     _emit_command_output(output, output_path, copy,
                          success_msg=f"Remediation report written to {output_path}",
@@ -21676,6 +21693,17 @@ def main_entry() -> None:
     can consume them as positional arguments (which would prevent subcommand
     routing for tokens like 'version' or 'config').
     """
+    # R-01 (5.9.26 re-audit): the earliest possible line in this process, for
+    # the same reason AUD-596-B10 marks the clock here rather than later — a
+    # failure that never reaches this point cannot be told apart, from
+    # outside, from one that reaches it and then goes silent. 32 empty
+    # answers on the audited machine wrote no forensic sidecar at all; this
+    # settles which side of that line they were on. Argv-gated (not every
+    # invocation) so `--help` and other latency-sensitive commands this audit
+    # also flagged are not charged for a trace they were never in question for.
+    if any(tok in REQUIRED_ANSWER_COMMANDS for tok in sys.argv[1:]):
+        from sourcecode import empty_answer_diagnostics as _diag
+        _diag.record_entry_reached(sys.argv[1:])
     # AUD-596-B10: the earliest point in the process that knows a command is
     # starting. `timings.wall_ms` is published under a unit reading "THIS
     # process's wall clock", and until this mark existed it measured from

{sourcecode-5.9.26 → sourcecode-5.9.27}/src/sourcecode/empty_answer_diagnostics.py

@@ -19,6 +19,15 @@ for explicitly: capture the process's own state at the exact moment either
 guard is about to fire, every time it fires, so the next occurrence in the
 field carries its own forensic record instead of a report written from
 memory afterward.
+
+R-01 (5.9.26 re-audit) sharpened the question: across 32 empty answers on the
+audited machine, `record()` above never fired at all — no sidecar, no error
+envelope. That does not mean the guard mishandled a failure; it means the
+failing runs never reached the guard, which was invisible until something
+recorded whether the process got that far in the first place. `record_entry`
+answers exactly that, for the six audit-family commands, on every invocation
+— reached or not is now a fact this build can be asked for directly, instead
+of inferred from the absence of a failure record.
 """
 from __future__ import annotations
 
@@ -92,3 +101,59 @@ def _prune(directory: Path) -> None:
             stale.unlink(missing_ok=True)
     except Exception:
         pass
+
+
+#: Filename for the entry-reached trace (R-01). Distinct from `record()`'s
+#: one-file-per-failure snapshots: this is a bounded append log, one line per
+#: invocation of an audit-family command, so a comparison across many
+#: invocations does not depend on `record()` ever having fired.
+_ENTRY_TRACE_NAME = "entry-trace.jsonl"
+
+#: Lines to keep once the trace is pruned. Pruning is triggered by file size,
+#: not by line count, so the common case (a small file) costs one `stat`.
+_ENTRY_TRACE_MAX_LINES = 500
+_ENTRY_TRACE_PRUNE_THRESHOLD_BYTES = 512_000
+
+
+def record_entry_reached(argv: "list[str]") -> None:
+    """Append one line: this process reached `main_entry`, with this argv.
+
+    R-01: called as the very first statement of `main_entry`, before any
+    other work, for the audit-family commands only (`REQUIRED_ANSWER_COMMANDS`
+    in `cli.py`) — the ones the empty-answer defect affects. A future
+    occurrence can then be checked against this trace: a PID with a matching
+    timestamp here proves the process reached this product's own entry point
+    before it went silent, which narrows the search to after this line; no
+    matching entry proves the opposite, that whatever killed the run did so
+    before Python's own `main_entry` code could run at all.
+
+    Best-effort and always cheap: one append, one `stat` call in the common
+    case. Never raises — this must not cost, or ever be able to break, the
+    invocation it is observing.
+    """
+    try:
+        directory = _diagnostics_dir()
+        directory.mkdir(parents=True, exist_ok=True)
+        path = directory / _ENTRY_TRACE_NAME
+        line = json.dumps(
+            {"ts": time.time(), "pid": os.getpid(), "argv": list(argv)},
+            ensure_ascii=True, default=str,
+        )
+        with path.open("a", encoding="utf-8") as fh:
+            fh.write(line + "\n")
+        try:
+            if path.stat().st_size > _ENTRY_TRACE_PRUNE_THRESHOLD_BYTES:
+                _prune_entry_trace(path)
+        except OSError:
+            pass
+    except Exception:
+        pass
+
+
+def _prune_entry_trace(path: Path) -> None:
+    try:
+        lines = path.read_text(encoding="utf-8").splitlines()
+        kept = lines[-_ENTRY_TRACE_MAX_LINES:]
+        path.write_text("\n".join(kept) + ("\n" if kept else ""), encoding="utf-8")
+    except Exception:
+        pass

{sourcecode-5.9.26 → sourcecode-5.9.27}/src/sourcecode/remediation_report.py

@@ -75,4 +75,7 @@ def render_markdown(report: dict[str, Any]) -> str:
     lines.extend(f"| {key} | {value} |" for key, value in report["by_severity"].items())
     lines.extend(["", "## Boundaries", ""])
     lines.extend(f"- {item}" for item in report["non_coverage"])
+    path_argument = report.get("path_argument")
+    if path_argument:
+        lines.append(f"- {path_argument['note']} (given: `{path_argument['given']}`)")
     return "\n".join(lines) + "\n"