harn-bump-fleet

Local Harn-version bump orchestrator. fleet.toml is the typed owner of fleet membership and reusable-workflow policy. The orchestrator resolves those declared repositories under ~/projects, rejects a missing checkout, wrong remote, or missing dispatch adapter, and drives every harn_bump = true repository to the latest published Harn release with auto-merge enabled in parallel, idempotently, with a self-contained audit trail.

This is a Harn-native script (bump_fleet.harn): no Python glue, no shell wrapper. It exists partly as a useful local tool, partly as a proof that Harn the language is viable beyond LLM orchestration.

The companion sync_agent_guidance.harn workflow owns one small marked block inside each fleet repository's AGENTS.md and projects CLAUDE.md directly to that canonical file. It preserves every repository-specific rule outside the markers.

scripts/with_env.sh harn run --no-sandbox sync_agent_guidance.harn -- --check
scripts/with_env.sh harn run --no-sandbox sync_agent_guidance.harn -- --dry-run
scripts/with_env.sh harn run --no-sandbox sync_agent_guidance.harn -- --apply
scripts/with_env.sh harn run --no-sandbox sync_agent_guidance.harn -- --only harn-cloud

Repository scope

lib/first_party_actions.harn owns this repository's reviewed Harn Action revision. After reviewing the Action sources and their bootstrap dependencies, update that contract and regenerate the local workflow references:

.harn/bin/harn run --no-sandbox sync_first_party_actions.harn -- --apply
.harn/bin/harn run --no-sandbox sync_first_party_actions.harn -- --check

The check measures every workflow and requires both registered Actions. Runtime versions and reusable workflow policy remain separately owned by fleet.toml.

This repo is public for transparency and cheap GitHub Actions coverage, but the tools are written for my own Burin Labs/Harn release operations. Keep audits, logs, prompts, and examples suitable for a public repo: do not commit private-repo details, customer data, secrets, or anything too inside baseball from private Burin repositories. Generated run artifacts are intentionally ignored under .harn-runs/ and .harn/.

Harn sandboxes harn run by default. These local ops harnesses inspect ~/projects, local Git state, and authenticated GitHub connector state, so use scripts/with_env.sh harn run --no-sandbox for real local release and bump runs. The wrapper verifies the repo-pinned runtime before Harn parses the program and loads the configured provider environment. Mock release runs can stay sandboxed.

Contributing

Read CONTRIBUTING.md before you open a pull request. It covers the pinned runtime setup, the two checks to run, the changelog fragment, and the [Area] Sentence case description title convention. AGENTS.md names which module owns which release stage.

Documentation

Start with the job you need to do.

Do a thing

• Bump the fleet. Every orchestrator command, from a discover-only rehearsal to a live parallel bump.
• Release Harn. Open Harn's workflow-owned release and observe its certified public files.
• Free a wedged release. Recover a stalled version, resume a certified candidate, apply a post-publish fixup.
• Reserve the release queue. Take and hold the single release slot.
• Sign blocked bot pull requests. Get an unsigned dependency bot head past a signature-required branch.
• Review a run in chat. Open an interactive loop over a finished run.

Look something up

• Shipping writer contract. Startup capture, effect checks and refusal behavior for shipping adapters.
• Local setup. Configuration files, credential precedence, planner tuning, the macOS launcher, and the tools a run expects to find.
• Continuous integration. What this repository's own CI runs, and what each job proves.
• Consumer refresh finalization. The optional contract for regenerating artifacts after runtime migrations.
• Dependabot fleet template. The projected dependency configuration every fleet repository receives.

Understand the design

• How a bump run works. The order a run executes in, why a rerun is safe, and what it leaves behind.
• Candidate record. How one signed certification identity selects the exact archives used after certification.
• Update benchmark. How repair performance is measured.