docs(agents): autonomy-first guardrails and Bugbot policy (#8)

Updates `AGENTS.md` and `.cursor/BUGBOT.md` with shared policy:

- **Autonomous work first** — default to finishing useful work without
unnecessary gates (within safety rules).
- **Multi-repo work encouraged** — one PR per repo; link sibling PRs.
- **Fresh tip** — `git fetch` + prefer `merge --ff-only`; `git pull
--rebase` ideal but **not required**.
- **No automatic force-push** — agents stop and give humans explicit
**reasoning**, **effects**, and **why**; approval required per
repo/branch.
- **Worktrees** — optional operator choice (not mandated in docs).

Does **not** include winget-pkgs (excluded by policy).

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Low risk documentation-only change adding guidance for
agents/reviewers; no runtime, security, or data-handling code is
modified.
> 
> **Overview**
> Adds new documentation to standardize autonomy-first workflows for
both agents and reviewers.
> 
> Introduces `AGENTS.md` with guardrails covering multi-repo PR
coordination, preferred branch update approach (favor fast-forward
merges; rebase optional), explicit prohibition on automatic force-push
without human approval, and expectations around keeping PRs focused and
verified. Adds `.cursor/BUGBOT.md` to guide reviewers to avoid blocking
autonomy, recognize intentional cross-repo splits, and require strong
justification before suggesting history rewrites.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
2a7ac66. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Author: bschellenberger2600

.cursor/BUGBOT.md

@@ -0,0 +1,6 @@
+# Bugbot review guidance
+## Autonomy, cross-repo, and history (reviewers)
+
+- **Autonomy first:** Prefer review feedback that keeps agents unblocked. Ask for repository splits or extra ceremony only when risk truly warrants it.
+- **Multi-repo efforts:** A change may be intentionally split across repositories; read the PR body for links to sibling PRs before calling the work incomplete for only touching one repo.
+- **Force-push:** Never suggest force-push as a silent or automatic fix. If history rewrite is raised, require clear **user-visible** justification: **why** it is proposed, **blast radius** and effects on others and CI, and why non-destructive options are insufficient—default to safer paths.

AGENTS.md

@@ -0,0 +1,30 @@
+# AGENTS.md
+
+<!-- agentic-guardrails:start -->
+## Agentic guardrails
+
+These notes apply to humans and to automated agents (including Cloud Agents).
+
+1. **Autonomous work comes first**  
+   The default posture is to **finish useful work without unnecessary human gates**. Prefer actions that keep momentum (fetch, build, test, open PRs) over asking for permission for routine steps—while still honoring the hard safety rules below.
+
+2. **Multi-repository work is encouraged**  
+   When a task genuinely spans more than one codebase (services, libraries, docs, sibling CLIs), work across **multiple repositories or local clones** as needed. Open **one PR per repository**, keep each PR scoped, and **link related PRs** in every description so reviewers see the coordinated change.
+
+3. **Stay on a fresh enough tip; rebase is optional**  
+   Before substantive work: `git fetch origin`, check out your branch, then prefer **`git merge --ff-only origin/<branch>`** (or `git pull --ff-only` when upstream exists). If you cannot fast-forward, pause and use the repository’s normal merge or rebase workflow—**do not** silently work on a stale checkout. **`git pull --rebase`** is *ideal* when updating an active feature branch, but it is **not required**; a merge commit or team-standard flow is fine when it avoids needless churn.
+
+4. **Force-push is never automatic and needs explicit human buy-in**  
+   Do **not** run `git push --force`, `git push --force-with-lease`, or rewrite published history on your own. If you believe it might be warranted, **stop** and give the **human** explicit **reasoning**, **effects** on collaborators, CI, and open PRs, and **why** a force-push would be needed versus safer alternatives (new branch, revert, merge). Proceed **only** after they **explicitly approve** that exact repository and branch.
+
+5. **Focused changes and verification**  
+   Keep pull requests focused; run this repository’s standard build, test, and lint commands (see `README`, `Makefile`, or `CLAUDE.md`) before requesting review.
+
+6. **Workflow shape is yours**  
+   Using **git worktree** versus a single working directory is an **operator choice**; these docs do **not** require worktrees.
+
+<!-- agentic-guardrails:end -->
+
+---
+
+