Skip to content

Layer A tool classification: unverified_unsupported stays permissive by default; consumers must override to be strict #61

Description

@simurg79

Summary

The Layer A tool-classification surface in the SDK still ships verified_unsupported and unverified_unsupported as two distinct categories with distinct severities, and its own classification logic fails only the former. Waldemort overrides that severity locally (compat/copilot-tool-classification.js) and owns the final observable outcome.

Why this is a latent trap

Because Layer A's default is the permissive one, any future consumer of Layer A that does not apply its own override will silently get the permissive behaviorunverified_unsupported tools will not fail. The strictness currently in effect is a property of Waldemort's override, not of the SDK.

The split ownership is documented in three places in the Waldemort design (decision D4, the Interfaces table, and a comment at the override site) and the design reviewer judged the record adequate. This issue tracks the underlying design question, not the documentation.

Question to resolve

Should Layer A be tightened so that unverified_unsupported also fails by default, collapsing the two categories or at least aligning their severities — making Waldemort's override unnecessary?

Severity

Low — no current incorrect behavior; risk is to future consumers of the SDK.

Related

Filed from Gate 16 (deferred-findings triage) of the Copilot CLI tool compatibility workflow.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions