LocalSetup 4.89.4

LocalSetup 4.89.4

LocalSetup 4.89.4 makes agent work easier to observe, preserves independently owned skills, and adapts test execution to resource pressure while keeping terminal operations under explicit owner control.

Highlights

• Follow native agent activity: an owned terminal view shows bounded item metadata and operation state, with guarded recovery after transient read failures and an explicit history-gap signal.
• Keep terminal work under its owner: managed shell operations retain process and session identity, private input remains operation-bound, and failures provide actionable feedback without granting new authority.
• Use independently owned skills: select repository, personal, or framework origins explicitly; recorded snapshots and collision checks protect custom source during install, update, and rollback.
• See test pressure and progress: the shared worker policy adapts to memory headroom and exposes versioned telemetry while the protected test scope retains its resource limits.
• Rejoin the right shell state: attach, logs, input, and family instructions retain an explicitly selected private state root, including safely quoted paths in older status layouts.
• Find the practical starting point: the homepage and framework guides lead with visible operations, privacy, and concrete engineering workflows, with detailed mechanisms in linked references.

Compatibility

Older settled terminal views remain usable. Pending records that lack proof of whether a pane-removal command ran stay unresolved until verified readback proves removal; LocalSetup does not repeat an uncertain removal.

The agent-shell family retained-text contract is qualified for Linux with tmux 3.4. Other tmux versions report an unqualified family result; Windows support remains WSL2-only. Native client activity currently reads bounded metadata from a qualified local Codex daemon, not a complete transcript or a universal client activity feed.

Managed shell mutations require the live native owner's process ancestry and generation. A detached or brokered runner outside that ancestry is unsupported even when tmux is available; use the client's ordinary command tool under its existing permissions and sandbox rather than replacing an owner session.

Explicit private shell state roots remain part of copyable follow-up commands. Omitting one selects the default store and cannot resolve that session. An observation handle does not grant mutation authority.

Independently owned skills keep their source and identity. Discovery or a format check does not trust, execute, upgrade, or authorize a skill; unresolved adapter-name collisions stop before changes.

Update

Refresh LocalSetup with its existing install or recorded package-refresh workflow. Run localsetup shell capabilities before starting an owned session, then use the actual live agent's qualified owner binding; do not substitute a short-lived helper or an unrelated process.

Select custom skill origins explicitly and inspect their integration-contract status and collision report before updating a target. Preserve local source and resolve changed snapshots through the recorded update or repair path.

Inspect the effective testing configuration and localsetup test-workers --json before changing worker preferences. Keep test resource controls and the aggregate worker budget in force.

Verification

Focused native terminal checks cover activity visibility, layout and input behavior, scoped join instructions, and recovery from transient observer reads while preserving pending items and reporting history gaps.

Focused test-policy checks cover adaptive worker changes, pressure sampling, telemetry fields, and protection of the owned test scope. These checks do not substitute for final exact-candidate validation.

An installed v4.84.6 full-runtime fixture exercised coding readiness and the generated scheduled entrypoint against a synthetic loopback provider. It made three provider requests, read the newly collected granted context, preserved collection during credential outage, and skipped work when disabled. It did not fire a host cron job or use an external provider account; see ls/docs/LSCLI_QUALIFICATION.md.

Before publication, require authoritative exact-candidate validation, release-document checks, and signed source and tag evidence. Download the framework archive with its .sha256 checksum and .cdx.json SBOM sidecars, keep all three together, and verify the archive and native-runtime assets. This record does not assert those final gates have passed.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.

LocalSetup 4.84.6

LocalSetup 4.84.6

LocalSetup 4.84.6 adds a dynamic terminal workspace, private input dialogs, encrypted artifact workflows, and an installed agent runtime with bounded controls and recovery.

Highlights

