Bastion 1.8.0

Added

• Load tools on demand, app-wide and per server. 1.7.0 kept the answer on the profile, which is where it belongs and not where anybody makes it: a saving reachable only by editing profiles one at a time is a saving nobody finds. Two more places to set it, and neither stores a second answer of its own.

  Settings › General now carries the default every profile follows. Profile.lazyTools goes tri-state — no value means "follow the app-wide switch" — so a profile that has disagreed keeps its override through an unrelated edit, instead of having the current default frozen into it by the next save.

  The server pane carries the tier between the two, under the profile rows it applies to, because the decision is almost always about one server: appstore-connect is 85 tools and 26.2k tokens, reddit is 14 and 3.3k, and nobody wants the same answer for both. It writes through to every profile of that server rather than storing a third answer — the absent value included, so Default there still means "follow the app-wide switch" rather than freezing today's answer into four rows. Profiles that already disagree read Mixed, which is a state somebody arrived at from the profile editor and not one to round off; a control that quietly read "Off" there would hide the profile that is on. Its caption quotes the measurement one of those profiles actually took, so the saving on offer is this server's own rather than the one from the changelog.

  Still off by default, and Settings names the client it is wrong for. That matters more than it did per profile, because the switch now moves every profile at once and Claude Code is the client most people are running — it defers tool schemas by itself, so a profile wired to it gains nothing here and still pays the coarser approval rule.

Fixed

• bastion_search_tools no longer answers "no tool matches" when one does. A model searching prod/appstore-connect for version builds submission was told nothing matched, out of 85 tools, because the one that does says "its build and metadata" and the query said "builds". Three things were wrong with the matching and all three are fixed: a plural now folds onto the singular a description happens to use; a word no tool carries no longer empties the result, which instead falls back to the tools that matched the most of the query and says which word missed; and matching reads the whole description rather than the 160-character summary it prints, so testflight build finds list_builds, whose description mentions TestFlight only past the cut. The index was the only way in, so a query that came back empty sent the model to the full listing the feature exists to avoid sending.