[P1] Move concrete project tools into in-repo standard tool packages #49

New issue

Closed

opened 2026-08-16 04:01:08 +00:00 by lost-rob0t · 2 comments

lost-rob0t commented

2026-08-16 04:01:08 +00:00

(Migrated from github.com)

Goal

Move concrete project/file/code-agent tools out of the prolog-rlm core runtime module set into separately loadable tool packages while keeping the core registry, loader, capability, authority, async, cancellation, and effect contracts unchanged.

Repository placement decision: the standard tool packages are maintained in the same lost-rob0t/prolog-rlm Git repository by default. “External” means external to the core runtime dependency graph / separately loadable, not “must live in another Git repository.” Third-party tool packs may still live in other repositories and use the same public loader ABI.

Suggested in-repo shape (exact directory/package naming may follow implementation evidence):

prolog-rlm/
  prolog/                 # domain-neutral core runtime
  tools/ or packs/        # separately loadable standard concrete tool packages
    filesystem/
    git/
    forge/
    process/
    network/

This keeps one checkout, one issue tracker, one CI/version graph, and one release surface while preserving the architectural rule that core does not import or require the concrete production tool catalog.

First migration

The existing project_read implementation is the first concrete tool to extract from the core runtime module set into the in-repo standard tool area.

Acceptance criteria

prolog-rlm core runtime modules no longer own the concrete production project_read implementation.
project_read is supplied by a separately loadable standard tool package maintained in this repository by default and registered through the public tool-loading boundary.
Standard filesystem/Git/forge/process/network tool packages can live in this repository without becoming dependencies of the core runtime.
Third-party tool packages can still live outside this repository and use the same loader/manifest contract.
Existing path confinement, traversal rejection, symlink rejection, byte limits, wall-time limits, schema validation, authority/effect semantics, and tracing remain intact.
Existing downstream code can opt into the in-repo standard tool packages explicitly.
Core tests use fixture/external registration paths rather than depending on production concrete-tool implementations.
Standard tool packages have their own focused tests while participating in the repository aggregate CI gate.
No concrete filesystem/network/process/repository authority becomes ambient merely because the packages are present in the checkout or loaded.
One repository does not imply one monolithic package: loading/category/capability/authority boundaries remain explicit.

Non-goals

Do not turn prolog-rlm core into a batteries-included coding-agent runtime.
Do not require a separate Git repository for each tool family.
Do not make core import the standard concrete tool packages.
Do not make loading a package equivalent to granting capabilities or authority.

Architectural intent

one Git repository

prolog-rlm core
  -> registry / schemas / loader / capabilities / authority / effects / async

in-repo standard tool packages
  -> filesystem / Git / forge / process / network implementations

third-party packages
  -> same public loader ABI, optionally maintained elsewhere

## Goal Move concrete project/file/code-agent tools out of the `prolog-rlm` **core runtime module set** into separately loadable tool packages while keeping the core registry, loader, capability, authority, async, cancellation, and effect contracts unchanged. **Repository placement decision:** the standard tool packages are maintained in the **same `lost-rob0t/prolog-rlm` Git repository by default**. “External” means external to the core runtime dependency graph / separately loadable, **not** “must live in another Git repository.” Third-party tool packs may still live in other repositories and use the same public loader ABI. Suggested in-repo shape (exact directory/package naming may follow implementation evidence): ```text prolog-rlm/ prolog/ # domain-neutral core runtime tools/ or packs/ # separately loadable standard concrete tool packages filesystem/ git/ forge/ process/ network/ ``` This keeps one checkout, one issue tracker, one CI/version graph, and one release surface while preserving the architectural rule that core does not import or require the concrete production tool catalog. ## First migration The existing `project_read` implementation is the first concrete tool to extract from the core runtime module set into the in-repo standard tool area. ## Acceptance criteria - [ ] `prolog-rlm` core runtime modules no longer own the concrete production `project_read` implementation. - [ ] `project_read` is supplied by a separately loadable standard tool package maintained in this repository by default and registered through the public tool-loading boundary. - [ ] Standard filesystem/Git/forge/process/network tool packages can live in this repository without becoming dependencies of the core runtime. - [ ] Third-party tool packages can still live outside this repository and use the same loader/manifest contract. - [ ] Existing path confinement, traversal rejection, symlink rejection, byte limits, wall-time limits, schema validation, authority/effect semantics, and tracing remain intact. - [ ] Existing downstream code can opt into the in-repo standard tool packages explicitly. - [ ] Core tests use fixture/external registration paths rather than depending on production concrete-tool implementations. - [ ] Standard tool packages have their own focused tests while participating in the repository aggregate CI gate. - [ ] No concrete filesystem/network/process/repository authority becomes ambient merely because the packages are present in the checkout or loaded. - [ ] One repository does not imply one monolithic package: loading/category/capability/authority boundaries remain explicit. ## Non-goals - Do not turn `prolog-rlm` core into a batteries-included coding-agent runtime. - Do not require a separate Git repository for each tool family. - Do not make core import the standard concrete tool packages. - Do not make loading a package equivalent to granting capabilities or authority. ## Architectural intent ```text one Git repository prolog-rlm core -> registry / schemas / loader / capabilities / authority / effects / async in-repo standard tool packages -> filesystem / Git / forge / process / network implementations third-party packages -> same public loader ABI, optionally maintained elsewhere ```

