P1 — RAGE research the post-client-split semantic intent architecture and freeze an `IntentFrame` contract #154

New issue

Closed

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

lost-rob0t commented

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

(Migrated from github.com)

Goal

Perform the deep adversarial research/code audit that decides the actual portable semantic-intent architecture before implementation. This is not a naming exercise: research must be capable of rejecting or materially changing the IntentFrame -> dialogue -> capability -> execution proposal in #150.

Mandatory code audit

Trace every current command/intent path from CLI, wake, desktop and agent through PrologEngine, intent_resolver.pl, command_loop.pl, commands.pl, Python skills/tools, RuntimeHost, AgentManager, ZARA/1 and current config. Identify duplicated authority, hidden mutable state, client/server assumptions and paths that bypass runtime commands/events.

Explicitly review:

existing pending(Intent) behavior and prompt ownership;
special timer/alarm/todo parsers;
IntentResult(kind,name,args) adaptation;
AgentManager's prompt-level command verb list / query_prolog routing;
#122 rewrite contract and ordering;
draft PR #119 capability reasoning and what is reusable vs obsolete;
current Linux-shaped kb/config.pl;
ZARA/1 closed schemas and extension constraints;
principal/session/conversation ownership from #131;
#51 context ownership so dialogue state does not become a second context manager.

Research questions

What is the minimum typed semantic representation that works in Prolog, Python, wire fixtures and future Android Prolog?
Which fields are semantic facts vs runtime correlation metadata?
How are typed slots represented without serializing arbitrary Prolog/Python objects?
How do ambiguity, invalid slots, missing slots, correction and cancellation compose?
Where does pending-dialogue state live and who owns lifecycle/persistence?
What must remain portable across Prolog runtimes?
How should resolver evidence be exposed without hidden model reasoning?
How does #122 feed the resolver without becoming semantic authority?
What parts of current command execution should disappear, adapt or stay compatibility-only?

Deliverables

append-only RAGE work log with immutable start SHA + this issue;
dedicated adversarial research artifact with primary-source/runtime evidence;
design artifact with decisions, rejected alternatives, invariants, lifecycle/state ownership, threat/failure analysis, migration plan, acceptance criteria and exact gates;
explicit versioned IntentFrame/slot result contract with examples;
migration map from every current intent result/path;
test matrix mapped to acceptance criteria;
no production implementation in the research commit(s).

Required examples in design/tests

At minimum model: complete timer; bare timer -> missing duration; follow-up duration; correction; cancellation; open app; bare open; text with missing message; server search; device screenshot; server memory query; unavailable capability; same semantic input with different platform provider availability.

Acceptance

The next implementation issue can build the contract without guessing ownership/schema semantics, and the research explains why rejected alternatives (raw args list, arbitrary JSON body, prompt-managed clarification, global pending command, direct shell/provider strings) are not used.

Parent epic: #150 Depends on: #133 Assumed baseline: #131/#148 design outcome is merged and its review blockers are resolved. Integrates with: #51, #82, #83, #122, #124; review draft PR #119 as prior art only. ## Goal Perform the deep adversarial research/code audit that decides the actual portable semantic-intent architecture before implementation. This is not a naming exercise: research must be capable of rejecting or materially changing the `IntentFrame -> dialogue -> capability -> execution` proposal in #150. ## Mandatory code audit Trace every current command/intent path from CLI, wake, desktop and agent through `PrologEngine`, `intent_resolver.pl`, `command_loop.pl`, `commands.pl`, Python skills/tools, `RuntimeHost`, `AgentManager`, ZARA/1 and current config. Identify duplicated authority, hidden mutable state, client/server assumptions and paths that bypass runtime commands/events. Explicitly review: - existing `pending(Intent)` behavior and prompt ownership; - special timer/alarm/todo parsers; - `IntentResult(kind,name,args)` adaptation; - AgentManager's prompt-level command verb list / `query_prolog` routing; - #122 rewrite contract and ordering; - draft PR #119 capability reasoning and what is reusable vs obsolete; - current Linux-shaped `kb/config.pl`; - ZARA/1 closed schemas and extension constraints; - principal/session/conversation ownership from #131; - #51 context ownership so dialogue state does not become a second context manager. ## Research questions - What is the minimum typed semantic representation that works in Prolog, Python, wire fixtures and future Android Prolog? - Which fields are semantic facts vs runtime correlation metadata? - How are typed slots represented without serializing arbitrary Prolog/Python objects? - How do ambiguity, invalid slots, missing slots, correction and cancellation compose? - Where does pending-dialogue state live and who owns lifecycle/persistence? - What must remain portable across Prolog runtimes? - How should resolver evidence be exposed without hidden model reasoning? - How does #122 feed the resolver without becoming semantic authority? - What parts of current command execution should disappear, adapt or stay compatibility-only? ## Deliverables - append-only RAGE work log with immutable start SHA + this issue; - dedicated adversarial research artifact with primary-source/runtime evidence; - design artifact with decisions, rejected alternatives, invariants, lifecycle/state ownership, threat/failure analysis, migration plan, acceptance criteria and exact gates; - explicit versioned `IntentFrame`/slot result contract with examples; - migration map from every current intent result/path; - test matrix mapped to acceptance criteria; - no production implementation in the research commit(s). ## Required examples in design/tests At minimum model: complete timer; bare timer -> missing duration; follow-up duration; correction; cancellation; open app; bare open; text with missing message; server search; device screenshot; server memory query; unavailable capability; same semantic input with different platform provider availability. ## Acceptance The next implementation issue can build the contract without guessing ownership/schema semantics, and the research explains why rejected alternatives (raw args list, arbitrary JSON body, prompt-managed clarification, global pending command, direct shell/provider strings) are not used.