release: v0.47.2

Introduce `tests/common/mod.rs::TempAlcHome`, an RAII harness that
spawns the `alc` MCP child with `ALC_HOME` (and `ALC_PACKAGES_PATH`)
pointing at a per-test tempdir. Seven previously-leaking e2e tests are
routed through it, so `cargo test --workspace` (and by extension
`just ci` / `@alc-pre-push mode=full`) no longer writes into the
developer's real `~/.algocline/installed.json` / `~/.algocline/config.toml`.

Fixes the recurring pollution first documented in issue `213cad4a`
(`installed.json` via pkg-family tests) and issue `efd45582`
(`config.toml` via `test_alc_info` snapshot). Prior to this release,
every workspace test run re-introduced six `e2e_*` entries into the
developer's global manifest even after manual `alc_pkg_remove
--scope=global` cleanup, requiring per-release cleanup ceremony
(measured in the 2026-07-23 v0.47.1 release cycle).

Design notes:
- `Command::env` per-child avoids parent-process env mutation; parallel
  cargo test threads never race on ALC_HOME. No `serial_test` crate is
  required.
- Field declaration order (`client` -> `_tmp` -> `home`) guarantees the
  alc child terminates before the tempdir is removed, per Rust
  Reference §5.8.1.
- `{home}/packages/` and `{home}/types/alc.d.lua` are pre-seeded so
  that `resolve_lib_paths()` retains `ALC_PACKAGES_PATH` in the require
  search chain and `alc_pkg_install` populates `types_path` in its
  response.

No production code changed.

Migrated tests:
- test_alc_info
- test_pkg_doctor_reports_installed_missing
- test_alc_fork_roundtrip
- test_pkg_install_returns_types_path
- test_pkg_install_returns_alc_shapes_types_path
- test_pkg_remove_scope_global_cleans_manifest_not_files
- test_pkg_repair_reinstalls_deleted_dir

Changes:
- tests/common/mod.rs: new module, `TempAlcHome` guard + accessors
- tests/e2e.rs: 7 tests migrated to harness; `redact_paths_with_alc_home`
  helper added for stable snapshot redaction; obsolete `dirs::home_dir`
  cleanup / assertion blocks removed
- tests/snapshots/e2e__alc_info.snap: regenerated with `<ALC_HOME>` prefix
- Cargo.toml: bump workspace.package.version + workspace.dependencies to 0.47.2
- crates/algocline-engine/Cargo.toml: bump algocline-nn direct pin to 0.47.2
- CHANGELOG.md: rename [Unreleased] -> [0.47.2] - 2026-07-24, add entries, insert fresh [Unreleased]
- Cargo.lock: cargo update refresh

release: v0.47.1

Drop `algocline-swarm-frame` from `BUNDLED_SOURCES` (`src/init.rs`) and
`AUTO_INSTALL_SOURCES` (`crates/algocline-app/src/service/resolve.rs`).

The upstream repo moved to a `packages/` nesting layout (v0.9.0+) that
is incompatible with the Collection-layout contract expected by
`discover_packages`, so `alc update` / `alc init` were emitting a
non-fatal `No packages found ... Expected subdirectories with init.lua`
warning for it on every run. The swarm-frame V3 stack is deprecated in
favor of the flow.ir + mse successor, so retaining the entry no longer
justified the warning cost.

Users still relying on swarm-frame V3 can install it manually via
`alc_pkg_install <url>` once `discover_packages` grows nested-layout
support (tracked in issue a31ad3ca).

Changes:
- src/init.rs: remove swarm-frame BundledSource entry
- crates/algocline-app/src/service/resolve.rs: remove swarm-frame URL
- Cargo.toml: bump workspace.package.version + workspace.dependencies to 0.47.1
- crates/algocline-engine/Cargo.toml: bump algocline-nn direct pin to 0.47.1
- tests/snapshots/e2e__alc_info.snap: bump version to 0.47.1
- CHANGELOG.md: rename [Unreleased] -> [0.47.1] - 2026-07-23, add Removed entry, insert fresh empty [Unreleased]
- Cargo.lock: cargo update refresh

release: v0.47.0

release: bump Cargo.lock for v0.46.1

Follow-up to 49b288c — the `release: v0.46.1` commit forgot to
stage `Cargo.lock`, which `cargo` updated automatically when the
workspace `version` field changed. Adding it as a separate commit
per CLAUDE.md §絶対禁止 (new commit rather than --amend on the
previous one).

No source change, only lockfile metadata.

Claude-Session: https://claude.ai/code/session_01LSWhCAAtmrcid4sz3AgUce

release: v0.46.0

release: v0.45.0

Claude-Session: https://claude.ai/code/session_01XfrAB2Tdbe5ktvaBNw8Fpd

fix: sweep bridge::data sentinel surfacing via to_lua_value helper

Generalize the v0.44.3 alc.json_decode fix (commit 3a9a79c) across all
15 sibling `lua.to_value(&...)` callsites in
crates/algocline-engine/src/bridge/data.rs. A new internal helper
`to_lua_value` funnels every serde JSON -> Lua conversion through
`to_value_with` with `serialize_none_to_null(false)` and
`serialize_unit_to_null(false)`, producing Lua nil for JSON null
(instead of the mlua default lightuserdata sentinel) across the
`alc.state.*`, `alc.card.*`, `alc.stats.*`, `alc.alias.*` surfaces.

`alc.json_decode` is re-routed through the same helper so the
SerializeOptions are managed in a single SoT instead of duplicated in
the decode closure. The helper is generic over `T: serde::Serialize`
so callers passing typed structs (e.g. `SinkBackfillReport`) or
non-nullable shapes (`Vec<String>`) funnel through the same contract
without churn.

Regression test:
`bridge::data::tests::state_get_object_with_null_field_yields_lua_nil`
verifies the state.get path representative of the helper sweep
(state.set(obj with null field) -> state.get(obj).x is Lua nil,
type() == "nil", sibling non-null field round-trips unchanged).

Bump version 0.44.3 -> 0.44.4 (PATCH bump, internal helper + no
public API change, no MCP wire change).

Refs: issue ff6372af (sibling of db041966)

fix: alc.json_decode now returns Lua nil for JSON null

Switch to to_value_with(SerializeOptions::new()
.serialize_none_to_null(false).serialize_unit_to_null(false)) so JSON
null decodes to Lua nil instead of an mlua lightuserdata sentinel.
Previously `if obj.x then ...` truthy checks would pass through
nullable fields and crash downstream when the sentinel was passed to
functions expecting typed values (e.g. io.open(value)).

Top-level null, nullable object fields, and array elements all surface
as Lua nil. `#arr` is preserved at the original JSON length (mlua/Lua
5.4 array part semantics); `ipairs()` stops at the first nil hole as
per standard Lua semantics. Consumers iterating with
`for i = 1, #arr do ... if arr[i] then` remain safe.

Aligns implementation with the existing bridge_test.lua API contract
(`alc.json_decode("null") == nil`).

Bump version 0.44.2 -> 0.44.3 (PATCH bump for bugfix, no public API
change, no MCP wire change).

Refs: issue db041966

release: v0.44.2

release: v0.44.1