Skip to content

gald3r v2.2.0

Choose a tag to compare

@wrm3 wrm3 released this 24 Jun 14:46
· 116 commits to main since this release

Download

v2.2.0 predates the current engine repo, so it has no matching build.
For a version you can actually install, get the newest release: Download gald3r.


_Pending release notes accumulate here as tasks and bugs are completed. At publish time this

section is renamed to [X.Y.Z] - YYYY-MM-DD and a fresh [Unreleased] block is opened._

Added

  • DeploySystem — the deploy pipeline step is now Python (T683, PS1-KILL epic T667). Ported the last numbered PowerShell pipeline script, custom_scripts/2_deploy_to_workspace.ps1, to maintainer/src/gald3r_forge/systems/deploy.py (Forge().deploy) behind a thin custom_scripts/2_deploy_to_workspace.py wrapper. Faithful parity with the PS1: backs up + replaces the framework-owned folders (.claude/.cursor/.gald3r_sys, each moved to <dir>_bk_<stamp>/ first), then upgrades .gald3r/ by invoking the target repo's own engine (uv run --project <repo>/.gald3r_sys/engine gald3r update --target <repo> --apply, python -m gald3r fallback) so user task/bug/plan/vault data is preserved, never wiped. Same three modes — dry-run (default, write-nothing plan), --apply, and --rollback YYYYMMDD_HHMMSS — plus multi-target via --repo and/or --workspace-manifest, --source override, and --skip-gald3r-upgrade. Dry-run is a hard write-guard (mutating helpers assert non-dry). 28 new tests (maintainer/tests/test_deploy.py); maintainer suite 203/203 green. Verified a real build → deploy --dry-run cycle against the live repo.

Changed

  • @g-go-go conductor now halts on coordinator failure instead of grinding the budget (circuit breakers). A run hit a Claude monthly spend cap mid-run (2026-06-24): every subsequent claude -p coordinator failed instantly (exit 1, spend-limit message) but ggo_outer_loop.py kept spawning them, burning ~296 no-op iterations to budget=0 — and the final state said only "budget exhausted," hiding the real cause. Two guards added: (1) fatal-output detection — the coordinator's streamed output is scanned for account-level sentinels (FATAL_OUTPUT_SENTINELS: monthly spend limit, credit balance too low, invalid api key, authentication error, unauthorized) and the run stops immediately with authorized_hard_stop = "coordinator fatal signal: '<sentinel>'" (retrying these always fails identically); (2) a consecutive-failure circuit breaker — --max-consecutive-failures (default 3) stops the run after N back-to-back non-zero coordinator exits. The coordinator's stdin write is now wrapped against BrokenPipeError so an instant-exit coordinator can't crash the conductor. Both paths record why in the marker so the stop reason is never hidden. Verified end-to-end (fatal sentinel stops at iter 0; breaker stops at the configured count) instead of running the full budget.

  • @g-go-go stateless conductor now streams live progress to the terminal/log. ggo_outer_loop.py previously let the spawned claude -p coordinator's output buffer and inherited stdout, so a launch that redirects to .gald3r/logs/ggo_outer_loop_stdout.log only updated once per finished iteration — a run looked dead mid-task even while working hard. The coordinator subprocess is now spawned line-buffered (Popen(..., bufsize=1, stderr=STDOUT)) and its output is re-emitted line-by-line with flush=True, and every outer-loop event goes through a new timestamped log() helper ([outer-loop <ts>] …) including a per-iteration iter advanced -> N / budget M (marker stamped …) pulse. Get-Content .gald3r/logs/ggo_outer_loop_stdout.log -Wait now shows progress as it happens. (First slice of the queued live-status-indicator feature.)

  • Maintainer release-pipeline scripts renumbered by run order (T667/T683). custom_scripts/ scripts now carry numeric run-order prefixes so the sequence is self-documenting: 1_build_repos.py → 2_deploy_to_workspace.py → 3_ship_repos.py → 4_push_repos.py → 5_release_repos.py. The @g-gald3r-build/ship/publish/release command docs, paths.py, gald3r_templates/CLAUDE.md, and the parity-pipeline subsystem registry were updated to the new paths; test scripts stay unnumbered. A rewritten custom_scripts/README.md documents the numbered pipeline, the ship-before-build version-cut nuance, and the ship-vs-publish "version number vs release docs" split.

Removed

  • Deprecated PowerShell pipeline twins deleted (T667/T683). custom_scripts/build_repos.ps1, custom_scripts/push_repos.ps1, and custom_scripts/2_deploy_to_workspace.ps1 removed — their Python replacements (1_build_repos.py, 4_push_repos.py, 2_deploy_to_workspace.py) are at full parity (build .py is a superset adding --workers; push .py is 1:1 on all 10 flags; deploy .py mirrors all PS1 flags + modes), each delegating to Forge().build / Forge().publish / Forge().deploy. The only remaining .ps1 in custom_scripts/ is the unnumbered test_full_scenario.ps1 (port tracked in T683).

Fixed

  • Publish no longer ships the unfilled NEXT_RELEASE template as the GitHub release body (BUG-178). PublishSystem._release_notes_content returned the archived releases/RELEASE_v{version}.md unconditionally, but the publish step archives NEXT_RELEASE.md even when nobody filled it in — so the empty promo skeleton (_(One punchy line…)_, "version number assigned at publish time") shipped as the release notes on 2.1.1 and 2.1.2. A new _is_placeholder_notes() guard detects the template sentinels and falls back to the (always-populated) CHANGELOG section. +1 publish test; maintainer publish suite 48/48. The live 2.1.1/2.1.2 GitHub releases were re-edited with proper notes from RELEASE_v2.1.2.md.