Skip to content

Centralize static and executing project-interpreter probes #2301

Description

@codeforester

Goal

Use one Base-owned runtime-inspection implementation for static interpreter presence and one for the opt-in executing probe. Route workspace and setup callers through those primitives while keeping their report-specific classifications.

Background

Repository-wide duplication review against f9c18f3294873cbbcda9acc7af7f1bc6b17eed45 (2026-09-17).

Workspace reporting and setup implement almost the same five-second python -c "import sys" subprocess probe. They differ in their executable-bit precheck. Static interpreter presence is also repeated in workspace status, runtime inspection and uv, with different OSError handling. These primitives govern related readiness and execution-consent behavior.

Verified source locations:

No matching open issue was found in the repository backlog.

This is a maintainability refactor. Similarity alone is not evidence of a production failure; any demonstrated differences are called out above.

Scope

Use one Base-owned runtime-inspection implementation for static interpreter presence and one for the opt-in executing probe. Route workspace and setup callers through those primitives while keeping their report-specific classifications.

Acceptance Criteria

  • Static presence never executes a project interpreter.
  • Executing probe retains its bounded timeout, suppressed output and false result for execution/timeout failures.
  • All callers use the same explicit filesystem-error and executable-bit policy.
  • Keep the opt-in verification boundary, uv sync checks and shell-only not-applicable behavior unchanged.
  • Preserve compatibility wrappers/re-exports only where callers require them.

Validation

Run workspace status/check tests and setup manifest/runtime tests. Cover missing, nonexecutable, successful, nonzero, timed-out and inaccessible interpreters using harmless stubs. Assert that default static inspection never invokes subprocess.

Run focused checks first, then the repository-required broader checks for the actual implementation. Preserve public command contracts and review .ai-context/ impact in the PR.

Non-Goals

Do not turn static checks into execution or remove consent; no native-Windows implementation in this issue.

Project Fields

  • Status: Ready
  • Priority: P2
  • Area: Runtime
  • Initiative: Contract Hardening
  • Size: S
  • Milestone: Unscheduled; no release commitment is implied by this audit.

Agent Assignment

Implementation-ready scoped follow-up, assigned to codeforester. Follow AGENTS.md and docs/github-workflow.md: start through basectl gh issue start, use the canonical issue worktree, characterize current behavior before extraction, and open an issue-linked PR. Keep each refactor independently reviewable.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or product improvement

Type

No type

Projects

  • Status
    Done

Relationships

None yet

Development

No branches or pull requests

Issue actions