[SUPERSEDED] Standalone AgentProlog downstream product boundary

lost-rob0t commented

2026-08-21 03:53:51 +00:00

(Migrated from github.com)

Companion to lost-rob0t/agentProlog#1.

Mission

Make prolog-rlm a clean, flake-consumable reusable runtime for the standalone lost-rob0t/agentProlog product while preserving prolog-rlm as a domain-neutral SWI-Prolog runtime/library.

Work autonomously and do as much useful work as possible per loop. Do not merely complete one trivial checklist item and stop. Before each slice, inspect current main, applicable repository instructions, docs/design/research, issues/comments, recent PRs/commits, source, tests, and CI; reconcile stale prose against merged executable truth.

Correct integration decision

prolog-rlm itself is NOT an AgentProlog plugin.

Do not route the runtime through rlm_tool_loader, and do not confuse XDG config.prolog with a package/plugin architecture.

The intended composition is:

AgentProlog product
  -> frontend plugins / coding tool packs / headless coding workflow
  -> public prolog-rlm APIs
  -> prolog-rlm runtime

AgentProlog consumes this repository as a pinned Nix flake input and normal SWI-Prolog package/library dependency.

prolog-rlm already has a SWI pack.pl and clean SWI-pack installation validation. Preserve that supported package identity while adding clean Nix flake consumption rather than replacing one packaging mechanism with an unrelated runtime copy.

Dependency direction remains:

agentProlog -> prolog-rlm

Never make core import or depend on AgentProlog product code.

When this repository should be edited

Implement changes in prolog-rlm when standalone AgentProlog exposes a missing or incorrect generic runtime contract, including:

model/provider runtime semantics;
async/Futures/cancellation;
authority and pending approvals;
durable effect identity/adoption;
MCP runtime/contracts;
tracing/usage/result envelopes;
Spec/Plan/Verify primitives;
managed conversation/context runtime;
graph/agent execution;
reusable project/source knowledge APIs;
generic frontend protocol/facade semantics;
external tool-library loader contract;
other domain-neutral APIs needed by multiple downstream clients.

Do not put coding-product-specific implementations in core merely because AgentProlog needs them. Concrete repository/Git/process/test tools, Bubble Tea rendering, editor UX, product defaults, and coding-specific composition belong downstream.

If a missing behavior is truly product-specific, cross-link/hand it back to lost-rob0t/agentProlog#1 rather than bloating core.

Existing extension boundaries: use them accurately

External tool packs

The existing rlm_tool_loader / docs/external-tool-libraries.md contract is the package/extension seam for concrete external tools.

Core owns:

tool registry lifecycle;
schemas/validation;
capabilities;
category/pack discovery and deterministic loading;
tracing/limits;
policy/authority/effect integration contracts.

External libraries own concrete tool implementations.

Use this for future AgentProlog filesystem/Git/process/test tool packs where appropriate.

Do not turn it into a universal runtime plugin loader.

`config.prolog`

