[hellices]

Closes #529

Summary

The view half of #411's Q2 slice. The :blocked view gains a fourth section, Possible constraints, built from possible_constraints() (#528): what the workload's next Pod, as its template asks, could run into under the namespace's quotas and LimitRanges as now observed.

• Rows.
  • Each row names its policy ("quota compute", "LimitRange tight") once per run of rows, then says what the row is about, the finding and the detail. For example: requests.cpu · would exceed · needs 500m; none remaining.
  • Enter opens the policy.
  • A claim row holds only if the claim is created: "would exceed, if the claim is created", or "if the claims are created" when several new claims are charged together.
• Notes.
  • The LimitRanges' Container defaults filled what the template leaves unset; other admission plugins can change a Pod further.
  • A possible constraint is not a cause or a forecast: quota status is not a reservation, other Pods are created concurrently, and admission webhooks are not observed.
  • "No ResourceQuota or LimitRange observed constrains this template" appears only when the core concludes it.
  • Otherwise the view says why that is not established: the lists were not all read, a RuntimeClass is set, or a claim has no storage class.
  • An unreadable template leaves the possibilities not established.
• Version matrix. The quota scenario now checks the blocked Deployment's possible constraints on a real cluster: defaults applied, and only matrix-pods: pods at its limit. The workflow also runs when creation_demand.py or creation_possibilities.py changes.
• Docs. docs/tui.md (section table and reading note), docs/keybindings.md, the release notes, and the plan docs/superpowers/plans/2026-10-31-creation-possibilities-view.md.

The controller, command and wiring are unchanged; the report already carries the template. The row count does not depend on the clock (now only decides nothing_constrains, which is a note), so the timer's cell refresh stays index-stable.

Verification

• 11 new tests in tests/ui/test_creation_constraints_screen.py (8 functions, one parametrized over 4 cases), written to fail first:
  • section order and once-per-run policy names;
  • claim condition, singular and plural;
  • defaults and caveat notes;
  • the "nothing constrains" conclusion;
  • each reason it is not established;
  • a list going stale;
  • an unreadable template;
  • Enter on a possibility row in a Textual pilot.
• Mutation checks on every new branch of the view, all caught. They exposed a missing case: an inconclusive LimitRange list, now added.
• The matrix expectation was checked offline: the fixture's Deployment, quota and LimitRange went through the real projections and gave [("matrix-pods", "pods", AT_LIMIT, "0 of 0 Pods exist")] with defaults applied. The live scenario runs on kind in CI.
• uv run --frozen pytest -p no:tach tests/ui/test_creation_constraints_*.py: 57 passed.
• Full gate run locally (check_source_size, ruff check, ruff format --check, mypy src, tach check, pytest -n 8): all pass except tests/providers/test_device_login_prefixes.py::test_the_measured_release_is_the_installed_one. That test fails only locally, because the installed litellm differs from the measured release; CI installs the locked version.

Checklist

• This closes an accepted issue in this repository that is assigned to me.
• Tests cover the change, written to fail first where behavior changed.
• make check passes locally.
• User-facing docs and the README match the change, or nothing user-facing changed.
• No security invariant is weakened: writes still need a keystroke approval
  and a fail-closed audit entry, and sensitive reads are still masked.

[Copilot]

🟡 Changes recommended

Timer refreshes can fail when stale LimitRange data introduces unmounted rows, and denied workload reads incorrectly suppress the required template-unreadable explanation.

2 open issues

• Reconcile rows when stale LimitRange data changes constraints · New
• Show the possibilities note when workload reads fail · New

What changed in this PR

Adds the view half of workload creation constraints: :blocked now displays the core calculations from #528 alongside recorded failures and namespace policies.

Changes:

• Adds possible-constraint rows, policy navigation, conditional claim wording, and evidence caveats.
• Extends UI tests and the live Kubernetes version-matrix scenario.
• Updates workflow triggers and user-facing documentation.

File	Description
tests/​version_matrix/​test_scenarios.py	Checks computed possibilities against live cluster policies.
tests/​ui/​test_creation_constraints_screen.py	Tests rows, notes, claim conditions, and navigation.
src/​korvid/​ui/​widgets/​creation_constraints_screen.py	Renders possible constraints and explanatory notes.
docs/​tui.md	Explains the new section and its evidence limits.
docs/​superpowers/​plans/​2026-10-31-creation-possibilities-view.md	Records the implementation and verification plan.
docs/​release-notes/​unreleased.md	Announces the possible-constraints section.
docs/​keybindings.md	Expands the description of :blocked.
.github/​workflows/​k8s-version-matrix.yml	Triggers matrix checks for demand and possibility changes.

_{Review effort: Balanced}

[my-reviewer-agent]

검토 범위에서 보고할 이슈가 없습니다.

[Copilot]

🟢 Approved

No active review issues remain for the change exposing possible workload constraints in the :blocked view.

No open issues 🎉

2 resolved since last review

• Show the possibilities note when workload reads fail
• Reconcile rows when stale LimitRange data changes constraints

_{Review effort: Balanced}

[my-reviewer-agent]

검토 범위에서 보고할 이슈가 없습니다.