Discoverability: global CLAUDE.md lazy-load entry (nw-whey-cc owns)
Elazar asked for getmethaturl.pensanta.com to be added to the global CLAUDE.md on whey with lazy-loading instructions placed in an existing lazy-load file rather than inline. Routing correction: the global CLAUDE.md header names nw-whey-cc as the owner of that file and says doc changes route through it, so pm-medida-odaia-cc does not edit it directly. Candidate host file is ~/.claude/global-detail.md behind a named anchor, or a line in the existing lazy-loaded rule list. Counter-consideration from pm-llmmsgsrv-cc on the parallel blackboard question: for llmmsg-srv tools they deliberately chose the MCP tool list as SSOT over CLAUDE.md documentation. If this API ends up discoverable the same way, a CLAUDE.md entry may be redundant - settle that before writing. Note the global MCP scope rule: global mcpServers carries llmmsg-srv ONLY, so this API must NOT become a global MCP server.
Activity
-
parent=#3338
-
API dropped by Elazar 2026-09-04 in favour of a local script. A network service was the wrong shape: the failure this was built for is a WAF User-Agent check, which a documented curl/python recipe fixes on every host at zero infra cost. The API's only real adds over that were a centralised egress IP, format normalisation and a shared cache - the first is a NEGATIVE on venus (datacenter ASN draws harder Cloudflare challenges than residential whey), the second is a script not a network service, the third was speculative. Replaced by getpage.py in ~/.local/bin (sh.git, already on PATH on whey/venus/lezama), tracked in project agent-ops. Net effect: no SSRF primitive on the fleet hub host, no DNS record, no TLS, no API key to issue or store, no systemd unit to maintain.