Runaway CPU investigation for python3.13: busy poll at unresolved offset in apt_pkg.cpython-313-x86_64-linux-gnu.so

python3.13 is stuck in a likely busy poll loop: 100.00% of sampled CPU passed through dequeue_entity, with repeated thread backtraces show 1 thread(s) around 0x00007f1c6e7efe92 in pthread_attr_destroy () from target:<path>.

Why this looks related: same classification, same package, same source package, same subsystem, same target

Last seen: 2026-06-05 03:12 UTC. Public page: /issues/019e9114-5b91-76f3-b9b4-c11d578198d2. Public JSON: /v1/issues/019e9114-5b91-76f3-b9b4-c11d578198d2

python3.13 shows a repeated `D`-state wait, likely blocked in unknown uninterruptible wait via current_time.

Why this looks related: same package, same source package, same target, same wait site

Last seen: 2026-05-06 23:10 UTC. Public page: /issues/019dff20-5e99-7871-8e0f-d0ff8b76b7aa. Public JSON: /v1/issues/019dff20-5e99-7871-8e0f-d0ff8b76b7aa

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and external handoff were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Plan Pass

## Problem
Fixer observed high CPU in `/usr/bin/python3.13` while running `/usr/bin/python3 /usr/bin/unattended-upgrade`, but the evidence does not identify a CPython runtime loop. The hot path is `apt_pkg.cpython-313-x86_64-linux-gnu.so`, with additional samples in `libapt-pkg.so.7.0.0`, and strace shows repeated `newfstatat()` probes under `/var/lib/apt/lists`.

## Evidence Confidence
inferred

## Proposed Subject
No CPython patch in this pass. Diagnose as likely misattributed to `python3.13`; the actionable target appears to be `python3-apt`, `libapt-pkg`, or `unattended-upgrades`.

## Patch Plan
1. Do not edit CPython unless a bounded reproduction shows CPython itself issuing the repeated path stats or causing an extension-level busy loop.
2. Treat `/usr/bin/unattended-upgrade` as the first investigation target, per the evidence command line, and inspect `python3-apt`/APT cache behavior before CPython runtime code.
3. If later evidence does identify a CPython caller, follow CPython conventions from `README.rst` and subsystem helpers such as `_Py_stat()`, `_Py_fstat()`, `_Py_wstat()`, `PyMem_Raw*`, and existing path/file utility wrappers rather than direct generic libc calls.
4. Avoid awkward control flow such as adding `goto` cleanup where a bounded early-return or existing helper pattern is cleaner.
5. No prior Fixer patch was found in this workspace to improve or replace.

## Risks
A CPython patch based only on this evidence would likely be speculative and upstream-hostile: the sampled Python frames show interpreter dispatch into an extension, while the hot DSO and syscall pattern point outside this source package. Patching CPython could mask the report without addressing the APT cache/stat behavior that Fixer observed.

## Validation
Before any future source edit, try the project entrypoint from the workspace root: `./configure && make`. If it fails because Debian source build dependencies or generated files are missing, record the exact failing command and error.

For the independent failure-signal check, run a bounded local probe such as `timeout 10s strace -f -e newfstatat /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run` only if safe in the test environment, and verify whether repeated `/var/lib/apt/lists/*` stats occur. If not safe, use a narrower Python import/cache smoke check around `apt_pkg`/APT cache construction rather than claiming reproduction.

## Patch Pass

Subject: Diagnose APT-cache runaway outside CPython

## Commit Message
No source change. The collected evidence points to APT cache work in `apt_pkg`/`libapt-pkg`, not to a CPython runtime defect, so a CPython patch would be speculative.

## Evidence Confidence
inferred

## Issue Connection
The observed signal is a running `/usr/bin/python3.13` process executing `/usr/bin/python3 /usr/bin/unattended-upgrade` with 99.7% CPU, 87,511 `newfstatat()` calls in 5 seconds, and repeated probes under `/var/lib/apt/lists`. The perf sample names `apt_pkg.cpython-313-x86_64-linux-gnu.so` as the hot DSO, and the top native symbols include `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()` from `libapt-pkg`.

The cautious inference is that Python is hosting an APT extension workload, while the expensive loop is in `python3-apt`/`libapt-pkg` or `unattended-upgrades` cache handling. CPython’s own source tree does not contain the implicated `apt_pkg` or APT cache code. I followed the saved plan and did not leave a source diff.

I checked CPython’s contribution/build guidance in `README.rst` and the local file helper conventions in `Python/fileutils.c`; CPython uses helpers such as `_Py_stat()`, `_Py_fstat()`, and `_Py_wstat()` around platform file status APIs. Those helpers do not fit this case because the collected stat storm is attributed to APT extension/library code outside this repository.

## Git Add Paths
None

## Validation
Ran `./configure && make` from the workspace root. It completed successfully. The build reported optional missing modules `_dbm`, `_gdbm`, and `_tkinter`, but no build failure.

Attempted bounded independent trace:
`timeout 10s strace -f -e trace=newfstatat -qq -o /tmp/fixer-apt-strace.log /usr/bin/python3 -c 'import apt; cache = apt.Cache(); print(len(cache))'`

That was blocked by sandbox ptrace restrictions:
`PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 7): Operation not permitted`; exit `1`, trace log had `0` lines.

Ran fallback smoke check:
`/usr/bin/time -f 'elapsed=%E user=%U sys=%S maxrss=%MKB' timeout 10s /usr/bin/python3 -c 'import apt; cache = apt.Cache(); print(len(cache))'`

It completed normally: printed `120025`, `elapsed=0:00.61 user=0.51 sys=0.03 maxrss=193360KB`, exit `0`. This did not reproduce the runaway behavior locally. Final `git status --short` was clean.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and external handoff were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Plan Pass

## Problem
Fixer observed high CPU in `/usr/bin/python3.13` while running `/usr/bin/python3 /usr/bin/unattended-upgrade`, but the evidence does not identify a CPython runtime loop. The hot path is `apt_pkg.cpython-313-x86_64-linux-gnu.so`, with additional samples in `libapt-pkg.so.7.0.0`, and strace shows repeated `newfstatat()` probes under `/var/lib/apt/lists`.

## Evidence Confidence
inferred

## Proposed Subject
No CPython patch in this pass. Diagnose as likely misattributed to `python3.13`; the actionable target appears to be `python3-apt`, `libapt-pkg`, or `unattended-upgrades`.

## Patch Plan
1. Do not edit CPython unless a bounded reproduction shows CPython itself issuing the repeated path stats or causing an extension-level busy loop.
2. Treat `/usr/bin/unattended-upgrade` as the first investigation target, per the evidence command line, and inspect `python3-apt`/APT cache behavior before CPython runtime code.
3. If later evidence does identify a CPython caller, follow CPython conventions from `README.rst` and subsystem helpers such as `_Py_stat()`, `_Py_fstat()`, `_Py_wstat()`, `PyMem_Raw*`, and existing path/file utility wrappers rather than direct generic libc calls.
4. Avoid awkward control flow such as adding `goto` cleanup where a bounded early-return or existing helper pattern is cleaner.
5. No prior Fixer patch was found in this workspace to improve or replace.

## Risks
A CPython patch based only on this evidence would likely be speculative and upstream-hostile: the sampled Python frames show interpreter dispatch into an extension, while the hot DSO and syscall pattern point outside this source package. Patching CPython could mask the report without addressing the APT cache/stat behavior that Fixer observed.

## Validation
Before any future source edit, try the project entrypoint from the workspace root: `./configure && make`. If it fails because Debian source build dependencies or generated files are missing, record the exact failing command and error.

For the independent failure-signal check, run a bounded local probe such as `timeout 10s strace -f -e newfstatat /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run` only if safe in the test environment, and verify whether repeated `/var/lib/apt/lists/*` stats occur. If not safe, use a narrower Python import/cache smoke check around `apt_pkg`/APT cache construction rather than claiming reproduction.

## Patch Pass

Subject: Diagnose APT-cache runaway outside CPython

## Commit Message
No source change. The collected evidence points to APT cache work in `apt_pkg`/`libapt-pkg`, not to a CPython runtime defect, so a CPython patch would be speculative.

## Evidence Confidence
inferred

## Issue Connection
The observed signal is a running `/usr/bin/python3.13` process executing `/usr/bin/python3 /usr/bin/unattended-upgrade` with 99.7% CPU, 87,511 `newfstatat()` calls in 5 seconds, and repeated probes under `/var/lib/apt/lists`. The perf sample names `apt_pkg.cpython-313-x86_64-linux-gnu.so` as the hot DSO, and the top native symbols include `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()` from `libapt-pkg`.

The cautious inference is that Python is hosting an APT extension workload, while the expensive loop is in `python3-apt`/`libapt-pkg` or `unattended-upgrades` cache handling. CPython’s own source tree does not contain the implicated `apt_pkg` or APT cache code. I followed the saved plan and did not leave a source diff.

I checked CPython’s contribution/build guidance in `README.rst` and the local file helper conventions in `Python/fileutils.c`; CPython uses helpers such as `_Py_stat()`, `_Py_fstat()`, and `_Py_wstat()` around platform file status APIs. Those helpers do not fit this case because the collected stat storm is attributed to APT extension/library code outside this repository.

## Git Add Paths
None

## Validation
Ran `./configure && make` from the workspace root. It completed successfully. The build reported optional missing modules `_dbm`, `_gdbm`, and `_tkinter`, but no build failure.

Attempted bounded independent trace:
`timeout 10s strace -f -e trace=newfstatat -qq -o /tmp/fixer-apt-strace.log /usr/bin/python3 -c 'import apt; cache = apt.Cache(); print(len(cache))'`

That was blocked by sandbox ptrace restrictions:
`PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 7): Operation not permitted`; exit `1`, trace log had `0` lines.

Ran fallback smoke check:
`/usr/bin/time -f 'elapsed=%E user=%U sys=%S maxrss=%MKB' timeout 10s /usr/bin/python3 -c 'import apt; cache = apt.Cache(); print(len(cache))'`

It completed normally: printed `120025`, `elapsed=0:00.61 user=0.51 sys=0.03 maxrss=193360KB`, exit `0`. This did not reproduce the runaway behavior locally. Final `git status --short` was clean.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Plan Pass

## Problem
Fixer observed high CPU in `/usr/bin/python3 /usr/bin/unattended-upgrade`. The hot code is `apt_pkg.cpython-313-...so` and `libapt-pkg.so.7.0`, with `strace` dominated by repeated `newfstatat()` probes under `/var/lib/apt/lists`. CPython appears as the host interpreter and generic call machinery (`_PyObject_MakeTpCall`), not as the likely root cause.

## Evidence Confidence
inferred

## Proposed Subject
No CPython patch: diagnose unattended-upgrade APT metadata polling

## Patch Plan
Do not edit the `python3.13` source in this pass. The evidence points through the script/application entrypoint into `python3-apt`/`libapt-pkg`, so an upstream CPython patch would be speculative and not pull-request-ready.

If stronger evidence is collected later, start from `unattended-upgrade` and `python3-apt` symbols rather than changing CPython runtime call paths. I found CPython contribution guidance in `README.rst` and docs guidance in `Doc/README.rst`; Debian packaging notes say quilt is used. In the only nearby CPython areas touched by the trace, local conventions include Argument Clinic, `path_t`, `path_error()`, `Py_BEGIN_ALLOW_THREADS`, and `PyMem_*`, but no relevant CPython helper addresses repeated APT list-file probing. No prior Fixer patch exists in this workspace to improve or replace.

Avoid awkward source changes such as inserting control-flow guards or `goto` paths in CPython’s `Objects/call.c` or `Modules/posixmodule.c`; those would not address the observed hot DSO and syscall pattern.

## Risks
The main risk is misattribution: patching CPython could hide or distort an APT-side performance problem. The embedded raw artifact paths are unavailable in this workspace, so the diagnosis relies on the evidence JSON excerpts rather than full local backtrace/strace files.

## Validation
For any future CPython source patch, first try the workspace-root project entrypoint: `./configure && make`.

For this no-patch diagnosis, the bounded independent check I would attempt is: `timeout 20s strace -f -e trace=newfstatat -c /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`, only if `unattended-upgrade` is installed and dry-run is available. I would not claim `reproduced` unless that command independently shows the repeated APT list-file `newfstatat()` pattern.

## Patch Pass

Subject: No CPython patch: diagnose APT metadata polling

## Commit Message
No source change. The collected evidence points to `unattended-upgrade` spending CPU in `python3-apt`/`libapt-pkg` while repeatedly probing APT list files, not to a CPython runtime defect.

## Evidence Confidence
inferred

## Issue Connection
The collected signal is a running `/usr/bin/python3 /usr/bin/unattended-upgrade` process with high CPU, 87,511 `newfstatat()` calls in a 5 second trace, and the hottest native path in `apt_pkg.cpython-313-...so` plus `libapt-pkg.so.7.0`. The CPython frames shown are generic execution and call frames, including `_PyObject_MakeTpCall`, rather than a concrete loop in CPython.

I followed the saved plan and did not change course. I inspected CPython contribution/build guidance in `README.rst`, docs guidance in `Doc/README.rst`, Debian source notes in `debian/README.source`, and the nearby CPython call/stat code. Relevant local conventions include Argument Clinic, `path_t`, `path_error()`, `Py_BEGIN_ALLOW_THREADS`, and `PyMem_*`; none address repeated APT repository metadata probing from `unattended-upgrade`.

The specific change is no source diff. The expected effect is to avoid landing a speculative CPython patch and to direct the report toward `unattended-upgrade`, `python3-apt`, or `libapt-pkg`, where the trace actually spends time.

## Git Add Paths
None

## Validation
`./configure && make` from the workspace root completed successfully. The build reported optional modules `_dbm`, `_gdbm`, and `_tkinter` as missing, but no build failure.

Independent reproduction attempt: `timeout 20s strace -f -e trace=newfstatat -c /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug` could not run because ptrace is blocked in this environment: `PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 5): Operation not permitted`. Therefore I did not independently reproduce the syscall pattern.

## Review Pass 1

RESULT: ok

No source diff is present, and `git status --short` is clean. The author correctly used `inferred`, avoided a speculative CPython patch, connected the evidence to `unattended-upgrade`/`python3-apt`/`libapt-pkg`, named relevant CPython conventions, and reported project-level validation plus the ptrace blocker for independent strace reproduction.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Plan Pass

## Problem
Fixer observed high CPU in `/usr/bin/python3 /usr/bin/unattended-upgrade`. The hot code is `apt_pkg.cpython-313-...so` and `libapt-pkg.so.7.0`, with `strace` dominated by repeated `newfstatat()` probes under `/var/lib/apt/lists`. CPython appears as the host interpreter and generic call machinery (`_PyObject_MakeTpCall`), not as the likely root cause.

## Evidence Confidence
inferred

## Proposed Subject
No CPython patch: diagnose unattended-upgrade APT metadata polling

## Patch Plan
Do not edit the `python3.13` source in this pass. The evidence points through the script/application entrypoint into `python3-apt`/`libapt-pkg`, so an upstream CPython patch would be speculative and not pull-request-ready.

If stronger evidence is collected later, start from `unattended-upgrade` and `python3-apt` symbols rather than changing CPython runtime call paths. I found CPython contribution guidance in `README.rst` and docs guidance in `Doc/README.rst`; Debian packaging notes say quilt is used. In the only nearby CPython areas touched by the trace, local conventions include Argument Clinic, `path_t`, `path_error()`, `Py_BEGIN_ALLOW_THREADS`, and `PyMem_*`, but no relevant CPython helper addresses repeated APT list-file probing. No prior Fixer patch exists in this workspace to improve or replace.

Avoid awkward source changes such as inserting control-flow guards or `goto` paths in CPython’s `Objects/call.c` or `Modules/posixmodule.c`; those would not address the observed hot DSO and syscall pattern.

## Risks
The main risk is misattribution: patching CPython could hide or distort an APT-side performance problem. The embedded raw artifact paths are unavailable in this workspace, so the diagnosis relies on the evidence JSON excerpts rather than full local backtrace/strace files.

## Validation
For any future CPython source patch, first try the workspace-root project entrypoint: `./configure && make`.

For this no-patch diagnosis, the bounded independent check I would attempt is: `timeout 20s strace -f -e trace=newfstatat -c /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`, only if `unattended-upgrade` is installed and dry-run is available. I would not claim `reproduced` unless that command independently shows the repeated APT list-file `newfstatat()` pattern.

## Patch Pass

Subject: No CPython patch: diagnose APT metadata polling

## Commit Message
No source change. The collected evidence points to `unattended-upgrade` spending CPU in `python3-apt`/`libapt-pkg` while repeatedly probing APT list files, not to a CPython runtime defect.

## Evidence Confidence
inferred

## Issue Connection
The collected signal is a running `/usr/bin/python3 /usr/bin/unattended-upgrade` process with high CPU, 87,511 `newfstatat()` calls in a 5 second trace, and the hottest native path in `apt_pkg.cpython-313-...so` plus `libapt-pkg.so.7.0`. The CPython frames shown are generic execution and call frames, including `_PyObject_MakeTpCall`, rather than a concrete loop in CPython.

I followed the saved plan and did not change course. I inspected CPython contribution/build guidance in `README.rst`, docs guidance in `Doc/README.rst`, Debian source notes in `debian/README.source`, and the nearby CPython call/stat code. Relevant local conventions include Argument Clinic, `path_t`, `path_error()`, `Py_BEGIN_ALLOW_THREADS`, and `PyMem_*`; none address repeated APT repository metadata probing from `unattended-upgrade`.

The specific change is no source diff. The expected effect is to avoid landing a speculative CPython patch and to direct the report toward `unattended-upgrade`, `python3-apt`, or `libapt-pkg`, where the trace actually spends time.

## Git Add Paths
None

## Validation
`./configure && make` from the workspace root completed successfully. The build reported optional modules `_dbm`, `_gdbm`, and `_tkinter` as missing, but no build failure.

Independent reproduction attempt: `timeout 20s strace -f -e trace=newfstatat -c /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug` could not run because ptrace is blocked in this environment: `PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 5): Operation not permitted`. Therefore I did not independently reproduce the syscall pattern.

## Review Pass 1

RESULT: ok

No source diff is present, and `git status --short` is clean. The author correctly used `inferred`, avoided a speculative CPython patch, connected the evidence to `unattended-upgrade`/`python3-apt`/`libapt-pkg`, named relevant CPython conventions, and reported project-level validation plus the ptrace blocker for independent strace reproduction.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Plan Pass

## Problem
Fixer observed high CPU in `/usr/bin/python3 /usr/bin/unattended-upgrade`, but the evidence points to `apt_pkg.cpython-313-x86_64-linux-gnu.so` and `libapt-pkg.so.7.0.0`, with repeated `newfstatat()` calls against `/var/lib/apt/lists/...`. The CPython source package does not contain `apt_pkg`, `libapt-pkg`, or `unattended-upgrade`, so I would not plan a CPython source patch from this bundle.

## Evidence Confidence
observed

## Proposed Subject
No `python3.13` upstream patch. Retarget the issue to `python3-apt`, `libapt-pkg`, or `unattended-upgrades`: “Avoid repeated apt list metadata probes during unattended-upgrade cache/dependency processing.”

## Patch Plan
1. Do not edit CPython in this pass; the failure signal is profiler/syscall evidence, not a reproduced interpreter bug.
2. Document that CPython’s relevant local convention already releases the GIL around POSIX stat calls in `Modules/posixmodule.c::posix_do_stat()` using `Py_BEGIN_ALLOW_THREADS`, and uses CPython path helpers such as `path_t`, `path_error()`, `_Py_fstat_noraise()`, and `_Py_stat()` where applicable.
3. Note that no relevant `apt_pkg`, `libapt-pkg`, or `unattended-upgrade` code exists in this workspace, and `rg` found no matching Python-apt/APT subsystem files.
4. No prior Fixer patch was found; Debian quilt patches are ordinary package patches listed in `.pc/applied-patches`.
5. If later evidence proves a CPython runtime issue, prefer a small bounded change in the owning helper path and avoid awkward control flow such as unnecessary `goto`; otherwise the patch should be made in the APT/python-apt source that owns the repeated file probing.

## Risks
A CPython patch here would likely be a workaround against the wrong component. The hot path is an extension module and APT library, while the interpreter frames only show normal Python execution around an external C extension call.

## Validation
For any future CPython-side patch, first try the project-level entrypoint from the workspace root: `./configure && make`. If that fails due to missing dependencies or generated files, record the exact failure and then run the narrowest relevant CPython compile/test.

Bounded independent reproduction attempt before editing would be: run the observed application path under a timeout and syscall counter, e.g. `timeout 30s strace -f -c /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`, if available and safe in the test environment. A CPython-only leaf test would not be enough to claim this issue is reproduced.

## Patch Pass

Subject: Diagnose APT-owned unattended-upgrade CPU loop

## Commit Message
No CPython source change is made. Fixer’s perf, strace, and `/proc` evidence shows `unattended-upgrade` running under Python 3.13 with high CPU, but the hot native code is in `apt_pkg` and `libapt-pkg`, and the syscall stream is dominated by repeated APT list-file `newfstatat()` probes. The CPython repository does not contain that code, and its own stat path already follows the local helper convention of releasing the GIL around filesystem syscalls.

## Evidence Confidence
observed

## Issue Connection
The collected signal is a running `/usr/bin/python3 /usr/bin/unattended-upgrade` process with up to 99.7% CPU, `87511` `newfstatat()` calls in a 5 second strace sample, and perf attribution to `apt_pkg.cpython-313-x86_64-linux-gnu.so` plus `libapt-pkg.so.7.0.0` symbols such as `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()`.

The likely root cause is repeated APT package-list metadata probing during unattended-upgrade dependency/cache processing, not a CPython interpreter stat-loop. I inspected CPython’s relevant POSIX stat path and found `Modules/posixmodule.c::posix_do_stat()` already wraps `stat()`, `lstat()`, and `fstatat()` with `Py_BEGIN_ALLOW_THREADS`, using local helpers/conventions such as `path_t`, `path_error()`, `_Py_fstat_noraise()`, and `_Py_stat()`.

No source change was made because the target repository does not contain `apt_pkg`, `libapt-pkg`, or `unattended-upgrade`. The expected effect of this no-patch diagnosis is to avoid an upstream CPython workaround for behavior owned by `python3-apt`, `libapt-pkg`, or `unattended-upgrades`.

## Git Add Paths
None

## Validation
- `./configure && make -j2` from the workspace root: passed. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the interpreter build completed.
- `timeout 30s strace -f -c /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`: blocked by sandbox ptrace restrictions: `PTRACE_TRACEME: Operation not permitted`.
- `timeout 30s /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`: blocked before APT processing by read-only `/var/run`: `OSError: [Errno 30] Read-only file system: '/var/run/unattended-upgrades.pid'`.
- `rg --files | rg '(^|/)(apt|apt_pkg|apt_inst|libapt|unattended)'`: no matching source files in this CPython workspace.
- Cleaned build artifacts with `make distclean`; final `git status --short` is clean.

## Review Pass 1

RESULT: ok

No source changes are present, and `Git Add Paths` correctly reports `None`.

The author followed the plan and did not force a CPython patch for evidence that points into `apt_pkg` / `libapt-pkg`. The explanation connects the collected signal to the no-patch decision: high CPU in `unattended-upgrade`, repeated `newfstatat()` calls, hot frames in APT libraries, and no matching APT-owned source in this CPython workspace.

The evidence confidence is valid as `observed`: the bundle has direct Fixer trace/profile/proc evidence, while the attempted independent reproduction was blocked and not claimed as reproduced. Validation includes the required workspace-root `./configure && make -j2`, blocked reproduction attempts with exact blockers, and a clean final worktree.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Plan Pass

## Problem
Fixer observed high CPU in `/usr/bin/python3 /usr/bin/unattended-upgrade`, but the evidence points to `apt_pkg.cpython-313-x86_64-linux-gnu.so` and `libapt-pkg.so.7.0.0`, with repeated `newfstatat()` calls against `/var/lib/apt/lists/...`. The CPython source package does not contain `apt_pkg`, `libapt-pkg`, or `unattended-upgrade`, so I would not plan a CPython source patch from this bundle.

## Evidence Confidence
observed

## Proposed Subject
No `python3.13` upstream patch. Retarget the issue to `python3-apt`, `libapt-pkg`, or `unattended-upgrades`: “Avoid repeated apt list metadata probes during unattended-upgrade cache/dependency processing.”

## Patch Plan
1. Do not edit CPython in this pass; the failure signal is profiler/syscall evidence, not a reproduced interpreter bug.
2. Document that CPython’s relevant local convention already releases the GIL around POSIX stat calls in `Modules/posixmodule.c::posix_do_stat()` using `Py_BEGIN_ALLOW_THREADS`, and uses CPython path helpers such as `path_t`, `path_error()`, `_Py_fstat_noraise()`, and `_Py_stat()` where applicable.
3. Note that no relevant `apt_pkg`, `libapt-pkg`, or `unattended-upgrade` code exists in this workspace, and `rg` found no matching Python-apt/APT subsystem files.
4. No prior Fixer patch was found; Debian quilt patches are ordinary package patches listed in `.pc/applied-patches`.
5. If later evidence proves a CPython runtime issue, prefer a small bounded change in the owning helper path and avoid awkward control flow such as unnecessary `goto`; otherwise the patch should be made in the APT/python-apt source that owns the repeated file probing.

## Risks
A CPython patch here would likely be a workaround against the wrong component. The hot path is an extension module and APT library, while the interpreter frames only show normal Python execution around an external C extension call.

## Validation
For any future CPython-side patch, first try the project-level entrypoint from the workspace root: `./configure && make`. If that fails due to missing dependencies or generated files, record the exact failure and then run the narrowest relevant CPython compile/test.

Bounded independent reproduction attempt before editing would be: run the observed application path under a timeout and syscall counter, e.g. `timeout 30s strace -f -c /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`, if available and safe in the test environment. A CPython-only leaf test would not be enough to claim this issue is reproduced.

## Patch Pass

Subject: Diagnose APT-owned unattended-upgrade CPU loop

## Commit Message
No CPython source change is made. Fixer’s perf, strace, and `/proc` evidence shows `unattended-upgrade` running under Python 3.13 with high CPU, but the hot native code is in `apt_pkg` and `libapt-pkg`, and the syscall stream is dominated by repeated APT list-file `newfstatat()` probes. The CPython repository does not contain that code, and its own stat path already follows the local helper convention of releasing the GIL around filesystem syscalls.

## Evidence Confidence
observed

## Issue Connection
The collected signal is a running `/usr/bin/python3 /usr/bin/unattended-upgrade` process with up to 99.7% CPU, `87511` `newfstatat()` calls in a 5 second strace sample, and perf attribution to `apt_pkg.cpython-313-x86_64-linux-gnu.so` plus `libapt-pkg.so.7.0.0` symbols such as `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()`.

The likely root cause is repeated APT package-list metadata probing during unattended-upgrade dependency/cache processing, not a CPython interpreter stat-loop. I inspected CPython’s relevant POSIX stat path and found `Modules/posixmodule.c::posix_do_stat()` already wraps `stat()`, `lstat()`, and `fstatat()` with `Py_BEGIN_ALLOW_THREADS`, using local helpers/conventions such as `path_t`, `path_error()`, `_Py_fstat_noraise()`, and `_Py_stat()`.

No source change was made because the target repository does not contain `apt_pkg`, `libapt-pkg`, or `unattended-upgrade`. The expected effect of this no-patch diagnosis is to avoid an upstream CPython workaround for behavior owned by `python3-apt`, `libapt-pkg`, or `unattended-upgrades`.

## Git Add Paths
None

## Validation
- `./configure && make -j2` from the workspace root: passed. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the interpreter build completed.
- `timeout 30s strace -f -c /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`: blocked by sandbox ptrace restrictions: `PTRACE_TRACEME: Operation not permitted`.
- `timeout 30s /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`: blocked before APT processing by read-only `/var/run`: `OSError: [Errno 30] Read-only file system: '/var/run/unattended-upgrades.pid'`.
- `rg --files | rg '(^|/)(apt|apt_pkg|apt_inst|libapt|unattended)'`: no matching source files in this CPython workspace.
- Cleaned build artifacts with `make distclean`; final `git status --short` is clean.

## Review Pass 1

RESULT: ok

No source changes are present, and `Git Add Paths` correctly reports `None`.

The author followed the plan and did not force a CPython patch for evidence that points into `apt_pkg` / `libapt-pkg`. The explanation connects the collected signal to the no-patch decision: high CPU in `unattended-upgrade`, repeated `newfstatat()` calls, hot frames in APT libraries, and no matching APT-owned source in this CPython workspace.

The evidence confidence is valid as `observed`: the bundle has direct Fixer trace/profile/proc evidence, while the attempted independent reproduction was blocked and not claimed as reproduced. Validation includes the required workspace-root `./configure && make -j2`, blocked reproduction attempts with exact blockers, and a clean final worktree.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Plan Pass

## Problem
Fixer observed a high-CPU `python3.13` process running `/usr/bin/python3 /usr/bin/unattended-upgrade`. The embedded evidence points away from CPython itself: the hot DSO is `apt_pkg.cpython-313-x86_64-linux-gnu.so`, top native symbols include `pkgDepCache::*` in `libapt-pkg.so.7.0.0`, and `strace` shows repeated `newfstatat()` calls over `/var/lib/apt/lists/*Packages*`.

## Evidence Confidence
inferred

## Proposed Subject
No CPython source patch in this pass. Treat this as a diagnosis/report plan: the candidate fix belongs in `python3-apt`, `libapt-pkg`, or possibly `unattended-upgrades`, not in the `python3.13` source package.

## Patch Plan
- Do not edit CPython unless new evidence links the loop to CPython runtime code.
- Document that the application entrypoint is `unattended-upgrade`, and the runtime is only the host interpreter.
- Note that CPython’s relevant stat implementation already follows local conventions: `path_t` validation, `Py_BEGIN_ALLOW_THREADS`, `path_error()`, `_pystat_fromstructstat()`, and Argument Clinic-generated wrappers.
- No prior Fixer patch is present in this worktree to improve or replace; Debian quilt patches were scanned and do not target this evidence.
- If later evidence proves a CPython bug, keep control flow local and bounded, avoiding awkward `goto` where a direct return or small helper matches nearby style.

## Risks
- A CPython patch would likely be speculative and PR-unready because the observed hot path is external extension/native apt code.
- The evidence bundle’s raw artifact path for the specific `unattended-upgrade` sample was not present, so the embedded excerpts are the reliable source here.
- Running `unattended-upgrade` directly may mutate system package state; reproduction should use bounded, read-only `apt_pkg` cache-loading probes first.

## Validation
- If a CPython patch is later justified, first try the project entrypoint from the workspace root: `./configure && make`.
- For an independent bounded signal check, run a read-only probe such as `timeout 10s strace -f -e trace=newfstatat /usr/bin/python3 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'` and compare whether the repeated `/var/lib/apt/lists` stats occur without claiming full reproduction unless it shows the same sustained failure pattern.
- If project build fails due to missing dependencies/generated files, record the exact failure and then run the narrowest relevant CPython compile/test.

## Patch Pass

Subject: Diagnose apt cache CPU trace outside CPython

## Commit Message
No source change was made. The collected signal shows `unattended-upgrade` running under Python, but the hot native code and repeated file probes are in `python3-apt`/`libapt-pkg`, not in CPython’s runtime. A CPython patch would be speculative without stronger evidence tying the loop to interpreter code.

## Evidence Confidence
inferred

## Issue Connection
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` consuming up to 99.7% CPU, with the process runnable, 87,511 `newfstatat()` calls in a 5-second trace, and repeated probes under `/var/lib/apt/lists/`.

The likely root cause is outside CPython: the hottest DSO is `apt_pkg.cpython-313-x86_64-linux-gnu.so`, the native symbols include `pkgDepCache::*` from `libapt-pkg.so.7.0.0`, and the main Python frame is just the interpreter calling extension code. I inspected CPython’s POSIX stat path and found it already uses the local conventions/helpers: `path_t` validation, `Py_BEGIN_ALLOW_THREADS`, `path_error()`, `_pystat_fromstructstat()`, and Argument Clinic wrappers.

I followed the saved plan and made no source change. The expected effect is that this proposal avoids an upstream-unready CPython diff and leaves a focused report pointing at `python3-apt`, `libapt-pkg`, or `unattended-upgrades`.

## Git Add Paths
None

## Validation
- Read contribution/style entrypoints: `README.rst` and `Misc/README`. `README.rst` documents `./configure`, `make`, and `make test`.
- Inspected relevant CPython subsystem code in `Modules/posixmodule.c`; no CPython loop or missing local wrapper was found.
- Ran workspace-root validation: `./configure && make`. It completed successfully. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the build itself completed.
- Attempted bounded independent reproduction: `timeout 10s strace -f -e trace=newfstatat /usr/bin/python3 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'`. This was blocked by sandbox ptrace restrictions: `PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 8): Operation not permitted`.
- Cleaned generated build artifacts with `make distclean`; final `git status --short` is clean.

