Baixar ironclaw 1.2.0 per a Windows

Release Notes
Stable promotion of 1.2.0-rc.3, including the fixes validated in RC2 and
RC3 and the complete RC1 feature set below.
Fixed in 1.2.0-rc.3
- The runtime container image now installs curl, so in-container HTTP
healthchecks can execute. Orchestrators probe the worker with
curl -fsS http://localhost:3000/; the image shipped no HTTP client, so the
probe could never run, the container was never marked healthy, and the deploy
timed out into error while the listener served 200s throughout.
Changed in 1.2.0-rc.3
- Reborn PR test planning and the root-partition runner now share one test
inventory covering every tests/*.rs target, and container image inputs
select the root test that asserts them. Previously the two sides disagreed on
partition assignment, so a scheduled root test could be reported green
without having run.
Fixed in 1.2.0-rc.2
- Windows first-start filesystem publication now uses native atomic rename
semantics instead of hard links and tolerates unsupported directory syncs.
- Release smoke runs preserve the Windows account identity required to secure
the standalone secrets key, isolate workspace state, and keep icacls
status output from contaminating machine-readable CLI JSON.
Added
- Slack channel context. Pinging the bot at the top level of a channel
gives the run recent channel history as context (last 30 messages); pinging
inside a thread gives it that whole thread (up to 100 replies). Context is
fetched host-side with the bot token (channels:history scope; missing
scopes degrade to no context), and is framed to the model as untrusted
quoted channel content, never as instructions. Telegram has no equivalent —
the Bot API cannot read history — so Telegram context is the conversation
the bot has itself processed.
- can_reply_in_threads channel presentation flag declaring each channel's
reply placement: Slack (true) replies in a thread rooted on the pinged
message; Telegram (false) replies as an anchored quote of it.
Changed
- Add the bot to a channel and it just works. Shared-conversation
admission is presence-based: any Slack channel or Telegram group the bot
has been added to is served, with no allowlist and nothing to configure
(the slack_allowed_channels / telegram_allowed_channels settings are
gone). Channels whose actor identity is not per-user still never serve
shared conversations.
- Shared conversations are genuinely shared — and every run still acts as
its invoker. A Slack thread (each top-level ping roots its own) or a
Telegram group/topic is ONE continuous conversation that every paired
participant shares: anyone can follow up on what someone else started.
Each message still runs as the person who sent it — their identity,
memory, settings, and approval gates — never as a configured subject or
the operator (that mechanism is retired). Pre-existing shared threads
simply resume. Shared channels are no longer offered as per-user
notification delivery targets (DM targets are unchanged), and previously
stored shared-channel notification preferences fail closed at resolution.
- Unpaired users get pointed the right way, in place. An unpaired user
who pings the bot in a shared conversation gets the connect notice as a
reply anchored on their own message (threaded in Slack, quoted in
Telegram), throttled per conversation — instead of silence or running as
someone else. DMs keep their existing connect prompt.
- Every parked gate is announced, on both delivery lanes. Gate prompts are
keyed by their gate ref in the live conversation lane and the background
automation lane alike, so a run that parks on several approval/auth gates
announces each one instead of collapsing into the first prompt's delivery
identity. One deploy-boundary note: a gate prompt delivered but not yet
acknowledged when this version deploys re-announces once (its durable
delivery identity changed shape).
Removed
- All shared-channel admin-configuration fields: the slack_shared_subject_user_id
and slack_subject_routes subject fields AND the slack_allowed_channels /
telegram_allowed_channels allowlists. Shared-channel admission is now
presence-based — there is nothing to configure, and adding the bot to a
channel is what admits it (see "Changed" above). Saved values for any of
these retired handles are inert, and new saves fail closed as unknown fields.