• Check before scheduling: the cron readiness command reports observable prerequisites, blockers, unchecked requirements, and next actions without running or enabling a task.
• Review guidance before retirement: assess accuracy, review age, historical value, dependent instructions, and the limits of a usage search before changing or retiring a reference.
• Understand recovery confidence: report backup attempts, integrity checks, and successful recovery exercises separately, then prepare an isolated exercise that protects originals.
• Resume a contribution: follow receiving-project rules and keep work, review readiness, submission readiness, and confirmed submission visible in one private progress record.
• Continue settled LSCli history in another workspace: select the source with --source-workspace and the destination with --workspace; the new session retains exact history while requiring fresh authority.
• Explain an unfamiliar tool from source: write an operational reference tied to a reviewed revision, with source citations, coverage, failure and recovery behavior, and visible unresolved questions.
• Manage local previews safely: guide existing project commands through verified loopback startup, reuse, inspection, conflict handling, and stopping only the owned preview.
• Prepare media metadata copies: choose hidden fields to retain, remove, or update, preserve original files and legitimate attribution, and verify each output against the chosen policy.
• Prepare private transcripts and captions: check local processing capability, mark drafts, review words and timing, export sidecar captions, and optionally render a separate captioned video.
• Follow active work in the terminal: dormant sections collapse to one row, active work expands below them, and paging preserves configurable minimum heights. Readable controls and selection redraws support keyboard and mouse use.
• Enter private input through reusable dialogs: text, multiline, password, checkbox, radio and confirmation fields use bounded, operation-bound delivery. Sudo and OpenPGP consumers retain their own authority checks.
• Share encrypted files across carriers: protected metadata, per-file messages, recipient addressing, volume reconstruction and persistent receipts preserve verification independently of storage or transport accounts.
• Read protected files through ordinary tools: configured catalogs resolve encrypted volumes and delta dependencies beneath explicit file and disclosure grants. Models do not select keys or bypass verification.
• Preserve independent origins and concurrent edits: bounded admissions retain each origin’s trust and receipts. Common-base forks remain separate until an explicitly authored merge creates a new immutable version.
• Resume authorized snapshot publication: exact coverage, current assignments and durable job identity govern client, worker and on-demand consolidation. Lost acknowledgements require reconciliation rather than duplicate publication.
• Apply signed configuration at defined boundaries: terminal tuning, container settings and ordered output filters consume validated revisions while preserving running operation identity.
• Run coding tools behind explicit grants: installed workers use the shared file, process and provider brokers. Private credentials stay outside worker environments, and cancellation remains available during stalled output.
• Control and reconcile admitted runs: one authenticated encrypted protocol carries bounded requests over owned streams, SSH relay processes and HTTP adapters. A fresh read-only recovery session can inspect an original run without replaying it.
• Prepare installed heartbeat reviews: explicit profiles, secret references, readiness checks and granted tool-free review support scheduled observation without treating configuration as activation authority.
• Install verified runtime assets: authenticated release sets and hash-locked dependency preparation support offline installation, protected launchers and retained predecessors.
• Bound retained observations and provider context: ordered filter policies, retained event limits and explicit context selection govern what resumed runs see, while preserving signed protocol fields and raw files.
• Qualify terminal startup before dispatch: status-pane startup tolerates a short process-label transition while retaining exact pane, process-birth and command checks. Native CI uses the qualified tmux runner and rejects an unexpected tmux version before the suite.

Compatibility

Existing same-workspace LSCli branches remain compatible: omitting --source-workspace uses --workspace for both sessions. Both workspace directories must already exist. Branching copies settled LSCli checkpoint history, not working-tree files or another client's live conversation; the guided procedure checks client capability before a move.

The new preview, metadata, and transcription packages are instruction-only procedures. They use available project commands and installed tools; they do not bundle a server supervisor, media editor, speech engine, or model. Unsupported tools, formats, clients, or local processing remain explicit limitations rather than automatic remote fallbacks.

Cron readiness is a read-only report with ready, blocked, and unchecked findings. It does not activate cron, execute task commands, verify task-specific credentials or recovery, or infer success from enabled state. A zero command exit status means the report was produced; inspect the reported readiness before activation.

Windows support remains WSL2-only. Native terminal behavior is qualified for supported tmux paths; transport and terminal compatibility do not imply that every remote host is configured.

Existing supported OpenPGP generations and their signed ciphertext remain readable under their historical receipt policy. New container/configuration capabilities use explicit versions; an unknown required capability fails before acceptance. Installing LocalSetup does not generate keys, enroll machines or authorize disclosure.

Encrypted control requires explicit current peer admission, a live owner and a fresh readiness challenge. SSH or HTTP connectivity alone grants no execution authority. The HTTP relay command is not an HTTPS listener; TLS configuration belongs to the caller of the server API.

Recovery grants admit reconciliation only. Saved bindings and journals identify evidence; they cannot restore expired execution authority or justify replaying an uncertain operation.

The earlier SDK paging and Agent Q v2/envelope compatibility changes remain. Corrected 4.x numbering does not restore older source or protocol APIs.

Update

Refresh the selected LocalSetup packages through the supported install or recorded package-refresh workflow. The new contribution workflow is in dev and GitHub-maintenance selections; previews are in dev, and media procedures are in dev and frontend. The normal profile includes dev.

Use the existing documentation-alignment, backup, Git, Node, and Remotion owners to reach the extended procedures. Keep task records and private evidence under the receiving repository's private state owner; review and sharing do not imply publication authority.

