@xcraftmind/mastermind 0.28.0 → 0.28.2

package/share/skills/flaky-finder/SKILL.md

@@ -1,75 +0,0 @@
----
-name: flaky-finder
-description: Identify flaky tests by running the suite repeatedly and bisecting failures across runs. Use when the user says "find flaky tests", "this test is flaky", "tests pass locally but fail in CI", or sees intermittent test failures.
-metadata:
-  version: 0.1.0
-  authors:
-    - mastermind
-  tags:
-    - testing
-  model: sonnet
----
-
-# Flaky Test Finder
-
-Finds tests that pass and fail non-deterministically. Runs the suite N times, records which tests changed outcome between runs, and ranks them by flake rate.
-
-## When to use
-
-- User reports "tests pass locally but fail in CI"
-- A test failed once and the user wants to confirm if it's flaky before retrying
-- User explicitly asks for a flake audit before a release
-- Do NOT use for finding *broken* tests — those fail consistently. Use a regular test run for that.
-
-## Prerequisites
-
-- A working `<test-command>` for the project (`pytest`, `go test ./...`, `npm test`, etc.)
-- Time — flake hunting is inherently slow (10-50 runs of the full suite)
-
-## Steps
-
-1. **Confirm the test command.** Read the project's CI config or `package.json` / `Makefile`. If unclear, ask.
-2. **Establish a baseline.** Run the suite once. If it fails, the failures aren't flakes — they're broken. Stop and report.
-3. **Decide N.** Default to 20 runs. For long suites (>5min), drop to 10. For fast suites (<30s), go to 50.
-4. **Run N times, recording each test's pass/fail per run.** Use the project's machine-readable output if available (`pytest --junitxml`, `go test -json`, `jest --json`).
-5. **Compute flake rate per test.** A test that passed 18/20 times and failed 2/20 has a flake rate of 10%.
-6. **Rank by flake rate descending.** Anything between 1% and 99% is suspicious; 0% and 100% are deterministic.
-7. **For the top 3 flakiest, read the test code.** Look for: shared state, time-based assertions, network calls, ordering assumptions, race conditions.
-8. **Report findings.**
-
-## Outputs
-
-```markdown
-## Flake report — N=<N> runs of <test-command>
-
-### Flaky tests (sorted by flake rate)
-| Test | Flake rate | Likely cause |
-|---|---|---|
-| `tests/limiter_test.go::TestConcurrentBucket` | 35% (7/20 failed) | Race on shared counter, no `t.Parallel()` synchronization |
-| `tests/api_test.py::test_response_time` | 15% (3/20 failed) | Time-based assertion `< 100ms` — fails under load |
-
-### Deterministic failures
-- `tests/foo_test.py::test_bar` — failed all 20 runs. Not a flake; this test is broken.
-
-### Deterministic passes
-- <count> tests passed all <N> runs.
-```
-
-## Examples
-
-**Input:** "Our CI is flaky, can you find the culprit?"
-
-**Output (abbreviated):**
-```markdown
-## Flake report — N=20 runs of `pytest tests/`
-
-### Flaky tests
-| Test | Flake rate | Likely cause |
-|---|---|---|
-| `test_websocket_reconnect` | 25% | Race between `await ws.connect()` and the heartbeat loop |
-| `test_cache_eviction` | 5% | Wall-clock assertion `time.time() - start < 1.0` |
-
-### Deterministic
-- 312 passed all 20 runs
-- 0 failed all 20 runs
-```

package/share/skills/mastermind-incident-response/SKILL.md

