P2 — prove programmable user commands have Linux/Android semantic parity and provider-specific execution #177

New issue

Open

opened 2026-08-22 21:56:15 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-22 21:56:15 +00:00

(Migrated from github.com)

Parent epic: #152
Depends on: #176, #165, #174

Goal

Make the programmable-command system from #151 genuinely multi-device. The same principal-owned semantic definition must resolve identically on Linux/server/Android while provider selection may choose platform-specific adapters.

Required cases

create a semantic command on one supported client and invoke it from Android after synchronization/reconnect;
work mode semantic actions map to Android-capable providers where available and explicit unavailable results where not;
parameterized command missing-slot flow uses identical shared semantics;
Android local/offline profile only executes actions allowed by #176;
provider-specific implementation details never leak back into the stored semantic definition;
editing/deleting on one client becomes visible according to durable server synchronization semantics;
two principals with same trigger remain isolated.

Tests

Cross-platform corpus compares normalized IntentFrame/slot data, then explicit provider differences; stale cached definition after edit/delete; reconnect refresh; provider permission revoked; Android unsupported action; malicious definition cannot reach Android arbitrary Intent/class API.

Acceptance

One authored semantic command can travel across clients without becoming Linux shell config or Android-specific source, and execution correctly follows each device's registered capabilities.

Parent epic: #152 Depends on: #176, #165, #174 ## Goal Make the programmable-command system from #151 genuinely multi-device. The same principal-owned semantic definition must resolve identically on Linux/server/Android while provider selection may choose platform-specific adapters. ## Required cases - create a semantic command on one supported client and invoke it from Android after synchronization/reconnect; - `work mode` semantic actions map to Android-capable providers where available and explicit unavailable results where not; - parameterized command missing-slot flow uses identical shared semantics; - Android local/offline profile only executes actions allowed by #176; - provider-specific implementation details never leak back into the stored semantic definition; - editing/deleting on one client becomes visible according to durable server synchronization semantics; - two principals with same trigger remain isolated. ## Tests Cross-platform corpus compares normalized IntentFrame/slot data, then explicit provider differences; stale cached definition after edit/delete; reconnect refresh; provider permission revoked; Android unsupported action; malicious definition cannot reach Android arbitrary Intent/class API. ## Acceptance One authored semantic command can travel across clients without becoming Linux shell config or Android-specific source, and execution correctly follows each device's registered capabilities.