Use the documented setup and dependency-preparation entrypoints with independently verified artifact digests. Retain the previous installed runtime and inspect incomplete candidates before recovery.

Select provider URLs and existing credential references explicitly, run readiness checks, and enable schedules only within the granted scope. External provider authentication and actual remote SSH-host setup require environment-specific qualification.

Verification

Focused source checks cover native input delivery, deterministic layout/redraw, independent encrypted origins, delta reconstruction, immutable forks/merges, authenticated control and cancellation under output backpressure.

Focused checks cover status-pane startup transitions, changed process identities, native rollover, controlled pager exit, and managed Bash handshake. These checks do not substitute for the final hosted candidate suite.

Synthetic observer checks cover terminal attachment, family rollover, paging and resizing with the parent terminal type unset or limited. Closed-terminal diagnostics retain bounded child output without requiring a second terminal read.

An isolated installed-runtime fixture verified ordinary CLI and sandboxed SDK reads across encrypted volumes, disclosure denial, hidden workspaces, absent worker credentials and plaintext-cache cleanup. A separate-key installed CLI fixture verified owner-exit reconciliation, rejected execution and unchanged original evidence.

These fixture results do not establish a live external scheduled review, fleet-wide deployment or actual remote SSH-host qualification. Before publication, require final exact-candidate full-suite and documentation evidence, verified source/tag signatures, and complete archive/checksum/SBOM/native-runtime asset checks. Verify localsetup-v4.84.6.tar.gz with its .sha256 checksum and .cdx.json SBOM sidecars.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.

LocalSetup 4.57.0

LocalSetup 4.57.0

LocalSetup 4.57.0 makes managed sudo credentials explicit, keeps uncertain operations safe to reconcile, preserves adapter content during package renames, and improves container installation diagnostics.

Highlights

• Use one explicit sudo credential: managed sudo resolves GENERIC_SUDO_KEY from the controller environment, then EnvMan only when the variable is absent. An explicit empty or invalid environment value remains authoritative, and workload processes do not inherit sudo credential variables.
• Reconcile long operations safely: sudo authentication has a separate bounded timeout. Workload observation timeouts leave the operation running; a durable status_handle retrieves its receipt later. Only a result that proves the workload did not start permits the documented manual fallback; unknown outcomes allow read-only status checks and no replay.
• Preserve adapter content during renames: recorded package selections resolve to current package names. An older alias directory is retired only when its marker, recorded owner, path, and content provenance match and no other owner uses it; edited, custom, malformed, or unrecorded content stays in place and is reported for review.
• Diagnose container installs in their selected context: Doctor identifies unwritable LocalSetup state paths, and the container workflow preserves the configured Docker or Podman engine and privilege mode while checking rootless requirements and persistent state.

Compatibility

Managed sudo no longer selects host- or repository-named credential variables. Configure GENERIC_SUDO_KEY in the controller environment or EnvMan; a present environment value takes precedence even when empty or invalid. Credential values remain private, and authentication does not authorize a command.

Use the returned operation ID and status_handle to check a running workload. Its observation timeout does not cancel the workload. Use a manual fallback only when the result includes sudo.manual_fallback and proves that the workload did not start; timeout, owner loss, policy denial, or unknown requires read-only reconciliation without replay.

Existing skill and workflow selectors remain accepted as aliases. Recorded refresh resolves renamed selections to current package locations. Automatic removal of a legacy adapter directory requires matching ownership and content proof; unrecorded or customized content remains in place and can block refresh for review.

Container diagnosis preserves the selected engine, endpoint, and privilege mode. Rootless Docker and rootless Podman are separate modes that require their own validation; a rootful run does not qualify a rootless setup. Detached app-server live-pane qualification remains unavailable, and fixture results do not qualify that integration or every live client.

Update

Use the supported LocalSetup installer or recorded package-refresh workflow to receive the updated commands and package aliases. Review any legacy_package_alias_shadow diagnosis before changing custom or unrecorded adapter content.

For managed sudo, configure GENERIC_SUDO_KEY in the controller environment or EnvMan. Follow the run receipt's exact manual-fallback instruction only when it explicitly confirms that the workload did not start; otherwise continue with status reconciliation.

For container installations, keep the selected LocalSetup state writable and persistent where needed. Use the existing Docker or Podman engine and privilege mode, and follow the container diagnostics for the specific engine and endpoint.

Verification

The exact source commit passed the full suite: 4,558 passed and 2 skipped. Actual container install and recreation checks passed with rootful Docker, rootless Docker, and rootless Podman in symlink and portable modes, including repeated updates, ownership checks, filesystem verification, and doctor.

Fixture tests cover managed-pane ownership, credential handling, timeouts, durable status, unknown outcomes, and alias preservation. Detached app-server live-pane qualification remains unavailable; these results do not establish support for that live integration.

Before release publication, download localsetup-v4.57.0.tar.gz, localsetup-v4.57.0.tar.gz.sha256, and localsetup-v4.57.0.tar.gz.cdx.json together. Run uv run --locked python ls/tools/localsetup.py --source-root . verify-release /path/to/localsetup-v4.57.0.tar.gz, then verify the exact signed source and tag, provenance, licenses, and an isolated installation.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.

LocalSetup 4.56.0

LocalSetup 4.56.0

LocalSetup 4.56.0 opens a managed operations pane below your agent and automates sudo authentication while preserving command input and handling uncertain outcomes safely.

Highlights

• Run operations below your agent: managed commands use a lower pane without taking focus. Herdr and tmux share the same ownership and safety checks, and sudo authentication preserves the command input.
• Keep compatibility evidence accurate: standalone compatibility records identify the release that shipped each integration while retaining the original standalone candidate evidence.
• Update security-sensitive dependencies: runtime certificate data uses certifi 2026.10.19, and development image tooling uses Pillow 13.0.0.
• Report sudo readiness safely: the managed workflow distinguishes cached readiness, credential-variable outcomes, and required manual authentication. Results expose variable names and statuses, never credential values; readiness does not authorize a privileged command.
• Find skills and workflows by task: all 20 workflows use the compact ls-wf- prefix. The naming review renamed 84 of 113 skills and retained 29 names. Published selectors remain aliases, recorded refresh migrates renamed selections, and authoring guidance starts with natural activation phrases.
• Catch installed-wheel preset regressions: a focused test builds and installs the wheel in isolation, runs the normal personal preset without a source-root override, checks that bootstrap references are present, and confirms private local-context files stay out of the install.

Compatibility

The ordered targets from the verified live v4.53.3 baseline are 4.53.4 for the compatibility-record correction, 4.53.5 for dependency maintenance, 4.54.0 for managed sudo credentials, 4.55.0 for activation-based package naming, and 4.55.1 for installed-wheel regression coverage. This terminal-pane feature targets 4.56.0 under corrected 4.x arithmetic; previously published tags and artifacts remain unchanged.

By default, pick and run use the caller-owned lower pane. Callers that need the former standalone ops* session behavior must explicitly pass --legacy-session; the legacy session path is retained for compatibility.

Published skill and workflow selectors remain accepted as aliases. Recorded package refresh, CLI package paths and package tokens resolve renamed selections to current locations while preserving custom adapter content.

The default managed-pane route selects <exact-host-alias.upper()>_SUDO_KEY for a bound host, or <repository.upper()>_SUDO_KEY locally, then GENERIC_SUDO_KEY when the first candidate is absent or invalid. Trying a second candidate after a rejected password requires an explicitly qualified single-password conversation; uncertain authentication stops fallback. The legacy route retains hostname-based lookup. Results expose variable names and statuses, never credential values; authentication does not expand command authorization.

Runtime certifi changes to 2026.10.19 and development Pillow changes to 13.0.0. Re-sync the supported environment to receive the pinned versions.

Qualification of detached app-server live panes is unavailable. tmux and PTY fixture results cover adapter behavior only and do not qualify detached app-server panes or every live client integration.

Local installed-wheel and source-distribution checks do not qualify optional live services or establish that every platform has been exercised.

Update

Use the supported LocalSetup install or recorded package-refresh workflow with the updated source. Existing selected package names continue to resolve; refresh installs the current canonical package directories and preserves custom adapter content.

Re-sync the project environment through the supported dependency workflow to install the updated certifi and Pillow pins.

For default managed sudo use, run pick and run from a verified caller context so LocalSetup can bind its owned lower pane. Use --legacy-session only when explicitly retaining the standalone ops* session lifecycle.

Verification

Focused authentication, alias and refresh, package-path, resource provenance, branding, installed-wheel and source-distribution checks passed locally. The wheel case applied the normal personal preset without a source-root override, verified all eight bootstrap reference documents and confirmed private local-context files were excluded.

The terminal changes passed focused authentication, pane lifecycle, workflow, release-preflight and PTY checks after review fixes. Release acceptance still requires successful hosted validation of the exact final candidate.

Caller-pane, shared Herdr/tmux, sudo, unknown-input and PTY fixtures exercise the adapters and operation safeguards. They are fixture evidence only; detached app-server live pane qualification remains unavailable.