Existing/planned programmable AgentProlog configuration (#126 and children) is runtime/operator configuration and trusted customization. It is not the packaging mechanism by which AgentProlog embeds prolog-rlm.

Do not cite config.prolog as evidence that the runtime already has a general binary/package plugin ABI.

Other pluggable contracts

Where current generic APIs already intentionally support multiple implementations (providers, parser backends, external tools, MCP adapters, frontend protocol clients, etc.), extend those existing contracts rather than inventing parallel systems.

Never create authority_v2, another scheduler, another effect ledger, another verifier stack, or another protocol merely to satisfy AgentProlog.

Nix flake packaging

Add/maintain first-class Nix flake packaging so downstream consumers can depend on this repository directly.

Create/maintain:

flake.nix
flake.lock

Expose sensible outputs, following repository conventions, such as:

packages.${system}.prolog-rlm
packages.${system}.default
devShells.${system}.default
checks.${system}.*

If a runnable CLI app output is appropriate, expose it without making the library packaging depend on the CLI.

The flake package must produce a usable SWI-Prolog library/pack that allows a consumer to load the installed runtime outside the source checkout.

Preserve and integrate the existing clean-pack install invariant: a fresh process outside the repository must be able to load the packaged library(rlm) (or the canonical public library entrypoint).

Use Nix for external/native build dependencies. Do not require downstream AgentProlog to perform ad-hoc clones or runtime downloads to consume core.

Provide a documented consumption example equivalent to:

inputs.prolog-rlm.url = "github:lost-rob0t/prolog-rlm";

and demonstrate how downstream packaging obtains the SWI library path/package artifact without reaching into arbitrary internal source paths.

Audit current nested AgentProlog code

Substantial product code still lives under:

agentProlog/

Audit it and all related support code/docs/tests.

Classify each relevant component as:

MIGRATE DOWNSTREAM
KEEP CORE
REUSE VIA PUBLIC CORE API
SPLIT GENERIC CORE FROM PRODUCT WRAPPER
LEGACY / DO NOT MIGRATE
BLOCKED

Reference exact files/modules/functions.

The classification must be based on semantics, not directory location. Some code under agentProlog/ may reveal missing generic runtime behavior that belongs in core; some code elsewhere may actually be product-facing and should migrate downstream.

Frontend protocol ownership

Preserve the renderer-independent semantics of prolog_agent_ui_v1 where they represent a reusable, authoritative product/runtime boundary.

Determine explicitly which pieces belong:

in generic prolog-rlm runtime/facade support;
in downstream AgentProlog protocol adapters;
in frontend plugins.

Do not let a Bubble Tea/OpenTUI/Emacs client become authoritative execution logic.

Preserve, where canonical:

bounded snapshots;
ordered semantic events;
request correlation;
reconnect/replay semantics;
cancellation;
approval/question command semantics;
generic unknown-tool representation;
verification/usage/trace/subagent/effect-uncertainty event semantics.

If protocol semantics are inherently AgentProlog-product-specific, keep the reusable transport/runtime primitives generic and migrate the product facade downstream instead of permanently coupling core to one coding UI.

Headless workflow support

Ensure core public APIs are sufficient for downstream AgentProlog to implement one headless coding workflow:

operator requirement
-> normalize/validate/freeze Spec
-> resolve project/context
-> Plan bound to Spec
-> execute bounded operations
-> refresh project observations/evidence
-> Verify exact Frozen Spec
-> repair/replan without weakening Spec
-> structured completion

Do not implement a special AgentProlog scheduler in core.

Reuse and complete existing generic work where needed, especially relevant slices under:

#54 async contract;
#56 result/evidence acceptance;
#57/#79 durable effects;
#68-#71 workflow/context/continuation;
#74-#77 scoped state/project policy;
#93/#95-#99 project/source knowledge;
#101 managed conversation runtime;
other current merged APIs discovered during implementation.

Do not assume old issue text is current. Inspect merged code/tests first.

External coding-tool integration contract

Standalone AgentProlog should be able to ship concrete filesystem/Git/process/test packs outside core using rlm_tool_loader.

Audit whether the existing loader and runtime execution contracts are sufficient for safe tools equivalent to:

project_read
project_search
project_write
project_patch
git_status
git_diff
git_show
git_apply
run_tests
bounded process_run

Core should not implement those concrete coding catalogs unless an item is genuinely generic and already belongs here.

Core should provide/fix generic contracts needed to preserve:

project/root confinement hooks;
structured schema validation;
capabilities;
authority mediation;
durable effect identity for writes/process/network operations;
cancellation;
bounded async execution;
time/output budgets;
structured outcomes/traces;
deterministic external-pack loading and conflict handling.

If the loader/runtime cannot safely support the downstream pack, create a focused upstream child issue and fix the contract here rather than letting AgentProlog bypass it.

Compare current nested harness against standalone target

Maintain an upstream-facing migration matrix covering:

Concern	Current nested code	Correct long-term owner	Action
providers
async/Futures
authority
effects
Spec/Plan/Verify
project/source KB
coding tools
protocol/facade
TUI/client code
config
persistence
MCP
traces
packaging
tests/fixtures

Use this to migrate code deliberately and prevent duplicated runtime behavior.

Verification

Use TDD and executable evidence.

At minimum ensure:

flake package builds reproducibly;
packaged SWI library loads outside source checkout;
nix flake check exercises meaningful runtime/package checks;
existing deterministic core suite remains green;
external tool-pack fixtures still prove loading != capability != authority;
generic runtime APIs used by standalone AgentProlog have deterministic conformance tests;
protocol/runtime changes preserve ordering/reconnect/cancellation/approval invariants where owned here;
no migration change weakens authority/effects/confinement semantics;
GitHub Actions remains canonical full evidence.

Do not weaken CI to obtain green.

OLD HARNESS REMOVAL GATE

DO NOT REMOVE prolog-rlm/agentProlog/ yet.

The nested harness is a migration source and compatibility reference until standalone AgentProlog reaches verified parity.

You may inspect, test, refactor generic portions, migrate product portions, and mark readiness accurately. Do not delete, gut, or replace it with an empty stub.

Final removal requires a separate explicit user command. Keep the corresponding cutover/removal work blocked until that command is given.

Autonomous-loop contract

For every autonomous work cycle on this epic:

inspect all relevant current repository state, applicable memory/task context if available, issues/comments, recent PRs/commits, docs/research/design, source, tests, CI, and lost-rob0t/agentProlog#1;
reconcile stale issue/roadmap text against merged executable truth;
determine whether the next need is a core change, existing API reuse, or downstream product work;
if core work is required, implement the smallest coherent generic slice with TDD;
if work is downstream, cross-link it to agentProlog#1 rather than implementing product-specific code here;
run focused and complete required gates;
update roadmap/docs/issues so GitHub state matches reality;
continue into another safe actionable slice when possible rather than stopping solely because one checkbox closed.

The loop must search beyond this issue body each run. This issue is a mission contract, not frozen repository truth.

Deliverables

first-class flake packaging for prolog-rlm;
documented downstream flake consumption;
explicit runtime-vs-plugin-vs-config boundary;
audit/classification of nested AgentProlog code;
any generic runtime API fixes required by standalone AgentProlog;
safe external coding-tool-pack integration contract;
protocol/runtime ownership cleanup where needed;
conformance tests and docs;
synchronized roadmap/issue state;
legacy nested harness retained until explicit removal authorization.

Companion to `lost-rob0t/agentProlog#1`. ## Mission Make `prolog-rlm` a clean, flake-consumable reusable runtime for the standalone `lost-rob0t/agentProlog` product while preserving `prolog-rlm` as a domain-neutral SWI-Prolog runtime/library. Work autonomously and do as much useful work as possible per loop. Do not merely complete one trivial checklist item and stop. Before each slice, inspect current `main`, applicable repository instructions, docs/design/research, issues/comments, recent PRs/commits, source, tests, and CI; reconcile stale prose against merged executable truth. ## Correct integration decision `prolog-rlm` itself is **NOT** an AgentProlog plugin. Do not route the runtime through `rlm_tool_loader`, and do not confuse XDG `config.prolog` with a package/plugin architecture. The intended composition is: ```text AgentProlog product -> frontend plugins / coding tool packs / headless coding workflow -> public prolog-rlm APIs -> prolog-rlm runtime ``` AgentProlog consumes this repository as a pinned **Nix flake input** and normal SWI-Prolog package/library dependency. `prolog-rlm` already has a SWI `pack.pl` and clean SWI-pack installation validation. Preserve that supported package identity while adding clean Nix flake consumption rather than replacing one packaging mechanism with an unrelated runtime copy. Dependency direction remains: ```text agentProlog -> prolog-rlm ``` Never make core import or depend on AgentProlog product code. ## When this repository should be edited Implement changes in `prolog-rlm` when standalone AgentProlog exposes a missing or incorrect **generic runtime contract**, including: - model/provider runtime semantics; - async/Futures/cancellation; - authority and pending approvals; - durable effect identity/adoption; - MCP runtime/contracts; - tracing/usage/result envelopes; - Spec/Plan/Verify primitives; - managed conversation/context runtime; - graph/agent execution; - reusable project/source knowledge APIs; - generic frontend protocol/facade semantics; - external tool-library loader contract; - other domain-neutral APIs needed by multiple downstream clients. Do **not** put coding-product-specific implementations in core merely because AgentProlog needs them. Concrete repository/Git/process/test tools, Bubble Tea rendering, editor UX, product defaults, and coding-specific composition belong downstream. If a missing behavior is truly product-specific, cross-link/hand it back to `lost-rob0t/agentProlog#1` rather than bloating core. ## Existing extension boundaries: use them accurately ### External tool packs The existing `rlm_tool_loader` / `docs/external-tool-libraries.md` contract is the package/extension seam for **concrete external tools**. Core owns: - tool registry lifecycle; - schemas/validation; - capabilities; - category/pack discovery and deterministic loading; - tracing/limits; - policy/authority/effect integration contracts. External libraries own concrete tool implementations. Use this for future AgentProlog filesystem/Git/process/test tool packs where appropriate. Do not turn it into a universal runtime plugin loader. ### `config.prolog` Existing/planned programmable AgentProlog configuration (`#126` and children) is **runtime/operator configuration and trusted customization**. It is not the packaging mechanism by which AgentProlog embeds `prolog-rlm`. Do not cite `config.prolog` as evidence that the runtime already has a general binary/package plugin ABI. ### Other pluggable contracts Where current generic APIs already intentionally support multiple implementations (providers, parser backends, external tools, MCP adapters, frontend protocol clients, etc.), extend those existing contracts rather than inventing parallel systems. Never create `authority_v2`, another scheduler, another effect ledger, another verifier stack, or another protocol merely to satisfy AgentProlog. ## Nix flake packaging Add/maintain first-class Nix flake packaging so downstream consumers can depend on this repository directly. Create/maintain: ```text flake.nix flake.lock ``` Expose sensible outputs, following repository conventions, such as: ```text packages.${system}.prolog-rlm packages.${system}.default devShells.${system}.default checks.${system}.* ``` If a runnable CLI app output is appropriate, expose it without making the library packaging depend on the CLI. The flake package must produce a usable SWI-Prolog library/pack that allows a consumer to load the installed runtime outside the source checkout. Preserve and integrate the existing clean-pack install invariant: a fresh process outside the repository must be able to load the packaged `library(rlm)` (or the canonical public library entrypoint). Use Nix for external/native build dependencies. Do not require downstream AgentProlog to perform ad-hoc clones or runtime downloads to consume core. Provide a documented consumption example equivalent to: ```nix inputs.prolog-rlm.url = "github:lost-rob0t/prolog-rlm"; ``` and demonstrate how downstream packaging obtains the SWI library path/package artifact without reaching into arbitrary internal source paths. ## Audit current nested AgentProlog code Substantial product code still lives under: ```text agentProlog/ ``` Audit it and all related support code/docs/tests. Classify each relevant component as: ```text MIGRATE DOWNSTREAM KEEP CORE REUSE VIA PUBLIC CORE API SPLIT GENERIC CORE FROM PRODUCT WRAPPER LEGACY / DO NOT MIGRATE BLOCKED ``` Reference exact files/modules/functions. The classification must be based on semantics, not directory location. Some code under `agentProlog/` may reveal missing generic runtime behavior that belongs in core; some code elsewhere may actually be product-facing and should migrate downstream. ## Frontend protocol ownership Preserve the renderer-independent semantics of `prolog_agent_ui_v1` where they represent a reusable, authoritative product/runtime boundary. Determine explicitly which pieces belong: - in generic `prolog-rlm` runtime/facade support; - in downstream AgentProlog protocol adapters; - in frontend plugins. Do not let a Bubble Tea/OpenTUI/Emacs client become authoritative execution logic. Preserve, where canonical: - bounded snapshots; - ordered semantic events; - request correlation; - reconnect/replay semantics; - cancellation; - approval/question command semantics; - generic unknown-tool representation; - verification/usage/trace/subagent/effect-uncertainty event semantics. If protocol semantics are inherently AgentProlog-product-specific, keep the reusable transport/runtime primitives generic and migrate the product facade downstream instead of permanently coupling core to one coding UI. ## Headless workflow support Ensure core public APIs are sufficient for downstream AgentProlog to implement one headless coding workflow: ```text operator requirement -> normalize/validate/freeze Spec -> resolve project/context -> Plan bound to Spec -> execute bounded operations -> refresh project observations/evidence -> Verify exact Frozen Spec -> repair/replan without weakening Spec -> structured completion ``` Do not implement a special AgentProlog scheduler in core. Reuse and complete existing generic work where needed, especially relevant slices under: - #54 async contract; - #56 result/evidence acceptance; - #57/#79 durable effects; - #68-#71 workflow/context/continuation; - #74-#77 scoped state/project policy; - #93/#95-#99 project/source knowledge; - #101 managed conversation runtime; - other current merged APIs discovered during implementation. Do not assume old issue text is current. Inspect merged code/tests first. ## External coding-tool integration contract Standalone AgentProlog should be able to ship concrete filesystem/Git/process/test packs outside core using `rlm_tool_loader`. Audit whether the existing loader and runtime execution contracts are sufficient for safe tools equivalent to: ```text project_read project_search project_write project_patch git_status git_diff git_show git_apply run_tests bounded process_run ``` Core should not implement those concrete coding catalogs unless an item is genuinely generic and already belongs here. Core **should** provide/fix generic contracts needed to preserve: - project/root confinement hooks; - structured schema validation; - capabilities; - authority mediation; - durable effect identity for writes/process/network operations; - cancellation; - bounded async execution; - time/output budgets; - structured outcomes/traces; - deterministic external-pack loading and conflict handling. If the loader/runtime cannot safely support the downstream pack, create a focused upstream child issue and fix the contract here rather than letting AgentProlog bypass it. ## Compare current nested harness against standalone target Maintain an upstream-facing migration matrix covering: | Concern | Current nested code | Correct long-term owner | Action | |---|---|---|---| | providers | | | | | async/Futures | | | | | authority | | | | | effects | | | | | Spec/Plan/Verify | | | | | project/source KB | | | | | coding tools | | | | | protocol/facade | | | | | TUI/client code | | | | | config | | | | | persistence | | | | | MCP | | | | | traces | | | | | packaging | | | | | tests/fixtures | | | | Use this to migrate code deliberately and prevent duplicated runtime behavior. ## Verification Use TDD and executable evidence. At minimum ensure: - flake package builds reproducibly; - packaged SWI library loads outside source checkout; - `nix flake check` exercises meaningful runtime/package checks; - existing deterministic core suite remains green; - external tool-pack fixtures still prove loading != capability != authority; - generic runtime APIs used by standalone AgentProlog have deterministic conformance tests; - protocol/runtime changes preserve ordering/reconnect/cancellation/approval invariants where owned here; - no migration change weakens authority/effects/confinement semantics; - GitHub Actions remains canonical full evidence. Do not weaken CI to obtain green. ## OLD HARNESS REMOVAL GATE **DO NOT REMOVE `prolog-rlm/agentProlog/` yet.** The nested harness is a migration source and compatibility reference until standalone AgentProlog reaches verified parity. You may inspect, test, refactor generic portions, migrate product portions, and mark readiness accurately. Do not delete, gut, or replace it with an empty stub. Final removal requires a separate explicit user command. Keep the corresponding cutover/removal work blocked until that command is given. ## Autonomous-loop contract For every autonomous work cycle on this epic: 1. inspect all relevant current repository state, applicable memory/task context if available, issues/comments, recent PRs/commits, docs/research/design, source, tests, CI, and `lost-rob0t/agentProlog#1`; 2. reconcile stale issue/roadmap text against merged executable truth; 3. determine whether the next need is a core change, existing API reuse, or downstream product work; 4. if core work is required, implement the smallest coherent generic slice with TDD; 5. if work is downstream, cross-link it to `agentProlog#1` rather than implementing product-specific code here; 6. run focused and complete required gates; 7. update roadmap/docs/issues so GitHub state matches reality; 8. continue into another safe actionable slice when possible rather than stopping solely because one checkbox closed. The loop must search beyond this issue body each run. This issue is a mission contract, not frozen repository truth. ## Deliverables - first-class flake packaging for `prolog-rlm`; - documented downstream flake consumption; - explicit runtime-vs-plugin-vs-config boundary; - audit/classification of nested AgentProlog code; - any generic runtime API fixes required by standalone AgentProlog; - safe external coding-tool-pack integration contract; - protocol/runtime ownership cleanup where needed; - conformance tests and docs; - synchronized roadmap/issue state; - legacy nested harness retained until explicit removal authorization.

lost-rob0t commented

2026-08-21 04:50:56 +00:00

(Migrated from github.com)

New research child: #142 defines the reusable evolutionary-search library side. The paired downstream AgentProlog work is lost-rob0t/agentProlog#2, implemented as a DeepSeek Harness/Cordis plugin with a thin Prolog bridge. Keep generic evolution mechanics here; keep DeepSeek/product glue downstream.

lost-rob0t commented

2026-08-21 05:50:05 +00:00

(Migrated from github.com)

Subagent/prompt audit on current main (f21df8ea5bf89c85d0d516f170e1f157c553d800) found a real generic-runtime gap and is now tracked as #144.

Executable truth: rlm_agent already supplies supervised spawn, capability/authority narrowing, bounded mailboxes/workers, cancellation propagation and traces; rlm_plan routes spawn_agent through the ordinary tool boundary; rlm_completion supplies bounded recursive model calls. But spawn_agent only yields a child handle, not a bounded RLM subagent result/evidence envelope, and there is no canonical unknown/unresolved -> delegate -> resume/replan path. Successful child result correlation is likewise not an end-to-end first-class fallback contract.

Prompt compiler truth: the substantial compiler is still on diverged agent/prompt-context-compiler (18 ahead / 14 behind current main). It already has bounded deterministic capability/context selection, but no typed KB short-prompt -> loop-command binding that resolves unknown -> delegate to the RLM subagent tool. #144 scopes the smallest coherent upstream slice and explicitly avoids #122/#125/#132 surfaces and any AgentProlog-specific TypeScript behavior.

Subagent/prompt audit on current `main` (`f21df8ea5bf89c85d0d516f170e1f157c553d800`) found a real generic-runtime gap and is now tracked as #144. Executable truth: `rlm_agent` already supplies supervised spawn, capability/authority narrowing, bounded mailboxes/workers, cancellation propagation and traces; `rlm_plan` routes `spawn_agent` through the ordinary tool boundary; `rlm_completion` supplies bounded recursive model calls. But `spawn_agent` only yields a child handle, not a bounded RLM subagent result/evidence envelope, and there is no canonical unknown/unresolved -> delegate -> resume/replan path. Successful child result correlation is likewise not an end-to-end first-class fallback contract. Prompt compiler truth: the substantial compiler is still on diverged `agent/prompt-context-compiler` (18 ahead / 14 behind current main). It already has bounded deterministic capability/context selection, but no typed KB short-prompt -> loop-command binding that resolves `unknown -> delegate` to the RLM subagent tool. #144 scopes the smallest coherent upstream slice and explicitly avoids #122/#125/#132 surfaces and any AgentProlog-specific TypeScript behavior.

lost-rob0t commented

2026-08-25 03:10:27 +00:00

(Migrated from github.com)

OLD HARNESS REMOVAL GATE — LIFTED

The user has now explicitly authorized cleaning the repository first by removing the old harnesses.

This supersedes the previous DO NOT REMOVE prolog-rlm/agentProlog/ yet gate in this issue.

Cleanup is tracked in #186. The required behavior is:

remove the obsolete nested/product harness from prolog-rlm;
preserve or relocate genuinely reusable runtime/protocol pieces before deletion;
keep prolog-rlm runtime-only and downstream-consumable;
retire the old DeepSeek Harness implementation direction before starting #184.

No future worker should treat the old removal gate as active.

## OLD HARNESS REMOVAL GATE — LIFTED The user has now explicitly authorized cleaning the repository first by removing the old harnesses. This supersedes the previous `DO NOT REMOVE prolog-rlm/agentProlog/ yet` gate in this issue. Cleanup is tracked in #186. The required behavior is: - remove the obsolete nested/product harness from `prolog-rlm`; - preserve or relocate genuinely reusable runtime/protocol pieces before deletion; - keep `prolog-rlm` runtime-only and downstream-consumable; - retire the old DeepSeek Harness implementation direction before starting #184. No future worker should treat the old removal gate as active.

lost-rob0t commented

2026-08-27 13:54:58 +00:00

(Migrated from github.com)

Architecture update — 2026-08-27

The current operator direction supersedes the earlier standalone-product repository boundary in this issue.

AgentProlog now belongs in the prolog-rlm repository as a separately packaged application layer while prolog/ remains an independently consumable library.

Canonical dependency direction:

harness/* -> agentProlog/* -> public prolog-rlm APIs in prolog/*

Rules:

packages.default stays the reusable prolog-rlm library;
no AgentProlog or TUI imports flow back into prolog/;
application/frontends do not become alternate provider, planner, authority, effect, or verification runtimes;
the old nested harness removed by #186 stays removed; this is a clean current-main application layer, not restoration of that code;
PR #132 is the recovery transaction implementing this boundary, including the AgentProlog CLI and an in-repo DeepSeek TUI harness.

Treat earlier “standalone lost-rob0t/agentProlog only” prose as historical, not the current repository boundary.

## Architecture update — 2026-08-27 The current operator direction supersedes the earlier standalone-product repository boundary in this issue. **AgentProlog now belongs in the `prolog-rlm` repository as a separately packaged application layer while `prolog/` remains an independently consumable library.** Canonical dependency direction: ```text harness/* -> agentProlog/* -> public prolog-rlm APIs in prolog/* ``` Rules: - `packages.default` stays the reusable `prolog-rlm` library; - no AgentProlog or TUI imports flow back into `prolog/`; - application/frontends do not become alternate provider, planner, authority, effect, or verification runtimes; - the old nested harness removed by #186 stays removed; this is a clean current-main application layer, not restoration of that code; - PR #132 is the recovery transaction implementing this boundary, including the AgentProlog CLI and an in-repo DeepSeek TUI harness. Treat earlier “standalone `lost-rob0t/agentProlog` only” prose as historical, not the current repository boundary.