nsaspy/zara
1
0
Fork 0
Code Issues 95 Pull requests 18 Projects Releases Packages Wiki Activity Actions

Add Prolog capability reasoning for command execution #119

Closed
lost-rob0t wants to merge 14 commits from agent/prolog-capability-reasoner into master
pull from: agent/prolog-capability-reasoner
merge into: nsaspy:master
Conversation 1 Commits 14 Files changed 8 +463 -15
lost-rob0t commented 2026-08-15 23:22:03 +00:00 (Migrated from github.com)
Copy link

What changed

  • added kb/capabilities.pl as the declarative capability-provider knowledge base
  • added modules/capability_resolver.pl as the single symbolic provider-selection layer
  • kept the existing command runtime authoritative; no second dispatcher or execution stack was introduced
  • routed existing open and search execution through capability selection
  • preserved configured app mappings, direct-app handling, and legacy executable fallback behavior
  • added queryable provider properties such as scope, transport, side-effect, and certainty terms
  • added composable symbolic constraints: require(Property) and exclude(Property)
  • added constrained candidate/5, candidates/4, and select/4 predicates while retaining the simple default-policy APIs
  • added explain/4, returning selected provider, priority, proof evidence, properties, and surviving alternatives
  • added CapabilityCandidate, PrologEngine.capability_candidates(), and PrologEngine.selected_capability() so Python/TUI/agent code can inspect Prolog decisions without executing them
  • added Prolog regression coverage for multiple solutions, ordering, strict filtering, conflicting constraints, and explanation evidence
  • added Python unit coverage for candidate enumeration and non-executing selection
  • extended scripts/test-prolog-engine.sh with a real SWI-Prolog/PySWIP capability fixture that proves multiple solutions and selected-provider behavior end to end
  • documented the architecture and extension points in wiki/capability-reasoning.org

Why

Zara already resolves natural language into symbolic intents. This PR adds the next expert-system stage: reason about which implementation can satisfy an intent and its arguments, preserve multiple valid solutions, constrain them symbolically, and select the best surviving provider.

The authority boundary is:

language -> intent/args -> Prolog capability reasoning -> existing command executor

This is ordinary Zara Prolog reasoning. It has no Prolog-RLM runtime dependency.

Example

?- capability_resolver:candidates(open, [vim], Candidates).
Candidates = [100-mapped_app, 50-direct_app, 10-executable_fallback].

?- capability_resolver:candidates(
       open,
       [vim],
       [exclude(certainty(speculative))],
       Candidates).
Candidates = [100-mapped_app, 50-direct_app].

Current status

The previous green CI result predates the current master and the removal of Prolog-RLM in #136. This PR is intentionally draft and must be reconciled with current master, proven to add no RLM dependency/code path, and rerun through the exact-head deterministic gate before merge.

Do not treat its older green checks as merge authority.

## What changed - added `kb/capabilities.pl` as the declarative capability-provider knowledge base - added `modules/capability_resolver.pl` as the single symbolic provider-selection layer - kept the existing command runtime authoritative; no second dispatcher or execution stack was introduced - routed existing `open` and `search` execution through capability selection - preserved configured app mappings, direct-app handling, and legacy executable fallback behavior - added queryable provider properties such as scope, transport, side-effect, and certainty terms - added composable symbolic constraints: `require(Property)` and `exclude(Property)` - added constrained `candidate/5`, `candidates/4`, and `select/4` predicates while retaining the simple default-policy APIs - added `explain/4`, returning selected provider, priority, proof evidence, properties, and surviving alternatives - added `CapabilityCandidate`, `PrologEngine.capability_candidates()`, and `PrologEngine.selected_capability()` so Python/TUI/agent code can inspect Prolog decisions without executing them - added Prolog regression coverage for multiple solutions, ordering, strict filtering, conflicting constraints, and explanation evidence - added Python unit coverage for candidate enumeration and non-executing selection - extended `scripts/test-prolog-engine.sh` with a real SWI-Prolog/PySWIP capability fixture that proves multiple solutions and selected-provider behavior end to end - documented the architecture and extension points in `wiki/capability-reasoning.org` ## Why Zara already resolves natural language into symbolic intents. This PR adds the next expert-system stage: reason about which implementation can satisfy an intent and its arguments, preserve multiple valid solutions, constrain them symbolically, and select the best surviving provider. The authority boundary is: `language -> intent/args -> Prolog capability reasoning -> existing command executor` This is ordinary Zara Prolog reasoning. It has no Prolog-RLM runtime dependency. ## Example ```prolog ?- capability_resolver:candidates(open, [vim], Candidates). Candidates = [100-mapped_app, 50-direct_app, 10-executable_fallback]. ?- capability_resolver:candidates( open, [vim], [exclude(certainty(speculative))], Candidates). Candidates = [100-mapped_app, 50-direct_app]. ``` ## Current status The previous green CI result predates the current `master` and the removal of Prolog-RLM in #136. This PR is intentionally draft and must be reconciled with current `master`, proven to add no RLM dependency/code path, and rerun through the exact-head deterministic gate before merge. Do not treat its older green checks as merge authority.
nsaspy changed title from WIP: Add Prolog capability reasoning for command execution to Add Prolog capability reasoning for command execution 2026-08-28 03:31:12 +00:00
nsaspy commented 2026-09-02 17:28:32 +00:00
Owner
Copy link

Closing per roadmap decision (issue #1, phase 11): this Prolog capability reasoner is reconciled as prior art only — it predates the ZARA/1 client split and the daemon runtime. The capability-reasoning behavior it prototyped is owned by #157 (capability/provider reasoning and typed ExecutionPlan), which will re-derive the design against the current runtime when consumed. Branch preserved for reference at consumption time.

Closing per roadmap decision (issue #1, phase 11): this Prolog capability reasoner is reconciled as prior art only — it predates the ZARA/1 client split and the daemon runtime. The capability-reasoning behavior it prototyped is owned by #157 (capability/provider reasoning and typed ExecutionPlan), which will re-derive the design against the current runtime when consumed. Branch preserved for reference at consumption time.
nsaspy closed this pull request 2026-09-04 14:40:03 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug
Something isn't working

  
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
enhancement
New feature or request

  
good first issue
Good for newcomers

  
help wanted
Extra attention is needed

  
invalid
This doesn't seem right

  
question
Further information is requested

  
wontfix
This will not be worked on

No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/zara!119
No description provided.