Release acceptance requires the exact final signed candidate to pass required hosted validation jobs. Before publication, verify the required-key signed commit and tag, downloaded archive and its .sha256 and .cdx.json sidecars, build provenance and an isolated installation.

Optional live capabilities remain unqualified; release inclusion and local fixture results are not evidence of live-service support.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.

LocalSetup 4.53.3

LocalSetup 4.53.3

LocalSetup 4.53.3 separates reviewed Herdr source evidence from stable release pins and keeps manually dispatched GitHub validation complete.

Highlights

• Review source changes without implying an upgrade: the Herdr watcher records a separately reviewed source revision and reports its exact immutable comparison links. Existing release and bundled-schema pins stay unchanged.
• Keep watching the API owner: source tracking includes the operation-definition module introduced by the upstream schema refactor. The operating guide now accurately describes the compact GitHub issue handoff used for confirmed drift.
• Keep release validation complete: manually dispatched checks retain full Git history and schedule required Python shards after optional checks are skipped. Older release anchors stay reachable, and missing test results cannot satisfy release validation.

Compatibility

This maintenance patch preserves Herdr v0.9.5 release, artifact and bundled-schema pins. It does not install, upgrade, restart or qualify a running Herdr client or server.

Existing manifests without a separate watched-source revision continue to use the release source revision. An explicitly malformed watched-source revision produces unknown baseline evidence and no fabricated comparison URL; confirmed file drift remains visible.

The reviewed upstream refactor retains the wire operations used by the existing LocalSetup adapter. Source review is not a claim that every newer upstream capability or live server is supported.

Published v4.53.1 is the verified baseline. The Herdr provenance maintenance slice advances to 4.53.2, and the validation-history maintenance slice advances to 4.53.3. Release preparation, fixups and generated/version synchronization add no increment. Historical tags, releases and artifacts are preserved.

Update

Use the existing installation or package-refresh workflow for selected packages. No dependency or configuration migration is required.

Start with the Herdr master skill and use its provenance specialist for explicit source checks. New upstream evidence remains a review handoff, never authority for a host upgrade.

Verification

Run focused provenance, watcher and QC regressions and the standard source/catalog/document checks. Validate the final exact signed candidate with the required hosted jobs, including all eight Python shards.

Before publication, verify the required-key signed commit and tag, the actual downloaded archive with its .sha256 checksum and .cdx.json SBOM sidecars, build provenance, draft release prose and an isolated installation. Keep source evidence distinct from live service qualification.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.

LocalSetup 4.53.1

LocalSetup 4.53.1

LocalSetup 4.53.1 gives AI coding agents a shared standard for how to work. The refreshed homepage explains how to keep development practices and useful project knowledge in reviewable files, reuse them across supported tools, and get started with less repeated setup.

Highlights

• Put your standards first: the homepage introduces LocalSetup as an open-source operating framework for development standards, reusable knowledge, and consistent workflows. A practical project example shows how to use it. The existing hero artwork stays in place.
• Keep the voice consistent: the branding guide and repository instructions now call for plain language, concrete benefits, and clear explanations. Persistence means files that agents can read and review; each client still follows its own loading rules and permissions.
• See how the tools fit together: the homepage links to Envman and bbackup (BestBackup), explains their roles in the CruxExperts ecosystem, and distinguishes optional Envman integration from an independent backup tool.

Compatibility

This patch changes documentation and branding guidance. Commands, installation paths, supported clients, package selection, runtime dependencies, and public interfaces are unchanged.

Reusable standards remain ordinary reviewable files. Their use depends on client loading, selected packages, permissions, and the instructions available to the agent; this release does not add permanent memory inside models or promise identical behavior across clients.

Envman integration remains optional. BestBackup is a complementary independent tool, not a bundled requirement.

Published v4.53.0 is the verified baseline. The branding source slice advances it once to 4.53.1. Release preparation, anchor maintenance, version synchronization, and generated documentation add no further increment. Historical release records, tags, and assets remain unchanged.

Update

Read the homepage for the new product introduction and the branding guide for the writing guidance.

Use the existing quickstart to install or refresh selected packages. No configuration migration or dependency update is required for this patch.

Verification

Validate the final signed candidate through the required GitHub checks, including all eight Python shards, generated documentation and version synchronization, shell smoke and framework audit, and deterministic quality checks. Review the rendered README and verify its local links and preserved hero.

Before publication, verify the signed tag and exact source commit, download the framework archive with its .sha256 checksum and .cdx.json SBOM sidecars, and run verify-release against that commit. Validate the SDK payload in the wheel and source distribution and check their licenses and file hashes.

