Skip to content

runtime: generic owner-scoped runtime-tool contribution seam #2347

Description

@AndrewBarba

Problem

Framework-owned runtime code sometimes needs to contribute a qualified set of branded dynamic tools after preamble resolution (today: connection_search; next: memory provider tools). No generic contributor seam owns validation, durable capture, replacement, collision handling, and provenance — so each contributor either reimplements those behaviors or bypasses them.

Reproduction

Contribute a branded tool set from runtime code outside the authored defineDynamic path. There is no single internal API that validates entries, records durable metadata through the F1 descriptor path, attaches owner/source provenance, replaces a prior contribution atomically per owner, handles name collisions by the established precedence rule, and cleans up on runtime-revision change.

Desired invariant

One internal runtime-tool contribution API: owner-scoped atomic contribution transactions feeding the same validation/merge path as authored dynamic tools, with qualification through the existing name-validation primitive, durable capture via F1, call origins via F2, and centralized replacement/cleanup. connection_search migrates as the first consumer without changing its public behavior.

Scope

Internal runtime API built entirely on F1/F2. No memory types.

Part of the first-class memory restructure (#1510); foundation PR F3.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions