docs: add ADR-016 — Stage 0 gate revised to "me or a friend", behavioural

Records the gate change: Stage 0 now passes when either the maintainer or an
onboarded friend returns unprompted in >=2 separate weeks. Behavioural (return
usage), not feedback-based, to resist politeness bias. Includes an honest
self-scrutiny note that this is a guardrail edit made while the original gate was
unmet — examined on that basis and proceeding because it broadens who supplies the
signal without softening the kind of signal required. Adds feedback-based-gate to
rejected alternatives.

DECISIONS.md

@@ -444,6 +444,51 @@ decision doc (`infra/docs/superpowers/handoffs/`). Build + reboot-validation: in
 
 ---
 
+## ADR-016 — Stage 0 gate revised: "useful to me OR a friend", behavioural not feedback
+
+**Status:** Accepted (2026-06-03). Revises the Stage 0 definition in VISION.md (supersedes the
+original "useful to me, specifically" gate and folds in the old Stage 1 "a trusted user returns"
+test).
+
+**Context.** The original Stage 0 gate was "the maintainer reads summaries weekly for four weeks
+and acts on one." The maintainer chose to change it to include friendly users, reasoning that
+early signal from friendly users is valuable. Two sub-decisions shaped the final form:
+- *Me OR a friend* (not AND): either the maintainer or an onboarded friend showing use clears it.
+- *Behavioural, not feedback*: the test is **return usage**, not stated approval.
+
+**Decision.** Stage 0 passes when, over a 3–4 week window, **either the maintainer or at least
+one onboarded friend returns to Tapir unprompted and reads/acts on summaries in ≥2 separate
+weeks.** Friend feedback is gathered and valued but is **not** the gate.
+
+**Why behavioural, not feedback (the load-bearing part).** Asked-for feedback from friendly
+users is the least reliable signal in product development — politeness bias means a friend you
+onboarded will tend to say encouraging things regardless of real value. The thing actually worth
+knowing is whether they *come back on their own*. So the gate measures returns, not nice words.
+This deliberately resists the most common way a principled gate dies: being declared "passed" on
+the strength of a polite reaction.
+
+**Honest note on what this change does.** This is a *guardrail edit made while the original gate
+was unmet* (Stage 0 had barely started; build had run well ahead of use-evidence). That is
+precisely the pattern that warrants scrutiny — redrawing a gate around work already done. It was
+examined on that basis and proceeds because: (a) the new gate is **not softer in kind** — it
+stays behavioural and sustained, merely broadening *who* can supply the signal; (b) friendly-user
+signal is genuinely valuable; (c) the politeness-bias guard keeps it from collapsing into
+"someone said it's nice." It is *not* a licence to treat the already-shipped Stage-1 machinery as
+evidence the gate passed — use-evidence remains open.
+
+**Consequences.**
+- VISION.md Stage 0 rewritten; old Stage 1 ("a trusted user returns") folded in (it was
+  near-identical to the new test); hardening renumbered to Stage 1.
+- New drift signal added: declaring the gate passed on polite feedback rather than return-usage.
+- The 2026-07-01 check-in now asks "is anyone (me or a friend) coming back unprompted?", not
+  "am I using it weekly?".
+
+**Reversibility.** A superseding ADR could tighten it back to maintainer-only or raise it to
+require multiple returning users. Recorded with the full rationale (including the self-scrutiny
+about editing a gate while it's unmet) so the reasoning survives, not just the new wording.
+
+---
+
 ## Rejected alternatives
 
 Approaches considered during the 2026-06-02 planning + grill session and **deliberately not
@@ -464,6 +509,7 @@ maps to the ADR that settles it.
 | Delegating the S5 reuse spike to an agent swarm | A 1-hour sequential read-and-judge with a single coupled conclusion; orchestration overhead exceeds the work, and it's Diamond-1 judgment the maintainer wanted to own | (process note) |
 | Vault-write SA for per-user OAuth tokens (ESO as runtime write path) | ESO syncs vault→cluster at deploy time, not a runtime write API; a write-SA widens blast radius to shared infra to store app row-data | ADR-015, infra#88 |
 | Supabase for per-user credential storage | Adds a second datastore for a few encrypted strings PG18 already holds; reopens ADR-002 | ADR-015, infra#88 |
+| Feedback-based Stage 0 gate (friends saying it's useful) | Politeness bias makes asked-for feedback the least reliable signal; return-usage is the real test | ADR-016 |
 
 If a future case genuinely reopens one of these, that's a new ADR superseding the relevant one —
 not a silent reversal.