docs: adopt Conventional Commits and land planning docs

- CONVENTIONAL-COMMITS.md: vendored spec (v1.0.0); CLAUDE.md requires
  agent-written commits to follow it
- tasks 0002-0020: remaining task breakdown of the gitea-axi spec
  (0019 reframed around the three-tier test taxonomy: unit,
  integration, end-to-end)
- spec, CONTEXT.md, and ADRs 0006/0007/0011: pending design
  refinements from the planning sessions

.claude/adr/0006-reviewdecision-parallel-fetch.md

@@ -23,3 +23,12 @@ Accepted explicitly: API call cost does not factor into design decisions for thi
 - `pr list` with N results makes N+1 HTTP calls (list + N review fetches).
 - `official` and `stale` fields are exposed on `pr view --reviews` as Gitea-specific bonus data.
 - The `reviewDecision` field appears in the default schema for both `pr list` and `pr view`.
+
+## Amendment (2026-07-10): official-first fallback
+
+The original logic required `official=true` for `APPROVED`, but Gitea only marks reviews official under branch protection with required approvals.
+On unprotected repos (the norm on personal instances) every review is `official=false`, making `APPROVED` unreachable — an approved PR would show `required` forever.
+
+Amended logic: if any review on the PR carries `official=true`, consider only official reviews (branch-protection semantics preserved); otherwise consider all reviews.
+Within the considered set the derivation is unchanged: `CHANGES_REQUESTED` if any non-dismissed `REQUEST_CHANGES`; `APPROVED` if any non-dismissed, non-stale review with state `APPROVED`; `REVIEW_REQUIRED` otherwise.
+The otherwise-bucket (zero reviews, comment-only) renders `required`; gitea-axi deliberately has no `none` value, since detecting "review not formally required" would need admin-only branch-protection API access.

.claude/adr/0007-fetch-then-patch-assignees-reviewers.md

@@ -27,3 +27,12 @@ Accepted cost: same policy as client-side filtering — extra HTTP calls do not
 - The operation is not atomic: a concurrent edit between the GET and the PATCH could cause a lost update.
   Accepted as a known limitation for single-agent workflows.
 - `issue label --add` / `--remove` does NOT use fetch-then-patch — Gitea has dedicated additive label endpoints that are already idempotent.
+
+## Amendment (2026-07-10): reviewers use dedicated endpoints, not fetch-then-patch
+
+The original decision was wrong about reviewers on two counts:
+`EditPullRequestOption` has no reviewers field at all (fetch-then-patch is impossible, not merely chosen against), and Gitea does have dedicated add/remove endpoints — `POST`/`DELETE /repos/{owner}/{repo}/pulls/{index}/requested_reviewers` with `{ reviewers: string[] }`.
+
+`pr edit --add-reviewer` / `--remove-reviewer` therefore use the dedicated review-request endpoints, mirroring the label-mutation pattern.
+Fetch-then-patch remains the pattern for assignees only (issues and PRs), where the PATCH body does replace the whole list and no dedicated endpoints exist.
+`pr create --reviewer` is unaffected: `CreatePullRequestOption` accepts `reviewers` directly.

.claude/adr/0011-pr-checkout-via-refs-pull-head.md

@@ -17,3 +17,14 @@ One uniform code path, no remote mutation, no fork credentials.
 - Same-repo and fork PRs check out identically.
 - Git subprocess failures (dirty worktree, network) classify as `GIT_ERROR`, carrying git's first stderr line.
 - The created local branch does not track the contributor's fork; pushing back to a fork branch is out of scope.
+
+## Amendment (2026-07-10): three-case handling for existing local branches
+
+The original two-step pipeline fails on re-checkout: git refuses to fetch into the currently checked-out branch, and a moved PR head makes the plain fetch non-fast-forward — so the second run of the same command errored, violating Principle 6.
+
+Amended behavior:
+1. Branch absent — original pipeline unchanged.
+2. Branch exists, not checked out — force-fetch (`+pull/<n>/head:<branch>`) then checkout; the local branch is defined as a mirror of the PR head.
+3. Branch currently checked out — fetch `pull/<n>/head` then `git merge --ff-only FETCH_HEAD`; divergence (local commits not on the PR head) surfaces as `GIT_ERROR` with explanatory help rather than being silently discarded.
+
+A force-reset-always variant was rejected: fully idempotent but silently destroys local commits, which is unacceptable for unattended agents.