[P1] Add configurable error and agent-loop detector registry #130

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

Parent: #126
Depends on: #127 and #128. Integrates with existing recursion guards, traces, conversation/agent events, verification and repair APIs.

Goal

Create a detector registry where trusted config.prolog may define/register executable Prolog detectors for structured errors, repetition, agent loops, and lack of progress.

The runtime should not force every detector into a static built-in catalog. The user's XDG config is a programmable extension environment. Trusted project config may register project-scoped detectors only after project trust.

Detector contract

Each registration has stable id/schema/version, supported observation kinds, bounded state requirements, priority/scope, config-generation ownership, sanitized metadata, and a trusted Prolog predicate.

Detector inputs are structured runtime observations/events. Outputs are structured decisions such as clear, suspected, detected, or indeterminate, with reason/evidence/confidence and a bounded recommended response class.

A detector may compute arbitrary trusted Prolog logic, but it does not by itself bypass the runtime that owns cancellation, repair, authority, effects, capabilities, or verification.

Initial loop/non-progress coverage

  • duplicate recursive subproblem fingerprints, while preserving #42 as an open correctness defect;
  • repeated equivalent tool calls/arguments;
  • repeated model -> same tool -> same result cycles;
  • repeated failed repair attempts without a meaningful plan/spec change;
  • repeated materially equivalent assistant outputs;
  • turn/step trajectories with no measured progress for configured windows;
  • repeated provider/transient failures where further retry is low-value;
  • user/project-defined detector predicates over structured observations.

Error detection/classification

Support trusted classifiers for provider, parsing/structured-output, tool, authority, effect, verification, project/source, and agent-runtime failures. Preserve original structured errors and provenance; classification augments rather than replaces evidence.

Acceptance

  • XDG config.prolog can define and register a detector predicate.
  • Trusted project config can register project-scoped detectors only after project trust.
  • Untrusted project/model data cannot register executable detector code.
  • Detector catalog exposes sanitized metadata, not callable terms.
  • Config enables/disables/tunes registered detectors by id.
  • Tests cover repeated-tool and non-progress loops beyond recursion-only fingerprints.
  • False-positive controls/window/budget semantics are deterministic.
  • #42 remains tracked until its fingerprint bug is actually fixed.
  • Detector outputs are structured, traceable and provenance-carrying.
  • Detector recommendations cannot directly bypass authority/effects/capabilities.
  • Reload removes stale config-generation detectors deterministically.
Parent: #126 Depends on: #127 and #128. Integrates with existing recursion guards, traces, conversation/agent events, verification and repair APIs. ## Goal Create a detector registry where trusted `config.prolog` may define/register executable Prolog detectors for structured errors, repetition, agent loops, and lack of progress. The runtime should not force every detector into a static built-in catalog. The user's XDG config is a programmable extension environment. Trusted project config may register project-scoped detectors only after project trust. ## Detector contract Each registration has stable id/schema/version, supported observation kinds, bounded state requirements, priority/scope, config-generation ownership, sanitized metadata, and a trusted Prolog predicate. Detector inputs are structured runtime observations/events. Outputs are structured decisions such as `clear`, `suspected`, `detected`, or `indeterminate`, with reason/evidence/confidence and a bounded recommended response class. A detector may compute arbitrary trusted Prolog logic, but it does not by itself bypass the runtime that owns cancellation, repair, authority, effects, capabilities, or verification. ## Initial loop/non-progress coverage - duplicate recursive subproblem fingerprints, while preserving #42 as an open correctness defect; - repeated equivalent tool calls/arguments; - repeated model -> same tool -> same result cycles; - repeated failed repair attempts without a meaningful plan/spec change; - repeated materially equivalent assistant outputs; - turn/step trajectories with no measured progress for configured windows; - repeated provider/transient failures where further retry is low-value; - user/project-defined detector predicates over structured observations. ## Error detection/classification Support trusted classifiers for provider, parsing/structured-output, tool, authority, effect, verification, project/source, and agent-runtime failures. Preserve original structured errors and provenance; classification augments rather than replaces evidence. ## Acceptance - [ ] XDG `config.prolog` can define and register a detector predicate. - [ ] Trusted project config can register project-scoped detectors only after project trust. - [ ] Untrusted project/model data cannot register executable detector code. - [ ] Detector catalog exposes sanitized metadata, not callable terms. - [ ] Config enables/disables/tunes registered detectors by id. - [ ] Tests cover repeated-tool and non-progress loops beyond recursion-only fingerprints. - [ ] False-positive controls/window/budget semantics are deterministic. - [ ] #42 remains tracked until its fingerprint bug is actually fixed. - [ ] Detector outputs are structured, traceable and provenance-carrying. - [ ] Detector recommendations cannot directly bypass authority/effects/capabilities. - [ ] Reload removes stale config-generation detectors deterministically.
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#130
No description provided.