@@ -1,157 +0,0 @@
----
-name: mastermind-incident-response
-description: Parallel workflow for production incidents — triage, stop the bleeding, investigate root cause via mmcg + git + .mastermind/tasks/ history, write a blameless postmortem, feed lessons back into CONTEXT.md and (if applicable) into the main workflow's spec template or critic dimensions. Use when the user says "incident", "outage", "rollback", "что-то сломалось в проде", or pastes paging alerts / error logs.
-metadata:
-  version: 0.1.0
-  authors:
-    - mastermind
-  tags:
-    - workflow
-    - incident-response
-    - postmortem
-    - operations
-  model: opus
----
-
-# Mastermind — Incident Response
-
-A **parallel workflow** for handling production breakage. Different from the main 13-step planning workflow ([`mastermind-task-planning`](../mastermind-task-planning/SKILL.md)) which builds new things — this one **stops bleeding**, finds root cause, and turns lessons into systemic improvements.
-
-## When to Activate
-
-User says or pastes:
-- "incident", "outage", "production is down", "что-то сломалось в проде", "rollback"
-- Paging alerts (Datadog, PagerDuty, Sentry)
-- Error logs with stack traces
-- "users are reporting…"
-- "deploy broke something"
-
-## What this is NOT
-
-- **Not** the bug-triage flow for development-time bugs — those go through the regular planning workflow
-- **Not** a feature-request channel
-- **Not** a debugging session for the user's local environment
-- **Not** a substitute for paging an actual on-call engineer for sev0/sev1 incidents — the workflow assists, doesn't replace the human
-
-## Different Priorities Than Planning
-
-| Planning workflow | Incident response |
-|---|---|
-| Optimize for quality | Optimize for **time** |
-| 7-dim critic before doing anything | Bias toward **rollback first**, understand later |
-| Mandatory specs, alternatives, tests | Hot-fix is OK if rollback impossible |
-| "Did we design this right?" | "What's the fastest way to stop the bleeding?" |
-| Blameless review post-fact | Blameless reasoning **during** |
-
-You are in **operations mode**. Speed of bleed-stop > completeness of fix > root-cause depth > paperwork. Reverse that order during postmortem.
-
-## Phases
-
-### Phase 1 — Triage (target: first 5 minutes)
-
-Ask the user (or extract from pasted alert):
-
-1. **Symptom** — what users / monitoring see (one sentence, observable)
-2. **Scope** — how many users / how much traffic / which surfaces
-3. **Severity** — pick a number:
-   - **sev0** — total outage, paging fire
-   - **sev1** — major degradation, immediate action needed
-   - **sev2** — partial degradation, action within hours
-   - **sev3** — minor / cosmetic, action within days
-4. **Timeline** — when did this start? (correlate with deploys / changes)
-5. **What's been tried already**
-
-While asking, parallel-research with `mastermind-researcher` subagent:
-```
-git log --since='2 hours ago' --oneline    → what changed recently
-git log -10 --oneline                       → most recent commits
-ls -lt .mastermind/tasks/*/spec.md 2>/dev/null | head -10  → most recent specs (folder-per-task)
-mmcg_status                                → index health
-```
-
-Use see [`references/triage-checklist.md`](references/triage-checklist.md) for the full first-response checklist.
-
-### Phase 2 — Stop the bleeding (target: next 10 minutes after triage)
-
-**Order of preference:**
-1. **Rollback** to last known good — if you can identify it, do it
-2. **Disable the feature** — if feature-flagged, flip the flag off
-3. **Hot patch** — only if 1 and 2 not possible; this carries risk
-4. **Escalate** — if stuck > 10 min on Phase 2, page additional help / wake on-call
-
-For each option, write to user what you're about to propose. **Do not execute destructive ops** (`git push --force`, deploys) without explicit user confirmation per turn — they're operating the controls, you're advising.
-
-Mitigation tactics by failure type:
-- **Recent deploy broke things** → revert the deploy
-- **Recent config change broke things** → revert config
-- **Data corruption** → freeze writes, restore from backup, investigate cause separately
-- **External dependency degraded** → enable degraded-mode fallback if present; otherwise wait + monitor
-- **Resource exhaustion (memory, disk, connections)** → kill / restart / scale; investigate cause separately
-
-### Phase 3 — Investigate (after symptoms stop)
-
-With pressure off, find **root cause** — not just the symptom. Five-whys discipline.
-
-**Investigation playbook** — see [`references/investigation-playbook.md`](references/investigation-playbook.md) for the full set of mmcg + git + log patterns. Quick summary:
-
-- **What changed recently?** `git log --since='<time of incident start - 1h>' -- <suspected paths>`
-- **What's the blast radius of the change?** `mmcg query impact <symbol> --depth 3`
-- **Were the relevant specs in `.mastermind/tasks/` going to catch this?** Read their Tests Plan + Observability Plan sections
-- **Did observability fire?** If yes, why didn't it page sooner? If no, why wasn't it instrumented?
-- **Is this a recurrence?** Grep `CONTEXT.md` for the symptom — known gotcha?
-
-If a fix is needed, **don't write it inline in this incident flow** — open a `.mastermind/tasks/<NNN>-<short-name>/spec.md` via the main workflow. The fix goes through the normal critic/auditor gates. Incident response identifies the need; planner designs the response.
-
-### Phase 4 — Postmortem (within 24h of resolution)
-
-Use [`references/postmortem-template.md`](references/postmortem-template.md). Sections:
-
-- **Summary** (1-2 sentences — what happened, impact, resolution)
-- **Timeline** (UTC, minute-resolution where relevant)
-- **What went wrong** (root cause, contributing factors)
-- **What went well** (yes, name what worked — psychological safety + reinforces good patterns)
-- **Why detection took N minutes** (separate from why-it-happened — detection is its own failure mode)
-- **Why mitigation took N minutes** (rollback fast? unclear who could act? missing runbook?)
-- **Action items** (specific, owned, dated — each becomes a `.mastermind/tasks/` spec or a CONTEXT.md update)
-
-**Blameless framing** — write about systems, not people:
-- ❌ "Engineer X deployed without testing"
-- ✓ "The deploy pipeline allowed merging with failing tests because the test job was marked non-blocking three weeks ago"
-
-If a person made a judgment call that turned out wrong, frame it as: "given the information available at the time, the action was reasonable; the lesson is that information X needs to be more accessible / surfaced earlier."
-
-### Phase 5 — Feed forward
-
-Two destinations:
-
-**A. Project `CONTEXT.md`** (immediate):
-- **Known gotchas** entry for the failure pattern — concrete + scenario + reference to postmortem path
-- **Don't-touch list** entry if a code area has subtle constraints now known
-- **Decision log** entry if the postmortem changed an architectural decision
-
-**B. Action items as new `.mastermind/tasks/` specs** (within days):
-- Each action item becomes a spec
-- Specs go through normal workflow (planner → critic → executor → auditor)
-- Link back to postmortem in spec's Notes section
-
-**C. Workflow improvements** (if applicable):
-- Did the spec for the offending change include an Observability Plan? If no, that's evidence the planner skill should make it more mandatory.
-- Did the critic's 7 dimensions miss this category of issue? Propose an 8th dimension or sharpening an existing one.
-- Did the auditor pass when it shouldn't have? Add a new check.
-
-Workflow improvements go into the mastermind repo itself as a meta-improvement spec. **The workflow learns from its own failures.**
-
-## Roles & subagents
-
-Most of incident response is run by the planner (in this mode), with these spawns:
-
-- **`mastermind-researcher`** — for git/mmcg fact-gathering during Phase 1 and Phase 3
-- **`mastermind-critic`** — for the postmortem's "what went wrong" section if there's a design question (e.g., "was this design fundamentally flawed?"). Optional.
-- **`mastermind-auditor`** — NOT used in incident response (it's a post-flight checker, doesn't apply here)
-- **`mastermind-task-planning`** (in main mode) — for any follow-up specs that come out of the postmortem
-
-## References
-
-- [`references/triage-checklist.md`](references/triage-checklist.md) — first 5 minutes
-- [`references/investigation-playbook.md`](references/investigation-playbook.md) — mmcg + git + .mastermind/tasks/ patterns for finding root cause
-- [`references/postmortem-template.md`](references/postmortem-template.md) — blameless postmortem fill-in

