Documentation
¶
Overview ¶
Package toolnames answers one question about a piece of written guidance: does it name a tool this deployment does not register?
A tool rename or removal leaves stale names behind in text nothing recompiles -- the deployment's customized agent instructions above all, which every session reads. Two callers ask: the startup lint over the instructions in force at boot (pkg/platform), and the apply_knowledge agent_instructions sink, which refuses a promotion naming one (pkg/toolkits/knowledge).
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Unknown ¶
Unknown returns the tool-name-like tokens in text that this deployment does not register, de-duplicated and in first-appearance order.
A token counts as tool-name-like when it is snake_case and its first underscore-delimited segment is one this deployment's own inventory uses, or one of floorToolPrefixes. Deriving most of the set from the inventory is what makes the check keep up with the platform: a deployment that registers api_discover puts "api_" in the set, so a stale api_list_endpoints is reported without anyone maintaining a list -- which the fixed six-prefix list this replaced could not do, leaving it blind to four of the fourteen names in scripts/retired-tools.txt.
A token written as a member of something (`platform.save_state`) is not a tool reference and is skipped, so a rule naming a script host method is not read as naming a tool.
registered is every tool name the deployment registers -- the toolkits' and the platform's own; see platform.RegisteredToolNames, since the toolkit registry alone omits the platform's.
Types ¶
This section is empty.
Source Files