Problem
docs/doctor-findings.md lists this finding ID:
| BASE-P050 | Project virtual environment integrity |
This finding ID is documented as stable and part of the automation contract. However, the Bash-layer checks in setup_common.sh and doctor.sh check only for virtual environment existence (-f $venv_dir/pyvenv.cfg), not integrity. The integrity check (does $venv_dir/bin/python execute? does pyvenv.cfg reference a live Python?) is described in issue #323 but has not yet been implemented.
The gap creates a misleading contract: automation that matches on BASE-P050 to detect broken venvs will never see this finding in practice because the check is never emitted.
The base-environment findings BASE-D004 ("Base virtual environment integrity") may have the same gap — the current check tests for existence, not that ~/.base.d/base/.venv/bin/python actually runs.
Fix
One of:
Option A — implement the integrity check first, then document the ID
Implement the virtualenv integrity check (#323) before BASE-P050 is listed as a shipped finding ID. Remove the entry from doctor-findings.md and add it back once the check actually emits it.
Option B — mark it as planned in the doc
Add a "Planned (not yet emitted)" column or note to doctor-findings.md for IDs that have been reserved but whose checks are not yet implemented. This prevents automation from depending on IDs that do not yet exist while still reserving the namespace.
Option C — add a preamble
Add a sentence at the top of the findings table: "Finding IDs listed here are either emitted by the current release or reserved for planned checks. Check the implementation before building automation against a specific ID."
Option B or C is the lowest-cost near-term fix. Option A is preferred once #323 is resolved.
Problem
docs/doctor-findings.mdlists this finding ID:This finding ID is documented as stable and part of the automation contract. However, the Bash-layer checks in
setup_common.shanddoctor.shcheck only for virtual environment existence (-f $venv_dir/pyvenv.cfg), not integrity. The integrity check (does$venv_dir/bin/pythonexecute? doespyvenv.cfgreference a live Python?) is described in issue #323 but has not yet been implemented.The gap creates a misleading contract: automation that matches on
BASE-P050to detect broken venvs will never see this finding in practice because the check is never emitted.The base-environment findings
BASE-D004("Base virtual environment integrity") may have the same gap — the current check tests for existence, not that~/.base.d/base/.venv/bin/pythonactually runs.Fix
One of:
Option A — implement the integrity check first, then document the ID
Implement the virtualenv integrity check (#323) before
BASE-P050is listed as a shipped finding ID. Remove the entry fromdoctor-findings.mdand add it back once the check actually emits it.Option B — mark it as planned in the doc
Add a "Planned (not yet emitted)" column or note to
doctor-findings.mdfor IDs that have been reserved but whose checks are not yet implemented. This prevents automation from depending on IDs that do not yet exist while still reserving the namespace.Option C — add a preamble
Add a sentence at the top of the findings table: "Finding IDs listed here are either emitted by the current release or reserved for planned checks. Check the implementation before building automation against a specific ID."
Option B or C is the lowest-cost near-term fix. Option A is preferred once #323 is resolved.