memory: move agent memory into repo (memory/), note in AGENTS.md

Persistent agent memories now live in memory/ in this repo; the Claude
auto-memory path is symlinked here so future memories land in the repo
and get committed like any other change.

memory/plausible-upgrade-base-trap.md

@@ -0,0 +1,27 @@
+---
+name: plausible-upgrade-base-trap
+description: "plausible CI REDs come from the published 3.0.0 base deploy (no x86_64 arch → 404 → silent exit 1), not the PR tree; needs UPGRADE_BASE_VERSION=3.0.1+v2.0.0 in cc-ci tests"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: fc17c9c2-ab6e-4c11-856e-a6a6e160a0ec
+---
+
+cc-ci's upgrade tier deploys `recipe_versions[-2]` as the base before upgrading to the PR
+head (deploy-once design: the install tier asserts against that base too). For plausible,
+tags are `…, 3.0.0+v2.0.0, 3.0.1+v2.0.0` so the default base is **3.0.0+v2.0.0**, whose
+entrypoint lacks an x86_64 ARCH mapping → requests `clickhouse-backup-linux-x86_64.tar.gz`
+→ HTTP 404 always → `set -e` + silenced wget → container exits 1 with **empty service
+logs** → crash-loop → install timeout RED. Nothing in the PR can fix this: the base tag is
+immutable history.
+
+**Why:** the PR adds 3.1.0 above the newest published tag — the harness-documented case
+where `[-2]` is the wrong base and `[-1]` (3.0.1) is correct.
+
+**How to apply:** the fix is one line in the cc-ci repo (gated by --with-tests / operator):
+`tests/plausible/recipe_meta.py: UPGRADE_BASE_VERSION = "3.0.1+v2.0.0"`. The recipe-side
+hardening (verified cached binary on the persistent volume, Altinity URL, retries+timeout,
+loud hard-fail, depends_on fix) is on PR #3 (commit 9f8bcbc). Diagnosis + ask posted at
+https://git.autonomic.zone/recipe-maintainers/plausible/pulls/3#issuecomment-14261.
+Before burning a !testme on an upgrade-stage recipe, check what base version the harness
+will pick and whether that base can actually converge. See [[abra-chaos-deploy-checkout-gotcha]].