[EPIC] AgentProlog programmable configuration, hooks, tools, and detectors

lost-rob0t commented

2026-08-19 16:54:36 +00:00

(Migrated from github.com)

Goal

Build a genuinely programmable AgentProlog configuration layer on top of #74/#75/#77, and make every frontend, including the DeepSeek Harness path, use it instead of owning frontend-local settings semantics.

There are exactly two configuration front doors:

executable Prolog-native config.prolog;
JSON loaded through the Prolog configuration runtime.

Prolog is the primary configuration language. The target experience should feel closer to Emacs configuration than to a static application preferences file: trusted user configuration may define predicates, hooks, tools, detectors, helper code, loaders, and extension registrations.

Trust and execution model

User config

The XDG user config is trusted executable operator code:

$XDG_CONFIG_HOME/prolog-rlm/agentProlog/config.prolog

with $HOME/.config fallback.

AgentProlog loads this file as executable Prolog under the user's process authority. This is intentional. It is host extension code, not a sandboxed data format.

The stock config module should provide helpers such as JSON loading so a user can write a tiny Prolog config that imports JSON when desired.

Project config

Project configuration may also be executable Prolog, but repository presence alone is not trust. Executable project config requires an explicit trusted-project decision bound to the structured project identity from #75. Untrusted projects may expose inert/discoverable config candidates, but AgentProlog must not silently execute repository code.

Project trust is therefore a real host-code trust decision. It is still distinct from the AgentProlog runtime authority modes used for individual registered operations.

Runtime boundary

Trusted config itself has the privileges of the AgentProlog process and may call ordinary Prolog/system APIs. Do not claim that arbitrary trusted config is capability-sandboxed.

The canonical capability/authority/effect guarantees continue to apply to AgentProlog-managed operations registered through those runtimes: tools, provider calls, durable effects, approvals, confined project mutations, and so on. A config-defined tool does not gain an invocation bypass merely because its handler was registered by trusted config.

Editing config

Editing user or project configuration is itself an AgentProlog file mutation and must cross the normal authority boundary. AgentProlog must never silently self-modify its configuration.

Config files created or rewritten through AgentProlog default to mode 0600; existing files with broader permissions should be tightened on an authorized write. Atomic replace/write semantics are preferred.

The approval should make clear that editing executable config is privileged: after reload, the changed file runs as host extension code.

Configuration surface

The runtime must be able to configure and extend:

provider/model/runtime/session settings;
lossless conversation/context behavior;
project settings and instructions;
tools/tool packs and tool definitions;
MCP configuration references;
hooks and extension points;
error detectors/classifiers;
agent loop/repetition/non-progress detectors;
prompt/context compiler inputs;
frontend/UI preferences;
arbitrary future extension classes registered from trusted Prolog config.

Secrets should remain external references by default rather than casually serialized frontend-visible preferences.

Hook / extension model

Create a typed extension-point registry, but allow trusted config.prolog to register actual Prolog handlers. Registry/catalog views expose identities and sanitized metadata, not executable closures to the model.

Initial extension points should cover config, project, session, prompt compilation, provider/model calls, tool lifecycle, authority, durable effects, turn/step lifecycle, errors/repair, loop detection, verification, and safe UI projection.

Reuse existing rlm_chain middleware, rlm_tool_loader, recursion guards, authority/effect boundaries, and prolog_agent_ui_v1 rather than cloning them.

Error and loop detectors

Trusted config may define/register detector predicates. Detectors consume structured observations/events and produce structured decisions/evidence. Their recommendations flow through the runtime that owns cancellation, repair, authority, and effects.

Loop detection should grow beyond the current recursive fingerprint guard to repeated equivalent tool calls, repeated model/tool cycles, repeated failed repairs, non-progressing turns/steps, repeated provider outputs, and project-specific detectors. #42 remains open until its existing fingerprint bug is actually fixed.

DeepSeek Harness integration

