## Problem/Motivation `checkRequirements()` is declared on the frozen interface but called by nothing, which this issue originally read as "wire it into execution." On reflection that was the wrong direction: the method was always intended to be **configuration-facing** — surface a visual indicator when a tool's requirements are unmet, and allow curation surfaces to prevent such a tool from being _added_ to something — while deliberately **not** blocking runtime. The reason the non-enforcement is deliberate: if `execute()`/`access()` enforced requirements, tool authors would be incentivized to put per-call runtime health checks (external server status, network reachability, credential liveness) into a hook meant for deployment readiness — and those checks would then run on **every invocation**. Requirements answer "is this site configured to offer this tool", not "is the world healthy right now"; runtime failures already have a channel (execution failure results). ## Proposed resolution - ~~Enforce checkRequirements() in execute()/access()~~ — **rejected**; an earlier branch state did this and has been replaced. - Document the contract explicitly (done on the issue branch): `ToolInterface::checkRequirements()` and `RequirementsException` now state the configuration-time intent, that `execute()`/`access()` deliberately never consult it, and why. - Pin the design with a kernel test: a tool with unmet requirements still passes `access()` and executes successfully (done on the issue branch) — so future "fixes" can't quietly reintroduce enforcement. - Build the actual configuration-facing consumers (this issue or split-offs): - Tool Explorer: unmet-requirements indicator on the listing and detail pages, showing the exception message. - A documented integration point for curation UIs (e.g. agent tool selection) to display the indicator and optionally refuse adding an unmet tool. The tool must stay _visible_ with an indicator — excluding it from derivative/function lists would hide it from the very UIs that should explain what is missing. - `drush tool:info` / `tool:search`: display requirement status informationally. ## API changes None — the method and exception keep their signatures; only documentation and test coverage land, plus UI consumers. ## AI usage (if applicable) - [x] **AI Assisted Issue:** This issue was generated with AI assistance, but was reviewed and refined by the creator. - [x] **AI Assisted Code:** This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision. - [ ] **AI Generated Code:** This code was mainly generated by an AI with human guidance, and reviewed, tested, and refined by a human. - [ ] **Vibe Coded:** This code was generated by an AI and has only been functionally tested.