Initial commit: tungsten's memory tree

1 files changed, 14 insertions, 0 deletions

diff --git a/feedback_architecture_review_scope.md b/feedback_architecture_review_scope.md
new file mode 100644
index 0000000..40f36b3
--- /dev/null
+++ b/feedback_architecture_review_scope.md
@@ -0,0 +1,14 @@
+---
+name: feedback-architecture-review-scope
+description: "When asked for an architectural review, keep it structural — don't lean on incident narrative as evidence or hook"
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: 2607e018-d4ad-4ec6-bb68-5f1d0f9a3906
+---
+
+When the user asks for an "architectural review," give structural analysis — how components relate, what the design trades off — not an incident post-mortem. Corrected 2026-08-07: a doot service-gateway review leaned on that day's outage (and an earlier 3-day incident) as the framing device and evidence for a "blast radius" argument; the user said "I'm not interested in an incident review, I believe I asked for an architectural review."
+
+**Why:** Incidents are useful *inputs* the reviewer can reason from privately, but citing them as the review's evidence/narrative conflates "this specific bug happened" with "this is a structural property of the design" — and the user reads the two as different documents entirely.
+
+**How to apply:** State structural costs/tradeoffs (e.g. "an in-process gateway means one process's failures take independent services down with it") as properties of the design, not as "here's what broke and when." If a past incident is genuinely relevant, it's fine to have privately informed the analysis — just don't put it in the document unless asked for a post-mortem specifically.