#124/#125 must ultimately stop owning a private provider/model/session settings authority. Harness config UI/editing becomes a client of AgentProlog config APIs.

OpenRouter remains a normal/default route. Direct DeepSeek remains optional.

Dependencies

#74/#75/#77 scoped state, project identity, and project policy boundary
#48 tool-loader boundary
#52/#72 MCP config references
#53 authority
#57 durable effects
#101/#116 prompt/context compiler
#124/#125 DeepSeek Harness path

Child issues

#127 XDG executable config.prolog + JSON loader + project trust/discovery
#128 typed hook/extension registry for executable trusted Prolog handlers
#129 config-defined tools/tool-pack selection
#130 configurable error/loop detector registry
#131 DeepSeek Harness config editing through AgentProlog

Acceptance criteria

XDG config.prolog is executable trusted user configuration and can define/register Prolog behavior.
The stock Prolog config runtime can load JSON into the same effective configuration.
JSON and Prolog can express equivalent ordinary settings.
Executable project config requires explicit project trust bound to structured project identity.
AgentProlog config edits require normal file-mutation authority and default resulting files to 0600.
Documentation treats trusted config as host code rather than falsely promising a sandbox.
AgentProlog-managed tools/effects registered from config still use their canonical invocation authority and effect boundaries.
Hooks/tools/detectors can be implemented in trusted Prolog config with inspectable registrations.
DeepSeek Harness reads/edits through the canonical AgentProlog config runtime.
OpenRouter works without any DeepSeek credential; direct DeepSeek remains optional.
Docs include real programmable Prolog examples, JSON loading, and trusted-project configuration.