## Review Pass 1

RESULT: ok

No findings. The first pass correctly leaves no source diff because the evidence ties the hot path to `apt_pkg`/`libapt-pkg`, not CPython. The response uses a permitted confidence value, avoids claiming reproduction, reports the ptrace blocker for the bounded strace probe, and includes project-level validation with `./configure && make`. The worktree is clean.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Plan Pass

## Problem
Fixer observed a high-CPU `python3.13` process running `/usr/bin/python3 /usr/bin/unattended-upgrade`. The embedded evidence points away from CPython itself: the hot DSO is `apt_pkg.cpython-313-x86_64-linux-gnu.so`, top native symbols include `pkgDepCache::*` in `libapt-pkg.so.7.0.0`, and `strace` shows repeated `newfstatat()` calls over `/var/lib/apt/lists/*Packages*`.

## Evidence Confidence
inferred

## Proposed Subject
No CPython source patch in this pass. Treat this as a diagnosis/report plan: the candidate fix belongs in `python3-apt`, `libapt-pkg`, or possibly `unattended-upgrades`, not in the `python3.13` source package.

## Patch Plan
- Do not edit CPython unless new evidence links the loop to CPython runtime code.
- Document that the application entrypoint is `unattended-upgrade`, and the runtime is only the host interpreter.
- Note that CPython’s relevant stat implementation already follows local conventions: `path_t` validation, `Py_BEGIN_ALLOW_THREADS`, `path_error()`, `_pystat_fromstructstat()`, and Argument Clinic-generated wrappers.
- No prior Fixer patch is present in this worktree to improve or replace; Debian quilt patches were scanned and do not target this evidence.
- If later evidence proves a CPython bug, keep control flow local and bounded, avoiding awkward `goto` where a direct return or small helper matches nearby style.

## Risks
- A CPython patch would likely be speculative and PR-unready because the observed hot path is external extension/native apt code.
- The evidence bundle’s raw artifact path for the specific `unattended-upgrade` sample was not present, so the embedded excerpts are the reliable source here.
- Running `unattended-upgrade` directly may mutate system package state; reproduction should use bounded, read-only `apt_pkg` cache-loading probes first.

## Validation
- If a CPython patch is later justified, first try the project entrypoint from the workspace root: `./configure && make`.
- For an independent bounded signal check, run a read-only probe such as `timeout 10s strace -f -e trace=newfstatat /usr/bin/python3 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'` and compare whether the repeated `/var/lib/apt/lists` stats occur without claiming full reproduction unless it shows the same sustained failure pattern.
- If project build fails due to missing dependencies/generated files, record the exact failure and then run the narrowest relevant CPython compile/test.

## Patch Pass

Subject: Diagnose apt cache CPU trace outside CPython

## Commit Message
No source change was made. The collected signal shows `unattended-upgrade` running under Python, but the hot native code and repeated file probes are in `python3-apt`/`libapt-pkg`, not in CPython’s runtime. A CPython patch would be speculative without stronger evidence tying the loop to interpreter code.

## Evidence Confidence
inferred

## Issue Connection
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` consuming up to 99.7% CPU, with the process runnable, 87,511 `newfstatat()` calls in a 5-second trace, and repeated probes under `/var/lib/apt/lists/`.

The likely root cause is outside CPython: the hottest DSO is `apt_pkg.cpython-313-x86_64-linux-gnu.so`, the native symbols include `pkgDepCache::*` from `libapt-pkg.so.7.0.0`, and the main Python frame is just the interpreter calling extension code. I inspected CPython’s POSIX stat path and found it already uses the local conventions/helpers: `path_t` validation, `Py_BEGIN_ALLOW_THREADS`, `path_error()`, `_pystat_fromstructstat()`, and Argument Clinic wrappers.

I followed the saved plan and made no source change. The expected effect is that this proposal avoids an upstream-unready CPython diff and leaves a focused report pointing at `python3-apt`, `libapt-pkg`, or `unattended-upgrades`.

## Git Add Paths
None

## Validation
- Read contribution/style entrypoints: `README.rst` and `Misc/README`. `README.rst` documents `./configure`, `make`, and `make test`.
- Inspected relevant CPython subsystem code in `Modules/posixmodule.c`; no CPython loop or missing local wrapper was found.
- Ran workspace-root validation: `./configure && make`. It completed successfully. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the build itself completed.
- Attempted bounded independent reproduction: `timeout 10s strace -f -e trace=newfstatat /usr/bin/python3 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'`. This was blocked by sandbox ptrace restrictions: `PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 8): Operation not permitted`.
- Cleaned generated build artifacts with `make distclean`; final `git status --short` is clean.

## Review Pass 1

RESULT: ok

No findings. The first pass correctly leaves no source diff because the evidence ties the hot path to `apt_pkg`/`libapt-pkg`, not CPython. The response uses a permitted confidence value, avoids claiming reproduction, reports the ptrace blocker for the bounded strace probe, and includes project-level validation with `./configure && make`. The worktree is clean.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1 (local metadata check)

Local metadata consistency check

## Refinement Pass 1

You are refining a fixer patch after an explicit code review.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Read the latest author response at `./patch-output.txt`. Read the review report at `./review-1-output.txt`. This is refinement round 1. The original pre-edit snapshot is available at `./source` if you need to compare the current patch against it. Re-read the planning pass at `./plan-output.txt` before editing. The workspace currently changes these repo-relative paths: Lib/__pycache__/__future__.cpython-313.pyc, Lib/__pycache__/_collections_abc.cpython-313.pyc, Lib/__pycache__/_colorize.cpython-313.pyc, Lib/__pycache__/_compat_pickle.cpython-313.pyc, Lib/__pycache__/_compression.cpython-313.pyc, Lib/__pycache__/_opcode_metadata.cpython-313.pyc, Lib/__pycache__/_sitebuiltins.cpython-313.pyc, Lib/__pycache__/_weakrefset.cpython-313.pyc, Lib/__pycache__/abc.cpython-313.pyc, Lib/__pycache__/argparse.cpython-313.pyc, Lib/__pycache__/ast.cpython-313.pyc, Lib/__pycache__/base64.cpython-313.pyc, Lib/__pycache__/bz2.cpython-313.pyc, Lib/__pycache__/codecs.cpython-313.pyc, Lib/__pycache__/contextlib.cpython-313.pyc, Lib/__pycache__/contextvars.cpython-313.pyc, Lib/__pycache__/copy.cpython-313.pyc, Lib/__pycache__/copyreg.cpython-313.pyc, Lib/__pycache__/datetime.cpython-313.pyc, Lib/__pycache__/dis.cpython-313.pyc, Lib/__pycache__/enum.cpython-313.pyc, Lib/__pycache__/fnmatch.cpython-313.pyc, Lib/__pycache__/functools.cpython-313.pyc, Lib/__pycache__/genericpath.cpython-313.pyc, Lib/__pycache__/gettext.cpython-313.pyc, Lib/__pycache__/glob.cpython-313.pyc, Lib/__pycache__/heapq.cpython-313.pyc, Lib/__pycache__/inspect.cpython-313.pyc, Lib/__pycache__/io.cpython-313.pyc, Lib/__pycache__/keyword.cpython-313.pyc, Lib/__pycache__/linecache.cpython-313.pyc, Lib/__pycache__/locale.cpython-313.pyc, Lib/__pycache__/lzma.cpython-313.pyc, Lib/__pycache__/numbers.cpython-313.pyc, Lib/__pycache__/opcode.cpython-313.pyc, Lib/__pycache__/operator.cpython-313.pyc, Lib/__pycache__/os.cpython-313.pyc, Lib/__pycache__/posixpath.cpython-313.pyc, Lib/__pycache__/reprlib.cpython-313.pyc, Lib/__pycache__/selectors.cpython-313.pyc, Lib/__pycache__/shutil.cpython-313.pyc, Lib/__pycache__/signal.cpython-313.pyc, Lib/__pycache__/site.cpython-313.pyc, Lib/__pycache__/socket.cpython-313.pyc, Lib/__pycache__/ssl.cpython-313.pyc, Lib/__pycache__/stat.cpython-313.pyc, Lib/__pycache__/string.cpython-313.pyc, Lib/__pycache__/struct.cpython-313.pyc, Lib/__pycache__/subprocess.cpython-313.pyc, Lib/__pycache__/textwrap.cpython-313.pyc, Lib/__pycache__/threading.cpython-313.pyc, Lib/__pycache__/token.cpython-313.pyc, Lib/__pycache__/tokenize.cpython-313.pyc, Lib/__pycache__/traceback.cpython-313.pyc, Lib/__pycache__/types.cpython-313.pyc, Lib/__pycache__/typing.cpython-313.pyc, Lib/__pycache__/warnings.cpython-313.pyc, Lib/__pycache__/weakref.cpython-313.pyc, Lib/asyncio/__pycache__/__init__.cpython-313.pyc, Lib/asyncio/__pycache__/base_events.cpython-313.pyc, Lib/asyncio/__pycache__/base_futures.cpython-313.pyc, Lib/asyncio/__pycache__/base_subprocess.cpython-313.pyc, Lib/asyncio/__pycache__/base_tasks.cpython-313.pyc, Lib/asyncio/__pycache__/constants.cpython-313.pyc, Lib/asyncio/__pycache__/coroutines.cpython-313.pyc, Lib/asyncio/__pycache__/events.cpython-313.pyc, Lib/asyncio/__pycache__/exceptions.cpython-313.pyc, Lib/asyncio/__pycache__/format_helpers.cpython-313.pyc, Lib/asyncio/__pycache__/futures.cpython-313.pyc, Lib/asyncio/__pycache__/locks.cpython-313.pyc, Lib/asyncio/__pycache__/log.cpython-313.pyc, Lib/asyncio/__pycache__/mixins.cpython-313.pyc, Lib/asyncio/__pycache__/protocols.cpython-313.pyc, Lib/asyncio/__pycache__/queues.cpython-313.pyc, Lib/asyncio/__pycache__/runners.cpython-313.pyc, Lib/asyncio/__pycache__/selector_events.cpython-313.pyc, Lib/asyncio/__pycache__/sslproto.cpython-313.pyc, Lib/asyncio/__pycache__/staggered.cpython-313.pyc, Lib/asyncio/__pycache__/streams.cpython-313.pyc, Lib/asyncio/__pycache__/subprocess.cpython-313.pyc, Lib/asyncio/__pycache__/taskgroups.cpython-313.pyc, Lib/asyncio/__pycache__/tasks.cpython-313.pyc, Lib/asyncio/__pycache__/threads.cpython-313.pyc, Lib/asyncio/__pycache__/timeouts.cpython-313.pyc, Lib/asyncio/__pycache__/transports.cpython-313.pyc, Lib/asyncio/__pycache__/trsock.cpython-313.pyc, Lib/asyncio/__pycache__/unix_events.cpython-313.pyc, Lib/collections/__pycache__/__init__.cpython-313.pyc, Lib/concurrent/__pycache__/__init__.cpython-313.pyc, Lib/concurrent/futures/__pycache__/__init__.cpython-313.pyc, Lib/concurrent/futures/__pycache__/_base.cpython-313.pyc, Lib/encodings/__pycache__/__init__.cpython-313.pyc, Lib/encodings/__pycache__/aliases.cpython-313.pyc, Lib/encodings/__pycache__/ascii.cpython-313.pyc, Lib/encodings/__pycache__/utf_8.cpython-313.pyc, Lib/importlib/__pycache__/__init__.cpython-313.pyc, Lib/importlib/__pycache__/_abc.cpython-313.pyc, Lib/logging/__pycache__/__init__.cpython-313.pyc, Lib/pathlib/__pycache__/__init__.cpython-313.pyc, Lib/pathlib/__pycache__/_abc.cpython-313.pyc, Lib/pathlib/__pycache__/_local.cpython-313.pyc, Lib/re/__pycache__/__init__.cpython-313.pyc, Lib/re/__pycache__/_casefix.cpython-313.pyc, Lib/re/__pycache__/_compiler.cpython-313.pyc, Lib/re/__pycache__/_constants.cpython-313.pyc, Lib/re/__pycache__/_parser.cpython-313.pyc, Lib/sysconfig/__pycache__/__init__.cpython-313.pyc, Lib/sysconfig/__pycache__/__main__.cpython-313.pyc, Lib/xml/__pycache__/__init__.cpython-313.pyc, Lib/xml/etree/__pycache__/ElementPath.cpython-313.pyc, Lib/xml/etree/__pycache__/__init__.cpython-313.pyc, Lib/zoneinfo/__pycache__/__init__.cpython-313.pyc, Lib/zoneinfo/__pycache__/_common.cpython-313.pyc, Lib/zoneinfo/__pycache__/_tzpath.cpython-313.pyc, Makefile, Makefile.pre, Misc/python-config.sh, Misc/python-embed.pc, Misc/python.pc, Modules/Setup.bootstrap, Modules/Setup.local, Modules/Setup.stdlib, Modules/_abc.o, Modules/_asyncio.cpython-313-x86_64-linux-gnu.so, Modules/_asynciomodule.o, Modules/_bisect.cpython-313-x86_64-linux-gnu.so, Modules/_bisectmodule.o, Modules/_blake2.cpython-313-x86_64-linux-gnu.so, Modules/_blake2/blake2b_impl.o, Modules/_blake2/blake2mo

[truncated 27774 bytes]

## Plan Pass

## Problem
Fixer observed high CPU in a Python 3.13 process running unattended-upgrade, with repeated `newfstatat` calls against APT list files. The evidence points to `apt_pkg.cpython-313-x86_64-linux-gnu.so` and `libapt-pkg.so.7.0.0`; the CPython frame `_PyObject_MakeTpCall` is ordinary C-extension dispatch, not a demonstrated interpreter loop.

## Evidence Confidence
inferred

## Proposed Subject
No CPython source patch in this pass. The maintainer-facing subject should be a diagnosis/reassignment: the collected signal implicates `python3-apt`/`libapt-pkg` or unattended-upgrades’ use of APT cache APIs, not a confirmed `python3.13` runtime defect.

## Patch Plan
- Do not edit CPython until an independent reproducer shows Python runtime code causing the busy loop.
- Treat `/usr/bin/unattended-upgrade` as the entrypoint evidence and `apt_pkg`/`libapt-pkg` as the first investigation target; only return to CPython if profiling shows the interpreter itself spinning outside extension code.
- No prior Fixer patch exists to improve or replace; the workspace is at `Fixer baseline`.
- CPython conventions found: `README.rst` points contributors to the Developer Guide and the normal `./configure`, `make`, `make test` flow. Relevant local helpers include `_Py_read` in `Python/fileutils.c`, `path_t`/`PyUnicode_FSConverter`, and `HAVE_FSTATAT_RUNTIME` handling in `Modules/posixmodule.c`, but none is on the observed hot path from the evidence bundle.
- Avoid awkward control flow such as adding CPython-level guards around extension calls; that would mask extension behavior and would not address the observed repeated APT file probing.

## Risks
The main risk is misattribution: patching CPython based only on a profiler sample that names `/usr/bin/python3.13` would create an upstream-unfriendly workaround. A valid patch likely belongs in `python-apt`, `libapt-pkg`, or unattended-upgrades after reducing the repeated APT list probing to a small reproducer.

## Validation
From the workspace root, first try the project entrypoint `./configure && make` if a CPython edit becomes justified. If that fails due missing dependencies/generated files, record the exact failure and then run the narrowest relevant compile/test.

Bounded independent signal check: run a read-only APT-cache smoke under syscall counting, for example `timeout 30s strace -f -c -e newfstatat python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'`. This can collect whether `apt_pkg` alone produces the repeated `newfstatat` pattern without claiming the unattended-upgrade runaway is reproduced.

## Patch Pass

Subject: Diagnose apt_pkg CPU evidence outside CPython

## Commit Message
No CPython source change is proposed. The collected perf, strace, and `/proc` evidence points to APT cache work in `python3-apt`/`libapt-pkg`, not to a CPython runtime loop.

I followed the saved plan and did not change course.

## Evidence Confidence
inferred

