nsaspy/prolog-rlm

Fork 0

[P1] Define a safe Prolog-native project policy/config pack boundary #77

New issue

Open

opened 2026-08-17 07:42:11 +00:00 by lost-rob0t · 1 comment

lost-rob0t commented

2026-08-17 07:42:11 +00:00

(Migrated from github.com)

Parent: #74

Depends on: #75

Goal

Define the safe extension boundary that lets downstream hosts/agents provide project-local Prolog-native settings, instructions, tool configuration, and bounded policy declarations on top of #75 without teaching core a coding-agent-specific .claude-style product convention.

The design conclusion from current architecture is:

Core should own only the small provider/registration, validation, scope, provenance, and trust ABI. A concrete project-local file/directory/pack convention should remain downstream/extensible unless implementation evidence shows that core needs a minimal neutral discovery hook.

“Prolog-native” means project policy/config can be represented naturally as Prolog data/relations. It does not mean auto-consult arbitrary repository code and execute whatever predicates it contains.

Problem / motivation

Downstream agents need a clean way to build a project-local experience containing things such as:

ordinary project settings;
agent/tool preferences;
project instructions;
references to external tool/MCP configuration;
named bounded permission profiles/rules;
other domain-specific declarative project policy.

Core already has two useful precedents:

#48's external tool loader separates trusted loader callables from sanitized declarative manifests and makes loading availability-only.
#52/#72 separates trusted host MCP execution profiles/config references from inert server declarations, capabilities, authority mediation, and hard execution confinement.

The same lesson should apply here. A downstream package needs an inspectable Prolog-native project policy/config boundary, but project repository content is not automatically trusted executable host policy.

Architectural boundary

Core should own

provider/pack registration ABI;
provider identity and schema/version;
project/scope association through #75;
closed declaration classes;
normalization/validation;
provenance/trust classification;
deterministic load/unload/reload semantics;
sanitized inspection/catalog output;
integration hooks to #75 effective state;
integration hooks for tool/MCP references;
explicit authority-policy eligibility hooks without granting authority;
fail-closed malformed/ambiguous provider behavior.

Downstream hosts/agents/tool packs should own

concrete file/directory names;
whether configuration is a module, pack, dedicated declarative file, generated data source, etc.;
product-specific setting keys;
coding-agent instructions and UX;
project-specific tool defaults;
domain-specific rule schemas built on core registration primitives;
user-facing project setup/discovery workflow.

Do not make core depend on agentProlog or any one downstream product.

Provider model

Define a tiny trusted provider/registration ABI analogous in spirit to the tool-loader boundary.

The exact representation should be designed with current repository conventions, but a provider should have inspectable metadata equivalent to:

provider id
provider schema/version
scope/project identity
origin/trust class
supported declaration classes
sanitized manifest/catalog data
trusted loader/reader registration kept out of model-facing data

Provider discovery/catalog APIs must not return arbitrary trusted callables.

Multiple independent downstream providers should be able to contribute project configuration without name collisions becoming nondeterministic. Duplicate provider/declaration identities must fail structurally or follow an explicitly documented deterministic merge rule.

Safe Prolog-native declaration boundary

Evaluate and document the safest minimal mechanism consistent with current architecture. Viable directions include:

ground schema-validated declarations parsed as data;
restricted multifile declarations contributed by modules that the trusted host has already loaded/allowed;
explicit trusted module/provider registration whose exported declaration predicate returns closed data;
a dedicated parser for a restricted Prolog-term configuration file that rejects directives/clauses/callables and reads only allowed ground declaration forms;
another bounded equivalent.

The implementation may combine these, but it must preserve one rule:

Repository presence is not executable trust.

Do not implement:

consult(ProjectFile),
call(WhateverItDeclared).

Do not pass arbitrary project/model terms into unrestricted call/1, once/1, meta-call, directive execution, term expansion, initialization hooks, or equivalent ambient execution paths.

If ordinary Prolog modules are supported, the host must explicitly trust/register the module/provider before its executable code participates. The sanitized declarations consumed by core must still pass the closed schema.

Declaration classes

The provider contract should be extensible but start with explicit classes such as:

Ordinary settings

Closed key/value data resolved through #75's non-security scope precedence.

Project instructions

Structured/textual operator/project instructions with explicit provenance. They may be consumed by #70/#68-#71 as operator/project configuration, not silently treated as repository facts of equal authority.

Tool/MCP configuration references

