nsaspy/prolog-rlm

Fork 0

[EPIC] Wire prompt compiler tool projection into the real rlm_completion planner surface #176

New issue

Open

opened 2026-08-22 22:04:00 +00:00 by lost-rob0t · 15 comments

lost-rob0t commented

2026-08-22 22:04:00 +00:00

(Migrated from github.com)

Goal

Make rlm_prompt_compiler actually control the tool schemas the root LLM sees in the production rlm_completion path, while keeping the full trusted runtime bindings available for execution and authority checks.

This closes the current gap between:

prompt compiler says: selected model-visible tools

and:

rlm_completion currently says: tool_discover(Registry, AllSchemas)
                               -> planner_prompt(..., AllSchemas, ...)

The implementation must preserve the architectural rule:

model visibility != runtime registration != execution authorization

No new tool registry or model-facing interface should be created.

Research: current main behavior

1. `prolog/rlm_prompt_compiler.pl` is implemented

The compiler already provides:

prompt_catalog_create/1
prompt_catalog_register/3
prompt_catalog_register_tool_registry/4
prompt_compile/4
prompt_recompile/4
prompt_render/3
prompt_compiler_tool_schemas/2

It produces a structured compiled_context{...} containing selected/rejected units, context units, tool schemas, token ledger, active units, reasons and a fingerprint.

It performs bounded evidence-driven selection, dependency closure, capability/discovery filtering, conflicts/supersession, and shared context packing.

research/RLM-RESEARCH-010-symbolic-prompt-compiler.org and research/RLM-RESEARCH-011-managed-context-tool-discovery.org define this as the provider-visible projection boundary.

2. Current `rlm_completion` bypasses it

In prolog/rlm_completion.pl, completion_with_handle/... currently does:

runtime_tools(Options,
              Capabilities,
              RuntimeTools,
              ToolSchemas),
planner_prompt(Query,
               MetadataRef.metadata,
               Capabilities,
               ChildCapabilities,
               ToolSchemas,
               Options,
               Prompt),

and runtime_tools/4 currently resolves registry schemas with:

tool_registry_runtime_tools(Registry, Capabilities, RegistryTools),
tool_discover(Registry, Schemas)

Therefore every schema returned by the runtime registry is still handed directly to the root planner when a registry is supplied.

That means prompt-compiler contextual activation/deactivation does not yet govern the actual production planner tool view.

3. `planner_prompt/7` serializes those schemas directly

The current planner prompt contains:

Registered tool schemas: ~q

using the raw ToolSchemas returned by tool_discover/2.

So the actual LLM-facing tool projection today is still owned by rlm_completion, not by rlm_prompt_compiler.

4. Compiler tests are currently isolated

Repository search of prompt_compile/4 shows compiler implementation/research/tests and other schema work, but no production rlm_completion call site on current main.

The compiler test context_deactivation_does_not_unregister_runtime_tool correctly proves that a tool may disappear from compiled context without runtime unregistering, but the production completion path does not yet consume that compiled tool list.

5. Existing research already called for this integration

RLM-RESEARCH-011-managed-context-tool-discovery.org explicitly states the intended direction:

rlm_completion should stop giving every discovered registry schema to the planner by default. The runtime bindings used by plan_run remain the full trusted set, while the model receives only selected schemas. all_tools preserves the old projection for regression comparison.

This epic implements that already-researched contract rather than inventing a new architecture.

Design contract

Split the current ambiguous runtime_tools responsibility into two explicit concepts:

trusted executable bindings
        !=
provider-visible compiled projection

Conceptually:

Tool Registry
    |
    +--> full trusted RuntimeTools -----------------> plan execution
    |
    +--> declarative catalog metadata
             |
             v
      rlm_prompt_compiler
             |
             v
      VisibleToolSchemas + CompiledText
             |
             v
          root LLM

Selection does not unregister tools. Selection does not grant authority. A tool hidden from the planner may remain registered and executable by trusted host code; a tool visible to the planner still must pass normal capability/schema/preflight/authority/effect checks when invoked.

Completion API / options

Do not add a second completion API.

Use existing rlm_completion(..., Options, ...) configuration.

Add/normalize compiler-related host options conceptually as:

prompt_catalog(Catalog)
prompt_compile_options(CompilerOptions)
prompt_compile_mode(compiled|all_tools)

Exact option naming may follow current conventions, but ownership must remain host-side.

Default mode

Target default after migration:

prompt_compile_mode(compiled)

all_tools remains an explicit compatibility/debug/benchmark mode as already specified by RLM-RESEARCH-010/011.

If backwards-compatibility risk requires a staged rollout, implementation may temporarily require an explicit compiler option for one release/slice, but the issue must document that staging and include a test proving the intended eventual compiled default. Do not leave two indefinite ambiguous defaults.

Catalog ownership

Preferred behavior:

if host supplies prompt_catalog(Catalog), use it directly;
otherwise, when tool_registry(Registry) exists, build a bounded ephemeral catalog projection from that registry for the completion call using prompt_catalog_register_tool_registry/4;
destroy only an ephemeral compiler catalog created by the completion call;
never destroy a host-owned supplied catalog.

A long-lived host catalog remains preferable when Skills/instructions/MCP/resources need to coexist with tool metadata across turns.

Do not store executable handlers inside the prompt catalog.

Exact `rlm_completion` flow

Refactor completion_with_handle/... so the order becomes conceptually:

resolve provider
resolve capabilities
resolve full runtime tool bindings
resolve/build prompt catalog
compile provider-visible projection from current Query + trusted signals
render compiled projection
build planner prompt from:
    - user Query
    - context metadata
    - capabilities
    - child capabilities
    - compiler-rendered text
    - compiler-selected active tool schemas
call planner
execute validated plan against FULL trusted RuntimeTools

The important invariant is:

Planner sees compiled schemas.
Executor retains full trusted capable runtime bindings.

Do not replace RuntimeTools with only selected tools unless a separate authority design explicitly requires that later.

Exact implementation files

1. `prolog/rlm_completion.pl`

A. Imports

Import/use rlm_prompt_compiler through the module-qualified style consistent with current architecture.

B. Split `runtime_tools/4`

Current predicate:

runtime_tools(Options, Capabilities, Tools, Schemas)

currently conflates executable tools and model-visible schemas.

Refactor into explicit responsibilities, conceptually:

runtime_tool_bindings(+Options,
                      +Capabilities,
                      -RuntimeTools,
                      -Registry).

provider_tool_projection(+Query,
                         +Registry,
                         +Capabilities,
                         +Options,
                         -Projection).

or equivalent names following current conventions.

runtime_tool_bindings owns the full trusted execution list.

provider_tool_projection owns catalog creation/import/compile/render and returns at least:

provider_projection{
    text:CompiledText,
    tool_schemas:VisibleToolSchemas,
    active_units:ActiveUnits,
    fingerprint:Fingerprint,
    compiled:Compiled
}

Do not pass raw handlers/callables into the compiler projection.

C. Compile input

The minimum compile input is the current normalized user Query.

Preferred shape:

prompt_input{
    text:Query,
    signals:TrustedSignals,
    needs:Needs,
    selected:HostSelected,
    denied:HostDenied
}

For the first integration slice, TrustedSignals, Needs, HostSelected, and HostDenied may default empty unless already available in Options.

Expose host options for these only if they can be cleanly normalized through the existing compiler API. Do not parse arbitrary model output into trusted selected/denied fields.

D. Compiler mode

For compiled mode call prompt_compile/4 normally.

For all_tools, use the compiler's existing compatibility mode instead of bypassing the compiler and directly calling tool_discover/2 for planner exposure. This keeps one projection path and makes comparison deterministic.

E. Planner prompt

Change planner_prompt/... so it no longer labels raw registry results as:

Registered tool schemas

Use language that reflects actual model visibility, e.g.:

Active tool schemas

Add compiler-rendered text in one explicit section, e.g.:

Compiled runtime guidance:
<CompiledText>

Do not serialize the same full tool schema twice. If prompt_render/3 already includes full schema text in CompiledText, decide one canonical representation for the planner path:

provider/tool schema channel if supported by this planner abstraction; or
the explicit Active tool schemas field in the typed-planner prompt.

The token ledger must charge the actual representation used. Do not count one representation and render another.

F. Completion result observability

Add non-secret compiler metadata to the completion result/trajectory if a stable extension point exists:

prompt_projection:_{
    fingerprint:Fingerprint,
    active_units:ActiveUnits,
    tool_count:Count
}

Do not expose rejected hidden tool schemas or host-only catalog internals by default.

This makes it possible to prove which projection the planner actually received.

G. Cleanup

If completion creates an ephemeral prompt catalog, wrap it in setup_call_cleanup/3 and destroy it on success, failure, timeout, cancellation, or planner error.

Host-owned catalogs supplied through Options must never be destroyed by completion cleanup.

2. `prolog/rlm_prompt_compiler.pl`

A. Provider tool schemas must correspond to active packed units

Audit selected_tool_schemas/2, active_units_from_pack/2, and prompt_render/3 together.

Current tool_schemas are derived from pre-pack SelectedEntries, while active_units come from the context pack.

For mandatory imported tools these normally coincide, but a custom tool with mandatory_context:false could theoretically be selected then omitted by packing while remaining in Compiled.tool_schemas.

The provider-visible contract must be exact:

if a tool schema is sent to the model, its tool unit is active in the final packed projection

Implement one canonical helper, conceptually:

active_tool_schemas(+SelectedEntries,
                    +ActiveUnits,
                    -Schemas).

and ensure prompt_render/3 returns only schemas corresponding to active tool/mcp_tool units.

If pack(false) is used for inspection, preserve a clearly documented pre-pack state rather than pretending it is a provider-ready render.

B. #174 integration

Issue #174 adds declarative activation:always|relevant to the same prompt_unit interface.

This completion epic must consume whatever final compiler contract #174 lands. It must not add its own special always-visible list.

If #176 lands before #174, tests should use current relevance behavior and add the always-visible integration regression when #174 lands.

3. `test/rlm_completion_test.pl` or canonical completion test file

Add production-path tests proving the root planner sees compiled schemas rather than raw registry discovery.

If current completion tests use support planners that capture planner prompt text, extend those fixtures instead of building a separate test harness.

4. `test/rlm_prompt_compiler_test.pl`

Add/adjust active-schema packing regressions if tool_schemas derivation changes.

5. `docs/completion-runtime.md`

Replace the current statement that the root planner receives registered tool schemas with the precise contract:

The runtime keeps registered/authorized execution bindings separately. The root planner receives the current compiled provider-visible tool projection.

Document compiled vs all_tools mode and catalog ownership.

6. New stable runtime doc

Create:

docs/prompt-compiler.md

This was already identified as missing in #174.

Required sections:

