feat: add documentation for release notes verification and workflow testing

.claude/agent-memory/opus-orchestrator/MEMORY.md

@@ -0,0 +1,4 @@
+# Opus orchestrator memory
+
+- [Release authority](project_release_authority.md) — owner does the load-unpacked check and owns the tag; a `v*.*.*` tag publishes live to the CWS with no approval gate.
+- [Owner approval style](feedback_owner_approval_style.md) — "proceed" means apply the plan's recommended defaults; it never authorizes a step the plan parked.

.claude/agent-memory/opus-orchestrator/feedback_owner_approval_style.md

@@ -0,0 +1,12 @@
+---
+name: feedback-owner-approval-style
+description: Owner approves by saying "proceed" without answering the plan's open questions — apply the recommended defaults and keep going, but still stop at irreversible external actions
+metadata:
+  type: feedback
+---
+
+When a plan ends with open decisions and the owner replies "proceed" rather than answering them, treat the recommended option for each as chosen and execute — do not re-ask.
+
+**Why:** on the v1.1.0 release (2026-08-12) the plan posed three questions (version number, how far to go, whether to include an adjacent fix); the owner answered "now proceed execution". Re-asking would have stalled work he had already delegated by choosing the recommendation.
+
+**How to apply:** state the applied defaults in the orchestration record so the assumption is visible and correctable, then run. The exception is any action the plan itself parked as owner-authorized — publishing, tagging a release, destructive or external state changes: "proceed" on the plan is not authorization for the step the plan explicitly deferred. See [[project-release-authority]].

.claude/agent-memory/opus-orchestrator/project_release_authority.md

@@ -0,0 +1,12 @@
+---
+name: project-release-authority
+description: LexAI releases — the owner tests load-unpacked personally and holds the tag; a v*.*.* tag publishes live to the Chrome Web Store with no manual approval step
+metadata:
+  type: project
+---
+
+The owner does the real-page (load-unpacked) verification himself and reports it back; agents should treat that as the DOM/selection acceptance evidence rather than trying to reproduce it. The `v*.*.*` tag is his to fire.
+
+**Why:** pushing a `v*.*.*` tag runs `deploy-chrome.yml`, which uploads *and publishes* to the Chrome Web Store in the same run — there is no draft/approval gate, and a published CWS version cannot be unpublished in place (only superseded by a higher version). Tags v1.0.1 and v1.0.2 were never created on the remote even though those versions exist in `package.json` history, so remote tag state must be read (`git ls-remote --tags origin`) rather than inferred from `package.json`.
+
+**How to apply:** take a release through bump → gates → merge to `main` → stop. Park the tag as an owner decision in `docs/PROGRESS.md`. Never create a tag without an explicit, specific go. See [[feedback-owner-approval-style]].