lost-rob0t commented

2026-08-17 07:39:24 +00:00

(Migrated from github.com)

Post-#72 live-state audit confirms #49 is now the smallest coherent external-tool follow-on from canonical main 7b527750a64d5cbd9fff79413a399a8c69e90c75.

Current concrete ownership is still exactly in core: prolog/rlm_tool.pl exports register_project_read_tool/4 and contains the project_read schema, confinement preflight, handler, root/path normalization, traversal rejection, symlink-component rejection, byte-limit handling, and project-root containment helpers. test/rlm_tool_test.pl still directly registers that core concrete implementation for success, confinement, and typed-plan coverage.

The loader boundary needed for extraction is now mature: trusted multifile pack + sanitized manifest, deterministic category loading/idempotency/conflict preflight, capability separation, authority separation, and inert MCP behavior are on main. The next acceptance should therefore extract only project_read through a separately loadable filesystem pack/companion-library path while keeping generic registry/preflight/schema/authority machinery in core.

Preserve the exact existing safety behavior during migration: project-root confinement, traversal/backslash/NUL rejection, symlink-component rejection, regular-file/readability checks, byte and wall-time bounds, schema validation, tracing, capability gating, and normalized authority effect identity. Do not use this slice to add project_search, Git/process/network tools, or the rest of #50.

Post-#72 live-state audit confirms #49 is now the smallest coherent external-tool follow-on from canonical `main` `7b527750a64d5cbd9fff79413a399a8c69e90c75`. Current concrete ownership is still exactly in core: `prolog/rlm_tool.pl` exports `register_project_read_tool/4` and contains the `project_read` schema, confinement preflight, handler, root/path normalization, traversal rejection, symlink-component rejection, byte-limit handling, and project-root containment helpers. `test/rlm_tool_test.pl` still directly registers that core concrete implementation for success, confinement, and typed-plan coverage. The loader boundary needed for extraction is now mature: trusted multifile pack + sanitized manifest, deterministic category loading/idempotency/conflict preflight, capability separation, authority separation, and inert MCP behavior are on `main`. The next acceptance should therefore extract only `project_read` through a separately loadable filesystem pack/companion-library path while keeping generic registry/preflight/schema/authority machinery in core. Preserve the exact existing safety behavior during migration: project-root confinement, traversal/backslash/NUL rejection, symlink-component rejection, regular-file/readability checks, byte and wall-time bounds, schema validation, tracing, capability gating, and normalized authority effect identity. Do not use this slice to add `project_search`, Git/process/network tools, or the rest of #50.

nsaspy referenced this issue

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

Canonical async tool + MCP runtime slice #60

nsaspy referenced this issue

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

Harden external tool category loading boundary #66

nsaspy referenced this issue

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

Reconcile backlog, roadmap, and GitHub issue state #89

nsaspy closed this issue

2026-09-08 01:28:59 +00:00

nsaspy commented

2026-09-08 01:31:43 +00:00

Owner

Closing as superseded by the canonical product boundary in #141. Concrete coding/project filesystem/Git/process/test tool packs are product/downstream ownership in lost-rob0t/agentProlog; prolog-rlm should keep only reusable generic runtime/tool contracts. Future expert-system work may reason over typed host-supplied capabilities without moving concrete coding tools back into core.

Closing as **superseded by the canonical product boundary in #141**. Concrete coding/project filesystem/Git/process/test tool packs are product/downstream ownership in `lost-rob0t/agentProlog`; `prolog-rlm` should keep only reusable generic runtime/tool contracts. Future expert-system work may reason over typed host-supplied capabilities without moving concrete coding tools back into core.

nsaspy referenced this issue

2026-09-10 21:18:01 +00:00

[P1] Define dual synchronous/asynchronous API contract across RLM libraries #425

nsaspy referenced this issue

2026-09-10 21:18:07 +00:00

[EPIC] Add durable scoped state and Prolog-native project policy configuration #432

nsaspy referenced this issue

2026-09-10 21:18:10 +00:00

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