References to installed/declared tool packs, categories, MCP server/profile/config references, or downstream tool settings.

A reference means “configure/select this thing,” not “grant capability” or “authorize its side effects.” Preserve #48/#52/#72 boundaries.

Bounded permission-profile declarations

A project policy pack may declare or select a bounded operation profile understood by #76, but declaration alone does not create a durable authorization grant.

Core must distinguish:

profile exists / is configured
        !=
operator granted persistent authority to it

A profile that can affect authorization must use a closed trusted matcher schema and stable identity/version. Untrusted project data cannot inject executable matching predicates.

Trust classes

The API must distinguish at least conceptually between:

trusted host/provider registration;
trusted operator mutation in #75;
project-provided declarative configuration;
model-proposed/candidate data;
repository/context observations.

Exact names may follow repository conventions.

A project declaration may be useful configuration without being allowed to widen authority. Prefer fail-safe semantics where project-local configuration can select/constrain known trusted profiles but cannot manufacture new host execution authority by itself.

If a host explicitly allows a provider to contribute authority-relevant declarations, that trust decision must be visible, bounded, and still subordinate to #76/#53 host ceilings. There must be no “trusted because it was in Git” rule. Humanity has suffered enough from executable config files.

Discovery and project-local convention

Do not hard-code a filename merely to imitate another agent product.

The implementation/design should compare:

an ordinary project-local Prolog module;
SWI-Prolog pack-style organization;
a dedicated restricted declarative Prolog-term file;
host-registered provider modules that discover their own downstream convention.

Given the current #48 loader architecture, the default direction should be:

prolog-rlm core
    -> provider registration + closed declarations + validation

downstream agent/tool package
    -> decides project-local convention and registers provider

If core grows project discovery, it should be neutral and return candidate locations/providers as data; it must not auto-execute arbitrary discovered code.

Load / unload / reload semantics

Define deterministic lifecycle behavior:

discover/register provider;
validate provider manifest/schema;
resolve target project identity through #75;
load declarations as data;
apply eligible ordinary settings/config into a scoped view;
expose sanitized inspection data;
unload provider/project contribution deterministically;
reload after file/provider change without accumulating duplicate stale declarations;
mark superseded/invalid provider data in provenance where needed;
do not retain executable loader/provider callables in audit history.

Loading a provider/project pack must be inert with respect to capability and authority.

Reload must never widen policy merely because a new declaration appeared. Authority-affecting changes that would alter an existing #76 grant's matcher identity/version must require explicit revalidation/re-authorization according to #76.

Public API direction

Exact predicate names must follow repository conventions. Core should expose semantics equivalent to:

project_policy_provider_register(+ProviderId, +TrustedProvider, -Outcome).
project_policy_provider_unregister(+ProviderId, -Outcome).
project_policy_providers(-Providers).
project_policy_catalog(+Project, -Catalog).

project_policy_load(+Store, +Project, +ProviderId, +Options, -Outcome).
project_policy_unload(+Store, +Project, +ProviderId, -Outcome).
project_policy_reload(+Store, +Project, +ProviderId, -Outcome).

project_policy_declarations(+Project, +Class, -Declarations).

Illustrative only. Trusted provider callables/reader internals must remain private like the tool-loader ABI; catalog/discovery returns sanitized declarative information.

Pure/local loading need not gain fake async twins. If a downstream provider genuinely performs latency-bearing external I/O, it should follow #54 internally through the canonical async contract and explicit capabilities rather than making the core project-policy API magically ambient-network-aware.

Security invariants

Project files are not automatically trusted executable Prolog.
No arbitrary consult + unrestricted meta-call boundary.
No model-generated provider registration or trusted callable injection.
Model/project data cannot create persistent grants directly.
Loading configuration does not grant capabilities.
Loading configuration does not set/widen #53 authority modes.
Loading configuration does not create a #76 persistent authorization merely because a permission profile is declared.
dangerous remains explicit host/user authority and is never implied by a project pack.
Schema validation happens before declarations become effective.
Unknown declarations/schema versions fail structurally; authority-affecting malformed state fails closed.
Provider/catalog inspection does not expose secrets or trusted callables.
Secrets remain references resolved through trusted host configuration mechanisms such as the #52/#72 pattern; they are not plaintext ordinary project facts/traces.
Tool/MCP declarations remain availability/configuration, separate from capability and authority.
Project instructions/config retain provenance distinct from repository observations/model inference in #70.
Unload/reload cannot leave stale authority-relevant declarations active invisibly.

