P1 — add capability/provider reasoning and typed `ExecutionPlan` without reviving draft architecture blindly #157

New issue

Closed

opened 2026-08-22 21:52:46 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-22 21:52:46 +00:00

(Migrated from github.com)

Parent epic: #150
Depends on: #156
Prior art: draft PR #119 must be reviewed/reconciled, not merged blindly.

Goal

Given a complete semantic IntentFrame, select a viable abstract provider/location under explicit availability, policy and authorization constraints, producing a typed ExecutionPlan rather than directly executing commands.

Required reasoning

Model candidates with properties sufficient for deterministic selection/explanation: capability, location (server/device/future local), provider id, side-effect class, required authorization/capability, device/session affinity, availability, certainty/priority and declared argument schema. Preserve multiple candidates until constraints select or report ambiguity/unavailability.

Invariants

intent parsing never executes provider;
provider selection never trusts arbitrary client-supplied executable names;
authenticated principal/server policy remains authority even if client advertises availability;
no fallback from unknown capability to shell/eval;
side-effecting plans carry idempotency/replay/cancellation semantics where required;
plans are bounded, serializable and provider-neutral enough for tests/wire adaptation;
explanations expose structured evidence/candidate reasons, not hidden model chain of thought.

Required examples/tests

open Firefox chooses initiating-device open-app provider when advertised;
same intent with no capable device -> typed unavailable;
search chooses server search/API provider;
timer can select server timer or device timer according to explicit configured policy and availability;
server admin provider requires admin authorization independent of authentication;
malicious device advertisement cannot acquire admin/server capability;
deterministic tie/ambiguity handling;
provider disappears between plan and execute -> typed stale/unavailable, no unsafe fallback;
two devices for one principal and targeting policy;
two principals cannot target each other's device/session.

PR #119 reconciliation

Document every reused/rejected concept from its capability_resolver design, especially constraints/candidate explanation. Prove no Prolog-RLM dependency/path survives.

Gates

Tests first; focused capability reasoner script; property tests for candidate ordering/filtering/unknown facts; full repo/Nix; exact-head Actions.

Acceptance

A complete intent deterministically becomes an authorized typed plan or an explicit ambiguity/unavailable/denied result, without performing the action.

Parent epic: #150 Depends on: #156 Prior art: draft PR #119 must be reviewed/reconciled, not merged blindly. ## Goal Given a complete semantic `IntentFrame`, select a viable abstract provider/location under explicit availability, policy and authorization constraints, producing a typed `ExecutionPlan` rather than directly executing commands. ## Required reasoning Model candidates with properties sufficient for deterministic selection/explanation: capability, location (`server`/`device`/future local), provider id, side-effect class, required authorization/capability, device/session affinity, availability, certainty/priority and declared argument schema. Preserve multiple candidates until constraints select or report ambiguity/unavailability. ## Invariants - intent parsing never executes provider; - provider selection never trusts arbitrary client-supplied executable names; - authenticated principal/server policy remains authority even if client advertises availability; - no fallback from unknown capability to shell/eval; - side-effecting plans carry idempotency/replay/cancellation semantics where required; - plans are bounded, serializable and provider-neutral enough for tests/wire adaptation; - explanations expose structured evidence/candidate reasons, not hidden model chain of thought. ## Required examples/tests - `open Firefox` chooses initiating-device open-app provider when advertised; - same intent with no capable device -> typed unavailable; - search chooses server search/API provider; - timer can select server timer or device timer according to explicit configured policy and availability; - server admin provider requires admin authorization independent of authentication; - malicious device advertisement cannot acquire admin/server capability; - deterministic tie/ambiguity handling; - provider disappears between plan and execute -> typed stale/unavailable, no unsafe fallback; - two devices for one principal and targeting policy; - two principals cannot target each other's device/session. ## PR #119 reconciliation Document every reused/rejected concept from its `capability_resolver` design, especially constraints/candidate explanation. Prove no Prolog-RLM dependency/path survives. ## Gates Tests first; focused capability reasoner script; property tests for candidate ordering/filtering/unknown facts; full repo/Nix; exact-head Actions. ## Acceptance A complete intent deterministically becomes an authorized typed plan or an explicit ambiguity/unavailable/denied result, without performing the action.