Preserve installed Local AI runtime controls - #1206
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
clawsweeper
Bot
added
P2
|
Codex review: needs real behavior proof before merge. Reviewed August 22, 2026, 12:32 PM ET / 16:32 UTC. ClawSweeper reviewWhat this changesThe PR separates Local AI hardware eligibility for fresh setup from controls that manage an already installed Companion-managed runtime. Merge readiness⛔ Blocked until real behavior proof from a real setup is added - 4 items remain Keep open. This is a focused corrective follow-up to the still-open Local AI UX parent PR, with no code correctness finding, but it still needs current-head native tray proof before merge. Priority: P2 Review scores
Verification
Live VerificationCommand: Result: FAIL (failed) — execution before step 1 Assertions:
How this fits togetherThe tray Local AI page combines runtime state, gateway state, and a hardware eligibility probe to determine available actions. This change preserves valid runtime-management actions while restricting only new setup or download retries. flowchart LR
A[Runtime snapshot] --> D[Local AI action policy]
B[Gateway connection state] --> D
C[Hardware eligibility probe] --> D
D --> E[Installed runtime controls]
D --> F[Fresh setup retry]
E --> G[Local AI tray page]
F --> G
Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Merge the parent UX work with this corrective action policy only after posting redacted current-head tray evidence that valid installed-runtime controls remain usable while fresh setup stays unavailable. Do we have a high-confidence way to reproduce the issue? No live reproduction is supplied. The unavailable-probe path is high-confidence from the current source and focused tests, but those tests use fake runtime, gateway, probe, and command dependencies. Is this the best way to solve the issue? Yes. Keeping existing action predicates and limiting hardware eligibility to fresh setup is the narrowest maintainable boundary, pending native tray confirmation. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against ccd64bbb7d68. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (3 earlier review cycles) |
clawsweeper
Bot
added
the
merge-risk: 🚨 compatibility
2 participants
Summary
This is a narrow follow-up for the ClawSweeper P1 on #1204.
Hardware eligibility now gates only fresh setup retry. It no longer disables management of an already installed Companion-managed Local AI runtime.
See whydiagnostics.This preserves #1204's UX work and does not change Core, WSL, credentials, or package trust behavior.
Validation
./build.ps1: PASS for Shared, CLI, WinNodeCli, SetupEngine, and WinUI.git diff --check: PASS.Real behavior proof
The focused tests exercise the exact failed-probe state for:
The page contract also proves that no enclosing card is disabled by the availability probe.
Proof level:
test_proven. A product-only preview seam was not added solely to manufacture a screenshot, soruntime_provenandend_to_end_provenare not claimed.Local TRX artifacts and hashes are preserved in the operator evidence bundle. The live installed Companion, WSL, Gateway, credentials, and settings were not started or changed.