package/share/skills/mastermind-incident-response/references/investigation-playbook.md

@@ -1,174 +0,0 @@
-# Investigation playbook — find root cause via mmcg + git + .mastermind/tasks/
-
-Reference for the [`mastermind-incident-response`](../SKILL.md) skill, Phase 3. After symptoms have stopped, find what actually broke.
-
-The patterns below are concrete recipes. Use them when the corresponding question comes up — don't run all of them speculatively (wastes context).
-
----
-
-## Question 1 — "What changed recently?"
-
-Most production incidents trace to a recent change. Start here.
-
-```bash
-# What was committed in the window when the incident started?
-git log --since='2 hours ago' --until='now' --oneline
-
-# What was committed in the file/dir we suspect?
-git log -20 --oneline -- <suspected/path/>
-
-# What did the most recent commits actually change?
-git log -5 -p --stat -- <suspected/path/>
-```
-
-Then for any candidate commit:
-```bash
-git show <commit-sha> --stat       # what files
-git show <commit-sha>              # full diff
-```
-
-**Heuristic for ranking suspect commits:**
-- Most recent first
-- Bigger diffs first (more surface to have bugs)
-- Commits to "interesting" paths (hot paths, recently-incident-prone dirs)
-- Commits that touch the symptom's component (grep error message in commit diff)
-
----
-
-## Question 2 — "What's the blast radius of the change?"
-
-If you have a suspect commit, what does it touch that could explain the symptom?
-
-```bash
-# What symbols changed in the suspect commit?
-git show <commit-sha> --name-only
-
-# For each changed function/method, what calls it?
-mmcg_callers <symbol> --language <lang>
-
-# Transitive — what else depends on it?
-mmcg_impact <symbol> --depth 3 --language <lang>
-```
-
-If the blast radius doesn't include the symptom's component → the suspect commit probably isn't the cause. Move to the next candidate.
-
-If the blast radius DOES include the symptom's component → strong candidate. Read the code change.
-
----
-
-## Question 3 — "Were the relevant specs supposed to catch this?"
-
-Spec for any recent change should have had Tests Plan + Observability Plan + Performance Considerations sections (per spec template).
-
-```bash
-# Find the spec for this work (look in .mastermind/tasks/ for matching folder or timestamp)
-ls -lt .mastermind/tasks/                                  # task folders, newest first
-ls -lt .mastermind/tasks/*/spec.md 2>/dev/null             # direct list of spec files by mtime
-
-# Read its Tests Plan
-grep -A 20 "Tests Plan" .mastermind/tasks/<NNN>-<name>/spec.md
-
-# Read its Observability Plan
-grep -A 10 "Observability Plan" .mastermind/tasks/<NNN>-<name>/spec.md
-
-# Read its Performance Considerations
-grep -A 10 "Performance Considerations" .mastermind/tasks/<NNN>-<name>/spec.md
-```
-
-Then ask:
-
-- **Did the Tests Plan cover this failure mode?** If no, that's a gap in spec quality. Action item: "harden Tests Plan for similar work."
-- **Did Observability fire for this failure?** If no, was it instrumented? If yes, did it page? Detection time is its own failure to root-cause.
-- **Did Performance Considerations anticipate this load?** If the issue is scale-related, the spec should have predicted it.
-
-These answers feed the postmortem's "Why detection took N minutes" and "Workflow improvements" sections.
-
----
-
-## Question 4 — "Has this happened before?"
-
-```bash
-# Check known gotchas
-grep -B 2 -A 4 -i "<symptom keywords>" CONTEXT.md
-
-# Check don't-touch list
-grep -B 2 -A 4 "<file or path>" CONTEXT.md
-
-# Check past postmortems (if you keep them)
-ls postmortems/ 2>/dev/null || ls docs/postmortems/ 2>/dev/null
-grep -ri "<symptom>" postmortems/ 2>/dev/null
-```
-
-If yes → this is a **recurrence**. That's a MUCH bigger finding than a first-time incident:
-- The previous fix didn't stick
-- The prevention didn't transfer
-- The CONTEXT.md entry was either missing or ignored
-
-A recurrence postmortem should focus heavily on Phase 5 (feed forward) and propose a STRUCTURAL fix, not just a code fix.
-
----
-
-## Question 5 — "What's the failure mode?"
-
-Classify the failure into a category. This guides both immediate response and what kind of structural improvement to propose:
-
-| Category | Examples | Typical fix |
-|---|---|---|
-| **Code bug** | null-pointer, off-by-one, wrong condition | Code change + test |
-| **Configuration bug** | wrong env var, bad timeout, missing flag | Config change + config validation in CI |
-| **Schema / migration** | column missing, type mismatch, FK violation | Migration + pre-flight schema check |
-| **Capacity / scale** | OOM, connection pool exhausted, CPU pegged | Scaling + capacity model in spec template |
-| **External dependency** | upstream API down, vendor SLA breach | Degraded-mode fallback + dep health probe |
-| **Race / concurrency** | lost write, deadlock, double-spend | Concurrency model documented + tests |
-| **Data quality** | bad input from upstream, encoding issue | Validation at boundary + schema for inputs |
-| **Process** | bad deploy, wrong branch, missed code review | Pipeline / process improvement |
-
-The category determines whether the postmortem proposes a CODE fix, a PROCESS fix, or a SYSTEM fix (architectural).
-
----
-
-## Question 6 — "What's the smallest reproducer?"
-
-Before declaring root cause found, get a reproducer:
-
-- **Unit test** — fastest; if you can write one that fails, you understand the bug
-- **Integration test** — if behavior depends on multiple components
-- **Manual reproduction** — if neither possible, document the exact steps
-
-A bug without a reproducer is a bug not understood. Don't ship the fix until you can reproduce.
-
-The reproducer becomes Test 1 in the fix spec's Tests Plan.
-
----
-
-## Five-whys discipline
-
-For the postmortem's "What went wrong" section, apply five-whys:
-
-1. **Why** did the symptom happen? → because <proximate cause>
-2. **Why** did that happen? → because <one level deeper>
-3. **Why** did THAT happen? → because <one more>
-4. **Why**?
-5. **Why**?
-
-Stop when:
-- The answer is a system property (e.g., "the deploy pipeline is asynchronous, so we ran without rollback safety")
-- The answer would require changing fundamental architecture (escalate, don't propose in postmortem)
-- You've gone 5 levels — at some point further whys are speculation
-
-Document the chain in the postmortem. The deepest "why" you can credibly answer is the **systemic** root cause; that's what the action items should address.
-
----
-
-## When to stop investigating
-
-You have enough when:
-
-1. ✓ You can name the proximate cause (the code/config/data thing that broke)
-2. ✓ You can name a systemic cause (the why that goes deeper than "engineer X did Y")
-3. ✓ You have a reproducer (or explicit decision that one is not feasible)
-4. ✓ You know what would have prevented this (a test? a check? a config? a process?)
-
-Then go to Phase 4 — write the postmortem.
-
-If after 1-2 hours you can't answer #1-2 → escalate or accept "we couldn't determine root cause" honestly in the postmortem. **Don't fabricate a cause to look complete.** Unknown root causes are themselves a finding.

package/share/skills/mastermind-incident-response/references/postmortem-template.md

@@ -1,184 +0,0 @@
-<!--
-  Mastermind blameless postmortem template.
-
-  HOW TO USE
-  - Copy this file to postmortems/<YYYY-MM-DD>-<short-name>.md (or docs/postmortems/, whichever convention your repo uses)
-  - Fill in every <placeholder> with concrete content
-  - Delete sections that genuinely don't apply (e.g., if a sev3 had no user impact)
-  - Keep the file short — a postmortem nobody reads is worse than no postmortem
-  - Action items get linked back here from the .mastermind/tasks/ specs they spawn
-
-  BLAMELESS PRINCIPLE
-  Write about systems, not people. If a person made a judgment call, frame it as:
-  "given the information available, the action was reasonable; the lesson is that
-  information X needs to be more accessible / surfaced earlier."
-
-  Anti-pattern: "Engineer X deployed without testing."
-  Better: "The deploy pipeline allowed merging with failing tests because the
-  test job was marked non-blocking three weeks ago."
-
-  TONE
-  - Past tense (this happened, this was tried)
-  - Concrete (timestamps, error messages, file paths)
-  - Honest about unknowns ("we don't yet know why X" is better than fabricating)
--->
-
-# Postmortem: <short title>
-
-## Summary
-
-**Date:** <YYYY-MM-DD>
-**Severity:** <sev0 | sev1 | sev2 | sev3>
-**Duration:** <N minutes from start to mitigation, M minutes to full resolution>
-**Impact:** <one sentence — what users / systems were affected, magnitude>
-
-<One to three sentences: what happened, what was the user impact, what was the resolution. Anyone reading should know what this is about in 30 seconds.>
-
----
-
-## Timeline (UTC)
-
-| Time | Event |
-|---|---|
-| <HH:MM> | First failure observed (per <source — log, monitor, user report>) |
-| <HH:MM> | Detection (paged / reported in #ops / noticed by …) |
-| <HH:MM> | Incident response engaged |
-| <HH:MM> | Triage complete; severity declared as <sev>; <initial hypothesis> |
-| <HH:MM> | Mitigation: <what was done> |
-| <HH:MM> | Symptoms stopped |
-| <HH:MM> | Root cause identified |
-| <HH:MM> | Full resolution (fix deployed / patch applied / dependency restored) |
-| <HH:MM> | Postmortem started |
-
----
-
-## What happened
-
-<2-4 paragraphs of narrative. Lead with the proximate cause. Then walk through how the symptom manifested, what was tried, what worked, what didn't.>
-
-<If multiple things went wrong in sequence (cascading failure), name each component and how they interacted.>
-
----
-
-## Root cause analysis
-
-### Proximate cause
-<The specific code change / config / dependency that triggered the symptom. Cite file:line, commit SHA, or external system.>
-
-### Systemic causes (five-whys chain)
-1. **Why** did the symptom happen? <because…>
-2. **Why** did that happen? <because…>
-3. **Why** did that happen? <because…>
-4. **Why** did that happen? <because…>
-5. **Why** did that happen? <because…>
-
-The deepest "why" we can credibly answer is the **systemic root cause** — that's what the action items should address.
-
-### Failure category
-
-<Pick one from the investigation-playbook.md table: code bug / configuration bug / schema / capacity / external dependency / race or concurrency / data quality / process.>
-
----
-
-## Detection
-
-**Why did detection take <N> minutes?**
-<Why didn't this fire earlier? Was there a monitor for this failure mode? Did the monitor fire but not page? Did it page someone who couldn't act?>
-
-**What detection improvements would have caught this <K> minutes sooner?**
-<Specific: "a P99 latency alert on /api/messages would have fired at 14:33 instead of 14:38 when users reported.">
-
----
-
-## Mitigation
-
-**Why did mitigation take <M> minutes?**
-<Was the rollback path clear? Was someone with deploy access available? Was the on-call runbook accurate?>
-
-**What mitigation improvements would have stopped the bleed sooner?**
-<Specific: "a feature flag for the new code path would have let us disable in seconds instead of waiting for a rollback deploy.">
-
----
-
-## What went well
-
-<Yes, name what worked. Reinforces good patterns and supports psychological safety. Be specific.>
-
-- <Thing 1 — e.g., "The Datadog dashboard for /api/messages clearly showed the regression once someone looked at it">
-- <Thing 2 — e.g., "On-call rotation was clear; <person> was immediately available">
-- <Thing 3>
-
----
-
-## What didn't go well
-
-<The hard part — be honest, but blameless. Focus on systems, gaps, processes.>
-
-- <Thing 1 — e.g., "The spec for this change didn't include an Observability Plan, so the new code path had no metrics">
-- <Thing 2 — e.g., "The deploy pipeline reported success even though the smoke test failed">
-- <Thing 3>
-
----
-
-## Where the mastermind workflow gates failed (if applicable)
-
-*Only relevant if this incident came from a change shipped through the mastermind workflow. If it came from a hot-fix, manual ops, or pre-mastermind code, skip this section.*
-
-- **Critic dimension(s) that should have caught this:** <e.g., "dimension #3 Observability — the design didn't include any metric / log on the failure path, and the critic missed flagging it">
-- **Spec template section(s) that were empty or weak:** <e.g., "Observability Plan was 'n/a — no production runtime' but this code DOES run in production">
-- **Auditor checks that passed when they shouldn't have:** <e.g., "auditor verified tests ran, but spec didn't include a load test, so capacity issue wasn't tested for">
-
-→ Each of these maps to a workflow-improvement action item (see Action Items below).
-
----
-
-## Action items
-
-Each action item gets owned, dated, and either (a) becomes a `.mastermind/tasks/` spec or (b) becomes a CONTEXT.md update.
-
-| # | Action | Type | Owner | Due | Spec / CONTEXT entry |
-|---|---|---|---|---|---|
-| 1 | <Specific change — code, config, process, doc> | <code-fix \| context-md \| workflow-improvement \| process> | <person> | <YYYY-MM-DD> | <`.mastermind/tasks/NNN-name/spec.md` or "CONTEXT.md → Known gotchas">|
-| 2 | <…> | <…> | <…> | <…> | <…> |
-
-**Avoid action items like:**
-- ❌ "Be more careful when deploying" — not actionable
-- ❌ "Add monitoring" — too vague
-- ❌ "Train the team on X" — training without process change rarely sticks
-
-**Prefer action items like:**
-- ✓ "Add P99 latency alert on /api/messages at 200ms threshold via Datadog monitor — `.mastermind/tasks/NNN-add-messages-latency-alert/spec.md`"
-- ✓ "Add 'capacity test' as mandatory line in Performance Considerations section of spec-template — `.mastermind/tasks/NNN-spec-template-capacity/spec.md`"
-- ✓ "Add CONTEXT.md known-gotcha: 'Redis cluster mode silently drops MULTI on key migrations during rebalance'"
-
----
-
-## Feed forward to CONTEXT.md
-
-The following entries get appended to project `CONTEXT.md`:
-
-### Known gotchas (append)
-- **<one-line summary of the failure pattern>** — <bite scenario>. See `postmortems/<this file>`.
-
-### Don't-touch list (if applicable, append)
-- **`<path or symbol>`** — <constraint that emerged from this incident>
-
-### Decision log (if architecture changed, append)
-- **<YYYY-MM-DD> — <decision name>** — <one-sentence decision, why, alternatives rejected, source: postmortems/<this file>>
-
----
-
-## Unknowns
-
-*If root cause is partially or fully unknown, name what's unknown. This is honest — fabricating a cause is worse than admitting uncertainty.*
-
-- <Unknown 1 — e.g., "We don't yet know why the Redis client closed the connection at 14:32 specifically; logs are too sparse to tell">
-- <What would we need to know it: a debug log, a packet capture, a repro environment>
-
----
-
-## Sign-off
-
-- **Author:** <name>
-- **Reviewers:** <names who read this before publishing>
-- **Distribution:** <team / org / wider>