Exercise an isolated installation from the actual release artifacts. These checks cover this documentation patch and the packaged files; they do not establish live model-provider behavior or remote service deployment.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.

LocalSetup 4.53.0

LocalSetup 4.53.0

LocalSetup 4.53.0 helps keep reusable guidance current with daily upstream checks and clear, evidence-backed refresh requests. It also makes the homepage easier to understand and brings guided GitHub upkeep, reusable setup handoffs, and more reliable remote work.

Highlights

• Know when guidance needs attention: a daily check compares the registered Herdr sources with fresh upstream evidence. Confirmed changes become compact GitHub issues with source links and a clear handoff; unchanged findings do not create repeated requests.
• Understand the product faster: the refreshed homepage explains what LocalSetup does, how it helps with everyday tasks, and how to get started, using plain language.
• Keep your GitHub project easier to maintain: choose optional guidance for reviewing changes, reporting problems, and checking dependencies while keeping the tools and rules you already use.
• Turn a successful setup into reusable help: save a completed setup as a skill with its source and helper files, so it is easier to repeat or hand over.
• Manage remote work with clearer safeguards: the Herdr tools help organize terminal work, track completed commands, and handle remote setup, configuration, and restarts. They check ownership and active work before making changes.
• Keep unfinished checks from getting lost: maintenance checks retain current observations between runs. Missing history pauses actions until it is explicitly recovered, helping avoid repeated requests.
• Refresh the Python dependencies: update two libraries and keep their checked installation files aligned.

Compatibility

The maintenance pack is opt-in and is not added to the normal selection profile. Installing it alone does not rewrite target .github files, publish a pull request, configure CodeQL, enable Copilot, or mutate repository and account settings.

Direct patrol invocations must supply valid packet dispositions or explicitly initialize them in deterministic mode. Missing or corrupt history fails closed; uncertain provider attempts are not automatically replayed. The response schema is retained, but patrol output is factual and artifact-only.

A provider alias, a concrete model name, or a token cap does not prove low cost or remaining allowance. Concrete economical backing, protected runtime qualification, and authorized usage must be verified before model-assisted cloud activation. External upstream source freshness is not established merely by local hash changes.

The Herdr skills join the normal ops pack and use the reviewed Herdr v0.9.5 source and API baseline. LocalSetup installation does not install or upgrade a native Herdr binary by itself. Protected panes, remote authentication, shared-session interruption, and target ownership remain governed by the active repository and session authority.

Standalone skill capture remains opt-in. Capturing source does not authorize service deployment, global policy changes, contribution, or publication.

The unpublished logical slices advance in ancestry order: GitHub maintenance to 4.50.0, standalone capture to 4.51.0, Herdr operations to 4.52.0, dependency maintenance to 4.52.1, the homepage refresh to 4.52.2, and daily provenance handoffs to 4.53.0. Patrol fixups stay with their maintenance slice; generated receipts and documentation preparation add no increment. Published tags and assets remain unchanged.

The homepage refresh changes presentation and navigation. Existing commands, install paths, supported tools, and package selection behavior are preserved.

The repository schedules Provenance Refresh for 6 a.m. America/Chicago each day and retains manual dispatch. Initial upstream coverage is Herdr only. Unavailable or inconclusive checks are reported as unknown, not as confirmed refresh requests. The job does not update sources, install or upgrade software, invoke models, or change QC Patrol.

The scheduled check belongs to the LocalSetup repository. Installing skills does not add a daily job to another project; the repository-only watcher and its workflow stay outside the framework download.

Update

Follow the GitHub maintenance adoption recipe and inspect the target's existing owners before adapting assets. Resolve repository-specific inputs and review the exact remote operation plan before applying settings.

Use the multi-platform install guide, including --sync-env when provisioning an explicit source directory or extracted archive. Preserve custom adapter content. Review packet-history initialization before enabling the existing hosted patrol's packet mode.

Start Herdr work with ls-herdr and the Herdr operations guide. Review its pinned source and the selected native endpoint before operating panes or remote sessions.

Review a provenance issue with the linked immutable upstream evidence and the existing Herdr provenance maintenance owner. An issue is a request to assess a bounded source refresh; it does not authorize host upgrades or automatic implementation.

Verification

Focused checks cover saved maintenance observations, recovery, dependency installation records, and the Herdr tools. Remote-operation tests exercise command validation, existing executable discovery, and uncertain registration recovery. Isolated native checks cover terminal ownership and actual command exit results. No live provider call or remote service deployment is established by these fixtures.