## Issue Connection
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` consuming CPU under `/usr/bin/python3.13`. The trace showed 87,511 `newfstatat` calls in 5 seconds against `/var/lib/apt/lists/*`, while perf attributed the hottest native path to `apt_pkg.cpython-313-x86_64-linux-gnu.so` and `libapt-pkg.so.7.0.0` symbols such as `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()`.

The cautious code-level inference is that unattended-upgrade is driving repeated APT package-cache probing through the `python3-apt` extension. The CPython frame in the backtrace, `_PyObject_MakeTpCall`, is the normal C-extension call path; it does not own the APT file probing. The GLib `gmain`/`gdbus` threads were blocked in poll-family calls and do not identify a CPython busy loop either.

I made no source change because the evidence is profiler/strace-based and does not show a CPython defect. CPython local conventions/helpers checked include `README.rst` for the upstream build/test flow, `_Py_read()` in `Python/fileutils.c`, and `path_t`/`PyUnicode_FSConverter`/`HAVE_FSTATAT_RUNTIME` in `Modules/posixmodule.c`; those helpers are not on the observed `apt_pkg`/`libapt-pkg` hot path. The expected effect of this no-patch diagnosis is to avoid landing an upstream-unfriendly CPython workaround and to direct the report toward `python3-apt`, `libapt-pkg`, or unattended-upgrades with the APT-cache syscall evidence.

## Git Add Paths
None

## Validation
`./configure && make` from the workspace root: passed. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the interpreter and checked modules built successfully.

Independent reproduction attempt: `timeout 30s strace -f -c -e newfstatat python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'` could not run because ptrace is blocked: `PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 5): Operation not permitted`.

Fallback smoke: `timeout 30s python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache(); print("apt_pkg cache smoke completed")'` completed normally, so the runaway CPU/syscall pattern was not independently reproduced.

## Review Pass 1 (local metadata check)

RESULT: fix-needed

## Findings
1. Patch metadata drift: the workspace currently changes `Lib/__pycache__/__future__.cpython-313.pyc`, `Lib/__pycache__/_collections_abc.cpython-313.pyc`, `Lib/__pycache__/_colorize.cpython-313.pyc`, `Lib/__pycache__/_compat_pickle.cpython-313.pyc`, `Lib/__pycache__/_compression.cpython-313.pyc`, `Lib/__pycache__/_opcode_metadata.cpython-313.pyc`, `Lib/__pycache__/_sitebuiltins.cpython-313.pyc`, `Lib/__pycache__/_weakrefset.cpython-313.pyc`, `Lib/__pycache__/abc.cpython-313.pyc`, `Lib/__pycache__/argparse.cpython-313.pyc`, `Lib/__pycache__/ast.cpython-313.pyc`, `Lib/__pycache__/base64.cpython-313.pyc`, `Lib/__pycache__/bz2.cpython-313.pyc`, `Lib/__pycache__/codecs.cpython-313.pyc`, `Lib/__pycache__/contextlib.cpython-313.pyc`, `Lib/__pycache__/contextvars.cpython-313.pyc`, `Lib/__pycache__/copy.cpython-313.pyc`, `Lib/__pycache__/copyreg.cpython-313.pyc`, `Lib/__pycache__/datetime.cpython-313.pyc`, `Lib/__pycache__/dis.cpython-313.pyc`, `Lib/__pycache__/enum.cpython-313.pyc`, `Lib/__pycache__/fnmatch.cpython-313.pyc`, `Lib/__pycache__/functools.cpython-313.pyc`, `Lib/__pycache__/genericpath.cpython-313.pyc`, `Lib/__pycache__/gettext.cpython-313.pyc`, `Lib/__pycache__/glob.cpython-313.pyc`, `Lib/__pycache__/heapq.cpython-313.pyc`, `Lib/__pycache__/inspect.cpython-313.pyc`, `Lib/__pycache__/io.cpython-313.pyc`, `Lib/__pycache__/keyword.cpython-313.pyc`, `Lib/__pycache__/linecache.cpython-313.pyc`, `Lib/__pycache__/locale.cpython-313.pyc`, `Lib/__pycache__/lzma.cpython-313.pyc`, `Lib/__pycache__/numbers.cpython-313.pyc`, `Lib/__pycache__/opcode.cpython-313.pyc`, `Lib/__pycache__/operator.cpython-313.pyc`, `Lib/__pycache__/os.cpython-313.pyc`, `Lib/__pycache__/posixpath.cpython-313.pyc`, `Lib/__pycache__/reprlib.cpython-313.pyc`, `Lib/__pycache__/selectors.cpython-313.pyc`, `Lib/__pycache__/shutil.cpython-313.pyc`, `Lib/__pycache__/signal.cpython-313.pyc`, `Lib/__pycache__/site.cpython-313.pyc`, `Lib/__pycache__/socket.cpython-313.pyc`, `Lib/__pycache__/ssl.cpython-313.pyc`, `Lib/__pycache__/stat.cpython-313.pyc`, `Lib/__pycache__/string.cpython-313.pyc`, `Lib/__pycache__/struct.cpython-313.pyc`, `Lib/__pycache__/subprocess.cpython-313.pyc`, `Lib/__pycache__/textwrap.cpython-313.pyc`, `Lib/__pycache__/threading.cpython-313.pyc`, `Lib/__pycache__/token.cpython-313.pyc`, `Lib/__pycache__/tokenize.cpython-313.pyc`, `Lib/__pycache__/traceback.cpython-313.pyc`, `Lib/__pycache__/types.cpython-313.pyc`, `Lib/__pycache__/typing.cpython-313.pyc`, `Lib/__pycache__/warnings.cpython-313.pyc`, `Lib/__pycache__/weakref.cpython-313.pyc`, `Lib/asyncio/__pycache__/__init__.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/constants.cpython-313.pyc`, `Lib/asyncio/__pycache__/coroutines.cpython-313.pyc`, `Lib/asyncio/__pycache__/events.cpython-313.pyc`, `Lib/asyncio/__pycache__/exceptions.cpython-313.pyc`, `Lib/asyncio/__pycache__/format_helpers.cpython-313.pyc`, `Lib/asyncio/__pycache__/futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/locks.cpython-313.pyc`, `Lib/asyncio/__pycache__/log.cpython-313.pyc`, `Lib/asyncio/__pycache__/mixins.cpython-313.pyc`, `Lib/asyncio/__pycache__/protocols.cpython-313.pyc`, `Lib/asyncio/__pycache__/queues.cpython-313.pyc`, `Lib/asyncio/__pycache__/runners.cpython-313.pyc`, `Lib/asyncio/__pycache__/selector_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/sslproto.cpython-313.pyc`, `Lib/asyncio/__pycache__/staggered.cpython-313.pyc`, `Lib/asyncio/__pycache__/streams.cpython-313.pyc`, `Lib/asyncio/__pycache__/subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/taskgroups.cpython-313.pyc`, `Lib/asyncio/__pycache__/tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/threads.cpython-313.pyc`, `Lib/asyncio/__pycache__/timeouts.cpython-313.pyc`, `Lib/asyncio/__pycache__/transports.cpython-313.pyc`, `Lib/asyncio/__pycache__/trsock.cpython-313.pyc`, `Lib/asyncio/__pycache__/unix_events.cpython-313.pyc`, `Lib/collections/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/_base.cpython-313.pyc`, `Lib/encodings/__pycache__/__init__.cpython-313.pyc`, `Lib/encodings/__pycache__/aliases.cpython-313.pyc`, `Lib/encodings/__pycache__/ascii.cpython-313.pyc`, `Lib/encodings/__pycache__/utf_8.cpython-313.pyc`, `Lib/importlib/__pycache__/__init__.cpython-313.pyc`, `Lib/importlib/__pycache__/_abc.cpython-313.pyc`, `Lib/logging/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/_abc.cpython-313.pyc`, `Lib/pathlib/__pycache__/_local.cpython-313.pyc`, `Lib/re/__pycache__/__init__.cpython-313.pyc`, `Lib/re/__pycache__/_casefix.cpython-313.pyc`, `Lib/re/__pycache__/_compiler.cpython-313.pyc`, `Lib/re/__pycache__/_constants.cpython-313.pyc`, `Lib/re/__pycache__/_parser.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__init__.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__main__.cpython-313.pyc`, `Lib/xml/__pycache__/__init__.cpython-313.pyc`, `Lib/xml/etree/__pycache__/ElementPath.cpython-313.pyc`, `Lib/xml/etree/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_common.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_tzpath.cpython-313.pyc`, `Makefile`, `Makefile.pre`, `Misc/python-config.sh`, `Misc/python-embed.pc`, `Misc/python.pc`, `Modules/Setup.bootstrap`, `Modules/Setup.local`, `Modules/Setup.stdlib`, `Modules/_abc.o`, `Modules/_asyncio.cpython-313-x86_64-linux-gnu.so`, `Modules/_asynciomodule.o`, `Modules/_bisect.cpython-313-x86_64-linux-gnu.so`, `Modules/_bisectmodule.o`, `Modules/_blake2.cpython-313-x86_64-linux-gnu.so`, `Modules/_blake2/blake2b_impl.o`, `Modules/_blake2/blake2module.o`, `Modules/_blake2/blake2s_impl.o`, `Modules/_bz2.cpython-313-x86_64-linux-gnu.so`, `Modules/_bz2module.o`, `Modules/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecsmodule.o`, `Modules/_collectionsmodule.o`, `Modules/_contextvars.cpython-313-x86_64-linux-gnu.so`, `Modules/_contextvarsmodule.o`, `Modules/_csv.cpython-313-x86_64-linux-gnu.so`, `Modules/_csv.o`, `Modules/_ctypes.cpython-313-x86_64-linux-gnu.so`, `Modules/_ctypes/_ctypes.o`, `Modules/_ctypes/_ctypes_test.o`, `Modules/_ctypes/callbacks.o`, `Modules/_ctypes/callproc.o`, `Modules/_ctypes/cfield.o`, `Modules/_ctypes/stgdict.o`, `Modules/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.o`, `Modules/_cursesmodule.o`, `Modules/_datetime.cpython-313-x86_64-linux-gnu.so`, `Modules/_datetimemodule.o`, `Modules/_decimal.cpython-313-x86_64-linux-gnu.so`, `Modules/_decimal/_decimal.o`, `Modules/_decimal/libmpdec/basearith.o`, `Modules/_decimal/libmpdec/constants.o`, `Modules/_decimal/libmpdec/context.o`, `Modules/_decimal/libmpdec/convolute.o`, `Modules/_decimal/libmpdec/crt.o`, `Modules/_decimal/libmpdec/difradix2.o`, `Modules/_decimal/libmpdec/fnt.o`, `Modules/_decimal/libmpdec/fourstep.o`, `Modules/_decimal/libmpdec/io.o`, `Modules/_decimal/libmpdec/libmpdec.a`, `Modules/_decimal/libmpdec/mpalloc.o`, `Modules/_decimal/libmpdec/mpdecimal.o`, `Modules/_decimal/libmpdec/numbertheory.o`, `Modules/_decimal/libmpdec/sixstep.o`, `Modules/_decimal/libmpdec/transpose.o`, `Modules/_elementtree.cpython-313-x86_64-linux-gnu.so`, `Modules/_elementtree.o`, `Modules/_functoolsmodule.o`, `Modules/_hacl/Hacl_Hash_MD5.o`, `Modules/_hacl/Hacl_Hash_SHA1.o`, `Modules/_hacl/Hacl_Hash_SHA2.o`, `Modules/_hacl/Hacl_Hash_SHA3.o`, `Modules/_hacl/libHacl_Hash_SHA2.a`, `Modules/_hashlib.cpython-313-x86_64-linux-gnu.so`, `Modules/_hashopenssl.o`, `Modules/_heapq.cpython-313-x86_64-linux-gnu.so`, `Modules/_heapqmodule.o`, `Modules/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpchannelsmodule.o`, `Modules/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpqueuesmodule.o`, `Modules/_interpreters.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpretersmodule.o`, `Modules/_io/_iomodule.o`, `Modules/_io/bufferedio.o`, `Modules/_io/bytesio.o`, `Modules/_io/fileio.o`, `Modules/_io/iobase.o`, `Modules/_io/stringio.o`, `Modules/_io/textio.o`, `Modules/_json.cpython-313-x86_64-linux-gnu.so`, `Modules/_json.o`, `Modules/_localemodule.o`, `Modules/_lsprof.cpython-313-x86_64-linux-gnu.so`, `Modules/_lsprof.o`, `Modules/_lzma.cpython-313-x86_64-linux-gnu.so`, `Modules/_lzmamodule.o`, `Modules/_md5.cpython-313-x86_64-linux-gnu.so`, `Modules/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing/multiprocessing.o`, `Modules/_multiprocessing/posixshmem.o`, `Modules/_multiprocessing/semaphore.o`, `Modules/_opcode.cpython-313-x86_64-linux-gnu.so`, `Modules/_opcode.o`, `Modules/_operator.o`, `Modules/_pickle.cpython-313-x86_64-linux-gnu.so`, `Modules/_pickle.o`, `Modules/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.o`, `Modules/_queue.cpython-313-x86_64-linux-gnu.so`, `Modules/_queuemodule.o`, `Modules/_random.cpython-313-x86_64-linux-gnu.so`, `Modules/_randommodule.o`, `Modules/_sha1.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha2.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha3.cpython-313-x86_64-linux-gnu.so`, `Modules/_socket.cpython-313-x86_64-linux-gnu.so`, `Modules/_sqlite/blob.o`, `Modules/_sqlite/connection.o`, `Modules/_sqlite/cursor.o`, `Modules/_sqlite/microprotocols.o`, `Modules/_sqlite/module.o`, `Modules/_sqlite/prepare_protocol.o`, `Modules/_sqlite/row.o`, `Modules/_sqlite/statement.o`, `Modules/_sqlite/util.o`, `Modules/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `Modules/_sre/sre.o`, `Modules/_ssl.cpython-313-x86_64-linux-gnu.so`, `Modules/_ssl.o`, `Modules/_stat.o`, `Modules/_statistics.cpython-313-x86_64-linux-gnu.so`, `Modules/_statisticsmodule.o`, `Modules/_struct.cpython-313-x86_64-linux-gnu.so`, `Modules/_struct.o`, `Modules/_suggestions.o`, `Modules/_sysconfig.o`, `Modules/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `Modules/_testbuffer.o`, `Modules/_testcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testcapi/abstract.o`, `Modules/_testcapi/buffer.o`, `Modules/_testcapi/bytes.o`, `Modules/_testcapi/code.o`, `Modules/_testcapi/codec.o`, `Modules/_testcapi/complex.o`, `Modules/_testcapi/datetime.o`, `Modules/_testcapi/dict.o`, `Modules/_testcapi/docstring.o`, `Modules/_testcapi/exceptions.o`, `Modules/_testcapi/file.o`, `Modules/_testcapi/float.o`, `Modules/_testcapi/gc.o`, `Modules/_testcapi/getargs.o`, `Modules/_testcapi/hash.o`, `Modules/_testcapi/heaptype.o`, `Modules/_testcapi/immortal.o`, `Modules/_testcapi/list.o`, `Modules/_testcapi/long.o`, `Modules/_testcapi/mem.o`, `Modules/_testcapi/monitoring.o`, `Modules/_testcapi/numbers.o`, `Modules/_testcapi/object.o`, `Modules/_testcapi/pyatomic.o`, `Modules/_testcapi/run.o`, `Modules/_testcapi/set.o`, `Modules/_testcapi/structmember.o`, `Modules/_testcapi/time.o`, `Modules/_testcapi/tuple.o`, `Modules/_testcapi/unicode.o`, `Modules/_testcapi/vectorcall.o`, `Modules/_testcapi/watchers.o`, `Modules/_testcapimodule.o`, `Modules/_testclinic.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic.o`, `Modules/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic_limited.o`, `Modules/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `Modules/_testexternalinspection.o`, `Modules/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `Modules/_testimportmultiple.o`, `Modules/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testinternalcapi.o`, `Modules/_testinternalcapi/pytime.o`, `Modules/_testinternalcapi/set.o`, `Modules/_testinternalcapi/test_critical_sections.o`, `Modules/_testinternalcapi/test_lock.o`, `Modules/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testlimitedcapi.o`, `Modules/_testlimitedcapi/abstract.o`, `Modules/_testlimitedcapi/bytearray.o`, `Modules/_testlimitedcapi/bytes.o`, `Modules/_testlimitedcapi/complex.o`, `Modules/_testlimitedcapi/dict.o`, `Modules/_testlimitedcapi/eval.o`, `Modules/_testlimitedcapi/file.o`, `Modules/_testlimitedcapi/float.o`, `Modules/_testlimitedcapi/heaptype_relative.o`, `Modules/_testlimitedcapi/import.o`, `Modules/_testlimitedcapi/list.o`, `Modules/_testlimitedcapi/long.o`, `Modules/_testlimitedcapi/object.o`, `Modules/_testlimitedcapi/pyos.o`, `Modules/_testlimitedcapi/set.o`, `Modules/_testlimitedcapi/sys.o`, `Modules/_testlimitedcapi/tuple.o`, `Modules/_testlimitedcapi/unicode.o`, `Modules/_testlimitedcapi/vectorcall_limited.o`, `Modules/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testmultiphase.o`, `Modules/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testsinglephase.o`, `Modules/_threadmodule.o`, `Modules/_tracemalloc.o`, `Modules/_typingmodule.o`, `Modules/_uuid.cpython-313-x86_64-linux-gnu.so`, `Modules/_uuidmodule.o`, `Modules/_weakref.o`, `Modules/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `Modules/_xxtestfuzz/_xxtestfuzz.o`, `Modules/_xxtestfuzz/fuzzer.o`, `Modules/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `Modules/_zoneinfo.o`, `Modules/array.cpython-313-x86_64-linux-gnu.so`, `Modules/arraymodule.o`, `Modules/atexitmodule.o`, `Modules/binascii.cpython-313-x86_64-linux-gnu.so`, `Modules/binascii.o`, `Modules/cjkcodecs/_codecs_cn.o`, `Modules/cjkcodecs/_codecs_hk.o`, `Modules/cjkcodecs/_codecs_iso2022.o`, `Modules/cjkcodecs/_codecs_jp.o`, `Modules/cjkcodecs/_codecs_kr.o`, `Modules/cjkcodecs/_codecs_tw.o`, `Modules/cjkcodecs/multibytecodec.o`, `Modules/cmath.cpython-313-x86_64-linux-gnu.so`, `Modules/cmathmodule.o`, `Modules/config.c`, `Modules/config.o`, `Modules/errnomodule.o`, `Modules/expat/libexpat.a`, `Modules/expat/xmlparse.o`, `Modules/expat/xmlrole.o`, `Modules/expat/xmltok.o`, `Modules/faulthandler.o`, `Modules/fcntl.cpython-313-x86_64-linux-gnu.so`, `Modules/fcntlmodule.o`, `Modules/gcmodule.o`, `Modules/getbuildinfo.o`, `Modules/getpath.o`, `Modules/getpath_noop.o`, `Modules/grp.cpython-313-x86_64-linux-gnu.so`, `Modules/grpmodule.o`, `Modules/itertoolsmodule.o`, `Modules/ld_so_aix`, `Modules/main.o`, `Modules/math.cpython-313-x86_64-linux-gnu.so`, `Modules/mathmodule.o`, `Modules/md5module.o`, `Modules/mmap.cpython-313-x86_64-linux-gnu.so`, `Modules/mmapmodule.o`, `Modules/posixmodule.o`, `Modules/pwdmodule.o`, `Modules/pyexpat.cpython-313-x86_64-linux-gnu.so`, `Modules/pyexpat.o`, `Modules/readline.cpython-313-x86_64-linux-gnu.so`, `Modules/readline.o`, `Modules/resource.cpython-313-x86_64-linux-gnu.so`, `Modules/resource.o`, `Modules/rotatingtree.o`, `Modules/select.cpython-313-x86_64-linux-gnu.so`, `Modules/selectmodule.o`, `Modules/sha1module.o`, `Modules/sha2module.o`, `Modules/sha3module.o`, `Modules/signalmodule.o`, `Modules/socketmodule.o`, `Modules/symtablemodule.o`, `Modules/syslog.cpython-313-x86_64-linux-gnu.so`, `Modules/syslogmodule.o`, `Modules/termios.cpython-313-x86_64-linux-gnu.so`, `Modules/termios.o`, `Modules/timemodule.o`, `Modules/unicodedata.cpython-313-x86_64-linux-gnu.so`, `Modules/unicodedata.o`, `Modules/xxlimited.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited.o`, `Modules/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited_35.o`, `Modules/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `Modules/xxsubtype.o`, `Modules/zlib.cpython-313-x86_64-linux-gnu.so`, `Modules/zlibmodule.o`, `Objects/abstract.o`, `Objects/boolobject.o`, `Objects/bytearrayobject.o`, `Objects/bytes_methods.o`, `Objects/bytesobject.o`, `Objects/call.o`, `Objects/capsule.o`, `Objects/cellobject.o`, `Objects/classobject.o`, `Objects/codeobject.o`, `Objects/complexobject.o`, `Objects/descrobject.o`, `Objects/dictobject.o`, `Objects/enumobject.o`, `Objects/exceptions.o`, `Objects/fileobject.o`, `Objects/floatobject.o`, `Objects/frameobject.o`, `Objects/funcobject.o`, `Objects/genericaliasobject.o`, `Objects/genobject.o`, `Objects/iterobject.o`, `Objects/listobject.o`, `Objects/longobject.o`, `Objects/memoryobject.o`, `Objects/methodobject.o`, `Objects/moduleobject.o`, `Objects/namespaceobject.o`, `Objects/object.o`, `Objects/obmalloc.o`, `Objects/odictobject.o`, `Objects/picklebufobject.o`, `Objects/rangeobject.o`, `Objects/setobject.o`, `Objects/sliceobject.o`, `Objects/structseq.o`, `Objects/tupleobject.o`, `Objects/typeobject.o`, `Objects/typevarobject.o`, `Objects/unicodectype.o`, `Objects/unicodeobject.o`, `Objects/unionobject.o`, `Objects/weakrefobject.o`, `Parser/action_helpers.o`, `Parser/lexer/buffer.o`, `Parser/lexer/lexer.o`, `Parser/lexer/state.o`, `Parser/myreadline.o`, `Parser/parser.o`, `Parser/peg_api.o`, `Parser/pegen.o`, `Parser/pegen_errors.o`, `Parser/string_parser.o`, `Parser/token.o`, `Parser/tokenizer/file_tokenizer.o`, `Parser/tokenizer/helpers.o`, `Parser/tokenizer/readline_tokenizer.o`, `Parser/tokenizer/string_tokenizer.o`, `Parser/tokenizer/utf8_tokenizer.o`, `Programs/_bootstrap_python.o`, `Programs/_freeze_module`, `Programs/_freeze_module.o`, `Programs/_testembed`, `Programs/_testembed.o`, `Programs/python.o`, `Python/Python-ast.o`, `Python/Python-tokenize.o`, `Python/_warnings.o`, `Python/asdl.o`, `Python/asm_trampoline.o`, `Python/assemble.o`, `Python/ast.o`, `Python/ast_opt.o`, `Python/ast_unparse.o`, `Python/bltinmodule.o`, `Python/bootstrap_hash.o`, `Python/brc.o`, `Python/ceval.o`, `Python/ceval_gil.o`, `Python/codecs.o`, `Python/compile.o`, `Python/context.o`, `Python/critical_section.o`, `Python/crossinterp.o`, `Python/dtoa.o`, `Python/dynamic_annotations.o`, `Python/dynload_shlib.o`, `Python/errors.o`, `Python/fileutils.o`, `Python/flowgraph.o`, `Python/formatter_unicode.o`, `Python/frame.o`, `Python/frozen.o`, `Python/frozen_modules/__hello__.h`, `Python/frozen_modules/__phello__.h`, `Python/frozen_modules/__phello__.ham.eggs.h`, `Python/frozen_modules/__phello__.ham.h`, `Python/frozen_modules/__phello__.spam.h`, `Python/frozen_modules/_collections_abc.h`, `Python/frozen_modules/_sitebuiltins.h`, `Python/frozen_modules/abc.h`, `Python/frozen_modules/codecs.h`, `Python/frozen_modules/frozen_only.h`, `Python/frozen_modules/genericpath.h`, `Python/frozen_modules/getpath.h`, `Python/frozen_modules/importlib._bootstrap.h`, `Python/frozen_modules/importlib._bootstrap_external.h`, `Python/frozen_modules/importlib.machinery.h`, `Python/frozen_modules/importlib.util.h`, `Python/frozen_modules/io.h`, `Python/frozen_modules/ntpath.h`, `Python/frozen_modules/os.h`, `Python/frozen_modules/posixpath.h`, `Python/frozen_modules/runpy.h`, `Python/frozen_modules/site.h`, `Python/frozen_modules/stat.h`, `Python/frozen_modules/zipimport.h`, `Python/frozenmain.o`, `Python/future.o`, `Python/gc.o`, `Python/gc_free_threading.o`, `Python/gc_gil.o`, `Python/getargs.o`, `Python/getcompiler.o`, `Python/getcopyright.o`, `Python/getopt.o`, `Python/getplatform.o`, `Python/getversion.o`, `Python/hamt.o`, `Python/hashtable.o`, `Python/import.o`, `Python/importdl.o`, `Python/initconfig.o`, `Python/instruction_sequence.o`, `Python/instrumentation.o`, `Python/interpconfig.o`, `Python/intrinsics.o`, `Python/jit.o`, `Python/legacy_tracing.o`, `Python/lock.o`, `Python/marshal.o`, `Python/modsupport.o`, `Python/mysnprintf.o`, `Python/mystrtoul.o`, `Python/object_stack.o`, `Python/optimizer.o`, `Python/optimizer_analysis.o`, `Python/optimizer_symbols.o`, `Python/parking_lot.o`, `Python/pathconfig.o`, `Python/perf_jit_trampoline.o`, `Python/perf_trampoline.o`, `Python/preconfig.o`, `Python/pyarena.o`, `Python/pyctype.o`, `Python/pyfpe.o`, `Python/pyhash.o`, `Python/pylifecycle.o`, `Python/pymath.o`, `Python/pystate.o`, `Python/pystrcmp.o`, `Python/pystrhex.o`, `Python/pystrtod.o`, `Python/pythonrun.o`, `Python/pytime.o`, `Python/qsbr.o`, `Python/specialize.o`, `Python/structmember.o`, `Python/suggestions.o`, `Python/symtable.o`, `Python/sysmodule.o`, `Python/thread.o`, `Python/traceback.o`, `Python/tracemalloc.o`, `_bootstrap_python`, `build/lib.linux-x86_64-3.13/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-313.pyc`, `build/lib.linux-x86_64-3.13/_asyncio.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bisect.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_blake2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bz2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_contextvars.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_csv.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_datetime.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_decimal.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_elementtree.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_hashlib.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_heapq.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpreters.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_json.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lsprof.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lzma.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_md5.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_opcode.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_pickle.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_queue.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_random.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha1.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_socket.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ssl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_statistics.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_struct.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sysconfigdata__linux_x86_64-linux-gnu.py`, `build/lib.linux-x86_64-3.13/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_uuid.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/array.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/binascii.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/cmath.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/fcntl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/grp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/math.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/mmap.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/pyexpat.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/readline.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/resource.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/select.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/syslog.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/termios.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/unicodedata.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/zlib.cpython-313-x86_64-linux-gnu.so`, `build/scripts-3.13/idle3.13`, `build/scripts-3.13/pydoc3.13`, `config.log`, `config.status`, `libpython3.13.a`, `platform`, `pybuilddir.txt`, `pyconfig.h`, `python`, `python-config`, `python-config.py`, `python-gdb.py`, but `## Git Add Paths` lists `None`. Update `## Git Add Paths` to match the real shipped file set exactly, and make sure `## Issue Connection` explains every functional file that remains in the patch.
2. Missing from `## Git Add Paths`: `Lib/__pycache__/__future__.cpython-313.pyc`, `Lib/__pycache__/_collections_abc.cpython-313.pyc`, `Lib/__pycache__/_colorize.cpython-313.pyc`, `Lib/__pycache__/_compat_pickle.cpython-313.pyc`, `Lib/__pycache__/_compression.cpython-313.pyc`, `Lib/__pycache__/_opcode_metadata.cpython-313.pyc`, `Lib/__pycache__/_sitebuiltins.cpython-313.pyc`, `Lib/__pycache__/_weakrefset.cpython-313.pyc`, `Lib/__pycache__/abc.cpython-313.pyc`, `Lib/__pycache__/argparse.cpython-313.pyc`, `Lib/__pycache__/ast.cpython-313.pyc`, `Lib/__pycache__/base64.cpython-313.pyc`, `Lib/__pycache__/bz2.cpython-313.pyc`, `Lib/__pycache__/codecs.cpython-313.pyc`, `Lib/__pycache__/contextlib.cpython-313.pyc`, `Lib/__pycache__/contextvars.cpython-313.pyc`, `Lib/__pycache__/copy.cpython-313.pyc`, `Lib/__pycache__/copyreg.cpython-313.pyc`, `Lib/__pycache__/datetime.cpython-313.pyc`, `Lib/__pycache__/dis.cpython-313.pyc`, `Lib/__pycache__/enum.cpython-313.pyc`, `Lib/__pycache__/fnmatch.cpython-313.pyc`, `Lib/__pycache__/functools.cpython-313.pyc`, `Lib/__pycache__/genericpath.cpython-313.pyc`, `Lib/__pycache__/gettext.cpython-313.pyc`, `Lib/__pycache__/glob.cpython-313.pyc`, `Lib/__pycache__/heapq.cpython-313.pyc`, `Lib/__pycache__/inspect.cpython-313.pyc`, `Lib/__pycache__/io.cpython-313.pyc`, `Lib/__pycache__/keyword.cpython-313.pyc`, `Lib/__pycache__/linecache.cpython-313.pyc`, `Lib/__pycache__/locale.cpython-313.pyc`, `Lib/__pycache__/lzma.cpython-313.pyc`, `Lib/__pycache__/numbers.cpython-313.pyc`, `Lib/__pycache__/opcode.cpython-313.pyc`, `Lib/__pycache__/operator.cpython-313.pyc`, `Lib/__pycache__/os.cpython-313.pyc`, `Lib/__pycache__/posixpath.cpython-313.pyc`, `Lib/__pycache__/reprlib.cpython-313.pyc`, `Lib/__pycache__/selectors.cpython-313.pyc`, `Lib/__pycache__/shutil.cpython-313.pyc`, `Lib/__pycache__/signal.cpython-313.pyc`, `Lib/__pycache__/site.cpython-313.pyc`, `Lib/__pycache__/socket.cpython-313.pyc`, `Lib/__pycache__/ssl.cpython-313.pyc`, `Lib/__pycache__/stat.cpython-313.pyc`, `Lib/__pycache__/string.cpython-313.pyc`, `Lib/__pycache__/struct.cpython-313.pyc`, `Lib/__pycache__/subprocess.cpython-313.pyc`, `Lib/__pycache__/textwrap.cpython-313.pyc`, `Lib/__pycache__/threading.cpython-313.pyc`, `Lib/__pycache__/token.cpython-313.pyc`, `Lib/__pycache__/tokenize.cpython-313.pyc`, `Lib/__pycache__/traceback.cpython-313.pyc`, `Lib/__pycache__/types.cpython-313.pyc`, `Lib/__pycache__/typing.cpython-313.pyc`, `Lib/__pycache__/warnings.cpython-313.pyc`, `Lib/__pycache__/weakref.cpython-313.pyc`, `Lib/asyncio/__pycache__/__init__.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/constants.cpython-313.pyc`, `Lib/asyncio/__pycache__/coroutines.cpython-313.pyc`, `Lib/asyncio/__pycache__/events.cpython-313.pyc`, `Lib/asyncio/__pycache__/exceptions.cpython-313.pyc`, `Lib/asyncio/__pycache__/format_helpers.cpython-313.pyc`, `Lib/asyncio/__pycache__/futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/locks.cpython-313.pyc`, `Lib/asyncio/__pycache__/log.cpython-313.pyc`, `Lib/asyncio/__pycache__/mixins.cpython-313.pyc`, `Lib/asyncio/__pycache__/protocols.cpython-313.pyc`, `Lib/asyncio/__pycache__/queues.cpython-313.pyc`, `Lib/asyncio/__pycache__/runners.cpython-313.pyc`, `Lib/asyncio/__pycache__/selector_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/sslproto.cpython-313.pyc`, `Lib/asyncio/__pycache__/staggered.cpython-313.pyc`, `Lib/asyncio/__pycache__/streams.cpython-313.pyc`, `Lib/asyncio/__pycache__/subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/taskgroups.cpython-313.pyc`, `Lib/asyncio/__pycache__/tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/threads.cpython-313.pyc`, `Lib/asyncio/__pycache__/timeouts.cpython-313.pyc`, `Lib/asyncio/__pycache__/transports.cpython-313.pyc`, `Lib/asyncio/__pycache__/trsock.cpython-313.pyc`, `Lib/asyncio/__pycache__/unix_events.cpython-313.pyc`, `Lib/collections/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/_base.cpython-313.pyc`, `Lib/encodings/__pycache__/__init__.cpython-313.pyc`, `Lib/encodings/__pycache__/aliases.cpython-313.pyc`, `Lib/encodings/__pycache__/ascii.cpython-313.pyc`, `Lib/encodings/__pycache__/utf_8.cpython-313.pyc`, `Lib/importlib/__pycache__/__init__.cpython-313.pyc`, `Lib/importlib/__pycache__/_abc.cpython-313.pyc`, `Lib/logging/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/_abc.cpython-313.pyc`, `Lib/pathlib/__pycache__/_local.cpython-313.pyc`, `Lib/re/__pycache__/__init__.cpython-313.pyc`, `Lib/re/__pycache__/_casefix.cpython-313.pyc`, `Lib/re/__pycache__/_compiler.cpython-313.pyc`, `Lib/re/__pycache__/_constants.cpython-313.pyc`, `Lib/re/__pycache__/_parser.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__init__.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__main__.cpython-313.pyc`, `Lib/xml/__pycache__/__init__.cpython-313.pyc`, `Lib/xml/etree/__pycache__/ElementPath.cpython-313.pyc`, `Lib/xml/etree/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_common.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_tzpath.cpython-313.pyc`, `Makefile`, `Makefile.pre`, `Misc/python-config.sh`, `Misc/python-embed.pc`, `Misc/python.pc`, `Modules/Setup.bootstrap`, `Modules/Setup.local`, `Modules/Setup.stdlib`, `Modules/_abc.o`, `Modules/_asyncio.cpython-313-x86_64-linux-gnu.so`, `Modules/_asynciomodule.o`, `Modules/_bisect.cpython-313-x86_64-linux-gnu.so`, `Modules/_bisectmodule.o`, `Modules/_blake2.cpython-313-x86_64-linux-gnu.so`, `Modules/_blake2/blake2b_impl.o`, `Modules/_blake2/blake2module.o`, `Modules/_blake2/blake2s_impl.o`, `Modules/_bz2.cpython-313-x86_64-linux-gnu.so`, `Modules/_bz2module.o`, `Modules/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecsmodule.o`, `Modules/_collectionsmodule.o`, `Modules/_contextvars.cpython-313-x86_64-linux-gnu.so`, `Modules/_contextvarsmodule.o`, `Modules/_csv.cpython-313-x86_64-linux-gnu.so`, `Modules/_csv.o`, `Modules/_ctypes.cpython-313-x86_64-linux-gnu.so`, `Modules/_ctypes/_ctypes.o`, `Modules/_ctypes/_ctypes_test.o`, `Modules/_ctypes/callbacks.o`, `Modules/_ctypes/callproc.o`, `Modules/_ctypes/cfield.o`, `Modules/_ctypes/stgdict.o`, `Modules/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.o`, `Modules/_cursesmodule.o`, `Modules/_datetime.cpython-313-x86_64-linux-gnu.so`, `Modules/_datetimemodule.o`, `Modules/_decimal.cpython-313-x86_64-linux-gnu.so`, `Modules/_decimal/_decimal.o`, `Modules/_decimal/libmpdec/basearith.o`, `Modules/_decimal/libmpdec/constants.o`, `Modules/_decimal/libmpdec/context.o`, `Modules/_decimal/libmpdec/convolute.o`, `Modules/_decimal/libmpdec/crt.o`, `Modules/_decimal/libmpdec/difradix2.o`, `Modules/_decimal/libmpdec/fnt.o`, `Modules/_decimal/libmpdec/fourstep.o`, `Modules/_decimal/libmpdec/io.o`, `Modules/_decimal/libmpdec/libmpdec.a`, `Modules/_decimal/libmpdec/mpalloc.o`, `Modules/_decimal/libmpdec/mpdecimal.o`, `Modules/_decimal/libmpdec/numbertheory.o`, `Modules/_decimal/libmpdec/sixstep.o`, `Modules/_decimal/libmpdec/transpose.o`, `Modules/_elementtree.cpython-313-x86_64-linux-gnu.so`, `Modules/_elementtree.o`, `Modules/_functoolsmodule.o`, `Modules/_hacl/Hacl_Hash_MD5.o`, `Modules/_hacl/Hacl_Hash_SHA1.o`, `Modules/_hacl/Hacl_Hash_SHA2.o`, `Modules/_hacl/Hacl_Hash_SHA3.o`, `Modules/_hacl/libHacl_Hash_SHA2.a`, `Modules/_hashlib.cpython-313-x86_64-linux-gnu.so`, `Modules/_hashopenssl.o`, `Modules/_heapq.cpython-313-x86_64-linux-gnu.so`, `Modules/_heapqmodule.o`, `Modules/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpchannelsmodule.o`, `Modules/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpqueuesmodule.o`, `Modules/_interpreters.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpretersmodule.o`, `Modules/_io/_iomodule.o`, `Modules/_io/bufferedio.o`, `Modules/_io/bytesio.o`, `Modules/_io/fileio.o`, `Modules/_io/iobase.o`, `Modules/_io/stringio.o`, `Modules/_io/textio.o`, `Modules/_json.cpython-313-x86_64-linux-gnu.so`, `Modules/_json.o`, `Modules/_localemodule.o`, `Modules/_lsprof.cpython-313-x86_64-linux-gnu.so`, `Modules/_lsprof.o`, `Modules/_lzma.cpython-313-x86_64-linux-gnu.so`, `Modules/_lzmamodule.o`, `Modules/_md5.cpython-313-x86_64-linux-gnu.so`, `Modules/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing/multiprocessing.o`, `Modules/_multiprocessing/posixshmem.o`, `Modules/_multiprocessing/semaphore.o`, `Modules/_opcode.cpython-313-x86_64-linux-gnu.so`, `Modules/_opcode.o`, `Modules/_operator.o`, `Modules/_pickle.cpython-313-x86_64-linux-gnu.so`, `Modules/_pickle.o`, `Modules/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.o`, `Modules/_queue.cpython-313-x86_64-linux-gnu.so`, `Modules/_queuemodule.o`, `Modules/_random.cpython-313-x86_64-linux-gnu.so`, `Modules/_randommodule.o`, `Modules/_sha1.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha2.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha3.cpython-313-x86_64-linux-gnu.so`, `Modules/_socket.cpython-313-x86_64-linux-gnu.so`, `Modules/_sqlite/blob.o`, `Modules/_sqlite/connection.o`, `Modules/_sqlite/cursor.o`, `Modules/_sqlite/microprotocols.o`, `Modules/_sqlite/module.o`, `Modules/_sqlite/prepare_protocol.o`, `Modules/_sqlite/row.o`, `Modules/_sqlite/statement.o`, `Modules/_sqlite/util.o`, `Modules/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `Modules/_sre/sre.o`, `Modules/_ssl.cpython-313-x86_64-linux-gnu.so`, `Modules/_ssl.o`, `Modules/_stat.o`, `Modules/_statistics.cpython-313-x86_64-linux-gnu.so`, `Modules/_statisticsmodule.o`, `Modules/_struct.cpython-313-x86_64-linux-gnu.so`, `Modules/_struct.o`, `Modules/_suggestions.o`, `Modules/_sysconfig.o`, `Modules/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `Modules/_testbuffer.o`, `Modules/_testcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testcapi/abstract.o`, `Modules/_testcapi/buffer.o`, `Modules/_testcapi/bytes.o`, `Modules/_testcapi/code.o`, `Modules/_testcapi/codec.o`, `Modules/_testcapi/complex.o`, `Modules/_testcapi/datetime.o`, `Modules/_testcapi/dict.o`, `Modules/_testcapi/docstring.o`, `Modules/_testcapi/exceptions.o`, `Modules/_testcapi/file.o`, `Modules/_testcapi/float.o`, `Modules/_testcapi/gc.o`, `Modules/_testcapi/getargs.o`, `Modules/_testcapi/hash.o`, `Modules/_testcapi/heaptype.o`, `Modules/_testcapi/immortal.o`, `Modules/_testcapi/list.o`, `Modules/_testcapi/long.o`, `Modules/_testcapi/mem.o`, `Modules/_testcapi/monitoring.o`, `Modules/_testcapi/numbers.o`, `Modules/_testcapi/object.o`, `Modules/_testcapi/pyatomic.o`, `Modules/_testcapi/run.o`, `Modules/_testcapi/set.o`, `Modules/_testcapi/structmember.o`, `Modules/_testcapi/time.o`, `Modules/_testcapi/tuple.o`, `Modules/_testcapi/unicode.o`, `Modules/_testcapi/vectorcall.o`, `Modules/_testcapi/watchers.o`, `Modules/_testcapimodule.o`, `Modules/_testclinic.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic.o`, `Modules/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic_limited.o`, `Modules/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `Modules/_testexternalinspection.o`, `Modules/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `Modules/_testimportmultiple.o`, `Modules/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testinternalcapi.o`, `Modules/_testinternalcapi/pytime.o`, `Modules/_testinternalcapi/set.o`, `Modules/_testinternalcapi/test_critical_sections.o`, `Modules/_testinternalcapi/test_lock.o`, `Modules/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testlimitedcapi.o`, `Modules/_testlimitedcapi/abstract.o`, `Modules/_testlimitedcapi/bytearray.o`, `Modules/_testlimitedcapi/bytes.o`, `Modules/_testlimitedcapi/complex.o`, `Modules/_testlimitedcapi/dict.o`, `Modules/_testlimitedcapi/eval.o`, `Modules/_testlimitedcapi/file.o`, `Modules/_testlimitedcapi/float.o`, `Modules/_testlimitedcapi/heaptype_relative.o`, `Modules/_testlimitedcapi/import.o`, `Modules/_testlimitedcapi/list.o`, `Modules/_testlimitedcapi/long.o`, `Modules/_testlimitedcapi/object.o`, `Modules/_testlimitedcapi/pyos.o`, `Modules/_testlimitedcapi/set.o`, `Modules/_testlimitedcapi/sys.o`, `Modules/_testlimitedcapi/tuple.o`, `Modules/_testlimitedcapi/unicode.o`, `Modules/_testlimitedcapi/vectorcall_limited.o`, `Modules/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testmultiphase.o`, `Modules/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testsinglephase.o`, `Modules/_threadmodule.o`, `Modules/_tracemalloc.o`, `Modules/_typingmodule.o`, `Modules/_uuid.cpython-313-x86_64-linux-gnu.so`, `Modules/_uuidmodule.o`, `Modules/_weakref.o`, `Modules/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `Modules/_xxtestfuzz/_xxtestfuzz.o`, `Modules/_xxtestfuzz/fuzzer.o`, `Modules/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `Modules/_zoneinfo.o`, `Modules/array.cpython-313-x86_64-linux-gnu.so`, `Modules/arraymodule.o`, `Modules/atexitmodule.o`, `Modules/binascii.cpython-313-x86_64-linux-gnu.so`, `Modules/binascii.o`, `Modules/cjkcodecs/_codecs_cn.o`, `Modules/cjkcodecs/_codecs_hk.o`, `Modules/cjkcodecs/_codecs_iso2022.o`, `Modules/cjkcodecs/_codecs_jp.o`, `Modules/cjkcodecs/_codecs_kr.o`, `Modules/cjkcodecs/_codecs_tw.o`, `Modules/cjkcodecs/multibytecodec.o`, `Modules/cmath.cpython-313-x86_64-linux-gnu.so`, `Modules/cmathmodule.o`, `Modules/config.c`, `Modules/config.o`, `Modules/errnomodule.o`, `Modules/expat/libexpat.a`, `Modules/expat/xmlparse.o`, `Modules/expat/xmlrole.o`, `Modules/expat/xmltok.o`, `Modules/faulthandler.o`, `Modules/fcntl.cpython-313-x86_64-linux-gnu.so`, `Modules/fcntlmodule.o`, `Modules/gcmodule.o`, `Modules/getbuildinfo.o`, `Modules/getpath.o`, `Modules/getpath_noop.o`, `Modules/grp.cpython-313-x86_64-linux-gnu.so`, `Modules/grpmodule.o`, `Modules/itertoolsmodule.o`, `Modules/ld_so_aix`, `Modules/main.o`, `Modules/math.cpython-313-x86_64-linux-gnu.so`, `Modules/mathmodule.o`, `Modules/md5module.o`, `Modules/mmap.cpython-313-x86_64-linux-gnu.so`, `Modules/mmapmodule.o`, `Modules/posixmodule.o`, `Modules/pwdmodule.o`, `Modules/pyexpat.cpython-313-x86_64-linux-gnu.so`, `Modules/pyexpat.o`, `Modules/readline.cpython-313-x86_64-linux-gnu.so`, `Modules/readline.o`, `Modules/resource.cpython-313-x86_64-linux-gnu.so`, `Modules/resource.o`, `Modules/rotatingtree.o`, `Modules/select.cpython-313-x86_64-linux-gnu.so`, `Modules/selectmodule.o`, `Modules/sha1module.o`, `Modules/sha2module.o`, `Modules/sha3module.o`, `Modules/signalmodule.o`, `Modules/socketmodule.o`, `Modules/symtablemodule.o`, `Modules/syslog.cpython-313-x86_64-linux-gnu.so`, `Modules/syslogmodule.o`, `Modules/termios.cpython-313-x86_64-linux-gnu.so`, `Modules/termios.o`, `Modules/timemodule.o`, `Modules/unicodedata.cpython-313-x86_64-linux-gnu.so`, `Modules/unicodedata.o`, `Modules/xxlimited.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited.o`, `Modules/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited_35.o`, `Modules/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `Modules/xxsubtype.o`, `Modules/zlib.cpython-313-x86_64-linux-gnu.so`, `Modules/zlibmodule.o`, `Objects/abstract.o`, `Objects/boolobject.o`, `Objects/bytearrayobject.o`, `Objects/bytes_methods.o`, `Objects/bytesobject.o`, `Objects/call.o`, `Objects/capsule.o`, `Objects/cellobject.o`, `Objects/classobject.o`, `Objects/codeobject.o`, `Objects/complexobject.o`, `Objects/descrobject.o`, `Objects/dictobject.o`, `Objects/enumobject.o`, `Objects/exceptions.o`, `Objects/fileobject.o`, `Objects/floatobject.o`, `Objects/frameobject.o`, `Objects/funcobject.o`, `Objects/genericaliasobject.o`, `Objects/genobject.o`, `Objects/iterobject.o`, `Objects/listobject.o`, `Objects/longobject.o`, `Objects/memoryobject.o`, `Objects/methodobject.o`, `Objects/moduleobject.o`, `Objects/namespaceobject.o`, `Objects/object.o`, `Objects/obmalloc.o`, `Objects/odictobject.o`, `Objects/picklebufobject.o`, `Objects/rangeobject.o`, `Objects/setobject.o`, `Objects/sliceobject.o`, `Objects/structseq.o`, `Objects/tupleobject.o`, `Objects/typeobject.o`, `Objects/typevarobject.o`, `Objects/unicodectype.o`, `Objects/unicodeobject.o`, `Objects/unionobject.o`, `Objects/weakrefobject.o`, `Parser/action_helpers.o`, `Parser/lexer/buffer.o`, `Parser/lexer/lexer.o`, `Parser/lexer/state.o`, `Parser/myreadline.o`, `Parser/parser.o`, `Parser/peg_api.o`, `Parser/pegen.o`, `Parser/pegen_errors.o`, `Parser/string_parser.o`, `Parser/token.o`, `Parser/tokenizer/file_tokenizer.o`, `Parser/tokenizer/helpers.o`, `Parser/tokenizer/readline_tokenizer.o`, `Parser/tokenizer/string_tokenizer.o`, `Parser/tokenizer/utf8_tokenizer.o`, `Programs/_bootstrap_python.o`, `Programs/_freeze_module`, `Programs/_freeze_module.o`, `Programs/_testembed`, `Programs/_testembed.o`, `Programs/python.o`, `Python/Python-ast.o`, `Python/Python-tokenize.o`, `Python/_warnings.o`, `Python/asdl.o`, `Python/asm_trampoline.o`, `Python/assemble.o`, `Python/ast.o`, `Python/ast_opt.o`, `Python/ast_unparse.o`, `Python/bltinmodule.o`, `Python/bootstrap_hash.o`, `Python/brc.o`, `Python/ceval.o`, `Python/ceval_gil.o`, `Python/codecs.o`, `Python/compile.o`, `Python/context.o`, `Python/critical_section.o`, `Python/crossinterp.o`, `Python/dtoa.o`, `Python/dynamic_annotations.o`, `Python/dynload_shlib.o`, `Python/errors.o`, `Python/fileutils.o`, `Python/flowgraph.o`, `Python/formatter_unicode.o`, `Python/frame.o`, `Python/frozen.o`, `Python/frozen_modules/__hello__.h`, `Python/frozen_modules/__phello__.h`, `Python/frozen_modules/__phello__.ham.eggs.h`, `Python/frozen_modules/__phello__.ham.h`, `Python/frozen_modules/__phello__.spam.h`, `Python/frozen_modules/_collections_abc.h`, `Python/frozen_modules/_sitebuiltins.h`, `Python/frozen_modules/abc.h`, `Python/frozen_modules/codecs.h`, `Python/frozen_modules/frozen_only.h`, `Python/frozen_modules/genericpath.h`, `Python/frozen_modules/getpath.h`, `Python/frozen_modules/importlib._bootstrap.h`, `Python/frozen_modules/importlib._bootstrap_external.h`, `Python/frozen_modules/importlib.machinery.h`, `Python/frozen_modules/importlib.util.h`, `Python/frozen_modules/io.h`, `Python/frozen_modules/ntpath.h`, `Python/frozen_modules/os.h`, `Python/frozen_modules/posixpath.h`, `Python/frozen_modules/runpy.h`, `Python/frozen_modules/site.h`, `Python/frozen_modules/stat.h`, `Python/frozen_modules/zipimport.h`, `Python/frozenmain.o`, `Python/future.o`, `Python/gc.o`, `Python/gc_free_threading.o`, `Python/gc_gil.o`, `Python/getargs.o`, `Python/getcompiler.o`, `Python/getcopyright.o`, `Python/getopt.o`, `Python/getplatform.o`, `Python/getversion.o`, `Python/hamt.o`, `Python/hashtable.o`, `Python/import.o`, `Python/importdl.o`, `Python/initconfig.o`, `Python/instruction_sequence.o`, `Python/instrumentation.o`, `Python/interpconfig.o`, `Python/intrinsics.o`, `Python/jit.o`, `Python/legacy_tracing.o`, `Python/lock.o`, `Python/marshal.o`, `Python/modsupport.o`, `Python/mysnprintf.o`, `Python/mystrtoul.o`, `Python/object_stack.o`, `Python/optimizer.o`, `Python/optimizer_analysis.o`, `Python/optimizer_symbols.o`, `Python/parking_lot.o`, `Python/pathconfig.o`, `Python/perf_jit_trampoline.o`, `Python/perf_trampoline.o`, `Python/preconfig.o`, `Python/pyarena.o`, `Python/pyctype.o`, `Python/pyfpe.o`, `Python/pyhash.o`, `Python/pylifecycle.o`, `Python/pymath.o`, `Python/pystate.o`, `Python/pystrcmp.o`, `Python/pystrhex.o`, `Python/pystrtod.o`, `Python/pythonrun.o`, `Python/pytime.o`, `Python/qsbr.o`, `Python/specialize.o`, `Python/structmember.o`, `Python/suggestions.o`, `Python/symtable.o`, `Python/sysmodule.o`, `Python/thread.o`, `Python/traceback.o`, `Python/tracemalloc.o`, `_bootstrap_python`, `build/lib.linux-x86_64-3.13/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-313.pyc`, `build/lib.linux-x86_64-3.13/_asyncio.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bisect.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_blake2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bz2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_contextvars.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_csv.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_datetime.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_decimal.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_elementtree.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_hashlib.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_heapq.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpreters.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_json.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lsprof.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lzma.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_md5.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_opcode.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_pickle.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_queue.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_random.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha1.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_socket.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ssl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_statistics.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_struct.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sysconfigdata__linux_x86_64-linux-gnu.py`, `build/lib.linux-x86_64-3.13/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_uuid.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/array.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/binascii.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/cmath.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/fcntl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/grp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/math.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/mmap.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/pyexpat.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/readline.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/resource.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/select.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/syslog.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/termios.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/unicodedata.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/zlib.cpython-313-x86_64-linux-gnu.so`, `build/scripts-3.13/idle3.13`, `build/scripts-3.13/pydoc3.13`, `config.log`, `config.status`, `libpython3.13.a`, `platform`, `pybuilddir.txt`, `pyconfig.h`, `python`, `python-config`, `python-config.py`, `python-gdb.py`.
2. Listed in `## Git Add Paths` but not actually changed: `None`.

## Refinement Pass 1

Subject: Diagnose apt_pkg CPU evidence outside CPython

## Commit Message
No CPython source change is proposed. The refinement addresses the review finding by removing generated validation artifacts from the workspace, keeping the no-patch diagnosis consistent with `Git Add Paths: None`.

## Evidence Confidence
inferred

## Issue Connection
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` consuming CPU under `/usr/bin/python3.13`, with 87,511 `newfstatat` calls in 5 seconds against `/var/lib/apt/lists/*`. Perf placed the hottest native path in `apt_pkg.cpython-313-x86_64-linux-gnu.so` and `libapt-pkg.so.7.0.0`, including `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()`.

The cautious inference remains that unattended-upgrade is repeatedly driving APT package-cache work through the `python3-apt` extension. The CPython frame `_PyObject_MakeTpCall` is normal C-extension call dispatch, not evidence of an interpreter-owned busy loop.

I made no source change. For this refinement, I removed only untracked build products and bytecode that were left by validation, addressing the review’s patch metadata drift finding. Checked conventions/helpers remain `README.rst` for CPython’s upstream build/test flow and local runtime helpers such as `_Py_read()`, `path_t`/`PyUnicode_FSConverter`, and `HAVE_FSTATAT_RUNTIME`; none fits the observed `apt_pkg`/`libapt-pkg` hot path. The expected effect is a clean no-patch report that does not misattribute APT extension behavior to CPython.

## Git Add Paths
None

## Validation
Previous project-level validation: `./configure && make` passed from the workspace root. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the interpreter and checked modules built successfully.

Independent reproduction attempt from the prior pass: `timeout 30s strace -f -c -e newfstatat python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'` was blocked by ptrace policy: `PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 5): Operation not permitted`.

Fallback smoke from the prior pass: `timeout 30s python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache(); print("apt_pkg cache smoke completed")'` completed normally, so the runaway syscall pattern was not independently reproduced.

Refinement check: `git status --short --untracked-files=all` and `git diff --name-only` are clean after removing generated artifacts.

## Review Pass 2

RESULT: ok

No findings. The workspace is clean, `## Git Add Paths` correctly lists `None`, and the no-patch diagnosis is consistent with the indirect evidence pointing at `python3-apt`/`libapt-pkg` rather than CPython runtime code.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1 (local metadata check)

Local metadata consistency check

## Refinement Pass 1

You are refining a fixer patch after an explicit code review.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Read the latest author response at `./patch-output.txt`. Read the review report at `./review-1-output.txt`. This is refinement round 1. The original pre-edit snapshot is available at `./source` if you need to compare the current patch against it. Re-read the planning pass at `./plan-output.txt` before editing. The workspace currently changes these repo-relative paths: Lib/__pycache__/__future__.cpython-313.pyc, Lib/__pycache__/_collections_abc.cpython-313.pyc, Lib/__pycache__/_colorize.cpython-313.pyc, Lib/__pycache__/_compat_pickle.cpython-313.pyc, Lib/__pycache__/_compression.cpython-313.pyc, Lib/__pycache__/_opcode_metadata.cpython-313.pyc, Lib/__pycache__/_sitebuiltins.cpython-313.pyc, Lib/__pycache__/_weakrefset.cpython-313.pyc, Lib/__pycache__/abc.cpython-313.pyc, Lib/__pycache__/argparse.cpython-313.pyc, Lib/__pycache__/ast.cpython-313.pyc, Lib/__pycache__/base64.cpython-313.pyc, Lib/__pycache__/bz2.cpython-313.pyc, Lib/__pycache__/codecs.cpython-313.pyc, Lib/__pycache__/contextlib.cpython-313.pyc, Lib/__pycache__/contextvars.cpython-313.pyc, Lib/__pycache__/copy.cpython-313.pyc, Lib/__pycache__/copyreg.cpython-313.pyc, Lib/__pycache__/datetime.cpython-313.pyc, Lib/__pycache__/dis.cpython-313.pyc, Lib/__pycache__/enum.cpython-313.pyc, Lib/__pycache__/fnmatch.cpython-313.pyc, Lib/__pycache__/functools.cpython-313.pyc, Lib/__pycache__/genericpath.cpython-313.pyc, Lib/__pycache__/gettext.cpython-313.pyc, Lib/__pycache__/glob.cpython-313.pyc, Lib/__pycache__/heapq.cpython-313.pyc, Lib/__pycache__/inspect.cpython-313.pyc, Lib/__pycache__/io.cpython-313.pyc, Lib/__pycache__/keyword.cpython-313.pyc, Lib/__pycache__/linecache.cpython-313.pyc, Lib/__pycache__/locale.cpython-313.pyc, Lib/__pycache__/lzma.cpython-313.pyc, Lib/__pycache__/numbers.cpython-313.pyc, Lib/__pycache__/opcode.cpython-313.pyc, Lib/__pycache__/operator.cpython-313.pyc, Lib/__pycache__/os.cpython-313.pyc, Lib/__pycache__/posixpath.cpython-313.pyc, Lib/__pycache__/reprlib.cpython-313.pyc, Lib/__pycache__/selectors.cpython-313.pyc, Lib/__pycache__/shutil.cpython-313.pyc, Lib/__pycache__/signal.cpython-313.pyc, Lib/__pycache__/site.cpython-313.pyc, Lib/__pycache__/socket.cpython-313.pyc, Lib/__pycache__/ssl.cpython-313.pyc, Lib/__pycache__/stat.cpython-313.pyc, Lib/__pycache__/string.cpython-313.pyc, Lib/__pycache__/struct.cpython-313.pyc, Lib/__pycache__/subprocess.cpython-313.pyc, Lib/__pycache__/textwrap.cpython-313.pyc, Lib/__pycache__/threading.cpython-313.pyc, Lib/__pycache__/token.cpython-313.pyc, Lib/__pycache__/tokenize.cpython-313.pyc, Lib/__pycache__/traceback.cpython-313.pyc, Lib/__pycache__/types.cpython-313.pyc, Lib/__pycache__/typing.cpython-313.pyc, Lib/__pycache__/warnings.cpython-313.pyc, Lib/__pycache__/weakref.cpython-313.pyc, Lib/asyncio/__pycache__/__init__.cpython-313.pyc, Lib/asyncio/__pycache__/base_events.cpython-313.pyc, Lib/asyncio/__pycache__/base_futures.cpython-313.pyc, Lib/asyncio/__pycache__/base_subprocess.cpython-313.pyc, Lib/asyncio/__pycache__/base_tasks.cpython-313.pyc, Lib/asyncio/__pycache__/constants.cpython-313.pyc, Lib/asyncio/__pycache__/coroutines.cpython-313.pyc, Lib/asyncio/__pycache__/events.cpython-313.pyc, Lib/asyncio/__pycache__/exceptions.cpython-313.pyc, Lib/asyncio/__pycache__/format_helpers.cpython-313.pyc, Lib/asyncio/__pycache__/futures.cpython-313.pyc, Lib/asyncio/__pycache__/locks.cpython-313.pyc, Lib/asyncio/__pycache__/log.cpython-313.pyc, Lib/asyncio/__pycache__/mixins.cpython-313.pyc, Lib/asyncio/__pycache__/protocols.cpython-313.pyc, Lib/asyncio/__pycache__/queues.cpython-313.pyc, Lib/asyncio/__pycache__/runners.cpython-313.pyc, Lib/asyncio/__pycache__/selector_events.cpython-313.pyc, Lib/asyncio/__pycache__/sslproto.cpython-313.pyc, Lib/asyncio/__pycache__/staggered.cpython-313.pyc, Lib/asyncio/__pycache__/streams.cpython-313.pyc, Lib/asyncio/__pycache__/subprocess.cpython-313.pyc, Lib/asyncio/__pycache__/taskgroups.cpython-313.pyc, Lib/asyncio/__pycache__/tasks.cpython-313.pyc, Lib/asyncio/__pycache__/threads.cpython-313.pyc, Lib/asyncio/__pycache__/timeouts.cpython-313.pyc, Lib/asyncio/__pycache__/transports.cpython-313.pyc, Lib/asyncio/__pycache__/trsock.cpython-313.pyc, Lib/asyncio/__pycache__/unix_events.cpython-313.pyc, Lib/collections/__pycache__/__init__.cpython-313.pyc, Lib/concurrent/__pycache__/__init__.cpython-313.pyc, Lib/concurrent/futures/__pycache__/__init__.cpython-313.pyc, Lib/concurrent/futures/__pycache__/_base.cpython-313.pyc, Lib/encodings/__pycache__/__init__.cpython-313.pyc, Lib/encodings/__pycache__/aliases.cpython-313.pyc, Lib/encodings/__pycache__/ascii.cpython-313.pyc, Lib/encodings/__pycache__/utf_8.cpython-313.pyc, Lib/importlib/__pycache__/__init__.cpython-313.pyc, Lib/importlib/__pycache__/_abc.cpython-313.pyc, Lib/logging/__pycache__/__init__.cpython-313.pyc, Lib/pathlib/__pycache__/__init__.cpython-313.pyc, Lib/pathlib/__pycache__/_abc.cpython-313.pyc, Lib/pathlib/__pycache__/_local.cpython-313.pyc, Lib/re/__pycache__/__init__.cpython-313.pyc, Lib/re/__pycache__/_casefix.cpython-313.pyc, Lib/re/__pycache__/_compiler.cpython-313.pyc, Lib/re/__pycache__/_constants.cpython-313.pyc, Lib/re/__pycache__/_parser.cpython-313.pyc, Lib/sysconfig/__pycache__/__init__.cpython-313.pyc, Lib/sysconfig/__pycache__/__main__.cpython-313.pyc, Lib/xml/__pycache__/__init__.cpython-313.pyc, Lib/xml/etree/__pycache__/ElementPath.cpython-313.pyc, Lib/xml/etree/__pycache__/__init__.cpython-313.pyc, Lib/zoneinfo/__pycache__/__init__.cpython-313.pyc, Lib/zoneinfo/__pycache__/_common.cpython-313.pyc, Lib/zoneinfo/__pycache__/_tzpath.cpython-313.pyc, Makefile, Makefile.pre, Misc/python-config.sh, Misc/python-embed.pc, Misc/python.pc, Modules/Setup.bootstrap, Modules/Setup.local, Modules/Setup.stdlib, Modules/_abc.o, Modules/_asyncio.cpython-313-x86_64-linux-gnu.so, Modules/_asynciomodule.o, Modules/_bisect.cpython-313-x86_64-linux-gnu.so, Modules/_bisectmodule.o, Modules/_blake2.cpython-313-x86_64-linux-gnu.so, Modules/_blake2/blake2b_impl.o, Modules/_blake2/blake2mo

[truncated 27774 bytes]

## Plan Pass

## Problem
Fixer observed high CPU in a Python 3.13 process running unattended-upgrade, with repeated `newfstatat` calls against APT list files. The evidence points to `apt_pkg.cpython-313-x86_64-linux-gnu.so` and `libapt-pkg.so.7.0.0`; the CPython frame `_PyObject_MakeTpCall` is ordinary C-extension dispatch, not a demonstrated interpreter loop.

## Evidence Confidence
inferred

## Proposed Subject
No CPython source patch in this pass. The maintainer-facing subject should be a diagnosis/reassignment: the collected signal implicates `python3-apt`/`libapt-pkg` or unattended-upgrades’ use of APT cache APIs, not a confirmed `python3.13` runtime defect.

## Patch Plan
- Do not edit CPython until an independent reproducer shows Python runtime code causing the busy loop.
- Treat `/usr/bin/unattended-upgrade` as the entrypoint evidence and `apt_pkg`/`libapt-pkg` as the first investigation target; only return to CPython if profiling shows the interpreter itself spinning outside extension code.
- No prior Fixer patch exists to improve or replace; the workspace is at `Fixer baseline`.
- CPython conventions found: `README.rst` points contributors to the Developer Guide and the normal `./configure`, `make`, `make test` flow. Relevant local helpers include `_Py_read` in `Python/fileutils.c`, `path_t`/`PyUnicode_FSConverter`, and `HAVE_FSTATAT_RUNTIME` handling in `Modules/posixmodule.c`, but none is on the observed hot path from the evidence bundle.
- Avoid awkward control flow such as adding CPython-level guards around extension calls; that would mask extension behavior and would not address the observed repeated APT file probing.

## Risks
The main risk is misattribution: patching CPython based only on a profiler sample that names `/usr/bin/python3.13` would create an upstream-unfriendly workaround. A valid patch likely belongs in `python-apt`, `libapt-pkg`, or unattended-upgrades after reducing the repeated APT list probing to a small reproducer.

## Validation
From the workspace root, first try the project entrypoint `./configure && make` if a CPython edit becomes justified. If that fails due missing dependencies/generated files, record the exact failure and then run the narrowest relevant compile/test.

Bounded independent signal check: run a read-only APT-cache smoke under syscall counting, for example `timeout 30s strace -f -c -e newfstatat python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'`. This can collect whether `apt_pkg` alone produces the repeated `newfstatat` pattern without claiming the unattended-upgrade runaway is reproduced.

## Patch Pass

Subject: Diagnose apt_pkg CPU evidence outside CPython

## Commit Message
No CPython source change is proposed. The collected perf, strace, and `/proc` evidence points to APT cache work in `python3-apt`/`libapt-pkg`, not to a CPython runtime loop.

I followed the saved plan and did not change course.

## Evidence Confidence
inferred

## Issue Connection
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` consuming CPU under `/usr/bin/python3.13`. The trace showed 87,511 `newfstatat` calls in 5 seconds against `/var/lib/apt/lists/*`, while perf attributed the hottest native path to `apt_pkg.cpython-313-x86_64-linux-gnu.so` and `libapt-pkg.so.7.0.0` symbols such as `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()`.

The cautious code-level inference is that unattended-upgrade is driving repeated APT package-cache probing through the `python3-apt` extension. The CPython frame in the backtrace, `_PyObject_MakeTpCall`, is the normal C-extension call path; it does not own the APT file probing. The GLib `gmain`/`gdbus` threads were blocked in poll-family calls and do not identify a CPython busy loop either.

I made no source change because the evidence is profiler/strace-based and does not show a CPython defect. CPython local conventions/helpers checked include `README.rst` for the upstream build/test flow, `_Py_read()` in `Python/fileutils.c`, and `path_t`/`PyUnicode_FSConverter`/`HAVE_FSTATAT_RUNTIME` in `Modules/posixmodule.c`; those helpers are not on the observed `apt_pkg`/`libapt-pkg` hot path. The expected effect of this no-patch diagnosis is to avoid landing an upstream-unfriendly CPython workaround and to direct the report toward `python3-apt`, `libapt-pkg`, or unattended-upgrades with the APT-cache syscall evidence.

## Git Add Paths
None

## Validation
`./configure && make` from the workspace root: passed. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the interpreter and checked modules built successfully.

Independent reproduction attempt: `timeout 30s strace -f -c -e newfstatat python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'` could not run because ptrace is blocked: `PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 5): Operation not permitted`.

Fallback smoke: `timeout 30s python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache(); print("apt_pkg cache smoke completed")'` completed normally, so the runaway CPU/syscall pattern was not independently reproduced.

## Review Pass 1 (local metadata check)

RESULT: fix-needed

## Findings
1. Patch metadata drift: the workspace currently changes `Lib/__pycache__/__future__.cpython-313.pyc`, `Lib/__pycache__/_collections_abc.cpython-313.pyc`, `Lib/__pycache__/_colorize.cpython-313.pyc`, `Lib/__pycache__/_compat_pickle.cpython-313.pyc`, `Lib/__pycache__/_compression.cpython-313.pyc`, `Lib/__pycache__/_opcode_metadata.cpython-313.pyc`, `Lib/__pycache__/_sitebuiltins.cpython-313.pyc`, `Lib/__pycache__/_weakrefset.cpython-313.pyc`, `Lib/__pycache__/abc.cpython-313.pyc`, `Lib/__pycache__/argparse.cpython-313.pyc`, `Lib/__pycache__/ast.cpython-313.pyc`, `Lib/__pycache__/base64.cpython-313.pyc`, `Lib/__pycache__/bz2.cpython-313.pyc`, `Lib/__pycache__/codecs.cpython-313.pyc`, `Lib/__pycache__/contextlib.cpython-313.pyc`, `Lib/__pycache__/contextvars.cpython-313.pyc`, `Lib/__pycache__/copy.cpython-313.pyc`, `Lib/__pycache__/copyreg.cpython-313.pyc`, `Lib/__pycache__/datetime.cpython-313.pyc`, `Lib/__pycache__/dis.cpython-313.pyc`, `Lib/__pycache__/enum.cpython-313.pyc`, `Lib/__pycache__/fnmatch.cpython-313.pyc`, `Lib/__pycache__/functools.cpython-313.pyc`, `Lib/__pycache__/genericpath.cpython-313.pyc`, `Lib/__pycache__/gettext.cpython-313.pyc`, `Lib/__pycache__/glob.cpython-313.pyc`, `Lib/__pycache__/heapq.cpython-313.pyc`, `Lib/__pycache__/inspect.cpython-313.pyc`, `Lib/__pycache__/io.cpython-313.pyc`, `Lib/__pycache__/keyword.cpython-313.pyc`, `Lib/__pycache__/linecache.cpython-313.pyc`, `Lib/__pycache__/locale.cpython-313.pyc`, `Lib/__pycache__/lzma.cpython-313.pyc`, `Lib/__pycache__/numbers.cpython-313.pyc`, `Lib/__pycache__/opcode.cpython-313.pyc`, `Lib/__pycache__/operator.cpython-313.pyc`, `Lib/__pycache__/os.cpython-313.pyc`, `Lib/__pycache__/posixpath.cpython-313.pyc`, `Lib/__pycache__/reprlib.cpython-313.pyc`, `Lib/__pycache__/selectors.cpython-313.pyc`, `Lib/__pycache__/shutil.cpython-313.pyc`, `Lib/__pycache__/signal.cpython-313.pyc`, `Lib/__pycache__/site.cpython-313.pyc`, `Lib/__pycache__/socket.cpython-313.pyc`, `Lib/__pycache__/ssl.cpython-313.pyc`, `Lib/__pycache__/stat.cpython-313.pyc`, `Lib/__pycache__/string.cpython-313.pyc`, `Lib/__pycache__/struct.cpython-313.pyc`, `Lib/__pycache__/subprocess.cpython-313.pyc`, `Lib/__pycache__/textwrap.cpython-313.pyc`, `Lib/__pycache__/threading.cpython-313.pyc`, `Lib/__pycache__/token.cpython-313.pyc`, `Lib/__pycache__/tokenize.cpython-313.pyc`, `Lib/__pycache__/traceback.cpython-313.pyc`, `Lib/__pycache__/types.cpython-313.pyc`, `Lib/__pycache__/typing.cpython-313.pyc`, `Lib/__pycache__/warnings.cpython-313.pyc`, `Lib/__pycache__/weakref.cpython-313.pyc`, `Lib/asyncio/__pycache__/__init__.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/constants.cpython-313.pyc`, `Lib/asyncio/__pycache__/coroutines.cpython-313.pyc`, `Lib/asyncio/__pycache__/events.cpython-313.pyc`, `Lib/asyncio/__pycache__/exceptions.cpython-313.pyc`, `Lib/asyncio/__pycache__/format_helpers.cpython-313.pyc`, `Lib/asyncio/__pycache__/futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/locks.cpython-313.pyc`, `Lib/asyncio/__pycache__/log.cpython-313.pyc`, `Lib/asyncio/__pycache__/mixins.cpython-313.pyc`, `Lib/asyncio/__pycache__/protocols.cpython-313.pyc`, `Lib/asyncio/__pycache__/queues.cpython-313.pyc`, `Lib/asyncio/__pycache__/runners.cpython-313.pyc`, `Lib/asyncio/__pycache__/selector_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/sslproto.cpython-313.pyc`, `Lib/asyncio/__pycache__/staggered.cpython-313.pyc`, `Lib/asyncio/__pycache__/streams.cpython-313.pyc`, `Lib/asyncio/__pycache__/subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/taskgroups.cpython-313.pyc`, `Lib/asyncio/__pycache__/tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/threads.cpython-313.pyc`, `Lib/asyncio/__pycache__/timeouts.cpython-313.pyc`, `Lib/asyncio/__pycache__/transports.cpython-313.pyc`, `Lib/asyncio/__pycache__/trsock.cpython-313.pyc`, `Lib/asyncio/__pycache__/unix_events.cpython-313.pyc`, `Lib/collections/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/_base.cpython-313.pyc`, `Lib/encodings/__pycache__/__init__.cpython-313.pyc`, `Lib/encodings/__pycache__/aliases.cpython-313.pyc`, `Lib/encodings/__pycache__/ascii.cpython-313.pyc`, `Lib/encodings/__pycache__/utf_8.cpython-313.pyc`, `Lib/importlib/__pycache__/__init__.cpython-313.pyc`, `Lib/importlib/__pycache__/_abc.cpython-313.pyc`, `Lib/logging/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/_abc.cpython-313.pyc`, `Lib/pathlib/__pycache__/_local.cpython-313.pyc`, `Lib/re/__pycache__/__init__.cpython-313.pyc`, `Lib/re/__pycache__/_casefix.cpython-313.pyc`, `Lib/re/__pycache__/_compiler.cpython-313.pyc`, `Lib/re/__pycache__/_constants.cpython-313.pyc`, `Lib/re/__pycache__/_parser.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__init__.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__main__.cpython-313.pyc`, `Lib/xml/__pycache__/__init__.cpython-313.pyc`, `Lib/xml/etree/__pycache__/ElementPath.cpython-313.pyc`, `Lib/xml/etree/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_common.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_tzpath.cpython-313.pyc`, `Makefile`, `Makefile.pre`, `Misc/python-config.sh`, `Misc/python-embed.pc`, `Misc/python.pc`, `Modules/Setup.bootstrap`, `Modules/Setup.local`, `Modules/Setup.stdlib`, `Modules/_abc.o`, `Modules/_asyncio.cpython-313-x86_64-linux-gnu.so`, `Modules/_asynciomodule.o`, `Modules/_bisect.cpython-313-x86_64-linux-gnu.so`, `Modules/_bisectmodule.o`, `Modules/_blake2.cpython-313-x86_64-linux-gnu.so`, `Modules/_blake2/blake2b_impl.o`, `Modules/_blake2/blake2module.o`, `Modules/_blake2/blake2s_impl.o`, `Modules/_bz2.cpython-313-x86_64-linux-gnu.so`, `Modules/_bz2module.o`, `Modules/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecsmodule.o`, `Modules/_collectionsmodule.o`, `Modules/_contextvars.cpython-313-x86_64-linux-gnu.so`, `Modules/_contextvarsmodule.o`, `Modules/_csv.cpython-313-x86_64-linux-gnu.so`, `Modules/_csv.o`, `Modules/_ctypes.cpython-313-x86_64-linux-gnu.so`, `Modules/_ctypes/_ctypes.o`, `Modules/_ctypes/_ctypes_test.o`, `Modules/_ctypes/callbacks.o`, `Modules/_ctypes/callproc.o`, `Modules/_ctypes/cfield.o`, `Modules/_ctypes/stgdict.o`, `Modules/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.o`, `Modules/_cursesmodule.o`, `Modules/_datetime.cpython-313-x86_64-linux-gnu.so`, `Modules/_datetimemodule.o`, `Modules/_decimal.cpython-313-x86_64-linux-gnu.so`, `Modules/_decimal/_decimal.o`, `Modules/_decimal/libmpdec/basearith.o`, `Modules/_decimal/libmpdec/constants.o`, `Modules/_decimal/libmpdec/context.o`, `Modules/_decimal/libmpdec/convolute.o`, `Modules/_decimal/libmpdec/crt.o`, `Modules/_decimal/libmpdec/difradix2.o`, `Modules/_decimal/libmpdec/fnt.o`, `Modules/_decimal/libmpdec/fourstep.o`, `Modules/_decimal/libmpdec/io.o`, `Modules/_decimal/libmpdec/libmpdec.a`, `Modules/_decimal/libmpdec/mpalloc.o`, `Modules/_decimal/libmpdec/mpdecimal.o`, `Modules/_decimal/libmpdec/numbertheory.o`, `Modules/_decimal/libmpdec/sixstep.o`, `Modules/_decimal/libmpdec/transpose.o`, `Modules/_elementtree.cpython-313-x86_64-linux-gnu.so`, `Modules/_elementtree.o`, `Modules/_functoolsmodule.o`, `Modules/_hacl/Hacl_Hash_MD5.o`, `Modules/_hacl/Hacl_Hash_SHA1.o`, `Modules/_hacl/Hacl_Hash_SHA2.o`, `Modules/_hacl/Hacl_Hash_SHA3.o`, `Modules/_hacl/libHacl_Hash_SHA2.a`, `Modules/_hashlib.cpython-313-x86_64-linux-gnu.so`, `Modules/_hashopenssl.o`, `Modules/_heapq.cpython-313-x86_64-linux-gnu.so`, `Modules/_heapqmodule.o`, `Modules/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpchannelsmodule.o`, `Modules/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpqueuesmodule.o`, `Modules/_interpreters.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpretersmodule.o`, `Modules/_io/_iomodule.o`, `Modules/_io/bufferedio.o`, `Modules/_io/bytesio.o`, `Modules/_io/fileio.o`, `Modules/_io/iobase.o`, `Modules/_io/stringio.o`, `Modules/_io/textio.o`, `Modules/_json.cpython-313-x86_64-linux-gnu.so`, `Modules/_json.o`, `Modules/_localemodule.o`, `Modules/_lsprof.cpython-313-x86_64-linux-gnu.so`, `Modules/_lsprof.o`, `Modules/_lzma.cpython-313-x86_64-linux-gnu.so`, `Modules/_lzmamodule.o`, `Modules/_md5.cpython-313-x86_64-linux-gnu.so`, `Modules/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing/multiprocessing.o`, `Modules/_multiprocessing/posixshmem.o`, `Modules/_multiprocessing/semaphore.o`, `Modules/_opcode.cpython-313-x86_64-linux-gnu.so`, `Modules/_opcode.o`, `Modules/_operator.o`, `Modules/_pickle.cpython-313-x86_64-linux-gnu.so`, `Modules/_pickle.o`, `Modules/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.o`, `Modules/_queue.cpython-313-x86_64-linux-gnu.so`, `Modules/_queuemodule.o`, `Modules/_random.cpython-313-x86_64-linux-gnu.so`, `Modules/_randommodule.o`, `Modules/_sha1.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha2.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha3.cpython-313-x86_64-linux-gnu.so`, `Modules/_socket.cpython-313-x86_64-linux-gnu.so`, `Modules/_sqlite/blob.o`, `Modules/_sqlite/connection.o`, `Modules/_sqlite/cursor.o`, `Modules/_sqlite/microprotocols.o`, `Modules/_sqlite/module.o`, `Modules/_sqlite/prepare_protocol.o`, `Modules/_sqlite/row.o`, `Modules/_sqlite/statement.o`, `Modules/_sqlite/util.o`, `Modules/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `Modules/_sre/sre.o`, `Modules/_ssl.cpython-313-x86_64-linux-gnu.so`, `Modules/_ssl.o`, `Modules/_stat.o`, `Modules/_statistics.cpython-313-x86_64-linux-gnu.so`, `Modules/_statisticsmodule.o`, `Modules/_struct.cpython-313-x86_64-linux-gnu.so`, `Modules/_struct.o`, `Modules/_suggestions.o`, `Modules/_sysconfig.o`, `Modules/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `Modules/_testbuffer.o`, `Modules/_testcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testcapi/abstract.o`, `Modules/_testcapi/buffer.o`, `Modules/_testcapi/bytes.o`, `Modules/_testcapi/code.o`, `Modules/_testcapi/codec.o`, `Modules/_testcapi/complex.o`, `Modules/_testcapi/datetime.o`, `Modules/_testcapi/dict.o`, `Modules/_testcapi/docstring.o`, `Modules/_testcapi/exceptions.o`, `Modules/_testcapi/file.o`, `Modules/_testcapi/float.o`, `Modules/_testcapi/gc.o`, `Modules/_testcapi/getargs.o`, `Modules/_testcapi/hash.o`, `Modules/_testcapi/heaptype.o`, `Modules/_testcapi/immortal.o`, `Modules/_testcapi/list.o`, `Modules/_testcapi/long.o`, `Modules/_testcapi/mem.o`, `Modules/_testcapi/monitoring.o`, `Modules/_testcapi/numbers.o`, `Modules/_testcapi/object.o`, `Modules/_testcapi/pyatomic.o`, `Modules/_testcapi/run.o`, `Modules/_testcapi/set.o`, `Modules/_testcapi/structmember.o`, `Modules/_testcapi/time.o`, `Modules/_testcapi/tuple.o`, `Modules/_testcapi/unicode.o`, `Modules/_testcapi/vectorcall.o`, `Modules/_testcapi/watchers.o`, `Modules/_testcapimodule.o`, `Modules/_testclinic.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic.o`, `Modules/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic_limited.o`, `Modules/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `Modules/_testexternalinspection.o`, `Modules/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `Modules/_testimportmultiple.o`, `Modules/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testinternalcapi.o`, `Modules/_testinternalcapi/pytime.o`, `Modules/_testinternalcapi/set.o`, `Modules/_testinternalcapi/test_critical_sections.o`, `Modules/_testinternalcapi/test_lock.o`, `Modules/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testlimitedcapi.o`, `Modules/_testlimitedcapi/abstract.o`, `Modules/_testlimitedcapi/bytearray.o`, `Modules/_testlimitedcapi/bytes.o`, `Modules/_testlimitedcapi/complex.o`, `Modules/_testlimitedcapi/dict.o`, `Modules/_testlimitedcapi/eval.o`, `Modules/_testlimitedcapi/file.o`, `Modules/_testlimitedcapi/float.o`, `Modules/_testlimitedcapi/heaptype_relative.o`, `Modules/_testlimitedcapi/import.o`, `Modules/_testlimitedcapi/list.o`, `Modules/_testlimitedcapi/long.o`, `Modules/_testlimitedcapi/object.o`, `Modules/_testlimitedcapi/pyos.o`, `Modules/_testlimitedcapi/set.o`, `Modules/_testlimitedcapi/sys.o`, `Modules/_testlimitedcapi/tuple.o`, `Modules/_testlimitedcapi/unicode.o`, `Modules/_testlimitedcapi/vectorcall_limited.o`, `Modules/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testmultiphase.o`, `Modules/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testsinglephase.o`, `Modules/_threadmodule.o`, `Modules/_tracemalloc.o`, `Modules/_typingmodule.o`, `Modules/_uuid.cpython-313-x86_64-linux-gnu.so`, `Modules/_uuidmodule.o`, `Modules/_weakref.o`, `Modules/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `Modules/_xxtestfuzz/_xxtestfuzz.o`, `Modules/_xxtestfuzz/fuzzer.o`, `Modules/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `Modules/_zoneinfo.o`, `Modules/array.cpython-313-x86_64-linux-gnu.so`, `Modules/arraymodule.o`, `Modules/atexitmodule.o`, `Modules/binascii.cpython-313-x86_64-linux-gnu.so`, `Modules/binascii.o`, `Modules/cjkcodecs/_codecs_cn.o`, `Modules/cjkcodecs/_codecs_hk.o`, `Modules/cjkcodecs/_codecs_iso2022.o`, `Modules/cjkcodecs/_codecs_jp.o`, `Modules/cjkcodecs/_codecs_kr.o`, `Modules/cjkcodecs/_codecs_tw.o`, `Modules/cjkcodecs/multibytecodec.o`, `Modules/cmath.cpython-313-x86_64-linux-gnu.so`, `Modules/cmathmodule.o`, `Modules/config.c`, `Modules/config.o`, `Modules/errnomodule.o`, `Modules/expat/libexpat.a`, `Modules/expat/xmlparse.o`, `Modules/expat/xmlrole.o`, `Modules/expat/xmltok.o`, `Modules/faulthandler.o`, `Modules/fcntl.cpython-313-x86_64-linux-gnu.so`, `Modules/fcntlmodule.o`, `Modules/gcmodule.o`, `Modules/getbuildinfo.o`, `Modules/getpath.o`, `Modules/getpath_noop.o`, `Modules/grp.cpython-313-x86_64-linux-gnu.so`, `Modules/grpmodule.o`, `Modules/itertoolsmodule.o`, `Modules/ld_so_aix`, `Modules/main.o`, `Modules/math.cpython-313-x86_64-linux-gnu.so`, `Modules/mathmodule.o`, `Modules/md5module.o`, `Modules/mmap.cpython-313-x86_64-linux-gnu.so`, `Modules/mmapmodule.o`, `Modules/posixmodule.o`, `Modules/pwdmodule.o`, `Modules/pyexpat.cpython-313-x86_64-linux-gnu.so`, `Modules/pyexpat.o`, `Modules/readline.cpython-313-x86_64-linux-gnu.so`, `Modules/readline.o`, `Modules/resource.cpython-313-x86_64-linux-gnu.so`, `Modules/resource.o`, `Modules/rotatingtree.o`, `Modules/select.cpython-313-x86_64-linux-gnu.so`, `Modules/selectmodule.o`, `Modules/sha1module.o`, `Modules/sha2module.o`, `Modules/sha3module.o`, `Modules/signalmodule.o`, `Modules/socketmodule.o`, `Modules/symtablemodule.o`, `Modules/syslog.cpython-313-x86_64-linux-gnu.so`, `Modules/syslogmodule.o`, `Modules/termios.cpython-313-x86_64-linux-gnu.so`, `Modules/termios.o`, `Modules/timemodule.o`, `Modules/unicodedata.cpython-313-x86_64-linux-gnu.so`, `Modules/unicodedata.o`, `Modules/xxlimited.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited.o`, `Modules/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited_35.o`, `Modules/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `Modules/xxsubtype.o`, `Modules/zlib.cpython-313-x86_64-linux-gnu.so`, `Modules/zlibmodule.o`, `Objects/abstract.o`, `Objects/boolobject.o`, `Objects/bytearrayobject.o`, `Objects/bytes_methods.o`, `Objects/bytesobject.o`, `Objects/call.o`, `Objects/capsule.o`, `Objects/cellobject.o`, `Objects/classobject.o`, `Objects/codeobject.o`, `Objects/complexobject.o`, `Objects/descrobject.o`, `Objects/dictobject.o`, `Objects/enumobject.o`, `Objects/exceptions.o`, `Objects/fileobject.o`, `Objects/floatobject.o`, `Objects/frameobject.o`, `Objects/funcobject.o`, `Objects/genericaliasobject.o`, `Objects/genobject.o`, `Objects/iterobject.o`, `Objects/listobject.o`, `Objects/longobject.o`, `Objects/memoryobject.o`, `Objects/methodobject.o`, `Objects/moduleobject.o`, `Objects/namespaceobject.o`, `Objects/object.o`, `Objects/obmalloc.o`, `Objects/odictobject.o`, `Objects/picklebufobject.o`, `Objects/rangeobject.o`, `Objects/setobject.o`, `Objects/sliceobject.o`, `Objects/structseq.o`, `Objects/tupleobject.o`, `Objects/typeobject.o`, `Objects/typevarobject.o`, `Objects/unicodectype.o`, `Objects/unicodeobject.o`, `Objects/unionobject.o`, `Objects/weakrefobject.o`, `Parser/action_helpers.o`, `Parser/lexer/buffer.o`, `Parser/lexer/lexer.o`, `Parser/lexer/state.o`, `Parser/myreadline.o`, `Parser/parser.o`, `Parser/peg_api.o`, `Parser/pegen.o`, `Parser/pegen_errors.o`, `Parser/string_parser.o`, `Parser/token.o`, `Parser/tokenizer/file_tokenizer.o`, `Parser/tokenizer/helpers.o`, `Parser/tokenizer/readline_tokenizer.o`, `Parser/tokenizer/string_tokenizer.o`, `Parser/tokenizer/utf8_tokenizer.o`, `Programs/_bootstrap_python.o`, `Programs/_freeze_module`, `Programs/_freeze_module.o`, `Programs/_testembed`, `Programs/_testembed.o`, `Programs/python.o`, `Python/Python-ast.o`, `Python/Python-tokenize.o`, `Python/_warnings.o`, `Python/asdl.o`, `Python/asm_trampoline.o`, `Python/assemble.o`, `Python/ast.o`, `Python/ast_opt.o`, `Python/ast_unparse.o`, `Python/bltinmodule.o`, `Python/bootstrap_hash.o`, `Python/brc.o`, `Python/ceval.o`, `Python/ceval_gil.o`, `Python/codecs.o`, `Python/compile.o`, `Python/context.o`, `Python/critical_section.o`, `Python/crossinterp.o`, `Python/dtoa.o`, `Python/dynamic_annotations.o`, `Python/dynload_shlib.o`, `Python/errors.o`, `Python/fileutils.o`, `Python/flowgraph.o`, `Python/formatter_unicode.o`, `Python/frame.o`, `Python/frozen.o`, `Python/frozen_modules/__hello__.h`, `Python/frozen_modules/__phello__.h`, `Python/frozen_modules/__phello__.ham.eggs.h`, `Python/frozen_modules/__phello__.ham.h`, `Python/frozen_modules/__phello__.spam.h`, `Python/frozen_modules/_collections_abc.h`, `Python/frozen_modules/_sitebuiltins.h`, `Python/frozen_modules/abc.h`, `Python/frozen_modules/codecs.h`, `Python/frozen_modules/frozen_only.h`, `Python/frozen_modules/genericpath.h`, `Python/frozen_modules/getpath.h`, `Python/frozen_modules/importlib._bootstrap.h`, `Python/frozen_modules/importlib._bootstrap_external.h`, `Python/frozen_modules/importlib.machinery.h`, `Python/frozen_modules/importlib.util.h`, `Python/frozen_modules/io.h`, `Python/frozen_modules/ntpath.h`, `Python/frozen_modules/os.h`, `Python/frozen_modules/posixpath.h`, `Python/frozen_modules/runpy.h`, `Python/frozen_modules/site.h`, `Python/frozen_modules/stat.h`, `Python/frozen_modules/zipimport.h`, `Python/frozenmain.o`, `Python/future.o`, `Python/gc.o`, `Python/gc_free_threading.o`, `Python/gc_gil.o`, `Python/getargs.o`, `Python/getcompiler.o`, `Python/getcopyright.o`, `Python/getopt.o`, `Python/getplatform.o`, `Python/getversion.o`, `Python/hamt.o`, `Python/hashtable.o`, `Python/import.o`, `Python/importdl.o`, `Python/initconfig.o`, `Python/instruction_sequence.o`, `Python/instrumentation.o`, `Python/interpconfig.o`, `Python/intrinsics.o`, `Python/jit.o`, `Python/legacy_tracing.o`, `Python/lock.o`, `Python/marshal.o`, `Python/modsupport.o`, `Python/mysnprintf.o`, `Python/mystrtoul.o`, `Python/object_stack.o`, `Python/optimizer.o`, `Python/optimizer_analysis.o`, `Python/optimizer_symbols.o`, `Python/parking_lot.o`, `Python/pathconfig.o`, `Python/perf_jit_trampoline.o`, `Python/perf_trampoline.o`, `Python/preconfig.o`, `Python/pyarena.o`, `Python/pyctype.o`, `Python/pyfpe.o`, `Python/pyhash.o`, `Python/pylifecycle.o`, `Python/pymath.o`, `Python/pystate.o`, `Python/pystrcmp.o`, `Python/pystrhex.o`, `Python/pystrtod.o`, `Python/pythonrun.o`, `Python/pytime.o`, `Python/qsbr.o`, `Python/specialize.o`, `Python/structmember.o`, `Python/suggestions.o`, `Python/symtable.o`, `Python/sysmodule.o`, `Python/thread.o`, `Python/traceback.o`, `Python/tracemalloc.o`, `_bootstrap_python`, `build/lib.linux-x86_64-3.13/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-313.pyc`, `build/lib.linux-x86_64-3.13/_asyncio.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bisect.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_blake2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bz2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_contextvars.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_csv.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_datetime.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_decimal.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_elementtree.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_hashlib.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_heapq.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpreters.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_json.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lsprof.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lzma.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_md5.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_opcode.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_pickle.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_queue.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_random.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha1.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_socket.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ssl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_statistics.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_struct.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sysconfigdata__linux_x86_64-linux-gnu.py`, `build/lib.linux-x86_64-3.13/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_uuid.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/array.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/binascii.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/cmath.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/fcntl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/grp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/math.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/mmap.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/pyexpat.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/readline.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/resource.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/select.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/syslog.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/termios.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/unicodedata.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/zlib.cpython-313-x86_64-linux-gnu.so`, `build/scripts-3.13/idle3.13`, `build/scripts-3.13/pydoc3.13`, `config.log`, `config.status`, `libpython3.13.a`, `platform`, `pybuilddir.txt`, `pyconfig.h`, `python`, `python-config`, `python-config.py`, `python-gdb.py`, but `## Git Add Paths` lists `None`. Update `## Git Add Paths` to match the real shipped file set exactly, and make sure `## Issue Connection` explains every functional file that remains in the patch.
2. Missing from `## Git Add Paths`: `Lib/__pycache__/__future__.cpython-313.pyc`, `Lib/__pycache__/_collections_abc.cpython-313.pyc`, `Lib/__pycache__/_colorize.cpython-313.pyc`, `Lib/__pycache__/_compat_pickle.cpython-313.pyc`, `Lib/__pycache__/_compression.cpython-313.pyc`, `Lib/__pycache__/_opcode_metadata.cpython-313.pyc`, `Lib/__pycache__/_sitebuiltins.cpython-313.pyc`, `Lib/__pycache__/_weakrefset.cpython-313.pyc`, `Lib/__pycache__/abc.cpython-313.pyc`, `Lib/__pycache__/argparse.cpython-313.pyc`, `Lib/__pycache__/ast.cpython-313.pyc`, `Lib/__pycache__/base64.cpython-313.pyc`, `Lib/__pycache__/bz2.cpython-313.pyc`, `Lib/__pycache__/codecs.cpython-313.pyc`, `Lib/__pycache__/contextlib.cpython-313.pyc`, `Lib/__pycache__/contextvars.cpython-313.pyc`, `Lib/__pycache__/copy.cpython-313.pyc`, `Lib/__pycache__/copyreg.cpython-313.pyc`, `Lib/__pycache__/datetime.cpython-313.pyc`, `Lib/__pycache__/dis.cpython-313.pyc`, `Lib/__pycache__/enum.cpython-313.pyc`, `Lib/__pycache__/fnmatch.cpython-313.pyc`, `Lib/__pycache__/functools.cpython-313.pyc`, `Lib/__pycache__/genericpath.cpython-313.pyc`, `Lib/__pycache__/gettext.cpython-313.pyc`, `Lib/__pycache__/glob.cpython-313.pyc`, `Lib/__pycache__/heapq.cpython-313.pyc`, `Lib/__pycache__/inspect.cpython-313.pyc`, `Lib/__pycache__/io.cpython-313.pyc`, `Lib/__pycache__/keyword.cpython-313.pyc`, `Lib/__pycache__/linecache.cpython-313.pyc`, `Lib/__pycache__/locale.cpython-313.pyc`, `Lib/__pycache__/lzma.cpython-313.pyc`, `Lib/__pycache__/numbers.cpython-313.pyc`, `Lib/__pycache__/opcode.cpython-313.pyc`, `Lib/__pycache__/operator.cpython-313.pyc`, `Lib/__pycache__/os.cpython-313.pyc`, `Lib/__pycache__/posixpath.cpython-313.pyc`, `Lib/__pycache__/reprlib.cpython-313.pyc`, `Lib/__pycache__/selectors.cpython-313.pyc`, `Lib/__pycache__/shutil.cpython-313.pyc`, `Lib/__pycache__/signal.cpython-313.pyc`, `Lib/__pycache__/site.cpython-313.pyc`, `Lib/__pycache__/socket.cpython-313.pyc`, `Lib/__pycache__/ssl.cpython-313.pyc`, `Lib/__pycache__/stat.cpython-313.pyc`, `Lib/__pycache__/string.cpython-313.pyc`, `Lib/__pycache__/struct.cpython-313.pyc`, `Lib/__pycache__/subprocess.cpython-313.pyc`, `Lib/__pycache__/textwrap.cpython-313.pyc`, `Lib/__pycache__/threading.cpython-313.pyc`, `Lib/__pycache__/token.cpython-313.pyc`, `Lib/__pycache__/tokenize.cpython-313.pyc`, `Lib/__pycache__/traceback.cpython-313.pyc`, `Lib/__pycache__/types.cpython-313.pyc`, `Lib/__pycache__/typing.cpython-313.pyc`, `Lib/__pycache__/warnings.cpython-313.pyc`, `Lib/__pycache__/weakref.cpython-313.pyc`, `Lib/asyncio/__pycache__/__init__.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/constants.cpython-313.pyc`, `Lib/asyncio/__pycache__/coroutines.cpython-313.pyc`, `Lib/asyncio/__pycache__/events.cpython-313.pyc`, `Lib/asyncio/__pycache__/exceptions.cpython-313.pyc`, `Lib/asyncio/__pycache__/format_helpers.cpython-313.pyc`, `Lib/asyncio/__pycache__/futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/locks.cpython-313.pyc`, `Lib/asyncio/__pycache__/log.cpython-313.pyc`, `Lib/asyncio/__pycache__/mixins.cpython-313.pyc`, `Lib/asyncio/__pycache__/protocols.cpython-313.pyc`, `Lib/asyncio/__pycache__/queues.cpython-313.pyc`, `Lib/asyncio/__pycache__/runners.cpython-313.pyc`, `Lib/asyncio/__pycache__/selector_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/sslproto.cpython-313.pyc`, `Lib/asyncio/__pycache__/staggered.cpython-313.pyc`, `Lib/asyncio/__pycache__/streams.cpython-313.pyc`, `Lib/asyncio/__pycache__/subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/taskgroups.cpython-313.pyc`, `Lib/asyncio/__pycache__/tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/threads.cpython-313.pyc`, `Lib/asyncio/__pycache__/timeouts.cpython-313.pyc`, `Lib/asyncio/__pycache__/transports.cpython-313.pyc`, `Lib/asyncio/__pycache__/trsock.cpython-313.pyc`, `Lib/asyncio/__pycache__/unix_events.cpython-313.pyc`, `Lib/collections/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/_base.cpython-313.pyc`, `Lib/encodings/__pycache__/__init__.cpython-313.pyc`, `Lib/encodings/__pycache__/aliases.cpython-313.pyc`, `Lib/encodings/__pycache__/ascii.cpython-313.pyc`, `Lib/encodings/__pycache__/utf_8.cpython-313.pyc`, `Lib/importlib/__pycache__/__init__.cpython-313.pyc`, `Lib/importlib/__pycache__/_abc.cpython-313.pyc`, `Lib/logging/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/_abc.cpython-313.pyc`, `Lib/pathlib/__pycache__/_local.cpython-313.pyc`, `Lib/re/__pycache__/__init__.cpython-313.pyc`, `Lib/re/__pycache__/_casefix.cpython-313.pyc`, `Lib/re/__pycache__/_compiler.cpython-313.pyc`, `Lib/re/__pycache__/_constants.cpython-313.pyc`, `Lib/re/__pycache__/_parser.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__init__.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__main__.cpython-313.pyc`, `Lib/xml/__pycache__/__init__.cpython-313.pyc`, `Lib/xml/etree/__pycache__/ElementPath.cpython-313.pyc`, `Lib/xml/etree/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_common.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_tzpath.cpython-313.pyc`, `Makefile`, `Makefile.pre`, `Misc/python-config.sh`, `Misc/python-embed.pc`, `Misc/python.pc`, `Modules/Setup.bootstrap`, `Modules/Setup.local`, `Modules/Setup.stdlib`, `Modules/_abc.o`, `Modules/_asyncio.cpython-313-x86_64-linux-gnu.so`, `Modules/_asynciomodule.o`, `Modules/_bisect.cpython-313-x86_64-linux-gnu.so`, `Modules/_bisectmodule.o`, `Modules/_blake2.cpython-313-x86_64-linux-gnu.so`, `Modules/_blake2/blake2b_impl.o`, `Modules/_blake2/blake2module.o`, `Modules/_blake2/blake2s_impl.o`, `Modules/_bz2.cpython-313-x86_64-linux-gnu.so`, `Modules/_bz2module.o`, `Modules/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecsmodule.o`, `Modules/_collectionsmodule.o`, `Modules/_contextvars.cpython-313-x86_64-linux-gnu.so`, `Modules/_contextvarsmodule.o`, `Modules/_csv.cpython-313-x86_64-linux-gnu.so`, `Modules/_csv.o`, `Modules/_ctypes.cpython-313-x86_64-linux-gnu.so`, `Modules/_ctypes/_ctypes.o`, `Modules/_ctypes/_ctypes_test.o`, `Modules/_ctypes/callbacks.o`, `Modules/_ctypes/callproc.o`, `Modules/_ctypes/cfield.o`, `Modules/_ctypes/stgdict.o`, `Modules/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.o`, `Modules/_cursesmodule.o`, `Modules/_datetime.cpython-313-x86_64-linux-gnu.so`, `Modules/_datetimemodule.o`, `Modules/_decimal.cpython-313-x86_64-linux-gnu.so`, `Modules/_decimal/_decimal.o`, `Modules/_decimal/libmpdec/basearith.o`, `Modules/_decimal/libmpdec/constants.o`, `Modules/_decimal/libmpdec/context.o`, `Modules/_decimal/libmpdec/convolute.o`, `Modules/_decimal/libmpdec/crt.o`, `Modules/_decimal/libmpdec/difradix2.o`, `Modules/_decimal/libmpdec/fnt.o`, `Modules/_decimal/libmpdec/fourstep.o`, `Modules/_decimal/libmpdec/io.o`, `Modules/_decimal/libmpdec/libmpdec.a`, `Modules/_decimal/libmpdec/mpalloc.o`, `Modules/_decimal/libmpdec/mpdecimal.o`, `Modules/_decimal/libmpdec/numbertheory.o`, `Modules/_decimal/libmpdec/sixstep.o`, `Modules/_decimal/libmpdec/transpose.o`, `Modules/_elementtree.cpython-313-x86_64-linux-gnu.so`, `Modules/_elementtree.o`, `Modules/_functoolsmodule.o`, `Modules/_hacl/Hacl_Hash_MD5.o`, `Modules/_hacl/Hacl_Hash_SHA1.o`, `Modules/_hacl/Hacl_Hash_SHA2.o`, `Modules/_hacl/Hacl_Hash_SHA3.o`, `Modules/_hacl/libHacl_Hash_SHA2.a`, `Modules/_hashlib.cpython-313-x86_64-linux-gnu.so`, `Modules/_hashopenssl.o`, `Modules/_heapq.cpython-313-x86_64-linux-gnu.so`, `Modules/_heapqmodule.o`, `Modules/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpchannelsmodule.o`, `Modules/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpqueuesmodule.o`, `Modules/_interpreters.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpretersmodule.o`, `Modules/_io/_iomodule.o`, `Modules/_io/bufferedio.o`, `Modules/_io/bytesio.o`, `Modules/_io/fileio.o`, `Modules/_io/iobase.o`, `Modules/_io/stringio.o`, `Modules/_io/textio.o`, `Modules/_json.cpython-313-x86_64-linux-gnu.so`, `Modules/_json.o`, `Modules/_localemodule.o`, `Modules/_lsprof.cpython-313-x86_64-linux-gnu.so`, `Modules/_lsprof.o`, `Modules/_lzma.cpython-313-x86_64-linux-gnu.so`, `Modules/_lzmamodule.o`, `Modules/_md5.cpython-313-x86_64-linux-gnu.so`, `Modules/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing/multiprocessing.o`, `Modules/_multiprocessing/posixshmem.o`, `Modules/_multiprocessing/semaphore.o`, `Modules/_opcode.cpython-313-x86_64-linux-gnu.so`, `Modules/_opcode.o`, `Modules/_operator.o`, `Modules/_pickle.cpython-313-x86_64-linux-gnu.so`, `Modules/_pickle.o`, `Modules/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.o`, `Modules/_queue.cpython-313-x86_64-linux-gnu.so`, `Modules/_queuemodule.o`, `Modules/_random.cpython-313-x86_64-linux-gnu.so`, `Modules/_randommodule.o`, `Modules/_sha1.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha2.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha3.cpython-313-x86_64-linux-gnu.so`, `Modules/_socket.cpython-313-x86_64-linux-gnu.so`, `Modules/_sqlite/blob.o`, `Modules/_sqlite/connection.o`, `Modules/_sqlite/cursor.o`, `Modules/_sqlite/microprotocols.o`, `Modules/_sqlite/module.o`, `Modules/_sqlite/prepare_protocol.o`, `Modules/_sqlite/row.o`, `Modules/_sqlite/statement.o`, `Modules/_sqlite/util.o`, `Modules/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `Modules/_sre/sre.o`, `Modules/_ssl.cpython-313-x86_64-linux-gnu.so`, `Modules/_ssl.o`, `Modules/_stat.o`, `Modules/_statistics.cpython-313-x86_64-linux-gnu.so`, `Modules/_statisticsmodule.o`, `Modules/_struct.cpython-313-x86_64-linux-gnu.so`, `Modules/_struct.o`, `Modules/_suggestions.o`, `Modules/_sysconfig.o`, `Modules/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `Modules/_testbuffer.o`, `Modules/_testcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testcapi/abstract.o`, `Modules/_testcapi/buffer.o`, `Modules/_testcapi/bytes.o`, `Modules/_testcapi/code.o`, `Modules/_testcapi/codec.o`, `Modules/_testcapi/complex.o`, `Modules/_testcapi/datetime.o`, `Modules/_testcapi/dict.o`, `Modules/_testcapi/docstring.o`, `Modules/_testcapi/exceptions.o`, `Modules/_testcapi/file.o`, `Modules/_testcapi/float.o`, `Modules/_testcapi/gc.o`, `Modules/_testcapi/getargs.o`, `Modules/_testcapi/hash.o`, `Modules/_testcapi/heaptype.o`, `Modules/_testcapi/immortal.o`, `Modules/_testcapi/list.o`, `Modules/_testcapi/long.o`, `Modules/_testcapi/mem.o`, `Modules/_testcapi/monitoring.o`, `Modules/_testcapi/numbers.o`, `Modules/_testcapi/object.o`, `Modules/_testcapi/pyatomic.o`, `Modules/_testcapi/run.o`, `Modules/_testcapi/set.o`, `Modules/_testcapi/structmember.o`, `Modules/_testcapi/time.o`, `Modules/_testcapi/tuple.o`, `Modules/_testcapi/unicode.o`, `Modules/_testcapi/vectorcall.o`, `Modules/_testcapi/watchers.o`, `Modules/_testcapimodule.o`, `Modules/_testclinic.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic.o`, `Modules/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic_limited.o`, `Modules/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `Modules/_testexternalinspection.o`, `Modules/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `Modules/_testimportmultiple.o`, `Modules/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testinternalcapi.o`, `Modules/_testinternalcapi/pytime.o`, `Modules/_testinternalcapi/set.o`, `Modules/_testinternalcapi/test_critical_sections.o`, `Modules/_testinternalcapi/test_lock.o`, `Modules/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testlimitedcapi.o`, `Modules/_testlimitedcapi/abstract.o`, `Modules/_testlimitedcapi/bytearray.o`, `Modules/_testlimitedcapi/bytes.o`, `Modules/_testlimitedcapi/complex.o`, `Modules/_testlimitedcapi/dict.o`, `Modules/_testlimitedcapi/eval.o`, `Modules/_testlimitedcapi/file.o`, `Modules/_testlimitedcapi/float.o`, `Modules/_testlimitedcapi/heaptype_relative.o`, `Modules/_testlimitedcapi/import.o`, `Modules/_testlimitedcapi/list.o`, `Modules/_testlimitedcapi/long.o`, `Modules/_testlimitedcapi/object.o`, `Modules/_testlimitedcapi/pyos.o`, `Modules/_testlimitedcapi/set.o`, `Modules/_testlimitedcapi/sys.o`, `Modules/_testlimitedcapi/tuple.o`, `Modules/_testlimitedcapi/unicode.o`, `Modules/_testlimitedcapi/vectorcall_limited.o`, `Modules/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testmultiphase.o`, `Modules/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testsinglephase.o`, `Modules/_threadmodule.o`, `Modules/_tracemalloc.o`, `Modules/_typingmodule.o`, `Modules/_uuid.cpython-313-x86_64-linux-gnu.so`, `Modules/_uuidmodule.o`, `Modules/_weakref.o`, `Modules/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `Modules/_xxtestfuzz/_xxtestfuzz.o`, `Modules/_xxtestfuzz/fuzzer.o`, `Modules/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `Modules/_zoneinfo.o`, `Modules/array.cpython-313-x86_64-linux-gnu.so`, `Modules/arraymodule.o`, `Modules/atexitmodule.o`, `Modules/binascii.cpython-313-x86_64-linux-gnu.so`, `Modules/binascii.o`, `Modules/cjkcodecs/_codecs_cn.o`, `Modules/cjkcodecs/_codecs_hk.o`, `Modules/cjkcodecs/_codecs_iso2022.o`, `Modules/cjkcodecs/_codecs_jp.o`, `Modules/cjkcodecs/_codecs_kr.o`, `Modules/cjkcodecs/_codecs_tw.o`, `Modules/cjkcodecs/multibytecodec.o`, `Modules/cmath.cpython-313-x86_64-linux-gnu.so`, `Modules/cmathmodule.o`, `Modules/config.c`, `Modules/config.o`, `Modules/errnomodule.o`, `Modules/expat/libexpat.a`, `Modules/expat/xmlparse.o`, `Modules/expat/xmlrole.o`, `Modules/expat/xmltok.o`, `Modules/faulthandler.o`, `Modules/fcntl.cpython-313-x86_64-linux-gnu.so`, `Modules/fcntlmodule.o`, `Modules/gcmodule.o`, `Modules/getbuildinfo.o`, `Modules/getpath.o`, `Modules/getpath_noop.o`, `Modules/grp.cpython-313-x86_64-linux-gnu.so`, `Modules/grpmodule.o`, `Modules/itertoolsmodule.o`, `Modules/ld_so_aix`, `Modules/main.o`, `Modules/math.cpython-313-x86_64-linux-gnu.so`, `Modules/mathmodule.o`, `Modules/md5module.o`, `Modules/mmap.cpython-313-x86_64-linux-gnu.so`, `Modules/mmapmodule.o`, `Modules/posixmodule.o`, `Modules/pwdmodule.o`, `Modules/pyexpat.cpython-313-x86_64-linux-gnu.so`, `Modules/pyexpat.o`, `Modules/readline.cpython-313-x86_64-linux-gnu.so`, `Modules/readline.o`, `Modules/resource.cpython-313-x86_64-linux-gnu.so`, `Modules/resource.o`, `Modules/rotatingtree.o`, `Modules/select.cpython-313-x86_64-linux-gnu.so`, `Modules/selectmodule.o`, `Modules/sha1module.o`, `Modules/sha2module.o`, `Modules/sha3module.o`, `Modules/signalmodule.o`, `Modules/socketmodule.o`, `Modules/symtablemodule.o`, `Modules/syslog.cpython-313-x86_64-linux-gnu.so`, `Modules/syslogmodule.o`, `Modules/termios.cpython-313-x86_64-linux-gnu.so`, `Modules/termios.o`, `Modules/timemodule.o`, `Modules/unicodedata.cpython-313-x86_64-linux-gnu.so`, `Modules/unicodedata.o`, `Modules/xxlimited.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited.o`, `Modules/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited_35.o`, `Modules/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `Modules/xxsubtype.o`, `Modules/zlib.cpython-313-x86_64-linux-gnu.so`, `Modules/zlibmodule.o`, `Objects/abstract.o`, `Objects/boolobject.o`, `Objects/bytearrayobject.o`, `Objects/bytes_methods.o`, `Objects/bytesobject.o`, `Objects/call.o`, `Objects/capsule.o`, `Objects/cellobject.o`, `Objects/classobject.o`, `Objects/codeobject.o`, `Objects/complexobject.o`, `Objects/descrobject.o`, `Objects/dictobject.o`, `Objects/enumobject.o`, `Objects/exceptions.o`, `Objects/fileobject.o`, `Objects/floatobject.o`, `Objects/frameobject.o`, `Objects/funcobject.o`, `Objects/genericaliasobject.o`, `Objects/genobject.o`, `Objects/iterobject.o`, `Objects/listobject.o`, `Objects/longobject.o`, `Objects/memoryobject.o`, `Objects/methodobject.o`, `Objects/moduleobject.o`, `Objects/namespaceobject.o`, `Objects/object.o`, `Objects/obmalloc.o`, `Objects/odictobject.o`, `Objects/picklebufobject.o`, `Objects/rangeobject.o`, `Objects/setobject.o`, `Objects/sliceobject.o`, `Objects/structseq.o`, `Objects/tupleobject.o`, `Objects/typeobject.o`, `Objects/typevarobject.o`, `Objects/unicodectype.o`, `Objects/unicodeobject.o`, `Objects/unionobject.o`, `Objects/weakrefobject.o`, `Parser/action_helpers.o`, `Parser/lexer/buffer.o`, `Parser/lexer/lexer.o`, `Parser/lexer/state.o`, `Parser/myreadline.o`, `Parser/parser.o`, `Parser/peg_api.o`, `Parser/pegen.o`, `Parser/pegen_errors.o`, `Parser/string_parser.o`, `Parser/token.o`, `Parser/tokenizer/file_tokenizer.o`, `Parser/tokenizer/helpers.o`, `Parser/tokenizer/readline_tokenizer.o`, `Parser/tokenizer/string_tokenizer.o`, `Parser/tokenizer/utf8_tokenizer.o`, `Programs/_bootstrap_python.o`, `Programs/_freeze_module`, `Programs/_freeze_module.o`, `Programs/_testembed`, `Programs/_testembed.o`, `Programs/python.o`, `Python/Python-ast.o`, `Python/Python-tokenize.o`, `Python/_warnings.o`, `Python/asdl.o`, `Python/asm_trampoline.o`, `Python/assemble.o`, `Python/ast.o`, `Python/ast_opt.o`, `Python/ast_unparse.o`, `Python/bltinmodule.o`, `Python/bootstrap_hash.o`, `Python/brc.o`, `Python/ceval.o`, `Python/ceval_gil.o`, `Python/codecs.o`, `Python/compile.o`, `Python/context.o`, `Python/critical_section.o`, `Python/crossinterp.o`, `Python/dtoa.o`, `Python/dynamic_annotations.o`, `Python/dynload_shlib.o`, `Python/errors.o`, `Python/fileutils.o`, `Python/flowgraph.o`, `Python/formatter_unicode.o`, `Python/frame.o`, `Python/frozen.o`, `Python/frozen_modules/__hello__.h`, `Python/frozen_modules/__phello__.h`, `Python/frozen_modules/__phello__.ham.eggs.h`, `Python/frozen_modules/__phello__.ham.h`, `Python/frozen_modules/__phello__.spam.h`, `Python/frozen_modules/_collections_abc.h`, `Python/frozen_modules/_sitebuiltins.h`, `Python/frozen_modules/abc.h`, `Python/frozen_modules/codecs.h`, `Python/frozen_modules/frozen_only.h`, `Python/frozen_modules/genericpath.h`, `Python/frozen_modules/getpath.h`, `Python/frozen_modules/importlib._bootstrap.h`, `Python/frozen_modules/importlib._bootstrap_external.h`, `Python/frozen_modules/importlib.machinery.h`, `Python/frozen_modules/importlib.util.h`, `Python/frozen_modules/io.h`, `Python/frozen_modules/ntpath.h`, `Python/frozen_modules/os.h`, `Python/frozen_modules/posixpath.h`, `Python/frozen_modules/runpy.h`, `Python/frozen_modules/site.h`, `Python/frozen_modules/stat.h`, `Python/frozen_modules/zipimport.h`, `Python/frozenmain.o`, `Python/future.o`, `Python/gc.o`, `Python/gc_free_threading.o`, `Python/gc_gil.o`, `Python/getargs.o`, `Python/getcompiler.o`, `Python/getcopyright.o`, `Python/getopt.o`, `Python/getplatform.o`, `Python/getversion.o`, `Python/hamt.o`, `Python/hashtable.o`, `Python/import.o`, `Python/importdl.o`, `Python/initconfig.o`, `Python/instruction_sequence.o`, `Python/instrumentation.o`, `Python/interpconfig.o`, `Python/intrinsics.o`, `Python/jit.o`, `Python/legacy_tracing.o`, `Python/lock.o`, `Python/marshal.o`, `Python/modsupport.o`, `Python/mysnprintf.o`, `Python/mystrtoul.o`, `Python/object_stack.o`, `Python/optimizer.o`, `Python/optimizer_analysis.o`, `Python/optimizer_symbols.o`, `Python/parking_lot.o`, `Python/pathconfig.o`, `Python/perf_jit_trampoline.o`, `Python/perf_trampoline.o`, `Python/preconfig.o`, `Python/pyarena.o`, `Python/pyctype.o`, `Python/pyfpe.o`, `Python/pyhash.o`, `Python/pylifecycle.o`, `Python/pymath.o`, `Python/pystate.o`, `Python/pystrcmp.o`, `Python/pystrhex.o`, `Python/pystrtod.o`, `Python/pythonrun.o`, `Python/pytime.o`, `Python/qsbr.o`, `Python/specialize.o`, `Python/structmember.o`, `Python/suggestions.o`, `Python/symtable.o`, `Python/sysmodule.o`, `Python/thread.o`, `Python/traceback.o`, `Python/tracemalloc.o`, `_bootstrap_python`, `build/lib.linux-x86_64-3.13/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-313.pyc`, `build/lib.linux-x86_64-3.13/_asyncio.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bisect.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_blake2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bz2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_contextvars.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_csv.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_datetime.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_decimal.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_elementtree.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_hashlib.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_heapq.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpreters.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_json.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lsprof.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lzma.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_md5.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_opcode.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_pickle.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_queue.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_random.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha1.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_socket.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ssl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_statistics.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_struct.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sysconfigdata__linux_x86_64-linux-gnu.py`, `build/lib.linux-x86_64-3.13/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_uuid.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/array.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/binascii.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/cmath.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/fcntl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/grp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/math.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/mmap.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/pyexpat.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/readline.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/resource.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/select.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/syslog.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/termios.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/unicodedata.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/zlib.cpython-313-x86_64-linux-gnu.so`, `build/scripts-3.13/idle3.13`, `build/scripts-3.13/pydoc3.13`, `config.log`, `config.status`, `libpython3.13.a`, `platform`, `pybuilddir.txt`, `pyconfig.h`, `python`, `python-config`, `python-config.py`, `python-gdb.py`.
2. Listed in `## Git Add Paths` but not actually changed: `None`.

## Refinement Pass 1

Subject: Diagnose apt_pkg CPU evidence outside CPython

## Commit Message
No CPython source change is proposed. The refinement addresses the review finding by removing generated validation artifacts from the workspace, keeping the no-patch diagnosis consistent with `Git Add Paths: None`.

## Evidence Confidence
inferred

## Issue Connection
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` consuming CPU under `/usr/bin/python3.13`, with 87,511 `newfstatat` calls in 5 seconds against `/var/lib/apt/lists/*`. Perf placed the hottest native path in `apt_pkg.cpython-313-x86_64-linux-gnu.so` and `libapt-pkg.so.7.0.0`, including `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()`.

The cautious inference remains that unattended-upgrade is repeatedly driving APT package-cache work through the `python3-apt` extension. The CPython frame `_PyObject_MakeTpCall` is normal C-extension call dispatch, not evidence of an interpreter-owned busy loop.

I made no source change. For this refinement, I removed only untracked build products and bytecode that were left by validation, addressing the review’s patch metadata drift finding. Checked conventions/helpers remain `README.rst` for CPython’s upstream build/test flow and local runtime helpers such as `_Py_read()`, `path_t`/`PyUnicode_FSConverter`, and `HAVE_FSTATAT_RUNTIME`; none fits the observed `apt_pkg`/`libapt-pkg` hot path. The expected effect is a clean no-patch report that does not misattribute APT extension behavior to CPython.

## Git Add Paths
None

## Validation
Previous project-level validation: `./configure && make` passed from the workspace root. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the interpreter and checked modules built successfully.

Independent reproduction attempt from the prior pass: `timeout 30s strace -f -c -e newfstatat python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache()'` was blocked by ptrace policy: `PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 5): Operation not permitted`.

Fallback smoke from the prior pass: `timeout 30s python3.13 -c 'import apt_pkg; apt_pkg.init(); apt_pkg.Cache(); print("apt_pkg cache smoke completed")'` completed normally, so the runaway syscall pattern was not independently reproduced.

Refinement check: `git status --short --untracked-files=all` and `git diff --name-only` are clean after removing generated artifacts.

## Review Pass 2

RESULT: ok

No findings. The workspace is clean, `## Git Add Paths` correctly lists `None`, and the no-patch diagnosis is consistent with the indirect evidence pointing at `python3-apt`/`libapt-pkg` rather than CPython runtime code.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1 (local metadata check)

Local metadata consistency check

## Refinement Pass 1

You are refining a fixer patch after an explicit code review.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Read the latest author response at `./patch-output.txt`. Read the review report at `./review-1-output.txt`. This is refinement round 1. The original pre-edit snapshot is available at `./source` if you need to compare the current patch against it. Re-read the planning pass at `./plan-output.txt` before editing. The workspace currently changes these repo-relative paths: Lib/__pycache__/__future__.cpython-313.pyc, Lib/__pycache__/_collections_abc.cpython-313.pyc, Lib/__pycache__/_colorize.cpython-313.pyc, Lib/__pycache__/_compat_pickle.cpython-313.pyc, Lib/__pycache__/_compression.cpython-313.pyc, Lib/__pycache__/_opcode_metadata.cpython-313.pyc, Lib/__pycache__/_sitebuiltins.cpython-313.pyc, Lib/__pycache__/_weakrefset.cpython-313.pyc, Lib/__pycache__/abc.cpython-313.pyc, Lib/__pycache__/argparse.cpython-313.pyc, Lib/__pycache__/ast.cpython-313.pyc, Lib/__pycache__/base64.cpython-313.pyc, Lib/__pycache__/bz2.cpython-313.pyc, Lib/__pycache__/codecs.cpython-313.pyc, Lib/__pycache__/contextlib.cpython-313.pyc, Lib/__pycache__/contextvars.cpython-313.pyc, Lib/__pycache__/copy.cpython-313.pyc, Lib/__pycache__/copyreg.cpython-313.pyc, Lib/__pycache__/datetime.cpython-313.pyc, Lib/__pycache__/dis.cpython-313.pyc, Lib/__pycache__/enum.cpython-313.pyc, Lib/__pycache__/fnmatch.cpython-313.pyc, Lib/__pycache__/functools.cpython-313.pyc, Lib/__pycache__/genericpath.cpython-313.pyc, Lib/__pycache__/gettext.cpython-313.pyc, Lib/__pycache__/glob.cpython-313.pyc, Lib/__pycache__/heapq.cpython-313.pyc, Lib/__pycache__/inspect.cpython-313.pyc, Lib/__pycache__/io.cpython-313.pyc, Lib/__pycache__/keyword.cpython-313.pyc, Lib/__pycache__/linecache.cpython-313.pyc, Lib/__pycache__/locale.cpython-313.pyc, Lib/__pycache__/lzma.cpython-313.pyc, Lib/__pycache__/numbers.cpython-313.pyc, Lib/__pycache__/opcode.cpython-313.pyc, Lib/__pycache__/operator.cpython-313.pyc, Lib/__pycache__/os.cpython-313.pyc, Lib/__pycache__/posixpath.cpython-313.pyc, Lib/__pycache__/reprlib.cpython-313.pyc, Lib/__pycache__/selectors.cpython-313.pyc, Lib/__pycache__/shutil.cpython-313.pyc, Lib/__pycache__/signal.cpython-313.pyc, Lib/__pycache__/site.cpython-313.pyc, Lib/__pycache__/socket.cpython-313.pyc, Lib/__pycache__/ssl.cpython-313.pyc, Lib/__pycache__/stat.cpython-313.pyc, Lib/__pycache__/string.cpython-313.pyc, Lib/__pycache__/struct.cpython-313.pyc, Lib/__pycache__/subprocess.cpython-313.pyc, Lib/__pycache__/textwrap.cpython-313.pyc, Lib/__pycache__/threading.cpython-313.pyc, Lib/__pycache__/token.cpython-313.pyc, Lib/__pycache__/tokenize.cpython-313.pyc, Lib/__pycache__/traceback.cpython-313.pyc, Lib/__pycache__/types.cpython-313.pyc, Lib/__pycache__/typing.cpython-313.pyc, Lib/__pycache__/warnings.cpython-313.pyc, Lib/__pycache__/weakref.cpython-313.pyc, Lib/asyncio/__pycache__/__init__.cpython-313.pyc, Lib/asyncio/__pycache__/base_events.cpython-313.pyc, Lib/asyncio/__pycache__/base_futures.cpython-313.pyc, Lib/asyncio/__pycache__/base_subprocess.cpython-313.pyc, Lib/asyncio/__pycache__/base_tasks.cpython-313.pyc, Lib/asyncio/__pycache__/constants.cpython-313.pyc, Lib/asyncio/__pycache__/coroutines.cpython-313.pyc, Lib/asyncio/__pycache__/events.cpython-313.pyc, Lib/asyncio/__pycache__/exceptions.cpython-313.pyc, Lib/asyncio/__pycache__/format_helpers.cpython-313.pyc, Lib/asyncio/__pycache__/futures.cpython-313.pyc, Lib/asyncio/__pycache__/locks.cpython-313.pyc, Lib/asyncio/__pycache__/log.cpython-313.pyc, Lib/asyncio/__pycache__/mixins.cpython-313.pyc, Lib/asyncio/__pycache__/protocols.cpython-313.pyc, Lib/asyncio/__pycache__/queues.cpython-313.pyc, Lib/asyncio/__pycache__/runners.cpython-313.pyc, Lib/asyncio/__pycache__/selector_events.cpython-313.pyc, Lib/asyncio/__pycache__/sslproto.cpython-313.pyc, Lib/asyncio/__pycache__/staggered.cpython-313.pyc, Lib/asyncio/__pycache__/streams.cpython-313.pyc, Lib/asyncio/__pycache__/subprocess.cpython-313.pyc, Lib/asyncio/__pycache__/taskgroups.cpython-313.pyc, Lib/asyncio/__pycache__/tasks.cpython-313.pyc, Lib/asyncio/__pycache__/threads.cpython-313.pyc, Lib/asyncio/__pycache__/timeouts.cpython-313.pyc, Lib/asyncio/__pycache__/transports.cpython-313.pyc, Lib/asyncio/__pycache__/trsock.cpython-313.pyc, Lib/asyncio/__pycache__/unix_events.cpython-313.pyc, Lib/collections/__pycache__/__init__.cpython-313.pyc, Lib/concurrent/__pycache__/__init__.cpython-313.pyc, Lib/concurrent/futures/__pycache__/__init__.cpython-313.pyc, Lib/concurrent/futures/__pycache__/_base.cpython-313.pyc, Lib/encodings/__pycache__/__init__.cpython-313.pyc, Lib/encodings/__pycache__/aliases.cpython-313.pyc, Lib/encodings/__pycache__/ascii.cpython-313.pyc, Lib/encodings/__pycache__/utf_8.cpython-313.pyc, Lib/importlib/__pycache__/__init__.cpython-313.pyc, Lib/importlib/__pycache__/_abc.cpython-313.pyc, Lib/logging/__pycache__/__init__.cpython-313.pyc, Lib/pathlib/__pycache__/__init__.cpython-313.pyc, Lib/pathlib/__pycache__/_abc.cpython-313.pyc, Lib/pathlib/__pycache__/_local.cpython-313.pyc, Lib/re/__pycache__/__init__.cpython-313.pyc, Lib/re/__pycache__/_casefix.cpython-313.pyc, Lib/re/__pycache__/_compiler.cpython-313.pyc, Lib/re/__pycache__/_constants.cpython-313.pyc, Lib/re/__pycache__/_parser.cpython-313.pyc, Lib/sysconfig/__pycache__/__init__.cpython-313.pyc, Lib/sysconfig/__pycache__/__main__.cpython-313.pyc, Lib/xml/__pycache__/__init__.cpython-313.pyc, Lib/xml/etree/__pycache__/ElementPath.cpython-313.pyc, Lib/xml/etree/__pycache__/__init__.cpython-313.pyc, Lib/zoneinfo/__pycache__/__init__.cpython-313.pyc, Lib/zoneinfo/__pycache__/_common.cpython-313.pyc, Lib/zoneinfo/__pycache__/_tzpath.cpython-313.pyc, Makefile, Makefile.pre, Misc/python-config.sh, Misc/python-embed.pc, Misc/python.pc, Modules/Setup.bootstrap, Modules/Setup.local, Modules/Setup.stdlib, Modules/_abc.o, Modules/_asyncio.cpython-313-x86_64-linux-gnu.so, Modules/_asynciomodule.o, Modules/_bisect.cpython-313-x86_64-linux-gnu.so, Modules/_bisectmodule.o, Modules/_blake2.cpython-313-x86_64-linux-gnu.so, Modules/_blake2/blake2b_impl.o, Modules/_blake2/blake2mo

[truncated 27774 bytes]

## Plan Pass

## Problem
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` consuming CPU, with repeated `newfstatat` calls against APT list files. The hot native DSO is `apt_pkg.cpython-313-x86_64-linux-gnu.so`, with additional hot symbols in `libapt-pkg.so.7.0.0`. The evidence does not currently identify a CPython-owned loop or CPython source location.

## Evidence Confidence
inferred

## Proposed Subject
No CPython source patch in this pass. Report this as an attribution/diagnosis: the observed runaway process is a Python interpreter hosting `unattended-upgrade`, but the collected hotspot points to `python3-apt`/`libapt-pkg`, not the CPython runtime.

## Patch Plan
Do not edit `python3.13` unless extra evidence shows CPython repeatedly issuing the stats from a CPython-owned API path.

If additional evidence is collected before editing, it should map the hot unresolved `apt_pkg` offset to a source line or show a Python-level stack in CPython stdlib code. Without that, a CPython patch would be speculative.

Local conventions checked: `README.rst` points contributors to the CPython Developer Guide and standard `./configure`, `make`, `make test`; `Include/README.rst` documents internal vs public C API boundaries. Relevant CPython file/stat helpers are `_Py_stat`, `_Py_fstat`, `_Py_fstat_noraise`, `path_t`, and `posix_do_stat()` in `Python/fileutils.c` and `Modules/posixmodule.c`; no relevant unattended-upgrade/python-apt helper exists in this tree.

No prior Fixer patch was found to improve or replace: git history shows only `Fixer baseline`, and searches under `debian`, `.pc`, `.agents`, and `.codex` found no Fixer patch for this issue.

## Risks
A CPython-side optimization could hide symptoms while leaving the real APT metadata scan behavior unchanged.

Changing `os.stat`/`fstatat` behavior for this evidence would be high blast radius and unjustified: repeated `newfstatat` is observable, but the caller appears to be `apt_pkg`/`libapt-pkg`.

## Validation
Before any future source edit, try the project build entrypoint from the workspace root:

```sh
./configure && make
```

If that fails due to missing dependencies or generated files, record the exact failure and then use the narrowest relevant CPython check.

Bounded independent reproduction attempt: run a local smoke command under `strace -c` for a simple CPython `os.stat` loop and confirm it only proves syscall behavior, not the unattended-upgrade failure. Do not claim `reproduced` unless a safe command can actually reproduce the high-CPU `unattended-upgrade`/`apt_pkg` signal.

## Patch Pass

Subject: Diagnose python-apt CPU hotspot outside CPython

## Commit Message
No source change was made. The collected perf, strace, and `/proc` evidence points to `unattended-upgrade` spending CPU in `python3-apt`/`libapt-pkg` while probing APT list files, not to a CPython-owned loop. A CPython patch would be speculative without a Python stack or native symbol mapping that identifies CPython as the caller.

## Evidence Confidence
inferred

## Issue Connection
The collected signal is a running `/usr/bin/python3 /usr/bin/unattended-upgrade` process at about 99.7% CPU, with 87,511 `newfstatat` calls in the trace and hot samples in `apt_pkg.cpython-313-x86_64-linux-gnu.so`, `pkgDepCache::MarkRequired()`, `pkgDepCache::Sweep()`, and `pkgCache::PkgIterator::operator++()`.

The cautious inference is that APT metadata traversal in `python3-apt`/`libapt-pkg` is repeatedly probing package-list and translation paths. CPython appears here as the interpreter hosting the application; the evidence does not identify `os.stat`, importlib, pathlib, or another CPython subsystem as the source of the loop.

I followed the saved plan and made no source change. I checked CPython’s local file/stat helpers (`_Py_stat`, `_Py_fstat`, `_Py_fstat_noraise`, `path_t`, and `posix_do_stat()`), plus the contribution/build guidance in `README.rst` and `Include/README.rst`; those helpers do not fit because the observed hotspot is in an external extension and libapt, not CPython’s stat wrappers.

The expected effect is that this proposal remains an upstreamable diagnosis instead of a misleading CPython patch. A stronger upstream bug report should target `python3-apt` or `libapt-pkg`, ideally with resolved symbols for the `apt_pkg` offset or a Python-level stack from the running `unattended-upgrade` process.

## Git Add Paths
None

## Validation
Ran `./configure && make` from the workspace root. It completed successfully. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the build finished with `0 failed on import`.

Attempted bounded syscall reproduction with:

```sh
timeout 10s strace -f -c ./python ...
timeout 10s strace -f -c /usr/bin/python3 /usr/bin/unattended-upgrade --help
```

Both strace attempts were blocked by the sandbox: `PTRACE_TRACEME: Operation not permitted` / `ptrace(PTRACE_SEIZE, ...): Operation not permitted`.

Ran safe smoke checks instead: `/usr/bin/python3` imports `apt_pkg`, `unattended-upgrade --help` exits normally, and a local `./python` loop doing 10,000 missing-file `os.stat()` calls completed in `0.007s`. That did not reproduce the high-CPU `unattended-upgrade` signal, so confidence stays `inferred`.

## Review Pass 1 (local metadata check)

RESULT: fix-needed

## Findings
1. Patch metadata drift: the workspace currently changes `Lib/__pycache__/__future__.cpython-313.pyc`, `Lib/__pycache__/_collections_abc.cpython-313.pyc`, `Lib/__pycache__/_colorize.cpython-313.pyc`, `Lib/__pycache__/_compat_pickle.cpython-313.pyc`, `Lib/__pycache__/_compression.cpython-313.pyc`, `Lib/__pycache__/_opcode_metadata.cpython-313.pyc`, `Lib/__pycache__/_sitebuiltins.cpython-313.pyc`, `Lib/__pycache__/_weakrefset.cpython-313.pyc`, `Lib/__pycache__/abc.cpython-313.pyc`, `Lib/__pycache__/argparse.cpython-313.pyc`, `Lib/__pycache__/ast.cpython-313.pyc`, `Lib/__pycache__/base64.cpython-313.pyc`, `Lib/__pycache__/bz2.cpython-313.pyc`, `Lib/__pycache__/codecs.cpython-313.pyc`, `Lib/__pycache__/contextlib.cpython-313.pyc`, `Lib/__pycache__/contextvars.cpython-313.pyc`, `Lib/__pycache__/copy.cpython-313.pyc`, `Lib/__pycache__/copyreg.cpython-313.pyc`, `Lib/__pycache__/datetime.cpython-313.pyc`, `Lib/__pycache__/dis.cpython-313.pyc`, `Lib/__pycache__/enum.cpython-313.pyc`, `Lib/__pycache__/fnmatch.cpython-313.pyc`, `Lib/__pycache__/functools.cpython-313.pyc`, `Lib/__pycache__/genericpath.cpython-313.pyc`, `Lib/__pycache__/gettext.cpython-313.pyc`, `Lib/__pycache__/glob.cpython-313.pyc`, `Lib/__pycache__/heapq.cpython-313.pyc`, `Lib/__pycache__/inspect.cpython-313.pyc`, `Lib/__pycache__/io.cpython-313.pyc`, `Lib/__pycache__/keyword.cpython-313.pyc`, `Lib/__pycache__/linecache.cpython-313.pyc`, `Lib/__pycache__/locale.cpython-313.pyc`, `Lib/__pycache__/lzma.cpython-313.pyc`, `Lib/__pycache__/numbers.cpython-313.pyc`, `Lib/__pycache__/opcode.cpython-313.pyc`, `Lib/__pycache__/operator.cpython-313.pyc`, `Lib/__pycache__/os.cpython-313.pyc`, `Lib/__pycache__/posixpath.cpython-313.pyc`, `Lib/__pycache__/reprlib.cpython-313.pyc`, `Lib/__pycache__/selectors.cpython-313.pyc`, `Lib/__pycache__/shutil.cpython-313.pyc`, `Lib/__pycache__/signal.cpython-313.pyc`, `Lib/__pycache__/site.cpython-313.pyc`, `Lib/__pycache__/socket.cpython-313.pyc`, `Lib/__pycache__/ssl.cpython-313.pyc`, `Lib/__pycache__/stat.cpython-313.pyc`, `Lib/__pycache__/string.cpython-313.pyc`, `Lib/__pycache__/struct.cpython-313.pyc`, `Lib/__pycache__/subprocess.cpython-313.pyc`, `Lib/__pycache__/textwrap.cpython-313.pyc`, `Lib/__pycache__/threading.cpython-313.pyc`, `Lib/__pycache__/token.cpython-313.pyc`, `Lib/__pycache__/tokenize.cpython-313.pyc`, `Lib/__pycache__/traceback.cpython-313.pyc`, `Lib/__pycache__/types.cpython-313.pyc`, `Lib/__pycache__/typing.cpython-313.pyc`, `Lib/__pycache__/warnings.cpython-313.pyc`, `Lib/__pycache__/weakref.cpython-313.pyc`, `Lib/asyncio/__pycache__/__init__.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/constants.cpython-313.pyc`, `Lib/asyncio/__pycache__/coroutines.cpython-313.pyc`, `Lib/asyncio/__pycache__/events.cpython-313.pyc`, `Lib/asyncio/__pycache__/exceptions.cpython-313.pyc`, `Lib/asyncio/__pycache__/format_helpers.cpython-313.pyc`, `Lib/asyncio/__pycache__/futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/locks.cpython-313.pyc`, `Lib/asyncio/__pycache__/log.cpython-313.pyc`, `Lib/asyncio/__pycache__/mixins.cpython-313.pyc`, `Lib/asyncio/__pycache__/protocols.cpython-313.pyc`, `Lib/asyncio/__pycache__/queues.cpython-313.pyc`, `Lib/asyncio/__pycache__/runners.cpython-313.pyc`, `Lib/asyncio/__pycache__/selector_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/sslproto.cpython-313.pyc`, `Lib/asyncio/__pycache__/staggered.cpython-313.pyc`, `Lib/asyncio/__pycache__/streams.cpython-313.pyc`, `Lib/asyncio/__pycache__/subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/taskgroups.cpython-313.pyc`, `Lib/asyncio/__pycache__/tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/threads.cpython-313.pyc`, `Lib/asyncio/__pycache__/timeouts.cpython-313.pyc`, `Lib/asyncio/__pycache__/transports.cpython-313.pyc`, `Lib/asyncio/__pycache__/trsock.cpython-313.pyc`, `Lib/asyncio/__pycache__/unix_events.cpython-313.pyc`, `Lib/collections/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/_base.cpython-313.pyc`, `Lib/encodings/__pycache__/__init__.cpython-313.pyc`, `Lib/encodings/__pycache__/aliases.cpython-313.pyc`, `Lib/encodings/__pycache__/ascii.cpython-313.pyc`, `Lib/encodings/__pycache__/utf_8.cpython-313.pyc`, `Lib/importlib/__pycache__/__init__.cpython-313.pyc`, `Lib/importlib/__pycache__/_abc.cpython-313.pyc`, `Lib/logging/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/_abc.cpython-313.pyc`, `Lib/pathlib/__pycache__/_local.cpython-313.pyc`, `Lib/re/__pycache__/__init__.cpython-313.pyc`, `Lib/re/__pycache__/_casefix.cpython-313.pyc`, `Lib/re/__pycache__/_compiler.cpython-313.pyc`, `Lib/re/__pycache__/_constants.cpython-313.pyc`, `Lib/re/__pycache__/_parser.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__init__.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__main__.cpython-313.pyc`, `Lib/xml/__pycache__/__init__.cpython-313.pyc`, `Lib/xml/etree/__pycache__/ElementPath.cpython-313.pyc`, `Lib/xml/etree/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_common.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_tzpath.cpython-313.pyc`, `Makefile`, `Makefile.pre`, `Misc/python-config.sh`, `Misc/python-embed.pc`, `Misc/python.pc`, `Modules/Setup.bootstrap`, `Modules/Setup.local`, `Modules/Setup.stdlib`, `Modules/_abc.o`, `Modules/_asyncio.cpython-313-x86_64-linux-gnu.so`, `Modules/_asynciomodule.o`, `Modules/_bisect.cpython-313-x86_64-linux-gnu.so`, `Modules/_bisectmodule.o`, `Modules/_blake2.cpython-313-x86_64-linux-gnu.so`, `Modules/_blake2/blake2b_impl.o`, `Modules/_blake2/blake2module.o`, `Modules/_blake2/blake2s_impl.o`, `Modules/_bz2.cpython-313-x86_64-linux-gnu.so`, `Modules/_bz2module.o`, `Modules/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecsmodule.o`, `Modules/_collectionsmodule.o`, `Modules/_contextvars.cpython-313-x86_64-linux-gnu.so`, `Modules/_contextvarsmodule.o`, `Modules/_csv.cpython-313-x86_64-linux-gnu.so`, `Modules/_csv.o`, `Modules/_ctypes.cpython-313-x86_64-linux-gnu.so`, `Modules/_ctypes/_ctypes.o`, `Modules/_ctypes/_ctypes_test.o`, `Modules/_ctypes/callbacks.o`, `Modules/_ctypes/callproc.o`, `Modules/_ctypes/cfield.o`, `Modules/_ctypes/stgdict.o`, `Modules/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.o`, `Modules/_cursesmodule.o`, `Modules/_datetime.cpython-313-x86_64-linux-gnu.so`, `Modules/_datetimemodule.o`, `Modules/_decimal.cpython-313-x86_64-linux-gnu.so`, `Modules/_decimal/_decimal.o`, `Modules/_decimal/libmpdec/basearith.o`, `Modules/_decimal/libmpdec/constants.o`, `Modules/_decimal/libmpdec/context.o`, `Modules/_decimal/libmpdec/convolute.o`, `Modules/_decimal/libmpdec/crt.o`, `Modules/_decimal/libmpdec/difradix2.o`, `Modules/_decimal/libmpdec/fnt.o`, `Modules/_decimal/libmpdec/fourstep.o`, `Modules/_decimal/libmpdec/io.o`, `Modules/_decimal/libmpdec/libmpdec.a`, `Modules/_decimal/libmpdec/mpalloc.o`, `Modules/_decimal/libmpdec/mpdecimal.o`, `Modules/_decimal/libmpdec/numbertheory.o`, `Modules/_decimal/libmpdec/sixstep.o`, `Modules/_decimal/libmpdec/transpose.o`, `Modules/_elementtree.cpython-313-x86_64-linux-gnu.so`, `Modules/_elementtree.o`, `Modules/_functoolsmodule.o`, `Modules/_hacl/Hacl_Hash_MD5.o`, `Modules/_hacl/Hacl_Hash_SHA1.o`, `Modules/_hacl/Hacl_Hash_SHA2.o`, `Modules/_hacl/Hacl_Hash_SHA3.o`, `Modules/_hacl/libHacl_Hash_SHA2.a`, `Modules/_hashlib.cpython-313-x86_64-linux-gnu.so`, `Modules/_hashopenssl.o`, `Modules/_heapq.cpython-313-x86_64-linux-gnu.so`, `Modules/_heapqmodule.o`, `Modules/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpchannelsmodule.o`, `Modules/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpqueuesmodule.o`, `Modules/_interpreters.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpretersmodule.o`, `Modules/_io/_iomodule.o`, `Modules/_io/bufferedio.o`, `Modules/_io/bytesio.o`, `Modules/_io/fileio.o`, `Modules/_io/iobase.o`, `Modules/_io/stringio.o`, `Modules/_io/textio.o`, `Modules/_json.cpython-313-x86_64-linux-gnu.so`, `Modules/_json.o`, `Modules/_localemodule.o`, `Modules/_lsprof.cpython-313-x86_64-linux-gnu.so`, `Modules/_lsprof.o`, `Modules/_lzma.cpython-313-x86_64-linux-gnu.so`, `Modules/_lzmamodule.o`, `Modules/_md5.cpython-313-x86_64-linux-gnu.so`, `Modules/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing/multiprocessing.o`, `Modules/_multiprocessing/posixshmem.o`, `Modules/_multiprocessing/semaphore.o`, `Modules/_opcode.cpython-313-x86_64-linux-gnu.so`, `Modules/_opcode.o`, `Modules/_operator.o`, `Modules/_pickle.cpython-313-x86_64-linux-gnu.so`, `Modules/_pickle.o`, `Modules/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.o`, `Modules/_queue.cpython-313-x86_64-linux-gnu.so`, `Modules/_queuemodule.o`, `Modules/_random.cpython-313-x86_64-linux-gnu.so`, `Modules/_randommodule.o`, `Modules/_sha1.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha2.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha3.cpython-313-x86_64-linux-gnu.so`, `Modules/_socket.cpython-313-x86_64-linux-gnu.so`, `Modules/_sqlite/blob.o`, `Modules/_sqlite/connection.o`, `Modules/_sqlite/cursor.o`, `Modules/_sqlite/microprotocols.o`, `Modules/_sqlite/module.o`, `Modules/_sqlite/prepare_protocol.o`, `Modules/_sqlite/row.o`, `Modules/_sqlite/statement.o`, `Modules/_sqlite/util.o`, `Modules/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `Modules/_sre/sre.o`, `Modules/_ssl.cpython-313-x86_64-linux-gnu.so`, `Modules/_ssl.o`, `Modules/_stat.o`, `Modules/_statistics.cpython-313-x86_64-linux-gnu.so`, `Modules/_statisticsmodule.o`, `Modules/_struct.cpython-313-x86_64-linux-gnu.so`, `Modules/_struct.o`, `Modules/_suggestions.o`, `Modules/_sysconfig.o`, `Modules/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `Modules/_testbuffer.o`, `Modules/_testcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testcapi/abstract.o`, `Modules/_testcapi/buffer.o`, `Modules/_testcapi/bytes.o`, `Modules/_testcapi/code.o`, `Modules/_testcapi/codec.o`, `Modules/_testcapi/complex.o`, `Modules/_testcapi/datetime.o`, `Modules/_testcapi/dict.o`, `Modules/_testcapi/docstring.o`, `Modules/_testcapi/exceptions.o`, `Modules/_testcapi/file.o`, `Modules/_testcapi/float.o`, `Modules/_testcapi/gc.o`, `Modules/_testcapi/getargs.o`, `Modules/_testcapi/hash.o`, `Modules/_testcapi/heaptype.o`, `Modules/_testcapi/immortal.o`, `Modules/_testcapi/list.o`, `Modules/_testcapi/long.o`, `Modules/_testcapi/mem.o`, `Modules/_testcapi/monitoring.o`, `Modules/_testcapi/numbers.o`, `Modules/_testcapi/object.o`, `Modules/_testcapi/pyatomic.o`, `Modules/_testcapi/run.o`, `Modules/_testcapi/set.o`, `Modules/_testcapi/structmember.o`, `Modules/_testcapi/time.o`, `Modules/_testcapi/tuple.o`, `Modules/_testcapi/unicode.o`, `Modules/_testcapi/vectorcall.o`, `Modules/_testcapi/watchers.o`, `Modules/_testcapimodule.o`, `Modules/_testclinic.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic.o`, `Modules/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic_limited.o`, `Modules/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `Modules/_testexternalinspection.o`, `Modules/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `Modules/_testimportmultiple.o`, `Modules/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testinternalcapi.o`, `Modules/_testinternalcapi/pytime.o`, `Modules/_testinternalcapi/set.o`, `Modules/_testinternalcapi/test_critical_sections.o`, `Modules/_testinternalcapi/test_lock.o`, `Modules/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testlimitedcapi.o`, `Modules/_testlimitedcapi/abstract.o`, `Modules/_testlimitedcapi/bytearray.o`, `Modules/_testlimitedcapi/bytes.o`, `Modules/_testlimitedcapi/complex.o`, `Modules/_testlimitedcapi/dict.o`, `Modules/_testlimitedcapi/eval.o`, `Modules/_testlimitedcapi/file.o`, `Modules/_testlimitedcapi/float.o`, `Modules/_testlimitedcapi/heaptype_relative.o`, `Modules/_testlimitedcapi/import.o`, `Modules/_testlimitedcapi/list.o`, `Modules/_testlimitedcapi/long.o`, `Modules/_testlimitedcapi/object.o`, `Modules/_testlimitedcapi/pyos.o`, `Modules/_testlimitedcapi/set.o`, `Modules/_testlimitedcapi/sys.o`, `Modules/_testlimitedcapi/tuple.o`, `Modules/_testlimitedcapi/unicode.o`, `Modules/_testlimitedcapi/vectorcall_limited.o`, `Modules/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testmultiphase.o`, `Modules/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testsinglephase.o`, `Modules/_threadmodule.o`, `Modules/_tracemalloc.o`, `Modules/_typingmodule.o`, `Modules/_uuid.cpython-313-x86_64-linux-gnu.so`, `Modules/_uuidmodule.o`, `Modules/_weakref.o`, `Modules/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `Modules/_xxtestfuzz/_xxtestfuzz.o`, `Modules/_xxtestfuzz/fuzzer.o`, `Modules/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `Modules/_zoneinfo.o`, `Modules/array.cpython-313-x86_64-linux-gnu.so`, `Modules/arraymodule.o`, `Modules/atexitmodule.o`, `Modules/binascii.cpython-313-x86_64-linux-gnu.so`, `Modules/binascii.o`, `Modules/cjkcodecs/_codecs_cn.o`, `Modules/cjkcodecs/_codecs_hk.o`, `Modules/cjkcodecs/_codecs_iso2022.o`, `Modules/cjkcodecs/_codecs_jp.o`, `Modules/cjkcodecs/_codecs_kr.o`, `Modules/cjkcodecs/_codecs_tw.o`, `Modules/cjkcodecs/multibytecodec.o`, `Modules/cmath.cpython-313-x86_64-linux-gnu.so`, `Modules/cmathmodule.o`, `Modules/config.c`, `Modules/config.o`, `Modules/errnomodule.o`, `Modules/expat/libexpat.a`, `Modules/expat/xmlparse.o`, `Modules/expat/xmlrole.o`, `Modules/expat/xmltok.o`, `Modules/faulthandler.o`, `Modules/fcntl.cpython-313-x86_64-linux-gnu.so`, `Modules/fcntlmodule.o`, `Modules/gcmodule.o`, `Modules/getbuildinfo.o`, `Modules/getpath.o`, `Modules/getpath_noop.o`, `Modules/grp.cpython-313-x86_64-linux-gnu.so`, `Modules/grpmodule.o`, `Modules/itertoolsmodule.o`, `Modules/ld_so_aix`, `Modules/main.o`, `Modules/math.cpython-313-x86_64-linux-gnu.so`, `Modules/mathmodule.o`, `Modules/md5module.o`, `Modules/mmap.cpython-313-x86_64-linux-gnu.so`, `Modules/mmapmodule.o`, `Modules/posixmodule.o`, `Modules/pwdmodule.o`, `Modules/pyexpat.cpython-313-x86_64-linux-gnu.so`, `Modules/pyexpat.o`, `Modules/readline.cpython-313-x86_64-linux-gnu.so`, `Modules/readline.o`, `Modules/resource.cpython-313-x86_64-linux-gnu.so`, `Modules/resource.o`, `Modules/rotatingtree.o`, `Modules/select.cpython-313-x86_64-linux-gnu.so`, `Modules/selectmodule.o`, `Modules/sha1module.o`, `Modules/sha2module.o`, `Modules/sha3module.o`, `Modules/signalmodule.o`, `Modules/socketmodule.o`, `Modules/symtablemodule.o`, `Modules/syslog.cpython-313-x86_64-linux-gnu.so`, `Modules/syslogmodule.o`, `Modules/termios.cpython-313-x86_64-linux-gnu.so`, `Modules/termios.o`, `Modules/timemodule.o`, `Modules/unicodedata.cpython-313-x86_64-linux-gnu.so`, `Modules/unicodedata.o`, `Modules/xxlimited.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited.o`, `Modules/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited_35.o`, `Modules/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `Modules/xxsubtype.o`, `Modules/zlib.cpython-313-x86_64-linux-gnu.so`, `Modules/zlibmodule.o`, `Objects/abstract.o`, `Objects/boolobject.o`, `Objects/bytearrayobject.o`, `Objects/bytes_methods.o`, `Objects/bytesobject.o`, `Objects/call.o`, `Objects/capsule.o`, `Objects/cellobject.o`, `Objects/classobject.o`, `Objects/codeobject.o`, `Objects/complexobject.o`, `Objects/descrobject.o`, `Objects/dictobject.o`, `Objects/enumobject.o`, `Objects/exceptions.o`, `Objects/fileobject.o`, `Objects/floatobject.o`, `Objects/frameobject.o`, `Objects/funcobject.o`, `Objects/genericaliasobject.o`, `Objects/genobject.o`, `Objects/iterobject.o`, `Objects/listobject.o`, `Objects/longobject.o`, `Objects/memoryobject.o`, `Objects/methodobject.o`, `Objects/moduleobject.o`, `Objects/namespaceobject.o`, `Objects/object.o`, `Objects/obmalloc.o`, `Objects/odictobject.o`, `Objects/picklebufobject.o`, `Objects/rangeobject.o`, `Objects/setobject.o`, `Objects/sliceobject.o`, `Objects/structseq.o`, `Objects/tupleobject.o`, `Objects/typeobject.o`, `Objects/typevarobject.o`, `Objects/unicodectype.o`, `Objects/unicodeobject.o`, `Objects/unionobject.o`, `Objects/weakrefobject.o`, `Parser/action_helpers.o`, `Parser/lexer/buffer.o`, `Parser/lexer/lexer.o`, `Parser/lexer/state.o`, `Parser/myreadline.o`, `Parser/parser.o`, `Parser/peg_api.o`, `Parser/pegen.o`, `Parser/pegen_errors.o`, `Parser/string_parser.o`, `Parser/token.o`, `Parser/tokenizer/file_tokenizer.o`, `Parser/tokenizer/helpers.o`, `Parser/tokenizer/readline_tokenizer.o`, `Parser/tokenizer/string_tokenizer.o`, `Parser/tokenizer/utf8_tokenizer.o`, `Programs/_bootstrap_python.o`, `Programs/_freeze_module`, `Programs/_freeze_module.o`, `Programs/_testembed`, `Programs/_testembed.o`, `Programs/python.o`, `Python/Python-ast.o`, `Python/Python-tokenize.o`, `Python/_warnings.o`, `Python/asdl.o`, `Python/asm_trampoline.o`, `Python/assemble.o`, `Python/ast.o`, `Python/ast_opt.o`, `Python/ast_unparse.o`, `Python/bltinmodule.o`, `Python/bootstrap_hash.o`, `Python/brc.o`, `Python/ceval.o`, `Python/ceval_gil.o`, `Python/codecs.o`, `Python/compile.o`, `Python/context.o`, `Python/critical_section.o`, `Python/crossinterp.o`, `Python/dtoa.o`, `Python/dynamic_annotations.o`, `Python/dynload_shlib.o`, `Python/errors.o`, `Python/fileutils.o`, `Python/flowgraph.o`, `Python/formatter_unicode.o`, `Python/frame.o`, `Python/frozen.o`, `Python/frozen_modules/__hello__.h`, `Python/frozen_modules/__phello__.h`, `Python/frozen_modules/__phello__.ham.eggs.h`, `Python/frozen_modules/__phello__.ham.h`, `Python/frozen_modules/__phello__.spam.h`, `Python/frozen_modules/_collections_abc.h`, `Python/frozen_modules/_sitebuiltins.h`, `Python/frozen_modules/abc.h`, `Python/frozen_modules/codecs.h`, `Python/frozen_modules/frozen_only.h`, `Python/frozen_modules/genericpath.h`, `Python/frozen_modules/getpath.h`, `Python/frozen_modules/importlib._bootstrap.h`, `Python/frozen_modules/importlib._bootstrap_external.h`, `Python/frozen_modules/importlib.machinery.h`, `Python/frozen_modules/importlib.util.h`, `Python/frozen_modules/io.h`, `Python/frozen_modules/ntpath.h`, `Python/frozen_modules/os.h`, `Python/frozen_modules/posixpath.h`, `Python/frozen_modules/runpy.h`, `Python/frozen_modules/site.h`, `Python/frozen_modules/stat.h`, `Python/frozen_modules/zipimport.h`, `Python/frozenmain.o`, `Python/future.o`, `Python/gc.o`, `Python/gc_free_threading.o`, `Python/gc_gil.o`, `Python/getargs.o`, `Python/getcompiler.o`, `Python/getcopyright.o`, `Python/getopt.o`, `Python/getplatform.o`, `Python/getversion.o`, `Python/hamt.o`, `Python/hashtable.o`, `Python/import.o`, `Python/importdl.o`, `Python/initconfig.o`, `Python/instruction_sequence.o`, `Python/instrumentation.o`, `Python/interpconfig.o`, `Python/intrinsics.o`, `Python/jit.o`, `Python/legacy_tracing.o`, `Python/lock.o`, `Python/marshal.o`, `Python/modsupport.o`, `Python/mysnprintf.o`, `Python/mystrtoul.o`, `Python/object_stack.o`, `Python/optimizer.o`, `Python/optimizer_analysis.o`, `Python/optimizer_symbols.o`, `Python/parking_lot.o`, `Python/pathconfig.o`, `Python/perf_jit_trampoline.o`, `Python/perf_trampoline.o`, `Python/preconfig.o`, `Python/pyarena.o`, `Python/pyctype.o`, `Python/pyfpe.o`, `Python/pyhash.o`, `Python/pylifecycle.o`, `Python/pymath.o`, `Python/pystate.o`, `Python/pystrcmp.o`, `Python/pystrhex.o`, `Python/pystrtod.o`, `Python/pythonrun.o`, `Python/pytime.o`, `Python/qsbr.o`, `Python/specialize.o`, `Python/structmember.o`, `Python/suggestions.o`, `Python/symtable.o`, `Python/sysmodule.o`, `Python/thread.o`, `Python/traceback.o`, `Python/tracemalloc.o`, `_bootstrap_python`, `build/lib.linux-x86_64-3.13/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-313.pyc`, `build/lib.linux-x86_64-3.13/_asyncio.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bisect.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_blake2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bz2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_contextvars.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_csv.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_datetime.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_decimal.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_elementtree.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_hashlib.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_heapq.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpreters.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_json.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lsprof.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lzma.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_md5.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_opcode.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_pickle.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_queue.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_random.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha1.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_socket.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ssl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_statistics.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_struct.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sysconfigdata__linux_x86_64-linux-gnu.py`, `build/lib.linux-x86_64-3.13/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_uuid.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/array.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/binascii.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/cmath.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/fcntl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/grp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/math.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/mmap.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/pyexpat.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/readline.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/resource.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/select.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/syslog.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/termios.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/unicodedata.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/zlib.cpython-313-x86_64-linux-gnu.so`, `build/scripts-3.13/idle3.13`, `build/scripts-3.13/pydoc3.13`, `config.log`, `config.status`, `libpython3.13.a`, `platform`, `pybuilddir.txt`, `pyconfig.h`, `python`, `python-config`, `python-config.py`, `python-gdb.py`, but `## Git Add Paths` lists `None`. Update `## Git Add Paths` to match the real shipped file set exactly, and make sure `## Issue Connection` explains every functional file that remains in the patch.
2. Missing from `## Git Add Paths`: `Lib/__pycache__/__future__.cpython-313.pyc`, `Lib/__pycache__/_collections_abc.cpython-313.pyc`, `Lib/__pycache__/_colorize.cpython-313.pyc`, `Lib/__pycache__/_compat_pickle.cpython-313.pyc`, `Lib/__pycache__/_compression.cpython-313.pyc`, `Lib/__pycache__/_opcode_metadata.cpython-313.pyc`, `Lib/__pycache__/_sitebuiltins.cpython-313.pyc`, `Lib/__pycache__/_weakrefset.cpython-313.pyc`, `Lib/__pycache__/abc.cpython-313.pyc`, `Lib/__pycache__/argparse.cpython-313.pyc`, `Lib/__pycache__/ast.cpython-313.pyc`, `Lib/__pycache__/base64.cpython-313.pyc`, `Lib/__pycache__/bz2.cpython-313.pyc`, `Lib/__pycache__/codecs.cpython-313.pyc`, `Lib/__pycache__/contextlib.cpython-313.pyc`, `Lib/__pycache__/contextvars.cpython-313.pyc`, `Lib/__pycache__/copy.cpython-313.pyc`, `Lib/__pycache__/copyreg.cpython-313.pyc`, `Lib/__pycache__/datetime.cpython-313.pyc`, `Lib/__pycache__/dis.cpython-313.pyc`, `Lib/__pycache__/enum.cpython-313.pyc`, `Lib/__pycache__/fnmatch.cpython-313.pyc`, `Lib/__pycache__/functools.cpython-313.pyc`, `Lib/__pycache__/genericpath.cpython-313.pyc`, `Lib/__pycache__/gettext.cpython-313.pyc`, `Lib/__pycache__/glob.cpython-313.pyc`, `Lib/__pycache__/heapq.cpython-313.pyc`, `Lib/__pycache__/inspect.cpython-313.pyc`, `Lib/__pycache__/io.cpython-313.pyc`, `Lib/__pycache__/keyword.cpython-313.pyc`, `Lib/__pycache__/linecache.cpython-313.pyc`, `Lib/__pycache__/locale.cpython-313.pyc`, `Lib/__pycache__/lzma.cpython-313.pyc`, `Lib/__pycache__/numbers.cpython-313.pyc`, `Lib/__pycache__/opcode.cpython-313.pyc`, `Lib/__pycache__/operator.cpython-313.pyc`, `Lib/__pycache__/os.cpython-313.pyc`, `Lib/__pycache__/posixpath.cpython-313.pyc`, `Lib/__pycache__/reprlib.cpython-313.pyc`, `Lib/__pycache__/selectors.cpython-313.pyc`, `Lib/__pycache__/shutil.cpython-313.pyc`, `Lib/__pycache__/signal.cpython-313.pyc`, `Lib/__pycache__/site.cpython-313.pyc`, `Lib/__pycache__/socket.cpython-313.pyc`, `Lib/__pycache__/ssl.cpython-313.pyc`, `Lib/__pycache__/stat.cpython-313.pyc`, `Lib/__pycache__/string.cpython-313.pyc`, `Lib/__pycache__/struct.cpython-313.pyc`, `Lib/__pycache__/subprocess.cpython-313.pyc`, `Lib/__pycache__/textwrap.cpython-313.pyc`, `Lib/__pycache__/threading.cpython-313.pyc`, `Lib/__pycache__/token.cpython-313.pyc`, `Lib/__pycache__/tokenize.cpython-313.pyc`, `Lib/__pycache__/traceback.cpython-313.pyc`, `Lib/__pycache__/types.cpython-313.pyc`, `Lib/__pycache__/typing.cpython-313.pyc`, `Lib/__pycache__/warnings.cpython-313.pyc`, `Lib/__pycache__/weakref.cpython-313.pyc`, `Lib/asyncio/__pycache__/__init__.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/base_tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/constants.cpython-313.pyc`, `Lib/asyncio/__pycache__/coroutines.cpython-313.pyc`, `Lib/asyncio/__pycache__/events.cpython-313.pyc`, `Lib/asyncio/__pycache__/exceptions.cpython-313.pyc`, `Lib/asyncio/__pycache__/format_helpers.cpython-313.pyc`, `Lib/asyncio/__pycache__/futures.cpython-313.pyc`, `Lib/asyncio/__pycache__/locks.cpython-313.pyc`, `Lib/asyncio/__pycache__/log.cpython-313.pyc`, `Lib/asyncio/__pycache__/mixins.cpython-313.pyc`, `Lib/asyncio/__pycache__/protocols.cpython-313.pyc`, `Lib/asyncio/__pycache__/queues.cpython-313.pyc`, `Lib/asyncio/__pycache__/runners.cpython-313.pyc`, `Lib/asyncio/__pycache__/selector_events.cpython-313.pyc`, `Lib/asyncio/__pycache__/sslproto.cpython-313.pyc`, `Lib/asyncio/__pycache__/staggered.cpython-313.pyc`, `Lib/asyncio/__pycache__/streams.cpython-313.pyc`, `Lib/asyncio/__pycache__/subprocess.cpython-313.pyc`, `Lib/asyncio/__pycache__/taskgroups.cpython-313.pyc`, `Lib/asyncio/__pycache__/tasks.cpython-313.pyc`, `Lib/asyncio/__pycache__/threads.cpython-313.pyc`, `Lib/asyncio/__pycache__/timeouts.cpython-313.pyc`, `Lib/asyncio/__pycache__/transports.cpython-313.pyc`, `Lib/asyncio/__pycache__/trsock.cpython-313.pyc`, `Lib/asyncio/__pycache__/unix_events.cpython-313.pyc`, `Lib/collections/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/__init__.cpython-313.pyc`, `Lib/concurrent/futures/__pycache__/_base.cpython-313.pyc`, `Lib/encodings/__pycache__/__init__.cpython-313.pyc`, `Lib/encodings/__pycache__/aliases.cpython-313.pyc`, `Lib/encodings/__pycache__/ascii.cpython-313.pyc`, `Lib/encodings/__pycache__/utf_8.cpython-313.pyc`, `Lib/importlib/__pycache__/__init__.cpython-313.pyc`, `Lib/importlib/__pycache__/_abc.cpython-313.pyc`, `Lib/logging/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/__init__.cpython-313.pyc`, `Lib/pathlib/__pycache__/_abc.cpython-313.pyc`, `Lib/pathlib/__pycache__/_local.cpython-313.pyc`, `Lib/re/__pycache__/__init__.cpython-313.pyc`, `Lib/re/__pycache__/_casefix.cpython-313.pyc`, `Lib/re/__pycache__/_compiler.cpython-313.pyc`, `Lib/re/__pycache__/_constants.cpython-313.pyc`, `Lib/re/__pycache__/_parser.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__init__.cpython-313.pyc`, `Lib/sysconfig/__pycache__/__main__.cpython-313.pyc`, `Lib/xml/__pycache__/__init__.cpython-313.pyc`, `Lib/xml/etree/__pycache__/ElementPath.cpython-313.pyc`, `Lib/xml/etree/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/__init__.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_common.cpython-313.pyc`, `Lib/zoneinfo/__pycache__/_tzpath.cpython-313.pyc`, `Makefile`, `Makefile.pre`, `Misc/python-config.sh`, `Misc/python-embed.pc`, `Misc/python.pc`, `Modules/Setup.bootstrap`, `Modules/Setup.local`, `Modules/Setup.stdlib`, `Modules/_abc.o`, `Modules/_asyncio.cpython-313-x86_64-linux-gnu.so`, `Modules/_asynciomodule.o`, `Modules/_bisect.cpython-313-x86_64-linux-gnu.so`, `Modules/_bisectmodule.o`, `Modules/_blake2.cpython-313-x86_64-linux-gnu.so`, `Modules/_blake2/blake2b_impl.o`, `Modules/_blake2/blake2module.o`, `Modules/_blake2/blake2s_impl.o`, `Modules/_bz2.cpython-313-x86_64-linux-gnu.so`, `Modules/_bz2module.o`, `Modules/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `Modules/_codecsmodule.o`, `Modules/_collectionsmodule.o`, `Modules/_contextvars.cpython-313-x86_64-linux-gnu.so`, `Modules/_contextvarsmodule.o`, `Modules/_csv.cpython-313-x86_64-linux-gnu.so`, `Modules/_csv.o`, `Modules/_ctypes.cpython-313-x86_64-linux-gnu.so`, `Modules/_ctypes/_ctypes.o`, `Modules/_ctypes/_ctypes_test.o`, `Modules/_ctypes/callbacks.o`, `Modules/_ctypes/callproc.o`, `Modules/_ctypes/cfield.o`, `Modules/_ctypes/stgdict.o`, `Modules/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `Modules/_curses_panel.o`, `Modules/_cursesmodule.o`, `Modules/_datetime.cpython-313-x86_64-linux-gnu.so`, `Modules/_datetimemodule.o`, `Modules/_decimal.cpython-313-x86_64-linux-gnu.so`, `Modules/_decimal/_decimal.o`, `Modules/_decimal/libmpdec/basearith.o`, `Modules/_decimal/libmpdec/constants.o`, `Modules/_decimal/libmpdec/context.o`, `Modules/_decimal/libmpdec/convolute.o`, `Modules/_decimal/libmpdec/crt.o`, `Modules/_decimal/libmpdec/difradix2.o`, `Modules/_decimal/libmpdec/fnt.o`, `Modules/_decimal/libmpdec/fourstep.o`, `Modules/_decimal/libmpdec/io.o`, `Modules/_decimal/libmpdec/libmpdec.a`, `Modules/_decimal/libmpdec/mpalloc.o`, `Modules/_decimal/libmpdec/mpdecimal.o`, `Modules/_decimal/libmpdec/numbertheory.o`, `Modules/_decimal/libmpdec/sixstep.o`, `Modules/_decimal/libmpdec/transpose.o`, `Modules/_elementtree.cpython-313-x86_64-linux-gnu.so`, `Modules/_elementtree.o`, `Modules/_functoolsmodule.o`, `Modules/_hacl/Hacl_Hash_MD5.o`, `Modules/_hacl/Hacl_Hash_SHA1.o`, `Modules/_hacl/Hacl_Hash_SHA2.o`, `Modules/_hacl/Hacl_Hash_SHA3.o`, `Modules/_hacl/libHacl_Hash_SHA2.a`, `Modules/_hashlib.cpython-313-x86_64-linux-gnu.so`, `Modules/_hashopenssl.o`, `Modules/_heapq.cpython-313-x86_64-linux-gnu.so`, `Modules/_heapqmodule.o`, `Modules/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpchannelsmodule.o`, `Modules/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpqueuesmodule.o`, `Modules/_interpreters.cpython-313-x86_64-linux-gnu.so`, `Modules/_interpretersmodule.o`, `Modules/_io/_iomodule.o`, `Modules/_io/bufferedio.o`, `Modules/_io/bytesio.o`, `Modules/_io/fileio.o`, `Modules/_io/iobase.o`, `Modules/_io/stringio.o`, `Modules/_io/textio.o`, `Modules/_json.cpython-313-x86_64-linux-gnu.so`, `Modules/_json.o`, `Modules/_localemodule.o`, `Modules/_lsprof.cpython-313-x86_64-linux-gnu.so`, `Modules/_lsprof.o`, `Modules/_lzma.cpython-313-x86_64-linux-gnu.so`, `Modules/_lzmamodule.o`, `Modules/_md5.cpython-313-x86_64-linux-gnu.so`, `Modules/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `Modules/_multiprocessing/multiprocessing.o`, `Modules/_multiprocessing/posixshmem.o`, `Modules/_multiprocessing/semaphore.o`, `Modules/_opcode.cpython-313-x86_64-linux-gnu.so`, `Modules/_opcode.o`, `Modules/_operator.o`, `Modules/_pickle.cpython-313-x86_64-linux-gnu.so`, `Modules/_pickle.o`, `Modules/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `Modules/_posixsubprocess.o`, `Modules/_queue.cpython-313-x86_64-linux-gnu.so`, `Modules/_queuemodule.o`, `Modules/_random.cpython-313-x86_64-linux-gnu.so`, `Modules/_randommodule.o`, `Modules/_sha1.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha2.cpython-313-x86_64-linux-gnu.so`, `Modules/_sha3.cpython-313-x86_64-linux-gnu.so`, `Modules/_socket.cpython-313-x86_64-linux-gnu.so`, `Modules/_sqlite/blob.o`, `Modules/_sqlite/connection.o`, `Modules/_sqlite/cursor.o`, `Modules/_sqlite/microprotocols.o`, `Modules/_sqlite/module.o`, `Modules/_sqlite/prepare_protocol.o`, `Modules/_sqlite/row.o`, `Modules/_sqlite/statement.o`, `Modules/_sqlite/util.o`, `Modules/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `Modules/_sre/sre.o`, `Modules/_ssl.cpython-313-x86_64-linux-gnu.so`, `Modules/_ssl.o`, `Modules/_stat.o`, `Modules/_statistics.cpython-313-x86_64-linux-gnu.so`, `Modules/_statisticsmodule.o`, `Modules/_struct.cpython-313-x86_64-linux-gnu.so`, `Modules/_struct.o`, `Modules/_suggestions.o`, `Modules/_sysconfig.o`, `Modules/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `Modules/_testbuffer.o`, `Modules/_testcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testcapi/abstract.o`, `Modules/_testcapi/buffer.o`, `Modules/_testcapi/bytes.o`, `Modules/_testcapi/code.o`, `Modules/_testcapi/codec.o`, `Modules/_testcapi/complex.o`, `Modules/_testcapi/datetime.o`, `Modules/_testcapi/dict.o`, `Modules/_testcapi/docstring.o`, `Modules/_testcapi/exceptions.o`, `Modules/_testcapi/file.o`, `Modules/_testcapi/float.o`, `Modules/_testcapi/gc.o`, `Modules/_testcapi/getargs.o`, `Modules/_testcapi/hash.o`, `Modules/_testcapi/heaptype.o`, `Modules/_testcapi/immortal.o`, `Modules/_testcapi/list.o`, `Modules/_testcapi/long.o`, `Modules/_testcapi/mem.o`, `Modules/_testcapi/monitoring.o`, `Modules/_testcapi/numbers.o`, `Modules/_testcapi/object.o`, `Modules/_testcapi/pyatomic.o`, `Modules/_testcapi/run.o`, `Modules/_testcapi/set.o`, `Modules/_testcapi/structmember.o`, `Modules/_testcapi/time.o`, `Modules/_testcapi/tuple.o`, `Modules/_testcapi/unicode.o`, `Modules/_testcapi/vectorcall.o`, `Modules/_testcapi/watchers.o`, `Modules/_testcapimodule.o`, `Modules/_testclinic.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic.o`, `Modules/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `Modules/_testclinic_limited.o`, `Modules/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `Modules/_testexternalinspection.o`, `Modules/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `Modules/_testimportmultiple.o`, `Modules/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testinternalcapi.o`, `Modules/_testinternalcapi/pytime.o`, `Modules/_testinternalcapi/set.o`, `Modules/_testinternalcapi/test_critical_sections.o`, `Modules/_testinternalcapi/test_lock.o`, `Modules/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `Modules/_testlimitedcapi.o`, `Modules/_testlimitedcapi/abstract.o`, `Modules/_testlimitedcapi/bytearray.o`, `Modules/_testlimitedcapi/bytes.o`, `Modules/_testlimitedcapi/complex.o`, `Modules/_testlimitedcapi/dict.o`, `Modules/_testlimitedcapi/eval.o`, `Modules/_testlimitedcapi/file.o`, `Modules/_testlimitedcapi/float.o`, `Modules/_testlimitedcapi/heaptype_relative.o`, `Modules/_testlimitedcapi/import.o`, `Modules/_testlimitedcapi/list.o`, `Modules/_testlimitedcapi/long.o`, `Modules/_testlimitedcapi/object.o`, `Modules/_testlimitedcapi/pyos.o`, `Modules/_testlimitedcapi/set.o`, `Modules/_testlimitedcapi/sys.o`, `Modules/_testlimitedcapi/tuple.o`, `Modules/_testlimitedcapi/unicode.o`, `Modules/_testlimitedcapi/vectorcall_limited.o`, `Modules/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testmultiphase.o`, `Modules/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `Modules/_testsinglephase.o`, `Modules/_threadmodule.o`, `Modules/_tracemalloc.o`, `Modules/_typingmodule.o`, `Modules/_uuid.cpython-313-x86_64-linux-gnu.so`, `Modules/_uuidmodule.o`, `Modules/_weakref.o`, `Modules/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `Modules/_xxtestfuzz/_xxtestfuzz.o`, `Modules/_xxtestfuzz/fuzzer.o`, `Modules/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `Modules/_zoneinfo.o`, `Modules/array.cpython-313-x86_64-linux-gnu.so`, `Modules/arraymodule.o`, `Modules/atexitmodule.o`, `Modules/binascii.cpython-313-x86_64-linux-gnu.so`, `Modules/binascii.o`, `Modules/cjkcodecs/_codecs_cn.o`, `Modules/cjkcodecs/_codecs_hk.o`, `Modules/cjkcodecs/_codecs_iso2022.o`, `Modules/cjkcodecs/_codecs_jp.o`, `Modules/cjkcodecs/_codecs_kr.o`, `Modules/cjkcodecs/_codecs_tw.o`, `Modules/cjkcodecs/multibytecodec.o`, `Modules/cmath.cpython-313-x86_64-linux-gnu.so`, `Modules/cmathmodule.o`, `Modules/config.c`, `Modules/config.o`, `Modules/errnomodule.o`, `Modules/expat/libexpat.a`, `Modules/expat/xmlparse.o`, `Modules/expat/xmlrole.o`, `Modules/expat/xmltok.o`, `Modules/faulthandler.o`, `Modules/fcntl.cpython-313-x86_64-linux-gnu.so`, `Modules/fcntlmodule.o`, `Modules/gcmodule.o`, `Modules/getbuildinfo.o`, `Modules/getpath.o`, `Modules/getpath_noop.o`, `Modules/grp.cpython-313-x86_64-linux-gnu.so`, `Modules/grpmodule.o`, `Modules/itertoolsmodule.o`, `Modules/ld_so_aix`, `Modules/main.o`, `Modules/math.cpython-313-x86_64-linux-gnu.so`, `Modules/mathmodule.o`, `Modules/md5module.o`, `Modules/mmap.cpython-313-x86_64-linux-gnu.so`, `Modules/mmapmodule.o`, `Modules/posixmodule.o`, `Modules/pwdmodule.o`, `Modules/pyexpat.cpython-313-x86_64-linux-gnu.so`, `Modules/pyexpat.o`, `Modules/readline.cpython-313-x86_64-linux-gnu.so`, `Modules/readline.o`, `Modules/resource.cpython-313-x86_64-linux-gnu.so`, `Modules/resource.o`, `Modules/rotatingtree.o`, `Modules/select.cpython-313-x86_64-linux-gnu.so`, `Modules/selectmodule.o`, `Modules/sha1module.o`, `Modules/sha2module.o`, `Modules/sha3module.o`, `Modules/signalmodule.o`, `Modules/socketmodule.o`, `Modules/symtablemodule.o`, `Modules/syslog.cpython-313-x86_64-linux-gnu.so`, `Modules/syslogmodule.o`, `Modules/termios.cpython-313-x86_64-linux-gnu.so`, `Modules/termios.o`, `Modules/timemodule.o`, `Modules/unicodedata.cpython-313-x86_64-linux-gnu.so`, `Modules/unicodedata.o`, `Modules/xxlimited.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited.o`, `Modules/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `Modules/xxlimited_35.o`, `Modules/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `Modules/xxsubtype.o`, `Modules/zlib.cpython-313-x86_64-linux-gnu.so`, `Modules/zlibmodule.o`, `Objects/abstract.o`, `Objects/boolobject.o`, `Objects/bytearrayobject.o`, `Objects/bytes_methods.o`, `Objects/bytesobject.o`, `Objects/call.o`, `Objects/capsule.o`, `Objects/cellobject.o`, `Objects/classobject.o`, `Objects/codeobject.o`, `Objects/complexobject.o`, `Objects/descrobject.o`, `Objects/dictobject.o`, `Objects/enumobject.o`, `Objects/exceptions.o`, `Objects/fileobject.o`, `Objects/floatobject.o`, `Objects/frameobject.o`, `Objects/funcobject.o`, `Objects/genericaliasobject.o`, `Objects/genobject.o`, `Objects/iterobject.o`, `Objects/listobject.o`, `Objects/longobject.o`, `Objects/memoryobject.o`, `Objects/methodobject.o`, `Objects/moduleobject.o`, `Objects/namespaceobject.o`, `Objects/object.o`, `Objects/obmalloc.o`, `Objects/odictobject.o`, `Objects/picklebufobject.o`, `Objects/rangeobject.o`, `Objects/setobject.o`, `Objects/sliceobject.o`, `Objects/structseq.o`, `Objects/tupleobject.o`, `Objects/typeobject.o`, `Objects/typevarobject.o`, `Objects/unicodectype.o`, `Objects/unicodeobject.o`, `Objects/unionobject.o`, `Objects/weakrefobject.o`, `Parser/action_helpers.o`, `Parser/lexer/buffer.o`, `Parser/lexer/lexer.o`, `Parser/lexer/state.o`, `Parser/myreadline.o`, `Parser/parser.o`, `Parser/peg_api.o`, `Parser/pegen.o`, `Parser/pegen_errors.o`, `Parser/string_parser.o`, `Parser/token.o`, `Parser/tokenizer/file_tokenizer.o`, `Parser/tokenizer/helpers.o`, `Parser/tokenizer/readline_tokenizer.o`, `Parser/tokenizer/string_tokenizer.o`, `Parser/tokenizer/utf8_tokenizer.o`, `Programs/_bootstrap_python.o`, `Programs/_freeze_module`, `Programs/_freeze_module.o`, `Programs/_testembed`, `Programs/_testembed.o`, `Programs/python.o`, `Python/Python-ast.o`, `Python/Python-tokenize.o`, `Python/_warnings.o`, `Python/asdl.o`, `Python/asm_trampoline.o`, `Python/assemble.o`, `Python/ast.o`, `Python/ast_opt.o`, `Python/ast_unparse.o`, `Python/bltinmodule.o`, `Python/bootstrap_hash.o`, `Python/brc.o`, `Python/ceval.o`, `Python/ceval_gil.o`, `Python/codecs.o`, `Python/compile.o`, `Python/context.o`, `Python/critical_section.o`, `Python/crossinterp.o`, `Python/dtoa.o`, `Python/dynamic_annotations.o`, `Python/dynload_shlib.o`, `Python/errors.o`, `Python/fileutils.o`, `Python/flowgraph.o`, `Python/formatter_unicode.o`, `Python/frame.o`, `Python/frozen.o`, `Python/frozen_modules/__hello__.h`, `Python/frozen_modules/__phello__.h`, `Python/frozen_modules/__phello__.ham.eggs.h`, `Python/frozen_modules/__phello__.ham.h`, `Python/frozen_modules/__phello__.spam.h`, `Python/frozen_modules/_collections_abc.h`, `Python/frozen_modules/_sitebuiltins.h`, `Python/frozen_modules/abc.h`, `Python/frozen_modules/codecs.h`, `Python/frozen_modules/frozen_only.h`, `Python/frozen_modules/genericpath.h`, `Python/frozen_modules/getpath.h`, `Python/frozen_modules/importlib._bootstrap.h`, `Python/frozen_modules/importlib._bootstrap_external.h`, `Python/frozen_modules/importlib.machinery.h`, `Python/frozen_modules/importlib.util.h`, `Python/frozen_modules/io.h`, `Python/frozen_modules/ntpath.h`, `Python/frozen_modules/os.h`, `Python/frozen_modules/posixpath.h`, `Python/frozen_modules/runpy.h`, `Python/frozen_modules/site.h`, `Python/frozen_modules/stat.h`, `Python/frozen_modules/zipimport.h`, `Python/frozenmain.o`, `Python/future.o`, `Python/gc.o`, `Python/gc_free_threading.o`, `Python/gc_gil.o`, `Python/getargs.o`, `Python/getcompiler.o`, `Python/getcopyright.o`, `Python/getopt.o`, `Python/getplatform.o`, `Python/getversion.o`, `Python/hamt.o`, `Python/hashtable.o`, `Python/import.o`, `Python/importdl.o`, `Python/initconfig.o`, `Python/instruction_sequence.o`, `Python/instrumentation.o`, `Python/interpconfig.o`, `Python/intrinsics.o`, `Python/jit.o`, `Python/legacy_tracing.o`, `Python/lock.o`, `Python/marshal.o`, `Python/modsupport.o`, `Python/mysnprintf.o`, `Python/mystrtoul.o`, `Python/object_stack.o`, `Python/optimizer.o`, `Python/optimizer_analysis.o`, `Python/optimizer_symbols.o`, `Python/parking_lot.o`, `Python/pathconfig.o`, `Python/perf_jit_trampoline.o`, `Python/perf_trampoline.o`, `Python/preconfig.o`, `Python/pyarena.o`, `Python/pyctype.o`, `Python/pyfpe.o`, `Python/pyhash.o`, `Python/pylifecycle.o`, `Python/pymath.o`, `Python/pystate.o`, `Python/pystrcmp.o`, `Python/pystrhex.o`, `Python/pystrtod.o`, `Python/pythonrun.o`, `Python/pytime.o`, `Python/qsbr.o`, `Python/specialize.o`, `Python/structmember.o`, `Python/suggestions.o`, `Python/symtable.o`, `Python/sysmodule.o`, `Python/thread.o`, `Python/traceback.o`, `Python/tracemalloc.o`, `_bootstrap_python`, `build/lib.linux-x86_64-3.13/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-313.pyc`, `build/lib.linux-x86_64-3.13/_asyncio.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bisect.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_blake2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_bz2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_cn.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_hk.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_iso2022.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_jp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_kr.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_codecs_tw.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_contextvars.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_csv.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ctypes_test.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_curses_panel.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_datetime.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_decimal.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_elementtree.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_hashlib.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_heapq.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpchannels.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpqueues.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_interpreters.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_json.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lsprof.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_lzma.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_md5.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multibytecodec.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_multiprocessing.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_opcode.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_pickle.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixshmem.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_posixsubprocess.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_queue.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_random.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha1.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha2.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sha3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_socket.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sqlite3.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_ssl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_statistics.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_struct.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_sysconfigdata__linux_x86_64-linux-gnu.py`, `build/lib.linux-x86_64-3.13/_testbuffer.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testclinic_limited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testexternalinspection.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testimportmultiple.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testinternalcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testlimitedcapi.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testmultiphase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_testsinglephase.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_uuid.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_xxtestfuzz.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/_zoneinfo.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/array.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/binascii.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/cmath.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/fcntl.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/grp.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/math.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/mmap.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/pyexpat.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/readline.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/resource.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/select.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/syslog.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/termios.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/unicodedata.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxlimited_35.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/xxsubtype.cpython-313-x86_64-linux-gnu.so`, `build/lib.linux-x86_64-3.13/zlib.cpython-313-x86_64-linux-gnu.so`, `build/scripts-3.13/idle3.13`, `build/scripts-3.13/pydoc3.13`, `config.log`, `config.status`, `libpython3.13.a`, `platform`, `pybuilddir.txt`, `pyconfig.h`, `python`, `python-config`, `python-config.py`, `python-gdb.py`.
2. Listed in `## Git Add Paths` but not actually changed: `None`.

## Refinement Pass 1

Subject: Diagnose python-apt CPU hotspot outside CPython

## Commit Message
No source change was made. The reviewed issue was patch metadata drift from generated build outputs, so I removed those artifacts and kept the proposal as a no-patch diagnosis. The collected evidence still points to `unattended-upgrade` spending CPU in `python3-apt`/`libapt-pkg`, not in a CPython-owned loop.

## Evidence Confidence
inferred

## Issue Connection
The collected signal is `/usr/bin/python3 /usr/bin/unattended-upgrade` running at about 99.7% CPU, with 87,511 `newfstatat` calls and hot samples in `apt_pkg.cpython-313-x86_64-linux-gnu.so`, `pkgDepCache::MarkRequired()`, `pkgDepCache::Sweep()`, and `pkgCache::PkgIterator::operator++()`.

The cautious inference is that APT metadata traversal in `python3-apt`/`libapt-pkg` is repeatedly probing package-list and translation paths. CPython appears to be the host interpreter; the evidence does not identify `os.stat`, importlib, pathlib, or another CPython subsystem as the source of the loop.

I followed the saved plan and made no source change. I addressed the review finding by cleaning the generated build outputs so the workspace matches `## Git Add Paths: None`. I also rechecked CPython’s file/stat helpers (`_Py_stat`, `_Py_fstat`, `_Py_fstat_noraise`, `path_t`, and `posix_do_stat()`); they do not fit because the observed hotspot is in an external extension and libapt.

The expected effect is that this remains an upstreamable diagnosis rather than a misleading CPython patch. A stronger bug report should target `python3-apt` or `libapt-pkg`, ideally with resolved symbols for the `apt_pkg` offset or a Python-level stack from the running `unattended-upgrade` process.

## Git Add Paths
None

## Validation
Previously ran `./configure && make` from the workspace root. It completed successfully; optional modules `_dbm`, `_gdbm`, and `_tkinter` were missing, but the build finished with `0 failed on import`.

Attempted bounded reproduction with:

```sh
timeout 10s strace -f -c ./python ...
timeout 10s strace -f -c /usr/bin/python3 /usr/bin/unattended-upgrade --help
```

Both were blocked by sandbox ptrace restrictions: `PTRACE_TRACEME: Operation not permitted` / `ptrace(PTRACE_SEIZE, ...): Operation not permitted`.

In this refinement round, ran `make distclean` to address the review’s metadata-drift finding, then `git status --short`; status produced no output. No source files remain changed.

## Review Pass 2

RESULT: ok

No findings. The workspace is clean after refinement, `## Git Add Paths` correctly lists `None`, and the response keeps evidence confidence at `inferred` with a no-patch diagnosis. The validation and issue connection are consistent with the evidence and do not claim a reproduced CPython bug.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Plan Pass

## Problem
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` consuming CPU, but the hot path is not in CPython: the evidence names `apt_pkg.cpython-313-x86_64-linux-gnu.so` at 17.47%, `libapt-pkg.so.7.0.0` symbols, and 87,511 `newfstatat` calls against `/var/lib/apt/lists/...`. The prepared source tree is `python3.13`, which does not contain `python3-apt`, `libapt-pkg`, or `unattended-upgrades` sources.

## Evidence Confidence
observed

The runaway process, syscall pattern, and native backtrace were observed by Fixer, but I did not independently reproduce the runaway loop. A later final `## Issue Connection` should say the failure was observed by Fixer and not independently reproduced.

## Proposed Subject
No CPython source patch in this workspace. The maintainer-facing subject should be a diagnosis/reassignment: `python3.13: no actionable CPython fix; hot path is python3-apt/libapt-pkg during unattended-upgrade apt cache scanning`.

## Patch Plan
Do not edit `python3.13` for this evidence. A CPython patch would be speculative because `os.stat()`/`fstatat()` already uses CPython’s local `path_t` conversion, `posix_do_stat()`, `_Py_fstat_noraise`, and `Py_BEGIN_ALLOW_THREADS` conventions, while the captured hot DSO is `apt_pkg`, not `Modules/posixmodule.c`.

If this is pursued as a source fix, replace this workspace with the correct source package first: likely `python3-apt`, `apt`, or possibly `unattended-upgrades`, then inspect the apt cache/file-list iteration around `apt.Cache.open()`, `apt_pkg.Cache`, `DepCache`, and `pkgDepCache::MarkRequired/Sweep`.

No prior Fixer patch relevant to this issue was found in the workspace. I would also avoid awkward control flow such as introducing `goto` in CPython or Debian packaging because there is no bounded CPython change to make.

## Risks
The main risk is misattribution: patching CPython could hide the real regression while changing global interpreter/stat behavior for every Python program. Another risk is inventing a user-visible bug from profiler evidence only; the bundle supports a targeted performance diagnosis, not a confirmed CPython correctness bug.

## Validation
Before any focused compile for a real CPython patch, try the project entrypoint from the workspace root:

`./configure && make`

If that fails because dependencies or generated files are missing, record the exact failure and then run the narrowest relevant compile/test.

For a cheap independent signal before editing the correct package, run a bounded read-only apt cache probe under Python 3.13:

`timeout 20s strace -f -e trace=newfstatat python3.13 -c 'import apt; c=apt.Cache(); c.open()'`

This can show whether the repeated `newfstatat` pattern is reproducible locally, but it should not be claimed as reproducing the unattended-upgrade runaway unless it also demonstrates sustained CPU or looping behavior.

## Patch Pass

Subject: python3.13: diagnose apt_pkg CPU trace without CPython patch

## Commit Message
No source change is proposed for CPython. The collected profile and strace data point to `apt_pkg` and `libapt-pkg` while `unattended-upgrade` scans APT package metadata, not to CPython’s stat or interpreter runtime paths.

## Evidence Confidence
inferred

## Issue Connection
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` running at high CPU, with 87,511 `newfstatat` calls in a 5 second trace and the hottest native frame in `apt_pkg.cpython-313-x86_64-linux-gnu.so`. The same evidence names `libapt-pkg.so.7.0.0` frames such as `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()`, which are APT dependency-cache operations.

The likely root cause is repeated APT list-file probing inside `python3-apt` or `libapt-pkg`, reached from `unattended-upgrade`, rather than CPython’s `os.stat()` implementation. CPython’s nearby code already uses its local path/stat conventions: `path_t`, `posix_do_stat()`, `_Py_fstat_noraise`, and `Py_BEGIN_ALLOW_THREADS` around filesystem syscalls.

I followed the saved plan and did not change course: a `python3.13` source patch would be speculative because this workspace does not contain the implicated `apt_pkg`, `libapt-pkg`, or `unattended-upgrades` sources. The expected effect of this no-patch diagnosis is to avoid a misleading CPython change and route the report to the package that owns the observed hot path.

## Git Add Paths
None

## Validation
Read `README.rst`; no `CONTRIBUTING`, `HACKING`, or `README-hacking` file was present. The README points contributors to the CPython Developer Guide and lists the Unix build entrypoint.

Ran project-level validation from the workspace root:

`./configure && make`

Result: succeeded. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the core build completed.

Attempted bounded independent reproduction of the collected syscall signal:

`timeout 20s strace -f -e trace=newfstatat -o /tmp/fixer-apt-cache.strace python3.13 -c 'import apt; c=apt.Cache(); c.open()'`

Result: blocked by sandbox ptrace restrictions: `PTRACE_TRACEME: Operation not permitted` and `ptrace(PTRACE_SEIZE, 7): Operation not permitted`.

Fallback smoke check:

`/usr/bin/time -f 'elapsed=%e maxrss=%M status=%x' timeout 20s python3.13 -c 'import apt; c=apt.Cache(); c.open(); print(len(c))'`

Result: completed normally, printed `120028`, `elapsed=0.90`, `status=0`. This did not reproduce the runaway CPU behavior.

## Review Pass 1

RESULT: ok

No source patch is present: `git status --short` is clean, and the workspace has no tracked source changes to review.

The author output includes the required sections, uses an allowed evidence confidence value, avoids claiming local reproduction, and explains why the `python3.13` tree is the wrong place for a speculative fix. Validation includes the project-level `./configure && make` entrypoint and a bounded reproduction attempt; the strace blocker is reported with the concrete ptrace error. The no-patch diagnosis is acceptable for this evidence because the hot frames and syscall pattern point to `apt_pkg`/`libapt-pkg`, not CPython code.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Plan Pass

## Problem
Fixer observed high CPU in a Python 3.13 process launched by unattended-upgrades. The evidence points to application/extension work: `/usr/bin/unattended-upgrade` or `unattended-upgrade-shutdown`, with hot frames in `apt_pkg.cpython-313-...so`, `libapt-pkg.so.7.0`, GLib/DBus loops, and repeated `newfstatat` over APT list files. The CPython source tree does not contain `apt_pkg` or unattended-upgrades, so a CPython runtime patch is not justified from this bundle.

## Evidence Confidence
inferred

## Proposed Subject
No CPython patch: diagnose and redirect the finding to `python3-apt`, `libapt-pkg`, or `unattended-upgrades` after a bounded reproduction attempt. Do not carry a Debian-local workaround in `python3.13` for an apparent extension/application loop.

## Patch Plan
No files should be edited in this pass. If later evidence proves a CPython bug, inspect the specific runtime path then, following CPython conventions from `README.rst`, `Doc/README.rst`, `.pre-commit-config.yaml`, and `Tools/patchcheck`.

Relevant local CPython helpers/conventions found: `Modules/posixmodule.c` uses `path_t`, `path_converter`, `posix_do_stat()`, `path_error()`, `Py_BEGIN_ALLOW_THREADS`, and Argument Clinic generated wrappers around `os.stat`/`os.lstat`; `Python/fileutils.c` has `_Py_stat()`/`_Py_fstat()`. None addresses repeated APT metadata probing inside `apt_pkg`/`libapt-pkg`. No prior Fixer patch for this issue was found in the workspace; Debian patches are unrelated.

Avoid awkward control flow such as adding throttling or `goto`-based escape paths in CPython’s stat wrappers, because that would change generic runtime semantics while the observed loop is outside CPython.

## Risks
A CPython patch here would likely mask or misattribute an APT/python-apt behavior and could regress normal filesystem APIs. The evidence is profiler/trace based and does not show a CPython-level defect, only Python hosting native extension code that is doing the hot work.

## Validation
Before reporting any focused check, try the project build entrypoint from the workspace root: `./configure && make`.

For the bounded independent signal check, run a safe timed trace such as `timeout 10s strace -f -e trace=newfstatat /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug` and compare whether repeated APT list `newfstatat` calls appear. If dependencies, permissions, or generated files block either command, record the exact command and failure reason; do not claim reproduced unless the timed trace actually shows the collected failure signal.

## Patch Pass

Subject: No patch: diagnose unattended-upgrades CPU trace

## Commit Message
No source patch is proposed. The collected perf, strace, and `/proc` evidence points to unattended-upgrades doing APT metadata work through `python3-apt`/`libapt-pkg`, not to a CPython runtime defect. The hot shared object is `apt_pkg.cpython-313-x86_64-linux-gnu.so`, the repeated syscall is `newfstatat` over `/var/lib/apt/lists`, and the CPython frames are interpreter dispatch around extension code.

## Evidence Confidence
inferred

## Issue Connection
Fixer collected a running Python 3.13 process at up to 99.7% CPU with 87,511 `newfstatat` calls in a 5-second trace, plus hot samples in `apt_pkg.cpython-313-x86_64-linux-gnu.so`, `pkgDepCache::MarkRequired`, and `pkgDepCache::Sweep`. The process command was `/usr/bin/python3 /usr/bin/unattended-upgrade`.

The cautious code-level inference is that CPython is hosting a native extension and application workload that repeatedly probes APT package-list paths. I inspected CPython’s relevant filesystem helpers and conventions: `Modules/posixmodule.c` uses `path_t`, `path_converter`, `posix_do_stat()`, `path_error()`, and `Py_BEGIN_ALLOW_THREADS`; `Python/fileutils.c` provides `_Py_stat()` and `_Py_fstat()`. Those wrappers correctly expose stat operations and do not contain APT-specific retry, cache, or event-loop logic.

I followed the saved plan and did not change course: no source files were edited. A CPython patch would be speculative and could change generic stat/runtime behavior to mask a workload that appears to belong in `python3-apt`, `libapt-pkg`, or unattended-upgrades. The expected effect is no runtime behavior change in CPython; this should be reported upstream against the APT/python-apt side with the collected trace evidence.

Contribution/style docs checked: `README.rst` and `Doc/README.rst`, which point to the CPython Developer Guide and the standard `./configure`, `make`, and `make test` workflow. No relevant local helper was found that would make a CPython source mitigation appropriate.

## Git Add Paths
None

## Validation
Ran project-level entrypoint from the workspace root:

`./configure && make`

Result: passed. Configure reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but the build completed successfully.

Attempted bounded independent reproduction of the collected syscall signal:

`timeout 10s strace -f -e trace=newfstatat -o /tmp/fixer-unattended-upgrade-newfstatat.log /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`

Result: blocked by sandbox ptrace restrictions. Exact failure: `strace: do_test_ptrace_get_syscall_info: PTRACE_TRACEME: Operation not permitted` and `strace: attach: ptrace(PTRACE_SEIZE, 7): Operation not permitted`; the output log was empty. I therefore did not classify the issue as reproduced.

## Review Pass 1

RESULT: ok

No source changes are present, and the no-patch diagnosis is consistent with the evidence. The author correctly keeps confidence at `inferred`, avoids a speculative CPython runtime patch, names the relevant CPython helper patterns inspected, and reports both project-level validation and the exact blocker for the independent `strace` reproduction attempt.

The workspace is clean, so `## Git Add Paths: None` matches the actual patch state.

python3.13 likely remains stuck in a busy-poll loop. A diagnosis report and patch proposal were created locally.

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation

Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.

## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.

## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.

## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.

## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing.

Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `python3.13` upstream patch, not just a Debian-local workaround.

Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Plan Pass

## Problem
Fixer observed high CPU in `/usr/bin/python3 /usr/bin/unattended-upgrade`, but the hot evidence points outside CPython: `apt_pkg.cpython-313-x86_64-linux-gnu.so`, `libapt-pkg.so.7.0.0`, and repeated `newfstatat()` probes under `/var/lib/apt/lists`. The CPython frame `_PyObject_MakeTpCall()` is only the generic C-extension call path into `apt_pkg`, not evidence of an interpreter loop bug.

## Evidence Confidence
observed

## Proposed Subject
No CPython source patch: diagnose as an observed `python-apt`/`libapt-pkg` or `unattended-upgrade` busy apt-list scan, not a `python3.13` runtime defect.

## Patch Plan
Do not edit this `python3.13` source package unless new evidence shows CPython runtime behavior is causal.

I checked CPython contribution guidance in `README.rst`, which points to the Python Developer Guide and uses the normal `./configure`, `make`, `make test` workflow. Debian packaging uses quilt per `debian/README.source`; no prior Fixer patch or workspace diff was present.

Relevant local CPython helper/convention found: calls flow through `_PyObject_VectorcallTstate()` and `_PyObject_MakeTpCall()` in `Objects/call.c`, with `_Py_CheckFunctionResult()` validation. No relevant local helper for apt cache/file probing exists in this source tree, and `apt_pkg`/`unattended-upgrade` are absent from the package.

If this were redirected to the right source package, the patch should target the repeated apt list stat/probe behavior with a bounded cache or loop guard in the apt-facing code, avoiding awkward control flow such as an avoidable `goto`.

## Risks
Patching CPython here would likely mask or misattribute a hot path owned by `python-apt`, `libapt-pkg`, or `unattended-upgrade`.

The profiler evidence is indirect and symbol-poor: raw artifact paths referenced in `evidence.json` are not present locally, and the top hot symbol in `apt_pkg` is unresolved.

## Validation
First try the project-level entrypoint from the workspace root before any focused check: `./configure && make`. If it fails because dependencies or generated files are missing, record the exact command and failure.

For a bounded independent reproduction attempt of the observed signal, run from the workspace root if available and safe: `timeout 30s strace -f -c -e trace=newfstatat /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`. This can show whether the repeated `newfstatat()` pattern is reproducible, but it should not be claimed as reproduced unless it actually shows the same failure signal.

## Patch Pass

Subject: No CPython change for apt-side unattended-upgrade scan

## Commit Message
No source change. The collected trace points to repeated apt package-list probing in `python-apt`/`libapt-pkg` while called from Python, not to a CPython runtime loop.

## Evidence Confidence
observed

## Issue Connection
Fixer observed `/usr/bin/python3 /usr/bin/unattended-upgrade` consuming high CPU, with `/proc` state `R`, 87,511 `newfstatat()` syscalls in a 5-second strace sample, and the hot DSO reported as `apt_pkg.cpython-313-x86_64-linux-gnu.so`. The top native frames also include `libapt-pkg` work such as `pkgDepCache::MarkRequired()` and `pkgDepCache::Sweep()`.

The likely root cause is repeated apt cache/list-file probing in the apt stack. CPython appears only as the embedding interpreter and as the generic extension-call path through `_PyObject_MakeTpCall()`, which adapts Python calls to a type’s `tp_call` slot. I inspected that call path and found no CPython-side state machine, file probing loop, or apt-specific code to patch.

I followed the saved plan and did not make a speculative CPython source change. `README.rst` points to the CPython Developer Guide and normal `./configure`, `make`, `make test` workflow; `debian/README.source` says Debian patches are quilt-managed. No relevant local helper for apt cache/file probing exists in this repository. The relevant local CPython call helpers are `_PyObject_VectorcallTstate()`, `_PyObject_MakeTpCall()`, and `_Py_CheckFunctionResult()`, but they are normal call dispatch/validation helpers, not the source of the repeated `newfstatat()` activity.

The expected effect is that the proposal avoids an upstream-unready CPython patch and leaves a focused diagnosis suitable for redirecting the issue to `python-apt`, `libapt-pkg`, or `unattended-upgrade`.

## Git Add Paths
None

## Validation
Ran the project-level workspace-root entrypoint:

`./configure && make`

Result: passed. The build completed successfully. Configure/build reported optional modules `_dbm`, `_gdbm`, and `_tkinter` missing, but these were non-fatal optional-module misses.

Attempted bounded independent reproduction of the collected syscall signal:

`timeout 30s strace -f -c -e trace=newfstatat /usr/bin/python3 /usr/bin/unattended-upgrade --dry-run --debug`

Result: blocked before the target could run because ptrace is not permitted in this environment:

`strace: do_test_ptrace_get_syscall_info: PTRACE_TRACEME: Operation not permitted`
`strace: attach: ptrace(PTRACE_SEIZE, 5): Operation not permitted`

Also checked that `/usr/bin/unattended-upgrade` exists and `apt_pkg` imports successfully under `/usr/bin/python3`; that confirms the local apt Python binding is present but does not reproduce the high-CPU syscall pattern.

## Review Pass 1

RESULT: ok

No findings. The first pass leaves no source diff, which matches the evidence: the hot path is in `apt_pkg`/`libapt-pkg`, while CPython only appears in the generic extension call path.

The report includes `## Evidence Confidence` with a valid value, avoids claiming reproduction, names the blocked strace reproduction attempt, documents the project-level `./configure && make` validation, and explains the relevant CPython helper/convention review. The workspace is clean against git; snapshot diff only shows local `.agents`/`.codex` metadata.