[P1] Add AgentProlog XDG config.prolog + JSON canonical loader #127

New issue

Closed

opened 2026-08-19 16:54:54 +00:00 by lost-rob0t · 1 comment

lost-rob0t commented

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

(Migrated from github.com)

Parent: #126
Depends on: #75/#77 for final scoped-state/project-identity integration.

Goal

Implement AgentProlog's two configuration modes:

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

The user XDG config is intentionally programmable. It should support an Emacs-like experience where the operator can define predicates, helpers, loaders and later hook/tool/detector registrations in ordinary Prolog.

Default user path:

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

with $HOME/.config fallback.

Trust model

User config

The XDG config.prolog is trusted executable operator/host code and is loaded normally by AgentProlog. It is not restricted to closed ground terms and is not sandboxed from the AgentProlog process.

The stock config runtime provides a standard JSON loader so a user may write a small Prolog config that imports config.json and then overrides or extends it with Prolog rules.

Project config

Executable project Prolog requires an explicit trusted-project decision bound to the structured project identity from #75. Merely opening/cloning a repository must not execute its config.

An untrusted project config candidate may be discovered and presented, but execution waits for project trust. Project trust is a host-code trust decision, not an AgentProlog tool permission or authority tier.

Runtime operations registered from config

Once trusted, config code itself has process privileges. Separately, tools/effects/providers registered through canonical AgentProlog runtime APIs continue to use those APIs' schemas, capabilities, authority, confinement, cancellation and durable-effect semantics when invoked.

Editing and file mode

AgentProlog must expose trusted config-edit/write APIs for frontends, but editing config is a normal file mutation and must pass the existing authority boundary. The model cannot silently rewrite its own executable configuration.

Files created or rewritten by AgentProlog must be mode 0600. Authorized rewrites should tighten broader existing modes to 0600. Use atomic replacement where practical and test the resulting mode.

An approval UI should make clear that a config edit is privileged because the changed Prolog runs as host extension code after reload.

Scope

XDG user config discovery;
executable user config.prolog loading;
standard JSON import helper available from Prolog config;
canonical effective ordinary settings/provenance view for frontends;
project config discovery + explicit project trust gate;
deterministic user -> trusted-project overlay for ordinary settings;
read/load/reload/inspect APIs;
authority-mediated write/edit integration, with trusted final write primitive and 0600 enforcement;
default provider/model/runtime/session values, with OpenRouter a normal default and direct DeepSeek optional;
migration/compatibility path for JSON-only users without a second runtime;
config-generation provenance so #128-#130 can remove stale registrations on reload.

This slice does not need the full #128 hook registry yet, but its API must preserve the executable Prolog module/config environment needed for later registration.

Acceptance

XDG user config.prolog executes as trusted Prolog configuration.
User config can define and call helper predicates, proving this is not a closed-data-only parser.
The stock config runtime provides a JSON loader callable from config.prolog.
JSON-only configuration can be loaded through that same runtime.
Equivalent ordinary settings from JSON and Prolog resolve identically.
Project config is not executed until its structured project identity is explicitly trusted.
Trusted project config can execute and overlay user configuration without leaking to another project.
AgentProlog config writes require authority mediation and produce 0600 files.
Rewriting an overly broad config mode tightens it to 0600.
Missing config yields documented defaults including OpenRouter without requiring DeepSeek credentials.
Reload replaces stale file clauses and advances config generation rather than accumulating old executable definitions.
Documentation explicitly states that trusted config itself is host code, not capability-sandboxed data.
Tests cover XDG fallback, executable helper code/directives, JSON import, project trust/isolation, reload, atomic write behavior, invalid-write preservation, and mode enforcement.

Non-goals

No full hook/tool/detector implementation in this slice; those are #128-#130. No implicit trust of repository code. No duplicate DeepSeek-local settings authority.