Before integration, require successful hosted validation of the exact signed final candidate. Separately verify CodeQL analysis, native Copilot entitlement and effective settings, actual default-branch bug intake, and the selected economical patrol model and runtime. Local source validation does not establish remote pilot activation.

Before release publication, verify the signed tag, exact source binding, downloaded archive, .sha256 checksum, .cdx.json SBOM sidecars, and cryptographic provenance. Exercise an isolated installation from the actual downloaded artifact before publishing the verified draft.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.

LocalSetup 4.49.2

LocalSetup 4.49.2

LocalSetup 4.49.2 integrates two reviewed dependency-maintenance slices, including the follow-on pull request discovered during validation. The framework runtime and independently installed storage skills retain synchronized, hash-pinned dependency exports and integrity records.

Highlights

• Refresh the selected framework runtime: the final locked resolution uses OpenAI 3.31.0, Pydantic 2.14.1, pydantic-core 2.50.1, genai-prices 0.1.12, and logfire-api 5.2.0. The declared framework runtime dependency ranges and vendored SDK source remain unchanged.
• Keep optional storage runtimes aligned: the S3 group selects Boto3 1.43.113 and botocore 1.43.114. Both storage skills receive the same regenerated hash-pinned requirements; the reviewed export guard follows the accepted version, while the current lock format is preserved.
• Keep dependency maintenance evidence aligned: the SDK ownership guide distinguishes historical adoption evidence from dated target checks and requires exports and the integrity receipt alongside the source lock. The obsolete branding exception for the removed version-pin test is retired without weakening validation.

Compatibility

The CLI, adapter-preservation, OpenPGP, verified-file-reader, and vendored SDK interfaces are unchanged. Ordinary wheel dependency ranges remain unchanged; unconstrained installers can select versions other than this repository's locked resolution.

Exact-version checks against OSV, GitHub Advisory Database, and registry evidence on 2026-10-17 found no reported vulnerabilities for the selected update targets. These dated checks are not a blanket safety guarantee or all-platform qualification.

Sequential release arithmetic counts the first accepted maintenance slice as 4.49.1 and the follow-on slice as 4.49.2. The combined release is 4.49.2; the intermediate 4.49.1 candidate was not tagged or published. Documentation corrections and generated receipts add no version increment. Previously published tags and assets remain unchanged.

Update

For an explicit source directory or extracted release archive, use --sync-env to provision its locked Python runtime. Follow the multi-platform install guide and preserve custom adapter content.

Maintain the framework SDK exports and receipt through the SDK ownership guide. Optional storage skills have their own shipped requirements; a framework lockfile update alone does not refresh those independent runtimes.

Verification

Before publication, require successful hosted validation of the exact final candidate, including every Python shard, automated smoke checks, framework audit, generated-document checks, and deterministic review. Earlier candidate success does not establish the final candidate's readiness.

Exercise the owning provider client over local HTTP with a synthetic credential and a Pydantic-validated response. Exercise the updated Boto3 and botocore client with a signed local S3 request and parsed response. These checks do not qualify a live provider or storage account.

Verify the signed tag, downloaded archive, .sha256 checksum and .cdx.json SBOM sidecars, exact source binding, and cryptographic provenance. Exercise an isolated installation from the actual downloaded artifact before publishing the verified draft.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.

LocalSetup 4.49.0

LocalSetup 4.49.0

LocalSetup 4.49.0 adds an owner-scoped provenance refresh workflow and a version-free space-themed visual identity. Scheduled automation proposes generated-document updates for local review and signing without changing branches, releases, or installed targets. Existing issue fixes remain available through the same supported interfaces.

Highlights

• Refresh mutable provenance through its owner: a first-class workflow separates current generated documentation from immutable release evidence, dependency snapshots, and installed-target state.
• Review scheduled documentation proposals: weekly, manual, and main-branch runs use canonical generators and emit a source-commit-bound, SHA-256-identified patch when generated documentation drifts. The job has read-only repository permissions and does not create commits or pull requests.
• Keep generated receipts distinct from source changes: provenance and release planning recognize managed count updates only in their owning document sections; unrelated prose remains an authored source change.
• Use consistent, version-free artwork: refreshed light and dark README banners and diagrams, a square mark, and a social-preview asset share the approved space-and-terminal identity. Generated asset inventory, rights metadata, and accessibility text follow the same source assets.

Compatibility

The existing CLI, OpenPGP, file-reader, adapter-preservation, and archive-install interfaces are unchanged by these two feature slices. This release does not restore the historical SDK paging or Agent Q envelope compatibility breaks documented by the corrected 4.x line.