Purpose
Unit algebra
Registration vs availability vs activation vs authorization
Compilation inputs
Relevant vs always activation (#174)
Dependency/conflict/supersession closure
Provider-visible packing
Tool schema projection
Completion integration
Catalog ownership/lifecycle
all_tools compatibility mode
Explainability and fingerprints
Security/authority boundary

The doc must explicitly show:

Registry handlers ---------> executor
Registry schemas -> catalog -> compiler -> LLM

7. Research/design source of truth

Update:

research/RLM-RESEARCH-011-managed-context-tool-discovery.org

Add an Implementation closure / completion integration section recording the exact landed path.

Do not create another competing architecture research note for this integration; RLM-RESEARCH-011 already researched and required it.

Required regression matrix

completion_planner_hides_irrelevant_registered_tool
- registry contains git_diff and project_search;
- query only matches git review;
- capture planner prompt/projection;
- assert git schema visible, project_search absent;
- assert both remain registered in runtime.
completion_executor_retains_hidden_runtime_binding
- after compilation hides an irrelevant tool from planner visibility, inspect trusted runtime-tool set/test support and prove compiler did not unregister/delete binding.
completion_all_tools_mode_preserves_compatibility_projection
- same registry/query;
- all_tools mode;
- assert both schemas visible.
completion_capability_denied_tool_not_visible
- registered tool without allowed capability;
- assert absent/rejected from model projection.
completion_compiler_projection_fingerprint_is_observable
- identical material input => identical fingerprint;
- changed query/tool activation => changed fingerprint.
completion_prompt_uses_active_not_registered_wording
- regression against accidentally restoring raw registry semantics.
completion_does_not_duplicate_full_schema_rendering
- inspect captured planner payload and token representation;
- each schema has one canonical provider-visible representation.
completion_ephemeral_catalog_is_cleaned_on_success
completion_ephemeral_catalog_is_cleaned_on_planner_failure
completion_ephemeral_catalog_is_cleaned_on_timeout_or_cancel
completion_host_owned_catalog_is_not_destroyed
completion_compiled_projection_can_include_instruction_or_skill_context

register one non-tool provider-visible unit matching query;
assert compiler-rendered guidance reaches planner.

completion_pack_budget_applies_to_tool_projection

use constrained policy;
prove mandatory active tool cannot silently disappear; structural budget failure when impossible.

provider_tool_schemas_are_subset_of_active_units

compiler-level invariant test.

optional_selected_but_packed_out_tool_schema_is_not_sent

if optional tool representations are supported;
selected before packing but omitted after packing;
assert absent from provider tool schemas.

always_visible_tool_reaches_completion_planner_on_unrelated_query

dependent on #174;
configure ordinary tool unit activation:always;
unrelated query;
assert tool appears in actual captured planner surface.

relevant_tool_still_deactivates_between_completion_turns

Turn A relevant -> visible;
Turn B unrelated -> hidden;
Turn C relevant -> visible again;
never re-register runtime handler.

hidden_tool_cannot_be_model_selected_by_test_planner_without_schema_visibility

test planner should only choose from supplied active schemas; ensure fixtures do not accidentally inject global registry knowledge.

Backwards compatibility

tool registry registration/execution APIs remain unchanged;
plan execution continues using trusted runtime bindings;
selection never grants authority;
host callers may use all_tools for old projection behavior;
compiler catalog may be host-owned or ephemeral;
direct tools(...) host bindings remain supported, but their model-visible schema story must be documented explicitly instead of silently bypassing compilation;
no arbitrary callable enters compiler IR.

Non-goals

no new tool registry;
no new planner/interpreter;
no physical tool unload on contextual deactivation;
no authorization based solely on compiler selection;
no model-supplied handler names;
no embedding-only router as authority;
no duplicated context-budget optimizer;
no hard-coded core-tool visibility list (use #174's ordinary prompt_unit activation field);
no provider-specific compiler fork.

Dependencies / ordering

Base compiler implementation is already on main.
#174 defines declarative persistent visibility and should be consumed by this path when available.
This epic is the production integration gate that makes compiler visibility decisions observable to the real root planner.

Acceptance gate

Complete only when:

production rlm_completion no longer gives raw tool_discover/2 output directly to the planner in normal compiled mode;
full trusted execution bindings remain separate and intact;
planner receives only final active compiler-selected schemas;
contextual deactivation is proven through the real completion path;
#174 always-visible behavior is proven through the real completion path when available;
token packing and emitted schema representation cannot drift;
catalog lifecycle is leak-free;
projection fingerprint/active-unit metadata is inspectable without exposing secrets/handlers;
all_tools remains an explicit compatibility mode through the same compiler path;
docs/prompt-compiler.md, docs/completion-runtime.md, and RLM-RESEARCH-011 reflect the landed contract;
focused compiler/completion tests and deterministic aggregate tests pass.

Implementation agents must re-read live main before editing, but they must preserve this separation of runtime execution bindings from provider-visible compiled tool schemas.

## Goal Make `rlm_prompt_compiler` actually control the **tool schemas the root LLM sees** in the production `rlm_completion` path, while keeping the full trusted runtime bindings available for execution and authority checks. This closes the current gap between: ```text prompt compiler says: selected model-visible tools ``` and: ```text rlm_completion currently says: tool_discover(Registry, AllSchemas) -> planner_prompt(..., AllSchemas, ...) ``` The implementation must preserve the architectural rule: ```text model visibility != runtime registration != execution authorization ``` No new tool registry or model-facing interface should be created. --- # Research: current main behavior ## 1. `prolog/rlm_prompt_compiler.pl` is implemented The compiler already provides: ```prolog prompt_catalog_create/1 prompt_catalog_register/3 prompt_catalog_register_tool_registry/4 prompt_compile/4 prompt_recompile/4 prompt_render/3 prompt_compiler_tool_schemas/2 ``` It produces a structured `compiled_context{...}` containing selected/rejected units, context units, tool schemas, token ledger, active units, reasons and a fingerprint. It performs bounded evidence-driven selection, dependency closure, capability/discovery filtering, conflicts/supersession, and shared context packing. `research/RLM-RESEARCH-010-symbolic-prompt-compiler.org` and `research/RLM-RESEARCH-011-managed-context-tool-discovery.org` define this as the provider-visible projection boundary. ## 2. Current `rlm_completion` bypasses it In `prolog/rlm_completion.pl`, `completion_with_handle/...` currently does: ```prolog runtime_tools(Options, Capabilities, RuntimeTools, ToolSchemas), planner_prompt(Query, MetadataRef.metadata, Capabilities, ChildCapabilities, ToolSchemas, Options, Prompt), ``` and `runtime_tools/4` currently resolves registry schemas with: ```prolog tool_registry_runtime_tools(Registry, Capabilities, RegistryTools), tool_discover(Registry, Schemas) ``` Therefore every schema returned by the runtime registry is still handed directly to the root planner when a registry is supplied. That means prompt-compiler contextual activation/deactivation does **not yet govern the actual production planner tool view**. ## 3. `planner_prompt/7` serializes those schemas directly The current planner prompt contains: ```text Registered tool schemas: ~q ``` using the raw `ToolSchemas` returned by `tool_discover/2`. So the actual LLM-facing tool projection today is still owned by `rlm_completion`, not by `rlm_prompt_compiler`. ## 4. Compiler tests are currently isolated Repository search of `prompt_compile/4` shows compiler implementation/research/tests and other schema work, but no production `rlm_completion` call site on current main. The compiler test `context_deactivation_does_not_unregister_runtime_tool` correctly proves that a tool may disappear from compiled context without runtime unregistering, but the production completion path does not yet consume that compiled tool list. ## 5. Existing research already called for this integration `RLM-RESEARCH-011-managed-context-tool-discovery.org` explicitly states the intended direction: ```text rlm_completion should stop giving every discovered registry schema to the planner by default. The runtime bindings used by plan_run remain the full trusted set, while the model receives only selected schemas. all_tools preserves the old projection for regression comparison. ``` This epic implements that already-researched contract rather than inventing a new architecture. --- # Design contract Split the current ambiguous `runtime_tools` responsibility into two explicit concepts: ```text trusted executable bindings != provider-visible compiled projection ``` Conceptually: ```text Tool Registry | +--> full trusted RuntimeTools -----------------> plan execution | +--> declarative catalog metadata | v rlm_prompt_compiler | v VisibleToolSchemas + CompiledText | v root LLM ``` Selection does not unregister tools. Selection does not grant authority. A tool hidden from the planner may remain registered and executable by trusted host code; a tool visible to the planner still must pass normal capability/schema/preflight/authority/effect checks when invoked. --- # Completion API / options Do not add a second completion API. Use existing `rlm_completion(..., Options, ...)` configuration. Add/normalize compiler-related host options conceptually as: ```prolog prompt_catalog(Catalog) prompt_compile_options(CompilerOptions) prompt_compile_mode(compiled|all_tools) ``` Exact option naming may follow current conventions, but ownership must remain host-side. ## Default mode Target default after migration: ```prolog prompt_compile_mode(compiled) ``` `all_tools` remains an explicit compatibility/debug/benchmark mode as already specified by RLM-RESEARCH-010/011. If backwards-compatibility risk requires a staged rollout, implementation may temporarily require an explicit compiler option for one release/slice, but the issue must document that staging and include a test proving the intended eventual `compiled` default. Do not leave two indefinite ambiguous defaults. ## Catalog ownership Preferred behavior: 1. if host supplies `prompt_catalog(Catalog)`, use it directly; 2. otherwise, when `tool_registry(Registry)` exists, build a bounded ephemeral catalog projection from that registry for the completion call using `prompt_catalog_register_tool_registry/4`; 3. destroy only an ephemeral compiler catalog created by the completion call; 4. never destroy a host-owned supplied catalog. A long-lived host catalog remains preferable when Skills/instructions/MCP/resources need to coexist with tool metadata across turns. Do not store executable handlers inside the prompt catalog. --- # Exact `rlm_completion` flow Refactor `completion_with_handle/...` so the order becomes conceptually: ```text resolve provider resolve capabilities resolve full runtime tool bindings resolve/build prompt catalog compile provider-visible projection from current Query + trusted signals render compiled projection build planner prompt from: - user Query - context metadata - capabilities - child capabilities - compiler-rendered text - compiler-selected active tool schemas call planner execute validated plan against FULL trusted RuntimeTools ``` The important invariant is: ```text Planner sees compiled schemas. Executor retains full trusted capable runtime bindings. ``` Do not replace `RuntimeTools` with only selected tools unless a separate authority design explicitly requires that later. --- # Exact implementation files ## 1. `prolog/rlm_completion.pl` ### A. Imports Import/use `rlm_prompt_compiler` through the module-qualified style consistent with current architecture. ### B. Split `runtime_tools/4` Current predicate: ```prolog runtime_tools(Options, Capabilities, Tools, Schemas) ``` currently conflates executable tools and model-visible schemas. Refactor into explicit responsibilities, conceptually: ```prolog runtime_tool_bindings(+Options, +Capabilities, -RuntimeTools, -Registry). provider_tool_projection(+Query, +Registry, +Capabilities, +Options, -Projection). ``` or equivalent names following current conventions. `runtime_tool_bindings` owns the full trusted execution list. `provider_tool_projection` owns catalog creation/import/compile/render and returns at least: ```prolog provider_projection{ text:CompiledText, tool_schemas:VisibleToolSchemas, active_units:ActiveUnits, fingerprint:Fingerprint, compiled:Compiled } ``` Do not pass raw handlers/callables into the compiler projection. ### C. Compile input The minimum compile input is the current normalized user `Query`. Preferred shape: ```prolog prompt_input{ text:Query, signals:TrustedSignals, needs:Needs, selected:HostSelected, denied:HostDenied } ``` For the first integration slice, `TrustedSignals`, `Needs`, `HostSelected`, and `HostDenied` may default empty unless already available in Options. Expose host options for these only if they can be cleanly normalized through the existing compiler API. Do not parse arbitrary model output into trusted `selected`/`denied` fields. ### D. Compiler mode For `compiled` mode call `prompt_compile/4` normally. For `all_tools`, use the compiler's existing compatibility mode instead of bypassing the compiler and directly calling `tool_discover/2` for planner exposure. This keeps one projection path and makes comparison deterministic. ### E. Planner prompt Change `planner_prompt/...` so it no longer labels raw registry results as: ```text Registered tool schemas ``` Use language that reflects actual model visibility, e.g.: ```text Active tool schemas ``` Add compiler-rendered text in one explicit section, e.g.: ```text Compiled runtime guidance: <CompiledText> ``` Do not serialize the same full tool schema twice. If `prompt_render/3` already includes full schema text in `CompiledText`, decide one canonical representation for the planner path: - provider/tool schema channel if supported by this planner abstraction; or - the explicit `Active tool schemas` field in the typed-planner prompt. The token ledger must charge the actual representation used. Do not count one representation and render another. ### F. Completion result observability Add non-secret compiler metadata to the completion result/trajectory if a stable extension point exists: ```prolog prompt_projection:_{ fingerprint:Fingerprint, active_units:ActiveUnits, tool_count:Count } ``` Do not expose rejected hidden tool schemas or host-only catalog internals by default. This makes it possible to prove which projection the planner actually received. ### G. Cleanup If completion creates an ephemeral prompt catalog, wrap it in `setup_call_cleanup/3` and destroy it on success, failure, timeout, cancellation, or planner error. Host-owned catalogs supplied through Options must never be destroyed by completion cleanup. ## 2. `prolog/rlm_prompt_compiler.pl` ### A. Provider tool schemas must correspond to active packed units Audit `selected_tool_schemas/2`, `active_units_from_pack/2`, and `prompt_render/3` together. Current `tool_schemas` are derived from pre-pack `SelectedEntries`, while `active_units` come from the context pack. For mandatory imported tools these normally coincide, but a custom tool with `mandatory_context:false` could theoretically be selected then omitted by packing while remaining in `Compiled.tool_schemas`. The provider-visible contract must be exact: ```text if a tool schema is sent to the model, its tool unit is active in the final packed projection ``` Implement one canonical helper, conceptually: ```prolog active_tool_schemas(+SelectedEntries, +ActiveUnits, -Schemas). ``` and ensure `prompt_render/3` returns only schemas corresponding to active tool/mcp_tool units. If `pack(false)` is used for inspection, preserve a clearly documented pre-pack state rather than pretending it is a provider-ready render. ### B. #174 integration Issue #174 adds declarative `activation:always|relevant` to the same `prompt_unit` interface. This completion epic must consume whatever final compiler contract #174 lands. It must not add its own special always-visible list. If #176 lands before #174, tests should use current relevance behavior and add the always-visible integration regression when #174 lands. ## 3. `test/rlm_completion_test.pl` or canonical completion test file Add production-path tests proving the root planner sees compiled schemas rather than raw registry discovery. If current completion tests use support planners that capture planner prompt text, extend those fixtures instead of building a separate test harness. ## 4. `test/rlm_prompt_compiler_test.pl` Add/adjust active-schema packing regressions if `tool_schemas` derivation changes. ## 5. `docs/completion-runtime.md` Replace the current statement that the root planner receives `registered tool schemas` with the precise contract: ```text The runtime keeps registered/authorized execution bindings separately. The root planner receives the current compiled provider-visible tool projection. ``` Document `compiled` vs `all_tools` mode and catalog ownership. ## 6. New stable runtime doc Create: ```text docs/prompt-compiler.md ``` This was already identified as missing in #174. Required sections: ```text Purpose Unit algebra Registration vs availability vs activation vs authorization Compilation inputs Relevant vs always activation (#174) Dependency/conflict/supersession closure Provider-visible packing Tool schema projection Completion integration Catalog ownership/lifecycle all_tools compatibility mode Explainability and fingerprints Security/authority boundary ``` The doc must explicitly show: ```text Registry handlers ---------> executor Registry schemas -> catalog -> compiler -> LLM ``` ## 7. Research/design source of truth Update: ```text research/RLM-RESEARCH-011-managed-context-tool-discovery.org ``` Add an `Implementation closure / completion integration` section recording the exact landed path. Do not create another competing architecture research note for this integration; RLM-RESEARCH-011 already researched and required it. --- # Required regression matrix 1. `completion_planner_hides_irrelevant_registered_tool` - registry contains `git_diff` and `project_search`; - query only matches git review; - capture planner prompt/projection; - assert git schema visible, project_search absent; - assert both remain registered in runtime. 2. `completion_executor_retains_hidden_runtime_binding` - after compilation hides an irrelevant tool from planner visibility, inspect trusted runtime-tool set/test support and prove compiler did not unregister/delete binding. 3. `completion_all_tools_mode_preserves_compatibility_projection` - same registry/query; - `all_tools` mode; - assert both schemas visible. 4. `completion_capability_denied_tool_not_visible` - registered tool without allowed capability; - assert absent/rejected from model projection. 5. `completion_compiler_projection_fingerprint_is_observable` - identical material input => identical fingerprint; - changed query/tool activation => changed fingerprint. 6. `completion_prompt_uses_active_not_registered_wording` - regression against accidentally restoring raw registry semantics. 7. `completion_does_not_duplicate_full_schema_rendering` - inspect captured planner payload and token representation; - each schema has one canonical provider-visible representation. 8. `completion_ephemeral_catalog_is_cleaned_on_success` 9. `completion_ephemeral_catalog_is_cleaned_on_planner_failure` 10. `completion_ephemeral_catalog_is_cleaned_on_timeout_or_cancel` 11. `completion_host_owned_catalog_is_not_destroyed` 12. `completion_compiled_projection_can_include_instruction_or_skill_context` - register one non-tool provider-visible unit matching query; - assert compiler-rendered guidance reaches planner. 13. `completion_pack_budget_applies_to_tool_projection` - use constrained policy; - prove mandatory active tool cannot silently disappear; structural budget failure when impossible. 14. `provider_tool_schemas_are_subset_of_active_units` - compiler-level invariant test. 15. `optional_selected_but_packed_out_tool_schema_is_not_sent` - if optional tool representations are supported; - selected before packing but omitted after packing; - assert absent from provider tool schemas. 16. `always_visible_tool_reaches_completion_planner_on_unrelated_query` - dependent on #174; - configure ordinary tool unit `activation:always`; - unrelated query; - assert tool appears in actual captured planner surface. 17. `relevant_tool_still_deactivates_between_completion_turns` - Turn A relevant -> visible; - Turn B unrelated -> hidden; - Turn C relevant -> visible again; - never re-register runtime handler. 18. `hidden_tool_cannot_be_model_selected_by_test_planner_without_schema_visibility` - test planner should only choose from supplied active schemas; ensure fixtures do not accidentally inject global registry knowledge. --- # Backwards compatibility - tool registry registration/execution APIs remain unchanged; - plan execution continues using trusted runtime bindings; - selection never grants authority; - host callers may use `all_tools` for old projection behavior; - compiler catalog may be host-owned or ephemeral; - direct `tools(...)` host bindings remain supported, but their model-visible schema story must be documented explicitly instead of silently bypassing compilation; - no arbitrary callable enters compiler IR. --- # Non-goals - no new tool registry; - no new planner/interpreter; - no physical tool unload on contextual deactivation; - no authorization based solely on compiler selection; - no model-supplied handler names; - no embedding-only router as authority; - no duplicated context-budget optimizer; - no hard-coded core-tool visibility list (use #174's ordinary `prompt_unit` activation field); - no provider-specific compiler fork. --- # Dependencies / ordering - Base compiler implementation is already on main. - #174 defines declarative persistent visibility and should be consumed by this path when available. - This epic is the production integration gate that makes compiler visibility decisions observable to the real root planner. # Acceptance gate Complete only when: - production `rlm_completion` no longer gives raw `tool_discover/2` output directly to the planner in normal compiled mode; - full trusted execution bindings remain separate and intact; - planner receives only final active compiler-selected schemas; - contextual deactivation is proven through the real completion path; - #174 always-visible behavior is proven through the real completion path when available; - token packing and emitted schema representation cannot drift; - catalog lifecycle is leak-free; - projection fingerprint/active-unit metadata is inspectable without exposing secrets/handlers; - `all_tools` remains an explicit compatibility mode through the same compiler path; - `docs/prompt-compiler.md`, `docs/completion-runtime.md`, and RLM-RESEARCH-011 reflect the landed contract; - focused compiler/completion tests and deterministic aggregate tests pass. Implementation agents must re-read live main before editing, but they must preserve this separation of **runtime execution bindings** from **provider-visible compiled tool schemas**.

lost-rob0t commented

2026-08-25 00:15:16 +00:00

(Migrated from github.com)

ADARD acceptance update: #183 extends the provider-surface gate beyond tool schemas. Completion integration must prove the exact provider-bound requests contain the active permanent RLM skills/instructions across root planner, recursive/subagent, RLM-internal model/leaf, and repair/retry calls. Internal compiler selected/active_units assertions alone are insufficient. Trusted opt-out must remove them; user/model prose must not. Behavioral live tests must not spoon-feed the exact plan JSON.

ADARD acceptance update: #183 extends the provider-surface gate beyond tool schemas. Completion integration must prove the **exact provider-bound requests** contain the active permanent RLM skills/instructions across root planner, recursive/subagent, RLM-internal model/leaf, and repair/retry calls. Internal compiler `selected`/`active_units` assertions alone are insufficient. Trusted opt-out must remove them; user/model prose must not. Behavioral live tests must not spoon-feed the exact plan JSON.

lost-rob0t commented

2026-08-25 13:15:14 +00:00

(Migrated from github.com)

RAGE live-state revalidation — 2026-08-25

Revalidated against canonical main 49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0 after the #172 merge and after the #117/#197 and #200 permanent-context work.

Analyze / deterministic defect evidence

The original #176 production gap still exists on this exact head. rlm_completion:completion_with_handle/... still calls:

runtime_tools(Options, Capabilities, RuntimeTools, ToolSchemas),
planner_prompt(..., ToolSchemas, ...)

while the issue's own audited runtime_tools/4 path obtains those planner-visible schemas directly from tool_discover/2. The default operating skills are now correctly compiled by rlm_prompt_compiler, and #200 propagates their already-compiled system context into internal model/retry execution through the trusted provider_context/2 wrapper, but tool-schema visibility is still a separate raw-registry projection.

So current production semantics are still:

prompt compiler owns skill/context selection
raw registry discovery owns root planner tool visibility

instead of the intended single symbolic projection authority.

This is falsifiable without intentionally red CI: the production regression must assert the exact planner/provider request contains only compiler-active tool schemas while the full capable runtime bindings remain available to plan_run; negative cases should assert the expected structured rejection/absence and keep the suite green.

Research reconciliation

#117/#197 already landed activation(always) plus default rlm-operate, rlm-recurse, rlm-facts, and rlm-constraints; do not recreate another skill selector.
#200 already landed exact permanent-context propagation for RLM-internal model/retry paths; do not wrap/recompile again in rlm_plan.
#172 is now on main and owns typed skill/role delegation policy; tool projection must not grant or widen child authority.
Active PR #212 owns #175 subagent deadline policy; do not touch that transaction.
Active PR #213 owns #211 tool-result projection presets; result retention/projection is orthogonal to schema visibility here.
Draft PR #132 owns trusted AgentProlog config; it may later point host policy at the compiler but must not become a second selector.
Downstream a0-symbolics PR #51 owns Agent Zero runtime-mode composition and agentProlog PR #8 owns the DeepSeek Harness AgentFactory. Neither owns this generic provider-visible tool projection contract.

Design / adversarial review

The existing #176 design still survives current-main review. Keep two explicit products from the same trusted registry:

full capable executable bindings -> executor/authority/effect path;
declarative schema units -> rlm_prompt_compiler -> provider-visible projection.

Adversarial constraints:

hiding a schema must never unregister a tool or change trusted executable bindings;
showing a schema must never grant capability, authority, handler possession, or effect permission;
model/user prose cannot set trusted selected/denied/always activation controls;
no callable/handler term enters prompt compiler data;
all_tools compatibility must still flow through one compiler projection path rather than bypassing it;
exact provider-bound requests, not only Compiled.active_units, are the acceptance evidence;
trusted opt-out must remove compiler-owned visibility/context without mutating runtime registration;
token accounting must match what is actually rendered/sent.

Decision

GO within the already-recorded #176/#183 architecture. The smallest safe realization slice is production-path root-planner tool-schema projection: retain RuntimeTools untouched for execution, import sanitized registry schemas into an ephemeral/host-owned prompt catalog, compile the current query under host policy, and feed only the resulting active schemas to the root planner. Preserve the existing permanent-skill context path and avoid broadening into #175/#211/downstream product code.

No implementation commit is claimed by this comment; exact-head CI/live/Nix evidence remains mandatory for any realization branch.

## RAGE live-state revalidation — 2026-08-25 Revalidated against canonical `main` `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0` after the #172 merge and after the #117/#197 and #200 permanent-context work. ### Analyze / deterministic defect evidence The original #176 production gap still exists on this exact head. `rlm_completion:completion_with_handle/...` still calls: ```prolog runtime_tools(Options, Capabilities, RuntimeTools, ToolSchemas), planner_prompt(..., ToolSchemas, ...) ``` while the issue's own audited `runtime_tools/4` path obtains those planner-visible schemas directly from `tool_discover/2`. The default operating skills are now correctly compiled by `rlm_prompt_compiler`, and #200 propagates their already-compiled system context into internal model/retry execution through the trusted `provider_context/2` wrapper, but **tool-schema visibility is still a separate raw-registry projection**. So current production semantics are still: ```text prompt compiler owns skill/context selection raw registry discovery owns root planner tool visibility ``` instead of the intended single symbolic projection authority. This is falsifiable without intentionally red CI: the production regression must assert the exact planner/provider request contains only compiler-active tool schemas while the full capable runtime bindings remain available to `plan_run`; negative cases should assert the expected structured rejection/absence and keep the suite green. ### Research reconciliation - #117/#197 already landed `activation(always)` plus default `rlm-operate`, `rlm-recurse`, `rlm-facts`, and `rlm-constraints`; do not recreate another skill selector. - #200 already landed exact permanent-context propagation for RLM-internal model/retry paths; do not wrap/recompile again in `rlm_plan`. - #172 is now on `main` and owns typed skill/role delegation policy; tool projection must not grant or widen child authority. - Active PR #212 owns #175 subagent deadline policy; do not touch that transaction. - Active PR #213 owns #211 tool-result projection presets; result retention/projection is orthogonal to schema visibility here. - Draft PR #132 owns trusted AgentProlog config; it may later point host policy at the compiler but must not become a second selector. - Downstream `a0-symbolics` PR #51 owns Agent Zero runtime-mode composition and `agentProlog` PR #8 owns the DeepSeek Harness AgentFactory. Neither owns this generic provider-visible tool projection contract. ### Design / adversarial review The existing #176 design still survives current-main review. Keep two explicit products from the same trusted registry: 1. **full capable executable bindings** -> executor/authority/effect path; 2. **declarative schema units** -> `rlm_prompt_compiler` -> provider-visible projection. Adversarial constraints: - hiding a schema must never unregister a tool or change trusted executable bindings; - showing a schema must never grant capability, authority, handler possession, or effect permission; - model/user prose cannot set trusted `selected`/`denied`/always activation controls; - no callable/handler term enters prompt compiler data; - `all_tools` compatibility must still flow through one compiler projection path rather than bypassing it; - exact provider-bound requests, not only `Compiled.active_units`, are the acceptance evidence; - trusted opt-out must remove compiler-owned visibility/context without mutating runtime registration; - token accounting must match what is actually rendered/sent. ### Decision **GO within the already-recorded #176/#183 architecture.** The smallest safe realization slice is production-path root-planner tool-schema projection: retain `RuntimeTools` untouched for execution, import sanitized registry schemas into an ephemeral/host-owned prompt catalog, compile the current query under host policy, and feed only the resulting active schemas to the root planner. Preserve the existing permanent-skill context path and avoid broadening into #175/#211/downstream product code. No implementation commit is claimed by this comment; exact-head CI/live/Nix evidence remains mandatory for any realization branch.

lost-rob0t commented

2026-08-25 14:12:45 +00:00

(Migrated from github.com)

Realization ownership is now live on rage/176-root-planner-tool-projection, cut from exact canonical main 49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0 after the current open-issue/open-PR/review/downstream audit.

Scope remains the GO slice already recorded above: root-planner provider-visible tool schemas must come from rlm_prompt_compiler, while the full capability-filtered executable RuntimeTools remain unchanged for plan_run/authority/effects. No #175 deadline work, #211 result-projection work, or downstream Agent Zero/AgentProlog product logic is included.

TDD convention for this realization: the final branch must keep required CI green. Negative visibility/rejection contracts assert the expected structured absence/failure; no xfail/skip/intentional-red CI convention. Exact provider-bound request evidence plus full execution-binding preservation is required before a PR/merge claim.

Realization ownership is now live on `rage/176-root-planner-tool-projection`, cut from exact canonical `main` `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0` after the current open-issue/open-PR/review/downstream audit. Scope remains the GO slice already recorded above: root-planner provider-visible tool schemas must come from `rlm_prompt_compiler`, while the full capability-filtered executable `RuntimeTools` remain unchanged for `plan_run`/authority/effects. No #175 deadline work, #211 result-projection work, or downstream Agent Zero/AgentProlog product logic is included. TDD convention for this realization: the final branch must keep required CI green. Negative visibility/rejection contracts assert the expected structured absence/failure; no xfail/skip/intentional-red CI convention. Exact provider-bound request evidence plus full execution-binding preservation is required before a PR/merge claim.

lost-rob0t commented

2026-08-25 15:10:19 +00:00

(Migrated from github.com)

RAGE scope correction — exact main `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0`

Fresh source audit narrows the remaining #176 defect.

rlm_prompt_compiler already enforces the compiler-level provider invariant after packing: maybe_pack_projection/3 derives ActiveUnits from the final context pack and then calls active_tool_schemas/3, so Compiled.tool_schemas is filtered to tool/mcp_tool units that survived into active_units. The older checklist item asking #176 to invent that helper is therefore already satisfied on current main and should not be reimplemented.

The production defect remains in rlm_completion: runtime_tools/4 still does tool_discover/2 + capability filtering and passes that raw list to planner_prompt/7 as Registered tool schemas. Thus the compiler has the correct final schema projection, but the real root planner never consumes it.

TDD contract for realization

Keep required CI green while asserting the behavioral contract:

registry has two capability-allowed tools with distinct relevance;
exact captured planner request contains only the compiler-active relevant schema in default compiled mode;
both trusted runtime bindings remain registered/available to execution;
all_tools compatibility uses compiler mode rather than a raw-discovery bypass and exposes both;
capability-denied schema remains absent;
planner wording says Active tool schemas, not Registered tool schemas.

Negative cases assert expected absence/rejection; no intentional red/xfail/skip CI convention.

Coordination audit

Open core transactions remain non-conflicting: #212 owns #175 deadline policy and its exact head 0109d25e2b22190d6d3339528f76c04748462c45 currently has CI failing while Nix/Tree-sitter/Clean-pack/Paid OpenRouter are green; #213 owns #211 result projection and exact head fced85495700a0746ce49d7f697db3aab39f408d likewise has CI failing while those other lanes are green. #132 remains draft/non-mergeable with no workflow runs on its current head. None has review submissions or unresolved review threads. Downstream A0 #51 and AgentProlog #8 still own product composition, not this generic compiler/provider projection.

Decision remains GO, but realization should now be smaller: wire current compiler output into the root planner; do not touch rlm_prompt_compiler packing logic unless new evidence breaks that already-landed invariant.

## RAGE scope correction — exact main `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0` Fresh source audit narrows the remaining #176 defect. `rlm_prompt_compiler` already enforces the compiler-level provider invariant after packing: `maybe_pack_projection/3` derives `ActiveUnits` from the final context pack and then calls `active_tool_schemas/3`, so `Compiled.tool_schemas` is filtered to tool/mcp_tool units that survived into `active_units`. The older checklist item asking #176 to invent that helper is therefore already satisfied on current `main` and should not be reimplemented. The production defect remains in `rlm_completion`: `runtime_tools/4` still does `tool_discover/2` + capability filtering and passes that raw list to `planner_prompt/7` as `Registered tool schemas`. Thus the compiler has the correct final schema projection, but the real root planner never consumes it. ### TDD contract for realization Keep required CI green while asserting the behavioral contract: - registry has two capability-allowed tools with distinct relevance; - exact captured planner request contains only the compiler-active relevant schema in default `compiled` mode; - both trusted runtime bindings remain registered/available to execution; - `all_tools` compatibility uses compiler mode rather than a raw-discovery bypass and exposes both; - capability-denied schema remains absent; - planner wording says `Active tool schemas`, not `Registered tool schemas`. Negative cases assert expected absence/rejection; no intentional red/xfail/skip CI convention. ### Coordination audit Open core transactions remain non-conflicting: #212 owns #175 deadline policy and its exact head `0109d25e2b22190d6d3339528f76c04748462c45` currently has CI failing while Nix/Tree-sitter/Clean-pack/Paid OpenRouter are green; #213 owns #211 result projection and exact head `fced85495700a0746ce49d7f697db3aab39f408d` likewise has CI failing while those other lanes are green. #132 remains draft/non-mergeable with no workflow runs on its current head. None has review submissions or unresolved review threads. Downstream A0 #51 and AgentProlog #8 still own product composition, not this generic compiler/provider projection. Decision remains **GO**, but realization should now be smaller: wire current compiler output into the root planner; do not touch `rlm_prompt_compiler` packing logic unless new evidence breaks that already-landed invariant.

lost-rob0t commented

2026-08-25 17:16:51 +00:00

(Migrated from github.com)

RAGE/TDD evidence update for #176 on exact branch head c736625960a58e97f307b9f5ded3e3aa97face84 (PR #216), based on canonical main 49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0.

The production-path regression is now captured without intentionally red CI. The tool-visibility fixture registers two capability-allowed tools, invokes the real rlm_completion root-planner path, and classifies the current raw-registry projection as structured raw_registry_visibility; the test asserts that expected failure contract. This isolates contextual prompt-compiler bypass from capability filtering.

The first test commit exposed a test-only SWI binding mistake: assertion(ProjectionOutcome = error(ProjectionError)) did not preserve the binding used by the next assertion. That exact-head deterministic CI failure was treated as a blocker, not desired TDD evidence. Commit c736625960a58e97f307b9f5ded3e3aa97face84 fixes the test by binding the structured failure outside assertion/1.

Exact-head verification for c736625960a58e97f307b9f5ded3e3aa97face84 is fully green:

CI / deterministic unit+load checks: success, including PlUnit, benchmark/conformance, deep recursion, CLI/trace, restart fixtures, and whitespace gate;
CI / REAL OpenRouter integration: success, including core, structured repair, benchmark, depth 0/1/2 recursion, and CLI smoke;
standalone Paid OpenRouter: success;
Nix flake: success;
Clean SWI pack install: success;
Tree-sitter FFI: success.

Decision remains GO for the previously recorded narrow realization: replace only the root planner's raw tool_discover/2 schema projection with the existing prompt compiler's active schema projection, while retaining the full trusted RuntimeTools set for execution/authority/effects. Do not duplicate the already-landed post-pack active_tool_schemas logic, and do not absorb #175/#211 or downstream product composition.

RAGE/TDD evidence update for #176 on exact branch head `c736625960a58e97f307b9f5ded3e3aa97face84` (PR #216), based on canonical `main` `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0`. The production-path regression is now captured without intentionally red CI. The tool-visibility fixture registers two capability-allowed tools, invokes the real `rlm_completion` root-planner path, and classifies the current raw-registry projection as structured `raw_registry_visibility`; the test asserts that expected failure contract. This isolates contextual prompt-compiler bypass from capability filtering. The first test commit exposed a test-only SWI binding mistake: `assertion(ProjectionOutcome = error(ProjectionError))` did not preserve the binding used by the next assertion. That exact-head deterministic CI failure was treated as a blocker, not desired TDD evidence. Commit `c736625960a58e97f307b9f5ded3e3aa97face84` fixes the test by binding the structured failure outside `assertion/1`. Exact-head verification for `c736625960a58e97f307b9f5ded3e3aa97face84` is fully green: - CI / deterministic unit+load checks: success, including PlUnit, benchmark/conformance, deep recursion, CLI/trace, restart fixtures, and whitespace gate; - CI / REAL OpenRouter integration: success, including core, structured repair, benchmark, depth 0/1/2 recursion, and CLI smoke; - standalone Paid OpenRouter: success; - Nix flake: success; - Clean SWI pack install: success; - Tree-sitter FFI: success. Decision remains GO for the previously recorded narrow realization: replace only the root planner's raw `tool_discover/2` schema projection with the existing prompt compiler's active schema projection, while retaining the full trusted `RuntimeTools` set for execution/authority/effects. Do not duplicate the already-landed post-pack `active_tool_schemas` logic, and do not absorb #175/#211 or downstream product composition.

lost-rob0t commented

2026-08-25 19:12:13 +00:00

(Migrated from github.com)

RAGE adversarial refinement — production test boundaries

Revalidated against current main 49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0, PR #216, and the current compiler implementation.

One important test/design correction before realization: once compiled becomes the completion default, the existing capability-only regression must opt into prompt_compile_mode(all_tools). Otherwise a missing schema could be caused by contextual activation rather than capability denial, and the test would stop proving the authority/visibility boundary it is named for.

The realization matrix for the first slice should therefore keep these concerns independent:

default compiled: query-relevant capability-allowed schema visible; unrelated capability-allowed schema absent;
explicit all_tools: all capability-allowed schemas visible through the compiler compatibility mode, never by raw tool_discover/2 bypass;
capability-denied schema remains absent even in all_tools mode;
invalid prompt_compile_mode fails explicitly before planner invocation;
full trusted RuntimeTools remain unchanged for execution/authority checks regardless of provider visibility.

Current rlm_prompt_compiler already performs the needed final post-pack active_tool_schemas filtering and already owns compiled|all_tools; no second selector is justified. Tool-registry imports are declarative metadata only and do not contain executable handlers, so the smallest safe implementation remains wiring the root planner to that existing compiler projection while retaining the executor binding path.

Adversarial decision remains GO for that narrow slice. Negative/rejection cases should assert their expected structured outcome while required CI remains green.

### RAGE adversarial refinement — production test boundaries Revalidated against current `main` `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0`, PR #216, and the current compiler implementation. One important test/design correction before realization: once `compiled` becomes the completion default, the existing capability-only regression must opt into `prompt_compile_mode(all_tools)`. Otherwise a missing schema could be caused by contextual activation rather than capability denial, and the test would stop proving the authority/visibility boundary it is named for. The realization matrix for the first slice should therefore keep these concerns independent: - default `compiled`: query-relevant capability-allowed schema visible; unrelated capability-allowed schema absent; - explicit `all_tools`: all capability-allowed schemas visible **through the compiler compatibility mode**, never by raw `tool_discover/2` bypass; - capability-denied schema remains absent even in `all_tools` mode; - invalid `prompt_compile_mode` fails explicitly before planner invocation; - full trusted `RuntimeTools` remain unchanged for execution/authority checks regardless of provider visibility. Current `rlm_prompt_compiler` already performs the needed final post-pack `active_tool_schemas` filtering and already owns `compiled|all_tools`; no second selector is justified. Tool-registry imports are declarative metadata only and do not contain executable handlers, so the smallest safe implementation remains wiring the root planner to that existing compiler projection while retaining the executor binding path. Adversarial decision remains **GO** for that narrow slice. Negative/rejection cases should assert their expected structured outcome while required CI remains green.

lost-rob0t commented

2026-08-25 20:13:22 +00:00

(Migrated from github.com)

TDD refinement + exact-head verification

Advanced the owned #176 realization branch to exact head 2f2df1f7f3ef8982b8e383dfdec91fa87cbab6ab without making required CI red.

The production-path contract now separates two independent semantics explicitly:

capability denial runs with prompt_compile_mode(all_tools), so a denied tool cannot disappear merely because contextual compiler selection hid it;
the contextual raw-registry regression runs with prompt_compile_mode(compiled), so its expected structured raw_registry_visibility evidence specifically targets the compiler-controlled mode.

This is still a test-first/falsifiable contract, not a production-fix claim. Current rlm_completion:runtime_tools/4 still capability-filters tool_discover/2 output and passes those schemas directly to planner_prompt/7; the production realization remains to split trusted runtime bindings from the compiler-owned provider-visible projection.

Exact-head verification for 2f2df1f7f3ef8982b8e383dfdec91fa87cbab6ab is green:

deterministic PlUnit + aggregate runner hardening;
deterministic benchmark/conformance + deep recursion;
CLI/trace and fresh-process graph/artifact restart checks;
REAL OpenRouter core, structured repair, benchmark, depth 0/1/2 and CLI smoke;
pinned paid OpenRouter lane;
Nix flake;
clean SWI pack install;
Tree-sitter FFI.

The realization design remains unchanged: RuntimeTools stay complete for plan_run/authority/effects; registry schemas flow through the existing rlm_prompt_compiler catalog/import/compiled|all_tools path before reaching the planner. PR #216 remains draft until that production path lands and a new exact head is fully reverified.

## TDD refinement + exact-head verification Advanced the owned #176 realization branch to exact head `2f2df1f7f3ef8982b8e383dfdec91fa87cbab6ab` without making required CI red. The production-path contract now separates two independent semantics explicitly: - capability denial runs with `prompt_compile_mode(all_tools)`, so a denied tool cannot disappear merely because contextual compiler selection hid it; - the contextual raw-registry regression runs with `prompt_compile_mode(compiled)`, so its expected structured `raw_registry_visibility` evidence specifically targets the compiler-controlled mode. This is still a test-first/falsifiable contract, not a production-fix claim. Current `rlm_completion:runtime_tools/4` still capability-filters `tool_discover/2` output and passes those schemas directly to `planner_prompt/7`; the production realization remains to split trusted runtime bindings from the compiler-owned provider-visible projection. Exact-head verification for `2f2df1f7f3ef8982b8e383dfdec91fa87cbab6ab` is green: - deterministic PlUnit + aggregate runner hardening; - deterministic benchmark/conformance + deep recursion; - CLI/trace and fresh-process graph/artifact restart checks; - REAL OpenRouter core, structured repair, benchmark, depth 0/1/2 and CLI smoke; - pinned paid OpenRouter lane; - Nix flake; - clean SWI pack install; - Tree-sitter FFI. The realization design remains unchanged: `RuntimeTools` stay complete for `plan_run`/authority/effects; registry schemas flow through the existing `rlm_prompt_compiler` catalog/import/`compiled|all_tools` path before reaching the planner. PR #216 remains draft until that production path lands and a new exact head is fully reverified.

lost-rob0t commented

2026-08-25 21:10:30 +00:00

(Migrated from github.com)

TDD contract refinement — exact head `b19e5c795eea4f2c3abd7cf70957f12da8c056a5`

Live-state revalidation still supports the recorded GO decision. The compiler already owns sanitized registry import, capability eligibility, compiled|all_tools, token-budget packing, and post-pack active_tool_schemas; realization should reuse those contracts rather than add another selector.

I added one more green falsifiable contract before production glue: prompt_compile_mode/1 is a trusted completion option, but current rlm_completion ignores it. The new regression passes prompt_compile_mode(garbage_mode) and asserts the current structured contract failure invalid_prompt_compile_mode_ignored while required CI stays green. Realization must instead fail closed with explicit invalid_prompt_compile_mode before planner dispatch.

Exact-head b19e5c7… is mergeable as a draft TDD transaction and the current 12 check runs contain no failures; deterministic unit/load, copied-pack install, Tree-sitter, and pinned paid OpenRouter are successful. This is still TDD evidence only: production rlm_completion has not been changed, so no realization/merge claim is being made.

The production boundary remains: full capability-filtered RuntimeTools stay unchanged for plan_run/authority/effects; only sanitized registry schemas flow through an ephemeral prompt catalog, current-query compilation, trusted compiled|all_tools mode, and the compiler's active-schema projection into the root planner request. #212/#175, #213/#211, a0-symbolics #51, and agentProlog #8 remain separate owned transactions.

## TDD contract refinement — exact head `b19e5c795eea4f2c3abd7cf70957f12da8c056a5` Live-state revalidation still supports the recorded GO decision. The compiler already owns sanitized registry import, capability eligibility, `compiled|all_tools`, token-budget packing, and post-pack `active_tool_schemas`; realization should reuse those contracts rather than add another selector. I added one more green falsifiable contract before production glue: `prompt_compile_mode/1` is a trusted completion option, but current `rlm_completion` ignores it. The new regression passes `prompt_compile_mode(garbage_mode)` and asserts the current structured contract failure `invalid_prompt_compile_mode_ignored` while required CI stays green. Realization must instead fail closed with explicit `invalid_prompt_compile_mode` before planner dispatch. Exact-head `b19e5c7…` is mergeable as a draft TDD transaction and the current 12 check runs contain no failures; deterministic unit/load, copied-pack install, Tree-sitter, and pinned paid OpenRouter are successful. This is still **TDD evidence only**: production `rlm_completion` has not been changed, so no realization/merge claim is being made. The production boundary remains: full capability-filtered `RuntimeTools` stay unchanged for `plan_run`/authority/effects; only sanitized registry schemas flow through an ephemeral prompt catalog, current-query compilation, trusted `compiled|all_tools` mode, and the compiler's active-schema projection into the root planner request. #212/#175, #213/#211, a0-symbolics #51, and agentProlog #8 remain separate owned transactions.

lost-rob0t commented

2026-08-25 22:06:00 +00:00

(Migrated from github.com)

RAGE realization boundary refinement — exact main `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0`, PR #216 head `b19e5c795eea4f2c3abd7cf70957f12da8c056a5`

Source-level finding

The production seam is narrower than the earlier issue prose implied:

completion_with_handle/6 already keeps full capability-filtered RuntimeTools separate and later passes them unchanged to plan_run/5 through tools(RuntimeTools).
Only planner-visible schemas are wrong: runtime_tools/4 still calls tool_discover/2 and capability-filters that raw registry list before embedding it in planner_prompt/7.
rlm_prompt_compiler already supplies the required projection machinery: prompt_catalog_register_tool_registry/4, compiled|all_tools candidate semantics, post-pack active_tool_schemas/3, and prompt_compiler_tool_schemas/2.

Therefore realization should not modify tool registration, executable bindings, authority, effects, or the existing permanent-skill/provider-context path.

Trusted mode validation correction

One adversarial detail matters for the new host option contract. The compiler's internal compile_mode/2 treats mode(all_tools)/all_tools(true) specially and otherwise defaults to compiled; it is intentionally not a validator for a higher-level prompt_compile_mode/1 option. So rlm_completion must validate its trusted option explicitly:

prompt_compile_mode(compiled)  -> compiler default/compiled projection
prompt_compile_mode(all_tools) -> compiler mode(all_tools)
anything else                  -> explicit structured invalid_prompt_compile_mode before planner dispatch

Do not pass arbitrary mode data through and let it silently collapse to compiled.

Smallest realization

Keep runtime_tools responsible for executable bindings and registry acquisition only.
For a registry, create an ephemeral prompt catalog, import sanitized declarative schemas with prompt_catalog_register_tool_registry/4, compile the current query under the normalized root capabilities and trusted compile mode, and extract prompt_compiler_tool_schemas/2.
Embed only that compiler projection in the root planner prompt.
Keep direct trusted tools(...) bindings executable-only unless/until they have an explicit declarative schema source; do not synthesize prompt authority from handlers.
Preserve the existing capability-denial regression under all_tools so compiler relevance cannot mask capability enforcement.
Flip the #216 defect contract from “expected raw_registry_visibility detected” to asserting the intended projection after production wiring lands; negative mode/rejection cases remain expected structured failures with green CI.

Adversarial decision

GO remains valid. This design preserves the key invariant: visibility is compiler-owned context projection; execution remains runtime/authority-owned possession. No second selector, no handler/callable enters compiler data, and no downstream Agent Zero/AgentProlog product logic moves into core.

Local checkout execution is unavailable in this worker environment because the runtime cannot currently resolve github.com; GitHub connector reads/writes and exact-head Actions remain available. I am not claiming a production commit or new verification head from this note.

## RAGE realization boundary refinement — exact main `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0`, PR #216 head `b19e5c795eea4f2c3abd7cf70957f12da8c056a5` ### Source-level finding The production seam is narrower than the earlier issue prose implied: - `completion_with_handle/6` already keeps full capability-filtered `RuntimeTools` separate and later passes them unchanged to `plan_run/5` through `tools(RuntimeTools)`. - Only planner-visible schemas are wrong: `runtime_tools/4` still calls `tool_discover/2` and capability-filters that raw registry list before embedding it in `planner_prompt/7`. - `rlm_prompt_compiler` already supplies the required projection machinery: `prompt_catalog_register_tool_registry/4`, `compiled|all_tools` candidate semantics, post-pack `active_tool_schemas/3`, and `prompt_compiler_tool_schemas/2`. Therefore realization should not modify tool registration, executable bindings, authority, effects, or the existing permanent-skill/provider-context path. ### Trusted mode validation correction One adversarial detail matters for the new host option contract. The compiler's internal `compile_mode/2` treats `mode(all_tools)`/`all_tools(true)` specially and otherwise defaults to `compiled`; it is intentionally not a validator for a higher-level `prompt_compile_mode/1` option. So `rlm_completion` must validate its trusted option explicitly: ```text prompt_compile_mode(compiled) -> compiler default/compiled projection prompt_compile_mode(all_tools) -> compiler mode(all_tools) anything else -> explicit structured invalid_prompt_compile_mode before planner dispatch ``` Do not pass arbitrary mode data through and let it silently collapse to `compiled`. ### Smallest realization 1. Keep `runtime_tools` responsible for executable bindings and registry acquisition only. 2. For a registry, create an ephemeral prompt catalog, import sanitized declarative schemas with `prompt_catalog_register_tool_registry/4`, compile the current query under the normalized root capabilities and trusted compile mode, and extract `prompt_compiler_tool_schemas/2`. 3. Embed only that compiler projection in the root planner prompt. 4. Keep direct trusted `tools(...)` bindings executable-only unless/until they have an explicit declarative schema source; do not synthesize prompt authority from handlers. 5. Preserve the existing capability-denial regression under `all_tools` so compiler relevance cannot mask capability enforcement. 6. Flip the #216 defect contract from “expected raw_registry_visibility detected” to asserting the intended projection after production wiring lands; negative mode/rejection cases remain expected structured failures with green CI. ### Adversarial decision **GO remains valid.** This design preserves the key invariant: visibility is compiler-owned context projection; execution remains runtime/authority-owned possession. No second selector, no handler/callable enters compiler data, and no downstream Agent Zero/AgentProlog product logic moves into core. Local checkout execution is unavailable in this worker environment because the runtime cannot currently resolve `github.com`; GitHub connector reads/writes and exact-head Actions remain available. I am not claiming a production commit or new verification head from this note.

lost-rob0t commented

2026-08-25 23:11:14 +00:00

(Migrated from github.com)

RAGE live-state refinement against canonical main 49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0 and owned PR #216 head b19e5c795eea4f2c3abd7cf70957f12da8c056a5.

Analyze / executable evidence

The production defect is still exactly at the completion boundary:

runtime_tools/4
  -> tool_registry_runtime_tools(...)     % trusted executable bindings
  -> tool_discover(...)
  -> capability-filter raw schemas
  -> planner_prompt(...)

planner_prompt still labels that projection Registered tool schemas, so normal root completion still bypasses compiler contextual selection.

The compiler side is already farther along than the original issue checklist: rlm_prompt_compiler:maybe_pack_projection/3 already computes active_units from the final context pack and filters tool_schemas through active_tool_schemas/3. Do not reimplement this in the realization.

A second live mismatch is now pinned precisely: rlm_prompt_compiler:compile_mode/2 intentionally treats only mode(all_tools)/all_tools(true) specially and otherwise defaults to compiled. Therefore the trusted completion option prompt_compile_mode/1 must be validated at the completion boundary; passing an unknown value into the compiler cannot supply fail-closed semantics by itself.

Current completion_exception/2 maps generic completion_fault(Fault) to kind:completion_fault. The #216 TDD contract requires invalid trusted mode to be an explicit structured kind:invalid_prompt_compile_mode, so realization also needs a narrow exception mapping before the generic completion-fault clause rather than weakening the test.

Research / ownership

Downstream evidence remains clean: a0-symbolics PR #51 owns Agent Zero native/RLM product composition and explicitly leaves symbolic selection/budgeting/planning/authority/effects to Prolog-RLM; agentProlog PR #8 owns the DeepSeek Harness AgentFactory/sidecar product integration and calls canonical Prolog runtime APIs. Neither owns this provider-projection defect.

Recent merge #209 explicitly advances #172 without closing it; no #172 follow-up belongs in this #176 slice.

Design

Smallest production realization remains:

registry
  +-> capability-filtered trusted RuntimeTools ----------------> executor
  `-> sanitized schemas -> ephemeral/supplied prompt catalog
                         -> prompt_compile(Query,
                                           capabilities,
                                           compiled|all_tools)
                         -> final packed active tool schemas
                         -> root planner

Rules:

default completion mode: compiled;
all_tools goes through the same compiler path, never a raw-discovery bypass;
invalid completion mode fails before planner dispatch with structured invalid_prompt_compile_mode;
ephemeral catalog uses setup_call_cleanup/3; supplied host catalog is never destroyed;
full trusted RuntimeTools remain unchanged for execution/authority/effects;
planner wording changes from Registered tool schemas to Active tool schemas;
no second selector, registry, authority layer, or tool unload behavior.

Adversarial review

GO, with these blockers on implementation correctness:

compiler-selected schemas must be a subset of final packed active units (already true upstream; reuse it);
capability denial must remain independently testable under all_tools so contextual relevance cannot create a false pass;
unknown compile mode must not silently fall back to compiled;
cleanup must run on planner failure/timeout/cancel as well as success;
visibility must never narrow the executor's trusted binding set;
negative contracts remain expected assertions so required CI stays green.

No production implementation/verification claim is made by this note. PR #216 remains the owned realization transaction.

RAGE live-state refinement against canonical `main` `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0` and owned PR #216 head `b19e5c795eea4f2c3abd7cf70957f12da8c056a5`. ## Analyze / executable evidence The production defect is still exactly at the completion boundary: ```text runtime_tools/4 -> tool_registry_runtime_tools(...) % trusted executable bindings -> tool_discover(...) -> capability-filter raw schemas -> planner_prompt(...) ``` `planner_prompt` still labels that projection `Registered tool schemas`, so normal root completion still bypasses compiler contextual selection. The compiler side is already farther along than the original issue checklist: `rlm_prompt_compiler:maybe_pack_projection/3` already computes `active_units` from the final context pack and filters `tool_schemas` through `active_tool_schemas/3`. Do not reimplement this in the realization. A second live mismatch is now pinned precisely: `rlm_prompt_compiler:compile_mode/2` intentionally treats only `mode(all_tools)`/`all_tools(true)` specially and otherwise defaults to `compiled`. Therefore the trusted completion option `prompt_compile_mode/1` must be validated at the completion boundary; passing an unknown value into the compiler cannot supply fail-closed semantics by itself. Current `completion_exception/2` maps generic `completion_fault(Fault)` to `kind:completion_fault`. The #216 TDD contract requires invalid trusted mode to be an explicit structured `kind:invalid_prompt_compile_mode`, so realization also needs a narrow exception mapping before the generic completion-fault clause rather than weakening the test. ## Research / ownership Downstream evidence remains clean: `a0-symbolics` PR #51 owns Agent Zero native/RLM product composition and explicitly leaves symbolic selection/budgeting/planning/authority/effects to Prolog-RLM; `agentProlog` PR #8 owns the DeepSeek Harness AgentFactory/sidecar product integration and calls canonical Prolog runtime APIs. Neither owns this provider-projection defect. Recent merge #209 explicitly advances #172 without closing it; no #172 follow-up belongs in this #176 slice. ## Design Smallest production realization remains: ```text registry +-> capability-filtered trusted RuntimeTools ----------------> executor `-> sanitized schemas -> ephemeral/supplied prompt catalog -> prompt_compile(Query, capabilities, compiled|all_tools) -> final packed active tool schemas -> root planner ``` Rules: - default completion mode: `compiled`; - `all_tools` goes through the same compiler path, never a raw-discovery bypass; - invalid completion mode fails before planner dispatch with structured `invalid_prompt_compile_mode`; - ephemeral catalog uses `setup_call_cleanup/3`; supplied host catalog is never destroyed; - full trusted RuntimeTools remain unchanged for execution/authority/effects; - planner wording changes from `Registered tool schemas` to `Active tool schemas`; - no second selector, registry, authority layer, or tool unload behavior. ## Adversarial review GO, with these blockers on implementation correctness: 1. compiler-selected schemas must be a subset of final packed active units (already true upstream; reuse it); 2. capability denial must remain independently testable under `all_tools` so contextual relevance cannot create a false pass; 3. unknown compile mode must not silently fall back to compiled; 4. cleanup must run on planner failure/timeout/cancel as well as success; 5. visibility must never narrow the executor's trusted binding set; 6. negative contracts remain expected assertions so required CI stays green. No production implementation/verification claim is made by this note. PR #216 remains the owned realization transaction.

lost-rob0t commented

2026-08-26 00:18:23 +00:00

(Migrated from github.com)

RAGE realization + exact-head verification — PR #216

Realization is now on rage/176-root-planner-tool-projection at exact head a7c1f58ee86ad2b9c61faf5323f4a3a8bdf99b0d.

Realized invariant

rlm_completion no longer uses capability-filtered raw tool_discover/2 results as the root planner surface. The path is now:

registry -> full capability-filtered RuntimeTools -> plan_run / authority / effects
       \-> sanitized schema import -> rlm_prompt_compiler
                                 -> compiled|all_tools
                                 -> final packed active tool schemas
                                 -> root planner

The compiler's already-landed active_tool_schemas contract remains canonical; no second selector was added.

Additional fail-closed behavior landed for trusted prompt_compile_mode/1: only compiled and all_tools are accepted, and unknown values return structured kind:invalid_prompt_compile_mode before planner dispatch.

Planner wording now says Active tool schemas. Ephemeral compiler catalogs use setup_call_cleanup/3.

TDD evidence

The previous expected-defect contracts were inverted after realization into intended behavior while keeping CI green:

compiled exposes the relevant schema and hides an unrelated capability-allowed schema in the exact captured planner request;
all_tools exposes all capability-eligible schemas through the same compiler path;
capability-denied schemas remain hidden;
invalid compile mode asserts the expected structured runtime failure and verifies planner call count remains zero;
planner prompt explicitly guards Active tool schemas vs the obsolete Registered tool schemas wording.

Exact-head gate

All required returned workflows for a7c1f58e… are successful:

deterministic PlUnit;
deterministic benchmark/conformance;
deterministic deep recursion;
CLI/trace smoke;
fresh-process graph/artifact restart checks;
whitespace gate;
REAL OpenRouter core/repair/benchmark/depth-0/1/2/CLI;
pinned paid OpenRouter equivalents;
Nix flake;
clean SWI pack install;
Tree-sitter FFI.

PR #216 is mergeable and has no reviews or unresolved review threads.

Scope reconciliation

This is a coherent production slice but does not close #176. Remaining epic work includes host-owned prompt_catalog lifecycle/ownership, projection fingerprint/active-unit observability, non-tool compiled guidance reaching the planner, broader cleanup/failure lifecycle regressions, direct tools(...) visibility contract, and the stable docs/research closure already listed in this issue.

Merge is intentionally not claimed here: repository instructions require explicit merge-on-green authorization for the exact transaction.

## RAGE realization + exact-head verification — PR #216 Realization is now on `rage/176-root-planner-tool-projection` at exact head `a7c1f58ee86ad2b9c61faf5323f4a3a8bdf99b0d`. ### Realized invariant `rlm_completion` no longer uses capability-filtered raw `tool_discover/2` results as the root planner surface. The path is now: ```text registry -> full capability-filtered RuntimeTools -> plan_run / authority / effects \-> sanitized schema import -> rlm_prompt_compiler -> compiled|all_tools -> final packed active tool schemas -> root planner ``` The compiler's already-landed `active_tool_schemas` contract remains canonical; no second selector was added. Additional fail-closed behavior landed for trusted `prompt_compile_mode/1`: only `compiled` and `all_tools` are accepted, and unknown values return structured `kind:invalid_prompt_compile_mode` before planner dispatch. Planner wording now says `Active tool schemas`. Ephemeral compiler catalogs use `setup_call_cleanup/3`. ### TDD evidence The previous expected-defect contracts were inverted after realization into intended behavior while keeping CI green: - `compiled` exposes the relevant schema and hides an unrelated capability-allowed schema in the exact captured planner request; - `all_tools` exposes all capability-eligible schemas through the same compiler path; - capability-denied schemas remain hidden; - invalid compile mode asserts the expected structured runtime failure and verifies planner call count remains zero; - planner prompt explicitly guards `Active tool schemas` vs the obsolete `Registered tool schemas` wording. ### Exact-head gate All required returned workflows for `a7c1f58e…` are successful: - deterministic PlUnit; - deterministic benchmark/conformance; - deterministic deep recursion; - CLI/trace smoke; - fresh-process graph/artifact restart checks; - whitespace gate; - REAL OpenRouter core/repair/benchmark/depth-0/1/2/CLI; - pinned paid OpenRouter equivalents; - Nix flake; - clean SWI pack install; - Tree-sitter FFI. PR #216 is mergeable and has no reviews or unresolved review threads. ### Scope reconciliation This is a coherent production slice but does **not** close #176. Remaining epic work includes host-owned `prompt_catalog` lifecycle/ownership, projection fingerprint/active-unit observability, non-tool compiled guidance reaching the planner, broader cleanup/failure lifecycle regressions, direct `tools(...)` visibility contract, and the stable docs/research closure already listed in this issue. Merge is intentionally not claimed here: repository instructions require explicit merge-on-green authorization for the exact transaction.

lost-rob0t commented

2026-08-26 01:03:52 +00:00

(Migrated from github.com)

Exact-head verification / reconciliation update

Revalidated the current #176 realization transaction against live remote state.

canonical main: 49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0
PR #216 head: a7c1f58ee86ad2b9c61faf5323f4a3a8bdf99b0d
PR #216 is open, non-draft, mergeable, with no review submissions, comments, or unresolved review threads
current exact-head check state is green, including deterministic CI, REAL OpenRouter, pinned paid OpenRouter, Nix/flake, clean SWI-pack loading, and Tree-sitter lanes

The automated failure issue #218 referred only to obsolete head cbffcdd3e113e6ecd8d6bcab7c4bf42067ae1e16; it has now been closed after the later exact head went green.

No merge performed in this RAGE pass: repository AGENTS.md requires explicit merge-on-green authorization for the exact transaction. #216 is therefore a verified merge candidate, not merged evidence.

#176 remains open after #216 because this PR is only the root-planner schema-projection slice. Remaining epic scope includes host-owned catalog lifecycle, projection fingerprint/active-unit observability, non-tool compiled guidance on the planner surface, direct tools(...) visibility semantics/docs, lifecycle regressions, and the stable prompt-compiler/completion docs + RLM-RESEARCH-011 closure.

## Exact-head verification / reconciliation update Revalidated the current #176 realization transaction against live remote state. - canonical `main`: `49d86f88730b4a0f5dc4a7cf300b8f09ef5845b0` - PR #216 head: `a7c1f58ee86ad2b9c61faf5323f4a3a8bdf99b0d` - PR #216 is open, non-draft, mergeable, with no review submissions, comments, or unresolved review threads - current exact-head check state is green, including deterministic CI, REAL OpenRouter, pinned paid OpenRouter, Nix/flake, clean SWI-pack loading, and Tree-sitter lanes The automated failure issue #218 referred only to obsolete head `cbffcdd3e113e6ecd8d6bcab7c4bf42067ae1e16`; it has now been closed after the later exact head went green. No merge performed in this RAGE pass: repository `AGENTS.md` requires explicit merge-on-green authorization for the exact transaction. #216 is therefore a verified merge candidate, not merged evidence. #176 remains open after #216 because this PR is only the root-planner schema-projection slice. Remaining epic scope includes host-owned catalog lifecycle, projection fingerprint/active-unit observability, non-tool compiled guidance on the planner surface, direct `tools(...)` visibility semantics/docs, lifecycle regressions, and the stable prompt-compiler/completion docs + RLM-RESEARCH-011 closure.

lost-rob0t commented

2026-08-26 06:10:27 +00:00

(Migrated from github.com)

#216 exact-head verification / docs reconciliation — 2026-08-26

Revalidated the current #176 transaction after the documentation/roadmap closure commits. Exact candidate head is 774454dba55855932f672f2de23b9e65936ede99 on PR #216.

Realization now present

root planner receives compiler-active registry schemas rather than raw tool_discover/2 inventory;
full capability-filtered trusted runtime bindings remain separate for plan_run, authority and effect enforcement;
compiled and compatibility all_tools both use the canonical rlm_prompt_compiler path;
invalid trusted prompt_compile_mode fails before planner dispatch as structured kind:invalid_prompt_compile_mode;
negative tests assert the expected failure/absence while CI stays green;
docs/prompt-compiler.md now records the stable visibility/authority contract, including the direct trusted tools(...) boundary;
docs/prolog-agent-roadmap.md now reflects that #216 supplies the root-planner local-tool projection while broader #176/#183 adoption remains open.

Exact-head evidence

774454db... is green on all returned required workflows:

canonical CI deterministic unit/load, benchmark/conformance, deep recursion, CLI/trace, fresh-process graph/artifact restart and whitespace gates;
credential-backed REAL OpenRouter core, structured repair, benchmark, depth 0/1/2 and CLI smoke;
pinned Paid OpenRouter equivalents;
Nix flake;
Clean SWI pack install;
Tree-sitter FFI.

PR #216 is non-draft and mergeable. Current review submissions, review threads and PR conversation comments are empty.

Remaining epic scope

Do not close #176 on this slice. Broader host-owned catalog lifecycle, projection observability/fingerprint exposure, lifecycle regressions, MCP/project-instruction/managed-context adoption, and research-record closure remain explicit follow-up scope.

Repository AGENTS.md still requires explicit merge-on-green authorization, so this worker stops #216 at the verified PR boundary rather than merging it.

## #216 exact-head verification / docs reconciliation — 2026-08-26 Revalidated the current #176 transaction after the documentation/roadmap closure commits. Exact candidate head is `774454dba55855932f672f2de23b9e65936ede99` on PR #216. ### Realization now present - root planner receives compiler-active registry schemas rather than raw `tool_discover/2` inventory; - full capability-filtered trusted runtime bindings remain separate for `plan_run`, authority and effect enforcement; - `compiled` and compatibility `all_tools` both use the canonical `rlm_prompt_compiler` path; - invalid trusted `prompt_compile_mode` fails before planner dispatch as structured `kind:invalid_prompt_compile_mode`; - negative tests assert the expected failure/absence while CI stays green; - `docs/prompt-compiler.md` now records the stable visibility/authority contract, including the direct trusted `tools(...)` boundary; - `docs/prolog-agent-roadmap.md` now reflects that #216 supplies the root-planner local-tool projection while broader #176/#183 adoption remains open. ### Exact-head evidence `774454db...` is green on all returned required workflows: - canonical CI deterministic unit/load, benchmark/conformance, deep recursion, CLI/trace, fresh-process graph/artifact restart and whitespace gates; - credential-backed REAL OpenRouter core, structured repair, benchmark, depth 0/1/2 and CLI smoke; - pinned Paid OpenRouter equivalents; - Nix flake; - Clean SWI pack install; - Tree-sitter FFI. PR #216 is non-draft and mergeable. Current review submissions, review threads and PR conversation comments are empty. ### Remaining epic scope Do not close #176 on this slice. Broader host-owned catalog lifecycle, projection observability/fingerprint exposure, lifecycle regressions, MCP/project-instruction/managed-context adoption, and research-record closure remain explicit follow-up scope. Repository `AGENTS.md` still requires explicit merge-on-green authorization, so this worker stops #216 at the verified PR boundary rather than merging it.

lost-rob0t commented

2026-08-26 07:11:44 +00:00

(Migrated from github.com)

RAGE reconciliation after #216 merge

Merged PR #216 into canonical main via the repository-allowed rebase method with expected-head protection. Reviewed candidate head was 774454dba55855932f672f2de23b9e65936ede99; canonical post-merge main is now 267697bef10a3fffff7c093e1435ece770e7444b.

The landed slice establishes the production boundary:

capability-filtered trusted runtime bindings remain available to plan execution / authority / effects;
sanitized registry schemas go through the canonical rlm_prompt_compiler before root-planner exposure;
default prompt_compile_mode(compiled) uses contextual activation/final packed schemas;
all_tools remains compatibility visibility through the same compiler path;
invalid compile modes fail closed before planner dispatch as kind:invalid_prompt_compile_mode;
ephemeral tool-projection catalogs are cleaned with setup_call_cleanup/3;
completion/prompt-compiler/AgentProlog roadmap docs were reconciled.

Pre-merge exact candidate/synthetic-merge validation was green: deterministic PlUnit (887/887), benchmark/conformance, deep-recursion experiment, CLI/trace, fresh-process graph/artifact restart, whitespace, credential-backed REAL OpenRouter, Paid OpenRouter, Nix flake, clean SWI pack install, and Tree-sitter FFI. Post-merge canonical 267697be… has triggered the repository workflow set; no failure conclusion is currently present in the returned canonical check/run state (failure-report jobs are skipped as expected).

Do NOT close #176: remaining epic scope still includes host-owned catalog lifecycle, projection fingerprint/observability on completion results, lifecycle regressions for ephemeral/host catalogs, MCP/project-instruction/managed-context compiler adoption, research-record implementation closure, and the broader single combined provider-context budgeting/packing story. The direct trusted tools(...) provider-visibility boundary remains documented as execution-only unless schemas enter the registry/compiler path.

RAGE reconciliation after #216 merge Merged PR #216 into canonical `main` via the repository-allowed rebase method with expected-head protection. Reviewed candidate head was `774454dba55855932f672f2de23b9e65936ede99`; canonical post-merge `main` is now `267697bef10a3fffff7c093e1435ece770e7444b`. The landed slice establishes the production boundary: - capability-filtered trusted runtime bindings remain available to plan execution / authority / effects; - sanitized registry schemas go through the canonical `rlm_prompt_compiler` before root-planner exposure; - default `prompt_compile_mode(compiled)` uses contextual activation/final packed schemas; - `all_tools` remains compatibility visibility through the same compiler path; - invalid compile modes fail closed before planner dispatch as `kind:invalid_prompt_compile_mode`; - ephemeral tool-projection catalogs are cleaned with `setup_call_cleanup/3`; - completion/prompt-compiler/AgentProlog roadmap docs were reconciled. Pre-merge exact candidate/synthetic-merge validation was green: deterministic PlUnit (887/887), benchmark/conformance, deep-recursion experiment, CLI/trace, fresh-process graph/artifact restart, whitespace, credential-backed REAL OpenRouter, Paid OpenRouter, Nix flake, clean SWI pack install, and Tree-sitter FFI. Post-merge canonical `267697be…` has triggered the repository workflow set; no failure conclusion is currently present in the returned canonical check/run state (failure-report jobs are skipped as expected). Do NOT close #176: remaining epic scope still includes host-owned catalog lifecycle, projection fingerprint/observability on completion results, lifecycle regressions for ephemeral/host catalogs, MCP/project-instruction/managed-context compiler adoption, research-record implementation closure, and the broader single combined provider-context budgeting/packing story. The direct trusted `tools(...)` provider-visibility boundary remains documented as execution-only unless schemas enter the registry/compiler path.

nsaspy referenced this issue

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

Add Prolog-owned automatic skill activation (linear replacement) #197

nsaspy referenced this issue

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

Propagate permanent RLM context to internal model calls #201

nsaspy referenced this issue

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

Wire compiler visibility contract into root planner #216

nsaspy referenced this issue

2026-08-29 10:26:36 +00:00

[P1] Add closed project-op plan vocabulary and plan dependency-graph executor #293

nsaspy referenced this issue

2026-09-08 01:29:18 +00:00

[MACHINE-SPIRIT 6/8] Retrieval and symbolic attention: bounded projection, graph search, relevance, embeddings as sensors, working-memory control #395

nsaspy commented

2026-09-08 01:36:51 +00:00

Owner

Machine Spirit #403A handoff — prompt packing after semantic attention

#403A/TAPS is upstream of provider-visible context packing when semantic/world-model knowledge is involved. The prompt compiler should consume already-admitted projection units and preserve their dependency classes:

pinned host obligation
semantic mandatory dependency
ranked resident periphery
frontier/gap reference

Budget packing must never keep a derived semantic conclusion while packing out a premise/rule/counterevidence item marked mandatory by its TAPS projection. If the closure cannot fit, either choose a smaller semantic candidate/result or expose a structural budget failure/partial projection; do not manufacture a dangling self-contained-looking answer.

This does not merge retrieval with the prompt compiler: #381/#403 choose/find semantic working sets; #176 continues to own provider-visible packing/tool projection. Existing invariant remains:

model visibility != runtime registration != execution authorization

Refs #403 #381 #396.

## Machine Spirit #403A handoff — prompt packing after semantic attention #403A/TAPS is upstream of provider-visible context packing when semantic/world-model knowledge is involved. The prompt compiler should consume already-admitted projection units and preserve their dependency classes: ```text pinned host obligation semantic mandatory dependency ranked resident periphery frontier/gap reference ``` Budget packing must never keep a derived semantic conclusion while packing out a premise/rule/counterevidence item marked mandatory by its TAPS projection. If the closure cannot fit, either choose a smaller semantic candidate/result or expose a structural budget failure/partial projection; do not manufacture a dangling self-contained-looking answer. This does **not** merge retrieval with the prompt compiler: #381/#403 choose/find semantic working sets; #176 continues to own provider-visible packing/tool projection. Existing invariant remains: ```text model visibility != runtime registration != execution authorization ``` Refs #403 #381 #396.

nsaspy referenced this issue

2026-09-08 01:47:53 +00:00

[MACHINE-SPIRIT 6/8] Retrieval and symbolic attention: bounded projection, graph search, relevance, embeddings as sensors, working-memory control #395

nsaspy referenced this issue

2026-09-08 01:47:53 +00:00

[MACHINE-SPIRIT 6/8] Retrieval and symbolic attention: bounded projection, graph search, relevance, embeddings as sensors, working-memory control #395

nsaspy referenced this issue

2026-09-08 01:47:53 +00:00

[MACHINE-SPIRIT 6/8] Retrieval and symbolic attention: bounded projection, graph search, relevance, embeddings as sensors, working-memory control #395

nsaspy referenced this issue

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

[EPIC] Wire prompt compiler tool projection into the real rlm_completion planner surface #450