## Goal Build a genuinely programmable AgentProlog configuration layer on top of #74/#75/#77, and make every frontend, including the DeepSeek Harness path, use it instead of owning frontend-local settings semantics. There are exactly two configuration front doors: 1. executable Prolog-native `config.prolog`; 2. JSON loaded through the Prolog configuration runtime. Prolog is the primary configuration language. The target experience should feel closer to Emacs configuration than to a static application preferences file: trusted user configuration may define predicates, hooks, tools, detectors, helper code, loaders, and extension registrations. ## Trust and execution model ### User config The XDG user config is trusted executable operator code: ```text $XDG_CONFIG_HOME/prolog-rlm/agentProlog/config.prolog ``` with `$HOME/.config` fallback. AgentProlog loads this file as executable Prolog under the user's process authority. This is intentional. It is host extension code, not a sandboxed data format. The stock config module should provide helpers such as JSON loading so a user can write a tiny Prolog config that imports JSON when desired. ### Project config Project configuration may also be executable Prolog, but repository presence alone is not trust. Executable project config requires an explicit trusted-project decision bound to the structured project identity from #75. Untrusted projects may expose inert/discoverable config candidates, but AgentProlog must not silently execute repository code. Project trust is therefore a real host-code trust decision. It is still distinct from the AgentProlog runtime authority modes used for individual registered operations. ### Runtime boundary Trusted config itself has the privileges of the AgentProlog process and may call ordinary Prolog/system APIs. Do not claim that arbitrary trusted config is capability-sandboxed. The canonical capability/authority/effect guarantees continue to apply to AgentProlog-managed operations registered through those runtimes: tools, provider calls, durable effects, approvals, confined project mutations, and so on. A config-defined tool does not gain an invocation bypass merely because its handler was registered by trusted config. ### Editing config Editing user or project configuration is itself an AgentProlog file mutation and must cross the normal authority boundary. AgentProlog must never silently self-modify its configuration. Config files created or rewritten through AgentProlog default to mode `0600`; existing files with broader permissions should be tightened on an authorized write. Atomic replace/write semantics are preferred. The approval should make clear that editing executable config is privileged: after reload, the changed file runs as host extension code. ## Configuration surface The runtime must be able to configure and extend: - provider/model/runtime/session settings; - lossless conversation/context behavior; - project settings and instructions; - tools/tool packs and tool definitions; - MCP configuration references; - hooks and extension points; - error detectors/classifiers; - agent loop/repetition/non-progress detectors; - prompt/context compiler inputs; - frontend/UI preferences; - arbitrary future extension classes registered from trusted Prolog config. Secrets should remain external references by default rather than casually serialized frontend-visible preferences. ## Hook / extension model Create a typed extension-point registry, but allow trusted `config.prolog` to register actual Prolog handlers. Registry/catalog views expose identities and sanitized metadata, not executable closures to the model. Initial extension points should cover config, project, session, prompt compilation, provider/model calls, tool lifecycle, authority, durable effects, turn/step lifecycle, errors/repair, loop detection, verification, and safe UI projection. Reuse existing `rlm_chain` middleware, `rlm_tool_loader`, recursion guards, authority/effect boundaries, and `prolog_agent_ui_v1` rather than cloning them. ## Error and loop detectors Trusted config may define/register detector predicates. Detectors consume structured observations/events and produce structured decisions/evidence. Their recommendations flow through the runtime that owns cancellation, repair, authority, and effects. Loop detection should grow beyond the current recursive fingerprint guard to repeated equivalent tool calls, repeated model/tool cycles, repeated failed repairs, non-progressing turns/steps, repeated provider outputs, and project-specific detectors. #42 remains open until its existing fingerprint bug is actually fixed. ## DeepSeek Harness integration #124/#125 must ultimately stop owning a private provider/model/session settings authority. Harness config UI/editing becomes a client of AgentProlog config APIs. OpenRouter remains a normal/default route. Direct DeepSeek remains optional. ## Dependencies - #74/#75/#77 scoped state, project identity, and project policy boundary - #48 tool-loader boundary - #52/#72 MCP config references - #53 authority - #57 durable effects - #101/#116 prompt/context compiler - #124/#125 DeepSeek Harness path ## Child issues - [ ] #127 XDG executable `config.prolog` + JSON loader + project trust/discovery - [ ] #128 typed hook/extension registry for executable trusted Prolog handlers - [ ] #129 config-defined tools/tool-pack selection - [ ] #130 configurable error/loop detector registry - [ ] #131 DeepSeek Harness config editing through AgentProlog ## Acceptance criteria - [ ] XDG `config.prolog` is executable trusted user configuration and can define/register Prolog behavior. - [ ] The stock Prolog config runtime can load JSON into the same effective configuration. - [ ] JSON and Prolog can express equivalent ordinary settings. - [ ] Executable project config requires explicit project trust bound to structured project identity. - [ ] AgentProlog config edits require normal file-mutation authority and default resulting files to `0600`. - [ ] Documentation treats trusted config as host code rather than falsely promising a sandbox. - [ ] AgentProlog-managed tools/effects registered from config still use their canonical invocation authority and effect boundaries. - [ ] Hooks/tools/detectors can be implemented in trusted Prolog config with inspectable registrations. - [ ] DeepSeek Harness reads/edits through the canonical AgentProlog config runtime. - [ ] OpenRouter works without any DeepSeek credential; direct DeepSeek remains optional. - [ ] Docs include real programmable Prolog examples, JSON loading, and trusted-project configuration.

nsaspy commented

2026-09-02 17:25:59 +00:00

Owner

Closing the AgentProlog programmable-configuration epic and children (#127-#131) per the restored canonical boundary (#141, 2026-08-31): product code does not move back into prolog-rlm. The epic targeted the nested prolog-rlm/agentProlog/ harness and DeepSeek Harness frontend that were removed from main by PR #187; product configuration/UX (XDG config.prolog, hooks, config-defined tools, detectors, Harness settings routing) is owned by lost-rob0t/agentProlog. None of these are current prolog-rlm runtime gaps that prevent building a coding agent: docs/prolog-agent-roadmap.md's 'still missing' list does not include them. Re-file in lost-rob0t/agentProlog if the programmable config layer is still wanted.