Interaction with existing modules/issues

#75

Owns scopes, project identity, durable records, precedence, provenance, and trusted mutation. This issue contributes validated provider/project declarations into that substrate or an effective view over it.

Provider-loaded project declarations and operator-mutated durable state must remain distinguishable by origin/trust class.

#76 / #53

This boundary may expose bounded permission-profile declarations to #76, but does not authorize them. Persistent authorization still requires trusted operator/host grant creation and remains capped by #53/current host policy.

#48 / `rlm_tool_loader`

Reuse the successful split between sanitized declarative manifests and private trusted loader callables. Do not expose project-provider callables through catalog APIs.

#49/#50

Concrete project/tool integration belongs naturally in downstream libraries/tool packs rather than core.

#52/#72 / `rlm_mcp_policy`

Preserve separation among MCP server declarations, trusted execution profiles/config references, capabilities, authority, and hard confinement. Project policy may refer to those entities but cannot collapse them.

#16

Project policy/config is trusted/operator configuration, not model-published durable reasoning artifact state.

#68-#71 / especially #70

#70 should be able to inspect effective project instructions/settings as a distinct operator/project configuration provenance class. It must not flatten them into generic repository facts or let resolved context write back trusted policy automatically.

Acceptance criteria

Core exposes a documented provider/registration ABI whose trusted callables/readers are not returned through model-facing discovery/catalog APIs.
Provider declarations are closed, ground where required, schema/version validated, and inspectable.
Arbitrary repository Prolog code is not auto-consulted/executed merely because a project config location exists.
A fixture containing directives/initialization/arbitrary clauses is rejected or parsed strictly as non-executable data according to the selected design.
Model-generated terms cannot register a trusted provider or cause arbitrary meta-call execution.
Two project fixtures can load different Prolog-native settings/instructions/tool references with no cross-project leakage.
The same downstream provider can unload/reload one project's changed configuration deterministically without duplicate stale declarations.
Invalid/unknown provider schema fails structurally and cannot partially activate authority-relevant policy.
Loading a project policy/config pack changes no capability grant.
Loading a project policy/config pack changes no #53 authority mode.
A bounded permission-profile declaration alone does not create an active #76 grant.
An explicit trusted #76 grant may reference a valid stable bounded profile; changing the profile identity/version forces the safe #76 behavior rather than silently widening the grant.
Tool/MCP references remain configuration only; install/start/invoke still pass capability, hard policy, and authority boundaries.
Catalog/trace/error output contains reference metadata rather than resolved secrets or trusted callables.
Effective project instructions/settings can be consumed by #70/#68-#71 with explicit provenance distinct from repo observation/model inference.
Documentation clearly tells downstream agents how to implement their own project-local convention without modifying core.

Non-goals

No fixed .claude-like filename/directory in core unless neutral discovery evidence later requires one.
No agentProlog-specific configuration schema in core.
No arbitrary repository consult/1 execution path.
No unrestricted project-defined predicates as permission matchers.
No implicit capability grant.
No implicit persistent authorization.
No automatic dangerous or persistent allow_session.
No secret store.
No replacement for external tool-pack or MCP configuration systems.
No UI/TUI.

Dependencies / references

Parent #74
Depends on #75 scoped durable-state/project identity substrate
Integrates with #76 persistent authorization profiles without creating grants
#48 external tool-library loader ABI
#49 companion tool library
#50 standard tool pack
#52/#72 declarative MCP + hard execution profiles/config references
#53 host-controlled authority
#54 sync/async contract
#68-#71 context/workflow pipeline
prolog/rlm_tool_loader.pl
prolog/rlm_mcp_policy.pl
docs/external-tool-libraries.md
docs/mcp-lifecycle.md
research/RLM-RESEARCH-003-typed-symbolic-execution.org
research/RLM-RESEARCH-009-durable-artifact-context.org

