Baixar crewhaus 0.7.0 per a Windows

**Tools a harness can run without spending a token.** A CrewHaus harness could
call 22 builtin tools; it can now call 549. They read chains and ledgers, drive
git and package managers, gate a page before it publishes, operate a fleet, and
answer the hundreds of small questions a run used to spend a model call on —
almost none of them makes one, and a spec turns them on a capability group at a
time rather than a name at a time. Two of the fixes below are worth reading even if
you upgrade nothing：an SSRF classifier that compared address text, found by
auditing all ten copies of it, and a daemon status page that had been binding
the wildcard rather than loopback.

### Added

• **Fifty-seven new `@crewhaus/tool-*` packages** (#453, #454, #458, #459,
#462, #463, #465, #466, #467, #469, #470, #471, #472). Each is an ordinary
builtin — it takes a typed input, does the work in-process, and returns a
result — so the work it does costs no tokens and cannot drift between runs.
Two of the 549 are the exception and say so in their own descriptions:
`ImageGenerate` calls a remote image model and `WebSearch` calls a paid
search API. Every other one is local work. Broadly:

• **Pure computation, no I/O at all.** Text, structured data (JSON, YAML,
TOML, CSV, XML), encoding and hashing, dates and schedules, maths and
exact money, schema validation, control flow, and tabular intake:
`tool-text`, `tool-data`, `tool-encode`, `tool-datetime`, `tool-math`,
`tool-schema`, `tool-flow`, `tool-table`.
• **The working tree and the toolchain.** Files and archives, processes,
git, GitHub and GitLab, SQLite, documents, HTML, packaging and lockfiles,
code intelligence, and the gates you run before a change lands —
`tool-fsx`, `tool-proc`, `tool-git`, `tool-codehost`, `tool-sql`,
`tool-docs`, `tool-html`, `tool-pkg`, `tool-code`, `tool-verify`,
`tool-changeset`, `tool-buildperf`, `tool-supplychain`, `tool-registry`,
`tool-containers`, `tool-distribution`.
• **What a harness remembers and what it reports.** Durable state, secrets
handling, messaging, observability and cost：`tool-state`, `tool-secure`,
`tool-secrets`, `tool-notify`, `tool-obs`, `tool-media`.
• **Money and chains, reading only.** ABI encoding and EIP-712 digests,
live EVM reads, token and DeFi queries, a hash-chained local ledger,
e-invoices, payment files and counterparty checks：`tool-onchain`,
`tool-chainread`, `tool-chaincall`, `tool-token`, `tool-defi`,
`tool-ledger`, `tool-einvoice`, `tool-kyc`, `tool-money`,
`tool-objectstore`.
• **The operator's own machine.** System and network facts, scheduled jobs,
filesystem watches, the system package manager and the desktop:
`tool-host`, `tool-hostfs`, `tool-cron`, `tool-pkgmgr`, `tool-desktop`.
• **CrewHaus operating itself.** Specs, evals, datasets, approvals, harness
lifecycle, fleets, deployments, routing and discovery：`tool-specops`,
`tool-evalops`, `tool-dataset`, `tool-approvals`, `tool-lifecycle`,
`tool-fleet`, `tool-deploy`, `tool-routing`, `tool-discovery`,
`tool-crewhaus`.

**What these tools deliberately will not do matters as much as what they
do,** because each of these was a capability that would have been easy to
add and wrong to ship:

• **None of these tools signs or sends a transaction.** They read. No
schema among them takes a private key, and each of the five chain
packages refuses `eth_sendTransaction` and `eth_sendRawTransaction` at
the RPC seam by assertion rather than by omission. (The separate
`@crewhaus/tool-evm-tx`, which does sign, is wired per shape and is not
one of the 549.)
• **Nothing moves money.** `PaymentFileBuild` writes a payment file and
`InvoiceRender` renders an invoice; transmitting either is a human's job
through their own bank. No schema takes a banking credential.
• **Nothing acquires privilege.** `PackageInstall` never runs `sudo`,
`doas`, `runas` or `pkexec`, and no schema has a password field. A
manager that needs root refuses and hands back the exact command an
operator would run; Homebrew, which does not, proceeds.
• **`SecretLookup` does not return the secret.** A tool result reaches a
model's context, then a transcript, a trace and a log, so it reports
presence, backend, length and a truncated fingerprint. There is no
reveal option.
• **Nothing a caller supplies becomes program text.** `osascript -e` takes
source code and a Windows toast body is XML, so `tool-desktop` passes
every caller value as an argument the script reads by index, never
interpolated into a statement.
• **`DeployPromote` was not built.** Its `protected_envs` guard cannot be
enforced by a tool, which never sees how the permission engine resolved
the target environment; with a standing allow the guard would be
decorative. The reasoning is kept in a docblock rather than lost.

• **`tools:` gains a grammar for turning on a capability group** (#453).

tools:
• all-code # every tool in the code roll-up
• -bash # ...except this one
• webFetch # plus one tool by name

Order does not matter：every include is unioned, then every exclude is
subtracted, so an exclusion always wins and a reader never has to simulate
the list top to bottom. A category is either a leaf, owning tool keys and
mapping 1:1 to the package that implements them, or a roll-up owning other
categories and expanding transitively — one mechanism for both `all-fs` and
`all-code`. Expansion happens once, at lowering, so the IR only ever carries
concrete names and no target emitter changed. A spec that uses no category
syntax is returned by reference, so every bundle written before this existed
still compiles byte-identically.

Two mistakes fail the compile with the offending path rather than passing
quietly：an unknown category, and an exclusion that removes nothing — a
`-gitPush` matching no included tool is almost always a typo, and ignoring
it would leave the author believing a tool is gated when it is not.

Because a category system is only as good as being able to see inside it:
`crewhaus tools categories`, `tools show <tool>`, `tools search <query>` and
`tools list --category`. The registry is the new `@crewhaus/tool-categories`,
which is data only and imports no tool package — the compiler imports it and
codegen has to stay offline.

• **`crewhaus hangar --lan` prints a QR code you can scan** (#455). It binds
this machine's LAN address instead of loopback and renders the console's
URL, token and all, as a QR code in the terminal. Scan it and the fleet
view, the run feed and the Advisor open on your phone — which is the point,
because they are exactly what you want on a second screen while a terminal
is busy, and nobody types a 64-character token into a phone twice.

The encoder is a new dependency-free package, `@crewhaus/qr-code`. A
package rather than an install because `apps/cli` carries exactly one
non-workspace dependency by policy, and because `bun build --compile`
embeds only statically-referenced imports — a QR library that loads a data
file at runtime would pass `bun test` and brick the released binary. This
one has no data files at all.

Two things a terminal renderer meets that a PNG renderer never does. A
terminal cell is twice as tall as it is wide, so half-block characters
carry two module rows per text row and the modules come out square. And a
terminal has no fixed background, so every line carries an explicit
black-on-white colour pair; without it the same characters read as a QR
code on a dark theme and as its photographic negative on a light one. With
colour disabled the mapping inverts instead, because the only remaining way
to make light modules light is to draw them and let the terminal's dark
background be the ink.

Picking the address is its own problem：`os.networkInterfaces()` offers no
ranking, and on a laptop most of what it offers is useless to a phone — VPN
tunnels, Apple's peer-to-peer radios, container bridges, self-assigned
169.254 addresses. The ranking prefers RFC 1918 on a physical-looking
interface, and ties break on the interface name so the answer is stable
across boots.

• **`crewhaus services setup` — the external services a harness needs, in one
command.** A spec declares *that* it wants a Slack channel, a public URL and
a hosted wiki; everything on the other side of those declarations has been a
click-path through three consoles, repeated per harness. The new
`@crewhaus/service-setup` package creates them：a Cloudflare named tunnel
with a public hostname and its DNS record, a Thredz wiki space, and a Slack
app built from a manifest, applied, and installed. Credentials land in the
harness's own `.env`; the wiki slug lands in the spec's `thredz.space`,
which the compiler bakes in as a literal and so cannot live in `.env`.

Everything is derived from the spec — including the credential variable
NAMES, which come from its own `$VAR` refs, because `channel-adapter-slack`
never reads a credential from the environment and the names are therefore
the author's choice. No naming convention is assumed.

This does not reverse `channel provision`'s deliberate emit-and-instruct
decision for Slack, it sits above it. That command is part of the runtime's
credential tier, which carries only what the daemon uses and cannot call the
manifest API. `services setup` is an operator command holding short-lived
provisioning credentials — a Slack app-configuration token, a Cloudflare API
token, a Thredz key — that are read once, used, and dropped. What lands in
the harness is still only what the daemon needs.

Three details are load-bearing. Setup **stands in on the events port** to
answer Slack's `url_verification` challenge, because the da