P1 — add server `api_service` providers and split semantic/server/device Prolog configuration #158

New issue

Closed

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

lost-rob0t commented

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

(Migrated from github.com)

Parent epic: #150
Depends on: #157

Goal

Create the closed server execution-service boundary and remove the architectural assumption that current Linux kb/config.pl mappings are valid server commands.

Scope

define a versioned api_service/server provider registry behind RuntimeHost;
route approved server capabilities (search, memory, timer/service work, database/MCP/tool adapters, explicitly authorized administration where supported) through typed provider interfaces;
separate shared semantic intent/slot/capability facts from server provider configuration and Linux device provider configuration;
preserve understandable user overrides without duplicating the intent vocabulary;
keep server tools/plugins available through existing registries where they are the chosen provider;
never let ZMQ gateway invoke services directly.

Configuration/migration

Research exact predicates/files. Migrate existing app_mapping, search/timer/alarm settings only where semantically appropriate. Desktop-specific xdg-open, GNOME, terminal, clipboard/screenshot/system-power actions stay device-side. Define explicit compatibility behavior for old user config.pl and fail safely on server-inappropriate mappings.

Tests

server search/service plan executes behind RuntimeHost;
Linux open-app plan never executes inside headless server;
server timer/provider behavior according to chosen policy;
unknown/disabled provider;
provider timeout/cancel/failure and no duplicate side effect on retry;
capability authorization before execution;
plugin/tool provider registration/unregistration races;
malformed config, duplicate provider ids and incompatible legacy overrides;
headless environment with no DISPLAY/desktop binaries remains healthy.

Gates

TDD; focused api-service/config migration script; headless integration; full repo/Nix and exact-head Actions.

Acceptance

Server capabilities execute through one explicit service/provider boundary, while device-specific configuration can no longer accidentally turn a container/server into the execution target for desktop commands.

Parent epic: #150 Depends on: #157 ## Goal Create the closed server execution-service boundary and remove the architectural assumption that current Linux `kb/config.pl` mappings are valid server commands. ## Scope - define a versioned `api_service`/server provider registry behind RuntimeHost; - route approved server capabilities (search, memory, timer/service work, database/MCP/tool adapters, explicitly authorized administration where supported) through typed provider interfaces; - separate shared semantic intent/slot/capability facts from server provider configuration and Linux device provider configuration; - preserve understandable user overrides without duplicating the intent vocabulary; - keep server tools/plugins available through existing registries where they are the chosen provider; - never let ZMQ gateway invoke services directly. ## Configuration/migration Research exact predicates/files. Migrate existing `app_mapping`, search/timer/alarm settings only where semantically appropriate. Desktop-specific `xdg-open`, GNOME, terminal, clipboard/screenshot/system-power actions stay device-side. Define explicit compatibility behavior for old user `config.pl` and fail safely on server-inappropriate mappings. ## Tests - server search/service plan executes behind RuntimeHost; - Linux open-app plan never executes inside headless server; - server timer/provider behavior according to chosen policy; - unknown/disabled provider; - provider timeout/cancel/failure and no duplicate side effect on retry; - capability authorization before execution; - plugin/tool provider registration/unregistration races; - malformed config, duplicate provider ids and incompatible legacy overrides; - headless environment with no DISPLAY/desktop binaries remains healthy. ## Gates TDD; focused api-service/config migration script; headless integration; full repo/Nix and exact-head Actions. ## Acceptance Server capabilities execute through one explicit service/provider boundary, while device-specific configuration can no longer accidentally turn a container/server into the execution target for desktop commands.