[P1] Add typed AgentProlog hook and extension-point registry #128

Closed
opened 2026-08-19 16:55:13 +00:00 by lost-rob0t · 1 comment
lost-rob0t commented 2026-08-19 16:55:13 +00:00 (Migrated from github.com)

Parent: #126
Depends on: #127 configuration runtime. Reuse existing rlm_chain middleware, rlm_tool_loader, authority/effect boundaries, recursion/runtime events, and prolog_agent_ui_v1; do not build competing stacks.

Goal

Define an inspectable typed extension-point registry for actual executable Prolog handlers registered from trusted AgentProlog configuration and trusted runtime modules.

The target is an Emacs-like programmable environment with explicit runtime ownership, not a static enable/disable catalog. A trusted XDG config.prolog should be able to define predicates and register them directly as hook implementations.

Executable project hooks are also supported only after that project configuration has passed #127's explicit trusted-project gate.

Required extension-point inventory

Initial registry must model stable identifiers for at least:

  • config/discover, config/load, config/validate, config/resolve, config/reload;
  • project/open, project/identity-resolved, project/config-reloaded;
  • session/create, session/open, session/resume, session/close;
  • prompt/before-compile, prompt/after-compile;
  • provider/before-route, provider/after-route;
  • model/before-request, model/after-response, model/stream-event;
  • tool/discover, tool/load, tool/preflight, tool/before-invoke, tool/after-result;
  • authority/request, authority/decision, authority/denied;
  • effect/prepare, effect/dispatch, effect/observe, effect/reconcile;
  • agent/turn-start, agent/step-start, agent/step-end, agent/turn-end;
  • error/observed, error/classified, error/repair-proposed, error/repair-result;
  • loop/observe, loop/detected, loop/decision;
  • verify/before, verify/result;
  • ui/before-project, ui/after-project for presentation projection.

Exact names may change to match repository conventions.

Registry contract

Each registration carries stable id, extension point, schema/version, priority/order, allowed scopes, failure policy, origin/config generation, and a trusted Prolog callable.

The callable is intentionally executable inside the runtime. Catalog/model-facing inspection exposes sanitized identity/metadata but not the callable term itself.

Trusted user config.prolog may register handlers. Trusted project config.prolog may register project-scoped handlers. Untrusted project/model data may not register executable hooks.

Define deterministic ordering, duplicate handling, generation-based unload/reload, cancellation propagation, and whether each point is observe-only, transform/waterfall, veto, or serial/parallel notification.

Runtime boundary

A hook may compute and influence only the semantics explicitly owned by its extension point. Registering a hook does not make its result a capability grant or authority decision unless the owning canonical subsystem explicitly interprets it that way.

Hooks must not silently swallow cancellation, durable-effect uncertainty, authority denial, or hard validation failures. Existing canonical modules remain the execution boundaries.

Acceptance

  • Trusted XDG config.prolog can define a normal Prolog predicate and register it as a hook.
  • Trusted project config can register project-scoped hooks only after project trust.
  • Extension points are queryable without exposing executable callables to model-facing catalogs.
  • Untrusted project/model data cannot register executable hooks.
  • Deterministic ordering/priority and duplicate-id behavior are tested.
  • Config generation reload removes stale executable registrations cleanly.
  • Failure policy is explicit and structured per hook class.
  • Cancellation/authority/effect boundaries cannot be swallowed by a hook.
  • Existing chain middleware and other canonical seams are adapted/reused instead of duplicated.
  • Hooks cannot widen capabilities or authority merely by returning data.
  • Docs include real config.prolog hook examples, not merely declarative JSON examples.
Parent: #126 Depends on: #127 configuration runtime. Reuse existing `rlm_chain` middleware, `rlm_tool_loader`, authority/effect boundaries, recursion/runtime events, and `prolog_agent_ui_v1`; do not build competing stacks. ## Goal Define an inspectable typed extension-point registry for **actual executable Prolog handlers** registered from trusted AgentProlog configuration and trusted runtime modules. The target is an Emacs-like programmable environment with explicit runtime ownership, not a static enable/disable catalog. A trusted XDG `config.prolog` should be able to define predicates and register them directly as hook implementations. Executable project hooks are also supported only after that project configuration has passed #127's explicit trusted-project gate. ## Required extension-point inventory Initial registry must model stable identifiers for at least: - config/discover, config/load, config/validate, config/resolve, config/reload; - project/open, project/identity-resolved, project/config-reloaded; - session/create, session/open, session/resume, session/close; - prompt/before-compile, prompt/after-compile; - provider/before-route, provider/after-route; - model/before-request, model/after-response, model/stream-event; - tool/discover, tool/load, tool/preflight, tool/before-invoke, tool/after-result; - authority/request, authority/decision, authority/denied; - effect/prepare, effect/dispatch, effect/observe, effect/reconcile; - agent/turn-start, agent/step-start, agent/step-end, agent/turn-end; - error/observed, error/classified, error/repair-proposed, error/repair-result; - loop/observe, loop/detected, loop/decision; - verify/before, verify/result; - ui/before-project, ui/after-project for presentation projection. Exact names may change to match repository conventions. ## Registry contract Each registration carries stable id, extension point, schema/version, priority/order, allowed scopes, failure policy, origin/config generation, and a trusted Prolog callable. The callable is intentionally executable inside the runtime. Catalog/model-facing inspection exposes sanitized identity/metadata but not the callable term itself. Trusted user `config.prolog` may register handlers. Trusted project `config.prolog` may register project-scoped handlers. Untrusted project/model data may not register executable hooks. Define deterministic ordering, duplicate handling, generation-based unload/reload, cancellation propagation, and whether each point is observe-only, transform/waterfall, veto, or serial/parallel notification. ## Runtime boundary A hook may compute and influence only the semantics explicitly owned by its extension point. Registering a hook does not make its result a capability grant or authority decision unless the owning canonical subsystem explicitly interprets it that way. Hooks must not silently swallow cancellation, durable-effect uncertainty, authority denial, or hard validation failures. Existing canonical modules remain the execution boundaries. ## Acceptance - [ ] Trusted XDG `config.prolog` can define a normal Prolog predicate and register it as a hook. - [ ] Trusted project config can register project-scoped hooks only after project trust. - [ ] Extension points are queryable without exposing executable callables to model-facing catalogs. - [ ] Untrusted project/model data cannot register executable hooks. - [ ] Deterministic ordering/priority and duplicate-id behavior are tested. - [ ] Config generation reload removes stale executable registrations cleanly. - [ ] Failure policy is explicit and structured per hook class. - [ ] Cancellation/authority/effect boundaries cannot be swallowed by a hook. - [ ] Existing chain middleware and other canonical seams are adapted/reused instead of duplicated. - [ ] Hooks cannot widen capabilities or authority merely by returning data. - [ ] Docs include real `config.prolog` hook examples, not merely declarative JSON examples.
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.

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.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/prolog-rlm#128
No description provided.