Parent: #74 Depends on: #75 ## Goal Define the **safe extension boundary** that lets downstream hosts/agents provide project-local Prolog-native settings, instructions, tool configuration, and bounded policy declarations on top of #75 without teaching core a coding-agent-specific `.claude`-style product convention. The design conclusion from current architecture is: > Core should own only the small provider/registration, validation, scope, provenance, and trust ABI. A concrete project-local file/directory/pack convention should remain downstream/extensible unless implementation evidence shows that core needs a minimal neutral discovery hook. “Prolog-native” means project policy/config can be represented naturally as Prolog data/relations. It does **not** mean auto-`consult` arbitrary repository code and execute whatever predicates it contains. ## Problem / motivation Downstream agents need a clean way to build a project-local experience containing things such as: - ordinary project settings; - agent/tool preferences; - project instructions; - references to external tool/MCP configuration; - named bounded permission profiles/rules; - other domain-specific declarative project policy. Core already has two useful precedents: 1. #48's external tool loader separates **trusted loader callables** from sanitized declarative manifests and makes loading availability-only. 2. #52/#72 separates **trusted host MCP execution profiles/config references** from inert server declarations, capabilities, authority mediation, and hard execution confinement. The same lesson should apply here. A downstream package needs an inspectable Prolog-native project policy/config boundary, but project repository content is not automatically trusted executable host policy. ## Architectural boundary ### Core should own - provider/pack registration ABI; - provider identity and schema/version; - project/scope association through #75; - closed declaration classes; - normalization/validation; - provenance/trust classification; - deterministic load/unload/reload semantics; - sanitized inspection/catalog output; - integration hooks to #75 effective state; - integration hooks for tool/MCP references; - explicit authority-policy eligibility hooks without granting authority; - fail-closed malformed/ambiguous provider behavior. ### Downstream hosts/agents/tool packs should own - concrete file/directory names; - whether configuration is a module, pack, dedicated declarative file, generated data source, etc.; - product-specific setting keys; - coding-agent instructions and UX; - project-specific tool defaults; - domain-specific rule schemas built on core registration primitives; - user-facing project setup/discovery workflow. Do not make core depend on `agentProlog` or any one downstream product. ## Provider model Define a tiny trusted provider/registration ABI analogous in spirit to the tool-loader boundary. The exact representation should be designed with current repository conventions, but a provider should have inspectable metadata equivalent to: ```text provider id provider schema/version scope/project identity origin/trust class supported declaration classes sanitized manifest/catalog data trusted loader/reader registration kept out of model-facing data ``` Provider discovery/catalog APIs must not return arbitrary trusted callables. Multiple independent downstream providers should be able to contribute project configuration without name collisions becoming nondeterministic. Duplicate provider/declaration identities must fail structurally or follow an explicitly documented deterministic merge rule. ## Safe Prolog-native declaration boundary Evaluate and document the safest minimal mechanism consistent with current architecture. Viable directions include: - ground schema-validated declarations parsed as data; - restricted multifile declarations contributed by modules that the trusted host has already loaded/allowed; - explicit trusted module/provider registration whose exported declaration predicate returns closed data; - a dedicated parser for a restricted Prolog-term configuration file that rejects directives/clauses/callables and reads only allowed ground declaration forms; - another bounded equivalent. The implementation may combine these, but it must preserve one rule: > **Repository presence is not executable trust.** Do not implement: ```prolog consult(ProjectFile), call(WhateverItDeclared). ``` Do not pass arbitrary project/model terms into unrestricted `call/1`, `once/1`, meta-call, directive execution, term expansion, initialization hooks, or equivalent ambient execution paths. If ordinary Prolog modules are supported, the host must explicitly trust/register the module/provider before its executable code participates. The sanitized declarations consumed by core must still pass the closed schema. ## Declaration classes The provider contract should be extensible but start with explicit classes such as: ### Ordinary settings Closed key/value data resolved through #75's non-security scope precedence. ### Project instructions Structured/textual operator/project instructions with explicit provenance. They may be consumed by #70/#68-#71 as operator/project configuration, not silently treated as repository facts of equal authority. ### Tool/MCP configuration references References to installed/declared tool packs, categories, MCP server/profile/config references, or downstream tool settings. A reference means “configure/select this thing,” not “grant capability” or “authorize its side effects.” Preserve #48/#52/#72 boundaries. ### Bounded permission-profile declarations A project policy pack may declare or select a **bounded operation profile** understood by #76, but declaration alone does not create a durable authorization grant. Core must distinguish: ```text profile exists / is configured != operator granted persistent authority to it ``` A profile that can affect authorization must use a closed trusted matcher schema and stable identity/version. Untrusted project data cannot inject executable matching predicates. ## Trust classes The API must distinguish at least conceptually between: - trusted host/provider registration; - trusted operator mutation in #75; - project-provided declarative configuration; - model-proposed/candidate data; - repository/context observations. Exact names may follow repository conventions. A project declaration may be useful configuration without being allowed to widen authority. Prefer fail-safe semantics where project-local configuration can select/constrain known trusted profiles but cannot manufacture new host execution authority by itself. If a host explicitly allows a provider to contribute authority-relevant declarations, that trust decision must be visible, bounded, and still subordinate to #76/#53 host ceilings. There must be no “trusted because it was in Git” rule. Humanity has suffered enough from executable config files. ## Discovery and project-local convention Do **not** hard-code a filename merely to imitate another agent product. The implementation/design should compare: - an ordinary project-local Prolog module; - SWI-Prolog pack-style organization; - a dedicated restricted declarative Prolog-term file; - host-registered provider modules that discover their own downstream convention. Given the current #48 loader architecture, the default direction should be: ```text prolog-rlm core -> provider registration + closed declarations + validation downstream agent/tool package -> decides project-local convention and registers provider ``` If core grows project discovery, it should be neutral and return candidate locations/providers as data; it must not auto-execute arbitrary discovered code. ## Load / unload / reload semantics Define deterministic lifecycle behavior: - discover/register provider; - validate provider manifest/schema; - resolve target project identity through #75; - load declarations as data; - apply eligible ordinary settings/config into a scoped view; - expose sanitized inspection data; - unload provider/project contribution deterministically; - reload after file/provider change without accumulating duplicate stale declarations; - mark superseded/invalid provider data in provenance where needed; - do not retain executable loader/provider callables in audit history. Loading a provider/project pack must be **inert with respect to capability and authority**. Reload must never widen policy merely because a new declaration appeared. Authority-affecting changes that would alter an existing #76 grant's matcher identity/version must require explicit revalidation/re-authorization according to #76. ## Public API direction Exact predicate names must follow repository conventions. Core should expose semantics equivalent to: ```prolog project_policy_provider_register(+ProviderId, +TrustedProvider, -Outcome). project_policy_provider_unregister(+ProviderId, -Outcome). project_policy_providers(-Providers). project_policy_catalog(+Project, -Catalog). project_policy_load(+Store, +Project, +ProviderId, +Options, -Outcome). project_policy_unload(+Store, +Project, +ProviderId, -Outcome). project_policy_reload(+Store, +Project, +ProviderId, -Outcome). project_policy_declarations(+Project, +Class, -Declarations). ``` Illustrative only. Trusted provider callables/reader internals must remain private like the tool-loader ABI; catalog/discovery returns sanitized declarative information. Pure/local loading need not gain fake async twins. If a downstream provider genuinely performs latency-bearing external I/O, it should follow #54 internally through the canonical async contract and explicit capabilities rather than making the core project-policy API magically ambient-network-aware. ## Security invariants - Project files are not automatically trusted executable Prolog. - No arbitrary `consult` + unrestricted meta-call boundary. - No model-generated provider registration or trusted callable injection. - Model/project data cannot create persistent grants directly. - Loading configuration does not grant capabilities. - Loading configuration does not set/widen #53 authority modes. - Loading configuration does not create a #76 persistent authorization merely because a permission profile is declared. - `dangerous` remains explicit host/user authority and is never implied by a project pack. - Schema validation happens before declarations become effective. - Unknown declarations/schema versions fail structurally; authority-affecting malformed state fails closed. - Provider/catalog inspection does not expose secrets or trusted callables. - Secrets remain references resolved through trusted host configuration mechanisms such as the #52/#72 pattern; they are not plaintext ordinary project facts/traces. - Tool/MCP declarations remain availability/configuration, separate from capability and authority. - Project instructions/config retain provenance distinct from repository observations/model inference in #70. - Unload/reload cannot leave stale authority-relevant declarations active invisibly. ## Interaction with existing modules/issues ### #75 Owns scopes, project identity, durable records, precedence, provenance, and trusted mutation. This issue contributes validated provider/project declarations into that substrate or an effective view over it. Provider-loaded project declarations and operator-mutated durable state must remain distinguishable by origin/trust class. ### #76 / #53 This boundary may expose bounded permission-profile declarations to #76, but does not authorize them. Persistent authorization still requires trusted operator/host grant creation and remains capped by #53/current host policy. ### #48 / `rlm_tool_loader` Reuse the successful split between sanitized declarative manifests and private trusted loader callables. Do not expose project-provider callables through catalog APIs. ### #49/#50 Concrete project/tool integration belongs naturally in downstream libraries/tool packs rather than core. ### #52/#72 / `rlm_mcp_policy` Preserve separation among MCP server declarations, trusted execution profiles/config references, capabilities, authority, and hard confinement. Project policy may refer to those entities but cannot collapse them. ### #16 Project policy/config is trusted/operator configuration, not model-published durable reasoning artifact state. ### #68-#71 / especially #70 #70 should be able to inspect effective project instructions/settings as a distinct operator/project configuration provenance class. It must not flatten them into generic repository facts or let resolved context write back trusted policy automatically. ## Acceptance criteria - [ ] Core exposes a documented provider/registration ABI whose trusted callables/readers are not returned through model-facing discovery/catalog APIs. - [ ] Provider declarations are closed, ground where required, schema/version validated, and inspectable. - [ ] Arbitrary repository Prolog code is not auto-consulted/executed merely because a project config location exists. - [ ] A fixture containing directives/initialization/arbitrary clauses is rejected or parsed strictly as non-executable data according to the selected design. - [ ] Model-generated terms cannot register a trusted provider or cause arbitrary meta-call execution. - [ ] Two project fixtures can load different Prolog-native settings/instructions/tool references with no cross-project leakage. - [ ] The same downstream provider can unload/reload one project's changed configuration deterministically without duplicate stale declarations. - [ ] Invalid/unknown provider schema fails structurally and cannot partially activate authority-relevant policy. - [ ] Loading a project policy/config pack changes no capability grant. - [ ] Loading a project policy/config pack changes no #53 authority mode. - [ ] A bounded permission-profile declaration alone does not create an active #76 grant. - [ ] An explicit trusted #76 grant may reference a valid stable bounded profile; changing the profile identity/version forces the safe #76 behavior rather than silently widening the grant. - [ ] Tool/MCP references remain configuration only; install/start/invoke still pass capability, hard policy, and authority boundaries. - [ ] Catalog/trace/error output contains reference metadata rather than resolved secrets or trusted callables. - [ ] Effective project instructions/settings can be consumed by #70/#68-#71 with explicit provenance distinct from repo observation/model inference. - [ ] Documentation clearly tells downstream agents how to implement their own project-local convention without modifying core. ## Non-goals - No fixed `.claude`-like filename/directory in core unless neutral discovery evidence later requires one. - No `agentProlog`-specific configuration schema in core. - No arbitrary repository `consult/1` execution path. - No unrestricted project-defined predicates as permission matchers. - No implicit capability grant. - No implicit persistent authorization. - No automatic `dangerous` or persistent `allow_session`. - No secret store. - No replacement for external tool-pack or MCP configuration systems. - No UI/TUI. ## Dependencies / references - Parent #74 - Depends on #75 scoped durable-state/project identity substrate - Integrates with #76 persistent authorization profiles without creating grants - #48 external tool-library loader ABI - #49 companion tool library - #50 standard tool pack - #52/#72 declarative MCP + hard execution profiles/config references - #53 host-controlled authority - #54 sync/async contract - #68-#71 context/workflow pipeline - `prolog/rlm_tool_loader.pl` - `prolog/rlm_mcp_policy.pl` - `docs/external-tool-libraries.md` - `docs/mcp-lifecycle.md` - `research/RLM-RESEARCH-003-typed-symbolic-execution.org` - `research/RLM-RESEARCH-009-durable-artifact-context.org`

lost-rob0t commented

2026-08-19 17:26:56 +00:00

(Migrated from github.com)

Architecture clarification from #126/#127: #77 remains the safe core project-policy/provider boundary for declarative/untrusted project configuration. AgentProlog adds a separate downstream trust decision: after the operator explicitly trusts a structured project identity, that project's .agentprolog/config.prolog may be loaded as executable host extension code. Repository presence alone remains inert. This does not weaken #77's reusable-core rule against arbitrary auto-consult; it distinguishes untrusted discovery from an explicit downstream code-trust grant.

Architecture clarification from #126/#127: #77 remains the safe **core** project-policy/provider boundary for declarative/untrusted project configuration. AgentProlog adds a separate downstream trust decision: after the operator explicitly trusts a structured project identity, that project's `.agentprolog/config.prolog` may be loaded as executable host extension code. Repository presence alone remains inert. This does not weaken #77's reusable-core rule against arbitrary auto-consult; it distinguishes untrusted discovery from an explicit downstream code-trust grant.