The scheduled refresh changes no installed targets, dependency locks, release records, signed tags, published assets, SBOMs, attestations, or exact-commit CI evidence. Its review patch expires after 30 days; applying and publishing it remain separate authorized actions.

Artwork intentionally contains no release number. The historical logo remains preserved. The bundled social-preview image does not by itself change GitHub repository settings or deploy a separate website.

Sequential release arithmetic counts continuous provenance refresh as 4.48.0 and the subsequent visual-identity feature as 4.49.0. Generated-document receipts do not add a version increment. No dependency update is included in this release.

Update

For an explicit source directory or extracted release archive, use --sync-env to provision the locked Python runtime. Follow the multi-platform install guide, preserve custom adapter content, and review recovery diagnostics before retrying a failed mutation.

Use the provenance refresh workflow to classify drift before applying a generated-only patch. Verify the exact source revision, patch digest, and changed-path scope; commit through the required local signing identity.

See the branding guide for artwork ownership and regeneration, and the versioning guide for corrected 4.x arithmetic and historical tag treatment.

Verification

Before publication, require exact-candidate hosted validation, the complete Python test suite through that validation, the automated smoke suite, and the signed release tag. Verify the downloaded archive, .sha256 and .cdx.json sidecars, source/tag binding, and cryptographic provenance; focused checks alone do not establish final release readiness.

Qualify the downloaded archive with an isolated all-preset portable install and inspect installed capability discovery without model calls or secret access. Preserve historical release assets rather than attempting to repair old archives in place.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.

LocalSetup 4.47.17

LocalSetup 4.47.17

LocalSetup 4.47.17 fixes package-lock error reporting, extends journaled rollback recovery to repository-only installations, and makes package-content comparisons unambiguous while preserving legacy receipt fields. This release also refreshes reviewed Python dependencies, storage exports, and pinned GitHub Actions.

Highlights

• Preserve operation errors: package-lock contention handling no longer masks filesystem failures raised inside the protected operation or during lock metadata writes.
• Recover ordinary repository rollback: the existing transaction now covers repository-only removal, preserves unmanaged library entries and adapter neighbors, and retains recovery evidence if restoration fails.
• Distinguish different package trees: framed content digests separate file paths and contents; additive provenance evidence retains historical digest fields for older readers.
• Refresh reviewed dependencies: synchronize the project lock, packaged SDK runtime export and receipt, and both optional storage SDK exports.
• Keep workflow pins aligned: update setup-uv and upload-artifact full-commit pins together with the exact-pin regression check; the selected uv runtime stays unchanged.

Compatibility

Existing marker package_digest/artifact_sha256 and top-level registry digest values retain their historical calculation and path ordering. New source-backed materialization adds package_digest_framed evidence using sha256-framed-files-v1 in existing provenance snapshots; older readers can continue using the legacy fields.

Legacy-only provenance is reported as legacy-limited. Unknown or malformed framed records produce unsupported diagnostics without a silent fallback. Reports do not rewrite baselines; source-backed install/update/repair can add framed evidence. Renaming legacy content during migration does not establish that baseline.

Rollback recovery handles in-process failures and journals managed state without replacing shared adapter parents. It does not guarantee crash recovery or successful restoration when storage refuses writes. Recovery failures retain journal/backup evidence for reconciliation before retry.

The reviewed lock changes are boto3 1.43.111, botocore 1.43.112, genai-prices 0.1.10, griffelib 2.3.2, openai 3.28.0, opentelemetry-api 1.45.1, pydantic 2.14.0, and pydantic-core 2.50.0.

GitHub Actions use setup-uv 10.3.0 and upload-artifact 7.0.2 at reviewed full commit hashes. The workflow-selected uv runtime remains 0.11.21. No new provider or host sandbox qualification is claimed.

Update

For an explicit source directory or extracted release archive, use --sync-env to provision the locked Python runtime. Follow the multi-platform install guide for adapter selection and bootstrap behavior; preserve custom adapter content and review recovery diagnostics before retrying a failed mutation.

Optional storage consumers should use each skill's regenerated requirements-s3-sdk.txt in a caller-owned environment; the tools do not install dependencies automatically. See optional storage skills.

Use the versioning guide for corrected 4.x release policy and historical tag treatment.

Verification

Before publication, require the complete Python test suite, documented automated smoke suite, required GitHub checks for the exact candidate, and the signed release tag. Verify downloaded archive bytes, .sha256 and .cdx.json sidecars, source/tag binding and cryptographic provenance; focused checks alone do not establish final release readiness.

Download the archive with its .sha256 checksum and .cdx.json SBOM sidecars, then follow the release guide.