P2: Define and project the canonical Python capability ledger

[tomdps]

Parent

Tracking parent #251; epic #243. This is one vertical delivery slice. Do not close or bypass the parent tracker from this child.

Goal

Create one typed source of product truth and project identical rows through every non-document runtime surface before public wording changes.

Dependency contract

• P0 — Make Python syntax validation compiler-truthful #244
• P0 — Harden Python type checking and configuration semantics #245
• P0 — Resolve Python projects, interpreters, environments, and tools canonically #246
• Hypothetical (validate pre-write) evaluation must be comprehensive — graph-backed checks are silently skipped #197
• fix(python): share import resolution between validation and graph #209
• fix(python): make ruff and pytest toolchain status honest #211
• feat(inspect-edit): scope and isolate language-service projects #217
• P1 — Add truthful Python LSP semantic inspection and navigation #248
• P1 — Make Python rename and module moves semantic and atomic #249
• P1: Make Python package-subtree moves atomic and import-aware #268 (P1: Make Python package-subtree moves atomic and import-aware)

Required behavior

1. Define opcore.python.capabilities.v1 rows for graph, syntax, authoritative types, imports, dead code, Ruff lint/format, pytest collect/run, each semantic inspect route, rename preview/apply, and module moves.
2. Keep availability/readiness (available, degraded, unsupported, disabled, not_applicable) separate from observed evidence (passed, findings, tool_unavailable, invalid_config, timeout, tool_failure, crash, stale_overlay, unsupported_overlay, not_run, not_applicable).
3. Each row binds project context, required/optional tools, exact evidence/provenance, remediation/disable action, readiness contribution, platform/artifact support, and observation identity; optional missing tools affect only dependent rows.
4. Derive and project byte-equivalent normalized rows through scan/status/doctor, init/install preview inputs, metrics/reporting, ASP assessment, managed descriptor, help/JSON manifests; static descriptors advertise vocabulary/artifact requirements, never repo-specific availability.
5. Validate deterministic generation from actual registered checks/semantic capabilities/receipts and reject missing, conflicting, stale, or optimistic evidence.
6. Maintainer/subagent-owned. Do not launch Zeroshot unless the user explicitly re-delegates this slice after its JIT review.

Acceptance criteria

• Fixtures cover no Python, Python only, mypy, Pyright, both ambiguous, Ruff, pytest, semantic service present/absent, optional tool missing, invalid config, timeout/crash, unsupported graph platform, nested projects, and overlay states.
• Cross-surface identity tests prove every runtime/reporting projection agrees; disabled/not-applicable is distinct from passed and lexical fallback is never semantic readiness.
• No public docs/readiness wording or setup mutation changes in this slice.

Observable outcomes

• Clean success carries positive execution/provenance evidence; zero diagnostics alone is never proof.
• Findings and every unavailable/invalid/timeout/crash/resource/stale/unsupported state are machine-readable and fail or degrade exactly as the capability contract says.
• No implicit fallback, partial result, or skipped execution is reported as a pass.
• Target source, configuration, lockfiles, environments, and caches remain unchanged except where this issue explicitly owns a validation-gated atomic edit; every temporary resource/process is cleaned.

Non-goals

• claiming parity/readiness
• setup mutation
• adding new runtime capabilities
• changing native platform support without architecture approval

Verification

Run focused behavior first, then the configured repository proof only after the acceptance matrix works:

• npm run build
• node --test tests/contracts.test.mjs tests/schema-contracts.test.mjs tests/opcore-facade.test.mjs tests/opcore-metrics.test.mjs tests/conformance.test.mjs tests/asp-provider.test.mjs
• npm run lint
• Attach exact real-tool/artifact versions, argv/config/cwd/source, normalized result examples, before/after cleanliness evidence, and packed-install proof where the slice changes public package behavior.

Execution rule

Implement only after a just-in-time review against current dev. Keep exactly one implementation run active. PR base is dev; require green checks, clean scoped diff, merged PR, closed child, parent checklist update, focused reproductions, and opcore-ci proof before starting the next child. Do not claim Python readiness/parity, ASP authority, old-tool replacement, security/SAST, all-stack support, automatic fixes, or a blended score.