Parent: #126 Depends on: #75/#77 for final scoped-state/project-identity integration. ## Goal Implement AgentProlog's two configuration modes: 1. trusted executable Prolog `config.prolog`; 2. JSON loaded through the Prolog configuration runtime. The user XDG config is intentionally programmable. It should support an Emacs-like experience where the operator can define predicates, helpers, loaders and later hook/tool/detector registrations in ordinary Prolog. Default user path: ```text $XDG_CONFIG_HOME/prolog-rlm/agentProlog/config.prolog ``` with `$HOME/.config` fallback. ## Trust model ### User config The XDG `config.prolog` is trusted executable operator/host code and is loaded normally by AgentProlog. It is not restricted to closed ground terms and is not sandboxed from the AgentProlog process. The stock config runtime provides a standard JSON loader so a user may write a small Prolog config that imports `config.json` and then overrides or extends it with Prolog rules. ### Project config Executable project Prolog requires an explicit trusted-project decision bound to the structured project identity from #75. Merely opening/cloning a repository must not execute its config. An untrusted project config candidate may be discovered and presented, but execution waits for project trust. Project trust is a host-code trust decision, not an AgentProlog tool permission or authority tier. ### Runtime operations registered from config Once trusted, config code itself has process privileges. Separately, tools/effects/providers registered through canonical AgentProlog runtime APIs continue to use those APIs' schemas, capabilities, authority, confinement, cancellation and durable-effect semantics when invoked. ## Editing and file mode AgentProlog must expose trusted config-edit/write APIs for frontends, but editing config is a normal file mutation and must pass the existing authority boundary. The model cannot silently rewrite its own executable configuration. Files created or rewritten by AgentProlog must be mode `0600`. Authorized rewrites should tighten broader existing modes to `0600`. Use atomic replacement where practical and test the resulting mode. An approval UI should make clear that a config edit is privileged because the changed Prolog runs as host extension code after reload. ## Scope - XDG user config discovery; - executable user `config.prolog` loading; - standard JSON import helper available from Prolog config; - canonical effective ordinary settings/provenance view for frontends; - project config discovery + explicit project trust gate; - deterministic user -> trusted-project overlay for ordinary settings; - read/load/reload/inspect APIs; - authority-mediated write/edit integration, with trusted final write primitive and `0600` enforcement; - default provider/model/runtime/session values, with OpenRouter a normal default and direct DeepSeek optional; - migration/compatibility path for JSON-only users without a second runtime; - config-generation provenance so #128-#130 can remove stale registrations on reload. This slice does not need the full #128 hook registry yet, but its API must preserve the executable Prolog module/config environment needed for later registration. ## Acceptance - [ ] XDG user `config.prolog` executes as trusted Prolog configuration. - [ ] User config can define and call helper predicates, proving this is not a closed-data-only parser. - [ ] The stock config runtime provides a JSON loader callable from `config.prolog`. - [ ] JSON-only configuration can be loaded through that same runtime. - [ ] Equivalent ordinary settings from JSON and Prolog resolve identically. - [ ] Project config is not executed until its structured project identity is explicitly trusted. - [ ] Trusted project config can execute and overlay user configuration without leaking to another project. - [ ] AgentProlog config writes require authority mediation and produce `0600` files. - [ ] Rewriting an overly broad config mode tightens it to `0600`. - [ ] Missing config yields documented defaults including OpenRouter without requiring DeepSeek credentials. - [ ] Reload replaces stale file clauses and advances config generation rather than accumulating old executable definitions. - [ ] Documentation explicitly states that trusted config itself is host code, not capability-sandboxed data. - [ ] Tests cover XDG fallback, executable helper code/directives, JSON import, project trust/isolation, reload, atomic write behavior, invalid-write preservation, and mode enforcement. ## Non-goals No full hook/tool/detector implementation in this slice; those are #128-#130. No implicit trust of repository code. No duplicate DeepSeek-local settings authority.

nsaspy referenced this issue from a pull request that will close it,

2026-08-27 20:02:08 +00:00

Bundle AgentProlog + DeepSeek harness in prolog-rlm #132

nsaspy commented

2026-09-02 17:26:00 +00:00

Owner

Child of #126; closed with the epic under the restored canonical boundary (#141, 2026-08-31): AgentProlog product configuration/UX belongs to lost-rob0t/agentProlog, and this is not a current prolog-rlm gap blocking a coding agent. Re-file in the product repo if still wanted.