git:20260828.e2f257d to git:20260909.779467e

+ ## Delegating to an external CLI

+ Some work is cheaper on another provider's compute (bulk scaffolding, exhaustive

+ test generation, long-context reads that distil to a digest). None of that tooling

+ ships with AOS — it depends on CLIs and Claude Code plugins the user installed

+ separately, so check what is actually present instead of assuming.

+

+ **Prefer a plugin's delegation subagent over shelling out to its CLI.** Where one

+ is installed it already handles the wrapper flags, cost discipline, and digest

+ contract: `antigravity:antigravity-delegate` (agy), `opencode:opencode-rescue`,

+ `codex:codex-rescue`. These are Claude Code plugins — on another harness, or a

+ machine without them, calling the CLI directly is the only path.

+

+ **Delegate only above the break-even.** A small, self-contained, or

+ judgement-heavy task costs more to hand off and verify than to just do. Keep the

+ digest, not the raw output.

+

+ **Verify the result, never the status field.** A failing delegation has been

+ observed returning `{"status": "SUCCESS", "usage": {"total": 0}}` with an empty

+ body — success by every field except the one that matters. Check the returned

+ content, and treat an empty body as failure regardless of status. Never report a

+ delegated step as done on the strength of its own self-report.

+

+

+ ## Release Automation — Conventional Commits required

+ `release-please` (`.github/workflows/release-please.yml`) tracks the last-released version in `.release-please-manifest.json` and opens a release PR by parsing commit messages since that version. It only recognizes Conventional Commits prefixes (`feat:`, `fix:`, `chore:`, `docs:`, `refactor:`, etc., with `!` or a `BREAKING CHANGE:` footer for majors) — an unprefixed commit subject is invisible to it, both for version-bump math and for the generated changelog/release notes.

+ - Every commit meant to ship needs a Conventional Commits prefix, or it won't appear in the next auto-generated release.

+ - Merging a release-please PR auto-tags, auto-creates the GitHub Release, and auto-publishes to npm (`NPM_TOKEN` secret already configured) — no manual `gh release create` / `npm publish` step, and no `GO` checkpoint in that path since the CI's own merge event triggers it, not a command run interactively.

+ - Do not bump `package.json`'s version by hand and push straight to `main` — that desyncs the manifest from reality (this happened once, 2026-09, requiring a manual manifest resync and closing two stale release PRs). Let release-please own the version bump via its PR.

+

+ ### `feat:` vs `fix:`/`chore:`/`docs:` — the version-bump lever

+ `feat:` always triggers a **minor** bump (`x.Y.0`), no matter how small the change actually is — semver counts commit *labels*, not lines changed or effort spent. Minor-version growth is controlled entirely by how strictly `feat:` is reserved, so default to the narrower type unless the change genuinely earns `feat:`:

+ - **`feat:`** — a new user-facing capability someone would want to see in a changelog: a new skill, agent, CLI command, or config option. Reserve it for this.

+ - **`fix:`** — corrects behavior that was actually broken.

+ - **`chore:`** — internal maintenance: repo hygiene, config/gitignore changes, dependency bumps, non-user-facing wiring — even when it touches many files or adds new ones.

+ - **`docs:`** — documentation-only changes; excluded from the changelog entirely.

+ - **`refactor:`** — restructuring with no behavior change.

+ When a piece of work has both a user-facing addition and pure housekeeping (e.g. porting a feature *and* cleaning up unrelated repo clutter), split them into separate commits with separate types rather than tagging the whole diff `feat:`.