diff options
Diffstat (limited to 'feedback_architecture_review_scope.md')
| -rw-r--r-- | feedback_architecture_review_scope.md | 14 |
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. |