docs(plugin): retire version gates below the 0.80.0 floor

CLAUDE.md

@@ -197,7 +197,7 @@ The one exception is a **beta/pre-release** (below): there the bump deliberately
 rides the feature branch, because the pre-release tag and GitHub Release are cut
 from that branch -- the branch temporarily *is* the release PR.
 
-### Beta / pre-release versions (since 0.43.3)
+### Beta / pre-release versions
 
 Beta and release-candidate versions follow **PEP 440**: `0.44.0b1`, `0.44.0rc1`, ... -- **not** the SemVer `-beta.1` form (hatchling + uv require PEP 440 syntax in `pyproject.toml`). Three independent gates keep stable users safe from accidentally landing on a beta:
 

CONTRIBUTING.md

@@ -677,6 +677,43 @@ silent-drift risks summarized in the
    that race eventually, because a release is exactly when parallel branches
    converge. Already-numeric headings are *not* flagged -- a resolved tag never
    changes again, so its slug is stable.
+4b. **Retire gates below the floor** (periodic, not every release):
+   ```bash
+   make gate-floor-report                     # what is below the current floor
+   ```
+   A version gate earns its place only while some live install predates it.
+   kbagent self-updates on startup, so that population shrinks to roughly
+   nothing: pip/uv installs upgrade themselves, and only a standalone binary
+   (brew/choco/apt/dnf, which self-update is disabled for), an explicit
+   `KBAGENT_AUTO_UPDATE=false`, a dev tree, or a pip install stranded below
+   0.62.0 by the #424 rename can sit on an old version. Meanwhile the stale
+   gate keeps making the agent refuse a command the user actually has -- which
+   this file already calls strictly worse than no gate.
+
+   The two failure modes are asymmetric, and that is the whole argument for
+   pruning: a **kept-too-long** gate fails silently and permanently (the user
+   never learns the command exists), while a **removed-too-early** gate fails
+   loudly and self-correctingly (`No such command 'x'`, and `kbagent context` /
+   `--help` on the user's own install are authoritative anyway).
+
+   **The floor is 0.80.0** as of the 0.91.0 cleanup. Retiring a gate means
+   deleting the *tag*, never the content -- the guidance under it is almost
+   always still true, and 0.91.0's pass kept every word while removing 223 tags.
+
+   Four things are deliberately out of scope:
+
+   - `changelog.py` -- the historical record; the version IS the content.
+   - `src/**/*.py` except `commands/context.py` -- developer comments
+     (`# DEPRECATED (since 0.43.4)`) are provenance, and no agent reads them.
+   - `X+` written inside a sentence -- often load-bearing prose
+     (`created by < 0.66.1 stay dormant until re-run on 0.66.1+`).
+   - **Safety gates, at any age.** Keep the tag wherever not knowing the
+     version causes silent data loss or a false assurance rather than an error
+     message -- e.g. `sync pull --force` (pre-0.53.0 it silently stranded local
+     edits), the `sync status` / `doctor` plaintext-secret audit (a false
+     all-clear on a leaked credential), the manage-token default-deny, and the
+     `--deny-writes` firewall.
+
 5. **Run `make version-sync`** -- propagates the new version to `plugins/kbagent/.claude-plugin/plugin.json`. The pre-commit hook does this automatically on `git commit`, but running it explicitly lets you eyeball the diff.
 6. **Run `make skill-gen`** -- regenerates the decision table in `SKILL.md`. Idempotent if no commands changed since the previous release.
 7. **Add a curated What's-new entry** to `web/frontend/src/whatsnew.ts` when the release ships anything UI-visible -- a `WhatsNewRelease` element keyed by the **exact** new version, newest first. This is the reel the web UI shows once per version; it is deliberately *not* derived from `changelog.py` (see `docs/web-server.md` > "What's-new popup"). Skipping it does not error anywhere: `whatsNewFor` falls back to the previous release's reel, which returning users have already dismissed -- so the release's UI work ships **dark**. A release with no UI-visible changes correctly adds nothing. Only the release PR can write this entry (a feature PR cannot know the version), which is why it lives in this checklist and not the per-command one.

Makefile

@@ -1,6 +1,6 @@
 .DEFAULT_GOAL := help
 
-.PHONY: help install install-server sync test test-unit test-integration test-e2e test-e2e-local test-e2e-invite test-e2e-feature test-e2e-stream test-e2e-auth test-file test-cov lint lint-fix format format-check typecheck typecheck-warn skill-check skill-gen version-sync version-check version-gate-check vnext-check vnext-resolve release-scope-check changelog changelog-check check-error-codes check-sentinel-guards loc-check loc-report loc-baseline command-sync-check gen-command-reference endpoints-gen endpoints-check check clean hooks web-install web-dev-backend web-dev-frontend web-build web-clean
+.PHONY: help install install-server sync test test-unit test-integration test-e2e test-e2e-local test-e2e-invite test-e2e-feature test-e2e-stream test-e2e-auth test-file test-cov lint lint-fix format format-check typecheck typecheck-warn skill-check skill-gen version-sync version-check version-gate-check vnext-check vnext-resolve gate-floor-report release-scope-check changelog changelog-check check-error-codes check-sentinel-guards loc-check loc-report loc-baseline command-sync-check gen-command-reference endpoints-gen endpoints-check check clean hooks web-install web-dev-backend web-dev-frontend web-build web-clean
 
 help: ## Show this help message
 	@grep -E '^[a-zA-Z0-9_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "  \033[36m%-18s\033[0m %s\n", $$1, $$2}'
@@ -128,6 +128,9 @@ vnext-resolve: ## Rewrite every live vNEXT gate to pyproject's version (RELEASE
 	@test -n "$(VERSION)" || { echo "usage: make vnext-resolve VERSION=X.Y.Z"; exit 2; }
 	uv run python scripts/check_version_gates.py --resolve $(VERSION)
 
+gate-floor-report: ## List version gates below the retirement floor (default 0.80.0)
+	uv run python scripts/check_version_gates.py --list-below $(or $(FLOOR),0.80.0)
+
 release-scope-check: ## Prove the changelog entry covers every PR the tag will contain
 	uv run python scripts/check_release_scope.py $(SCOPE_ARGS)
 

docs/TUTORIAL.md

@@ -139,7 +139,7 @@ Flags worth knowing:
 The command is **idempotent**: running it again skips projects that
 are already registered. Safe to re-run after adding new project IDs.
 
-**Security note (since v0.29.0)**: `KBC_MANAGE_API_TOKEN` is **ignored
+**Security note**: `KBC_MANAGE_API_TOKEN` is **ignored
 by default** -- the env var is read only when the top-level
 `--allow-env-manage-token` flag is passed. Without the flag, kbagent
 prompts on stdin (hidden input). kbagent never accepts the token as a
@@ -810,7 +810,7 @@ footguns the platform does not surface as errors:
    platform transitions `created -> stopped -> starting -> running`, so a
    naive poll that exits on `stopped` reports a phantom failure.
 
-`kbagent data-app` (since 0.27.0) encodes all four in the service layer,
+`kbagent data-app` encodes all four in the service layer,
 so the `--json` output you see at the CLI is what would have happened if
 you had done everything right at the raw HTTP level. The eight
 subcommands -- `list`, `detail`, `create`, `deploy`, `start`, `stop`,
@@ -923,7 +923,7 @@ kbagent --json data-app create \
 deploy. To retrieve it:
 
 ```bash
-# Manage API token: interactive prompt by default (since v0.29.0). For CI,
+# Manage API token: interactive prompt by default. For CI,
 # add `--allow-env-manage-token` and set KBC_MANAGE_API_TOKEN in env.
 kbagent --json data-app password \
   --project prod --app-id 12345678 \

plugins/kbagent/skills/kbagent/references/agent-tasks-cli-workflow.md

@@ -55,7 +55,7 @@ Every task carries an `action` envelope with `type` + `params`:
 `cli` accepts `claude`, `codex`, or `gemini`. The chosen CLI must be on
 the server's `PATH` when the task fires (cron or `agent run`).
 
-**`extra_args` are ignored unless the serve operator opts in (since v0.60.2).**
+**`extra_args` are ignored unless the serve operator opts in.**
 They are passed verbatim to the AI CLI and can disable its safety rails, so
 `kbagent serve` drops them with a warning unless it was started with a truthy
 `KBAGENT_ALLOW_AI_EXTRA_ARGS` (e.g. `KBAGENT_ALLOW_AI_EXTRA_ARGS=1`). The
@@ -98,7 +98,7 @@ kbagent agent list
 kbagent agent show <task_id>
 ```
 
-> **ID forms (since v0.44.0):** every subcommand that takes a task/run ID
+> **ID forms:** every subcommand that takes a task/run ID
 > accepts it positionally (`agent show <task_id>`) or via a named flag
 > (`--id` / `--task-id`, plus `--run-id` for `run-detail` / `run-events`) --
 > matching the rest of the CLI (`--job-id`, `--config-id`, ...). Examples

plugins/kbagent/skills/kbagent/references/agent-tasks-rest-workflow.md

@@ -66,7 +66,7 @@ Every task has an `action` block with `type` + `params`:
 `cli` accepts `claude`, `codex`, or `gemini`. The chosen CLI must be on
 the server's `PATH`.
 
-**`extra_args` are ignored unless the serve operator opts in (since v0.60.2).**
+**`extra_args` are ignored unless the serve operator opts in.**
 They are forwarded verbatim to the AI CLI and can disable its safety rails, so
 `kbagent serve` drops them with a warning unless it was started with a truthy
 `KBAGENT_ALLOW_AI_EXTRA_ARGS`. The `["--print"]` above takes effect only when