mirror of
https://github.com/nearai/ironclaw.git
synced 2026-09-03 08:06:01 +08:00
9bf094fb4d
* fix(sandbox): consume the material mode on every platform
`main` has been red on `Clippy Windows (default)` and
`Clippy Windows (all-features)` since f88ef87ce:
error: unused variable: `mode`
--> crates\lanes\ironclaw_sandbox\src\sandbox_process\managed_egress.rs:1889:5
= note: `-D unused-variables` implied by `-D warnings`
`write_atomic_material_file_with_mode` took a `mode: u32` that only a
`#[cfg(unix)]` block at the call site consumed, so on Windows the parameter
was genuinely unused. This blocks cutting any release candidate: the weekly
strategy requires cutting from a commit whose required checks are green, and
no recent `main` commit qualifies.
Rather than suppress the lint, remove the reason for it. The permission apply
moves into `apply_material_mode`, with a `#[cfg(unix)]` implementation that
sets the bits and a non-unix one that is a deliberate no-op -- but still takes
`mode`. Consuming the parameter on every platform keeps a single signature,
needs no `allow`, and puts the platform difference behind a named function
instead of an inline `cfg` block.
Tested rather than exempted. The regression gate offers a `skip-regression-check`
path, but both of its forms require asserting "deterministic reproduction is
impossible", which is false here -- the Windows clippy lanes reproduce this
deterministically on every run -- so claiming it would have put an untrue
statement in the PR to buy a green tick.
`apply_material_mode_restricts_the_file_to_its_owner` asserts the mode
actually lands, not merely that the call returns Ok: these files carry proxy
credentials, so a writer that silently stopped restricting them would be a
leak rather than a style regression. The non-unix twin pins that the no-op
still accepts `mode`, which is the property that keeps the lint away.
Verified by simulating the Windows configuration on macOS (swapping which
`apply_material_mode` compiles): the crate builds clean under `-D warnings`
with no suppression anywhere. A native unix build cannot exercise this,
which is why the simulation is the local evidence and the Windows CI lanes
are the real gate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(changelog): add the v1.4.0 release entry
Covers the 81 commits since ironclaw-v1.3.0 (30 fix, 23 feat, 9 refactor,
2 perf): the durable notification inbox and actionable run gates, background
subagents with per-child delivery and healing sweeps, persistent per-user
sandbox containers behind a managed egress proxy, run-now for automations,
suggestions generated over the user's own read-only tools, Google Docs
semantic editing, and the stall/diagnostic fixes across the LLM, capability
and resource-governor paths.
The operator paragraph carries the three things a deployment actually has to
know about this release: the in-worker SSH listener is off unless
IRONCLAW_REBORN_SSH_PUBLIC_KEY is set (public-key-only as `agent` on port
2222, which must be published, and `agent` shares uid 1000 with the runtime
user so the private key is equivalent to shell access);
IRONCLAW_REBORN_WORKSPACE_ROOT is honored on both boot paths and neither it
nor IRONCLAW_REBORN_HOME may be the filesystem root; and the two new sandbox
knobs.
Upgrade note says no migration steps: installation state written by 1.2.x is
accepted and preserved, so a deployment that skipped 1.3 can come straight
here.
This lands on the release branch rather than main because the branch was cut
first. It MUST be cherry-picked back to main: the release branch freezes and
is never merged back, so an entry that lives only here disappears from the
next candidate and the live changelog silently drops this release — exactly
what happened to v1.3.0, which #7913 had to repair
(docs/internal/weekly-release-strategy.md, Candidate rules step 3).
Verified: ensure_stable_changelog_entry(".", "1.4.0") passes (it refused
before this commit), docs_publication_boundary.py and check-guidance.py OK.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>