[
  {
    "id": "81fe2d44-24ae-4946-a063-d4ea3a12a71a",
    "learning_type": "scar",
    "title": "Done != Deployed != Verified Working",
    "description": "Code being 'done' (merged) doesn't mean it's deployed, and being deployed doesn't mean it's working correctly in production. The full loop is: merge → deploy → verify the feature works end-to-end in the target environment. Skipping verification leads to silent failures.",
    "severity": "critical",
    "scar_type": "verification",
    "is_starter": true,
    "counter_arguments": [
      "Our deployment pipeline is automated so merge = deploy — but automated doesn't mean verified working",
      "We have monitoring that would catch issues — but monitoring has blind spots and alert fatigue is real"
    ],
    "keywords": ["deployment", "verification", "production", "done"],
    "domain": ["deployment", "operations"],
    "project": "default",
    "source_date": "2026-01-01",
    "created_at": "2026-01-01T00:00:00Z"
  },
  {
    "id": "07c7f9d3-1336-4fef-81da-af7c97590ab9",
    "learning_type": "scar",
    "title": "Database Migration Without Rollback Plan",
    "description": "Running database migrations without a tested rollback plan risks data loss or extended downtime. Destructive migrations (dropping columns, changing types) are especially dangerous. Always write and test the down migration before running the up migration in production.",
    "severity": "critical",
    "scar_type": "architectural",
    "is_starter": true,
    "counter_arguments": [
      "This migration is additive so it's safe — but even additive migrations can fail and leave the schema in a partial state",
      "We can always restore from backup — but backup restoration takes time and may lose recent data"
    ],
    "keywords": ["database", "migration", "rollback", "schema", "data-loss"],
    "domain": ["database", "operations"],
    "project": "default",
    "source_date": "2026-01-01",
    "created_at": "2026-01-01T00:00:00Z"
  },
  {
    "id": "33996174-a7f4-42f5-81ac-f601e566cc5a",
    "learning_type": "scar",
    "title": "Silent Error Swallowing Hides Real Failures",
    "description": "Empty catch blocks and generic error handlers that log but don't surface errors lead to silent failures. The system appears to work while data is lost or corrupted. At minimum, log errors with enough context to diagnose the issue. Better: fail visibly so problems are caught early.",
    "severity": "high",
    "scar_type": "operational",
    "is_starter": true,
    "counter_arguments": [
      "We catch errors to prevent crashes — but catching without handling is worse than crashing because the problem is hidden",
      "The error is non-critical so swallowing it is fine — but 'non-critical' errors compound and mask the root cause of critical issues"
    ],
    "keywords": ["error-handling", "catch", "silent-failure", "logging"],
    "domain": ["error-handling", "debugging"],
    "project": "default",
    "source_date": "2026-01-01",
    "created_at": "2026-01-01T00:00:00Z"
  },
  {
    "id": "726c03d4-8962-4b0f-89a2-ea1cd0b223aa",
    "learning_type": "scar",
    "title": "Untested Code Passes By Coincidence",
    "description": "Code without tests may appear to work because the happy path succeeds, but untested edge cases silently fail. Tests that don't exist can't catch regressions. 'It works on my machine' is not a test — write assertions for the behavior you expect, especially boundary conditions and error paths.",
    "severity": "high",
    "scar_type": "process",
    "is_starter": true,
    "counter_arguments": [
      "The code is simple enough that tests aren't needed — but simple code gets modified later and regressions appear without test coverage",
      "Manual testing is sufficient for this — but manual tests don't run automatically and get skipped under time pressure"
    ],
    "keywords": ["testing", "coverage", "regression", "assertions", "edge-cases"],
    "domain": ["testing", "quality"],
    "project": "default",
    "source_date": "2026-01-01",
    "created_at": "2026-01-01T00:00:00Z"
  },
  {
    "id": "8a376e29-dc8d-49a7-b840-28643086e90a",
    "learning_type": "scar",
    "title": "Environment Config Drift Between Local and Production",
    "description": "Environment variables, feature flags, and configuration that differ between local dev and production cause bugs that only appear after deployment. The fix works locally but breaks in prod because of a missing env var, different API URL, or stricter security policy. Keep a canonical list of all config, validate it at startup, and test with production-like config.",
    "severity": "high",
    "scar_type": "operational",
    "is_starter": true,
    "counter_arguments": [
      "We use the same .env file everywhere — but .env files drift silently and new variables get added locally without updating production",
      "Our staging environment matches production — but staging configs still diverge over time without automated drift detection"
    ],
    "keywords": ["environment", "config", "env-vars", "production", "deployment", "drift"],
    "domain": ["config", "deployment"],
    "project": "default",
    "source_date": "2026-01-01",
    "created_at": "2026-01-01T00:00:00Z"
  },
  {
    "id": "b6a9ac29-25ba-4667-9fed-0ada98dd588e",
    "learning_type": "scar",
    "title": "Changing Dependencies Without Checking Breaking Changes",
    "description": "Upgrading or adding dependencies without reading the changelog introduces breaking changes that surface later as mysterious failures. Semver violations are common — a minor version bump can still break your code. Always read the changelog, check for breaking changes, and run your test suite after any dependency change.",
    "severity": "medium",
    "scar_type": "process",
    "is_starter": true,
    "counter_arguments": [
      "It's just a patch version so it should be safe — but semver is a social contract, not a guarantee, and patch releases do contain breaking changes",
      "Our lockfile protects us — but lockfiles only help if everyone uses them consistently and CI doesn't do fresh installs"
    ],
    "keywords": ["dependencies", "npm", "upgrade", "breaking-changes", "changelog", "semver"],
    "domain": ["dependencies", "maintenance"],
    "project": "default",
    "source_date": "2026-01-01",
    "created_at": "2026-01-01T00:00:00Z"
  },
  {
    "id": "5db0ffc7-e6d8-48bc-aa23-fce7fd8eaadb",
    "learning_type": "scar",
    "title": "Fixing Symptoms Instead of Root Causes",
    "description": "Adding workarounds, special cases, or retry logic to mask a bug treats the symptom while the root cause remains. The workaround becomes tech debt that makes the real fix harder to find later. Before writing a fix, trace the execution path to understand WHY the failure happens, not just WHERE it happens.",
    "severity": "high",
    "scar_type": "process",
    "is_starter": true,
    "counter_arguments": [
      "We need a quick fix now and can investigate later — but 'later' rarely comes and the workaround becomes permanent",
      "The root cause is in a system we don't control — but understanding the root cause still helps write a better workaround with clear documentation"
    ],
    "keywords": ["debugging", "root-cause", "workaround", "tech-debt", "symptoms"],
    "domain": ["debugging", "engineering"],
    "project": "default",
    "source_date": "2026-01-01",
    "created_at": "2026-01-01T00:00:00Z"
  },
  {
    "id": "5c1111a9-c161-4b2d-83f9-063780164b7c",
    "learning_type": "scar",
    "title": "Sub-agents Start With Zero Context — Always Inject Memory",
    "description": "When you spawn a sub-agent (Task tool), it starts with a blank slate — no conversation history, no institutional memory, no project context. If you don't explicitly inject context via prepare_context or a detailed prompt, the sub-agent will repeat mistakes the team already learned from. The 2-3 seconds to prepare context prevents minutes of wasted work.",
    "severity": "high",
    "scar_type": "process",
    "is_starter": true,
    "counter_arguments": [
      "The sub-agent has access to the same tools so it can figure things out — but without memory context it will rediscover pitfalls the hard way",
      "Injecting context slows down spawning — but 2-3 seconds of prep prevents full task re-runs when the agent hits a known issue"
    ],
    "keywords": ["sub-agent", "task-tool", "context", "delegation", "multi-agent", "prepare-context"],
    "domain": ["multi-agent", "delegation"],
    "project": "default",
    "source_date": "2026-02-22",
    "created_at": "2026-02-22T00:00:00Z"
  },
  {
    "id": "f7d1dcb8-dcf1-48fb-9ab0-e682cd704530",
    "learning_type": "scar",
    "title": "Sub-agents Cannot See Your Conversation — Spell Out Everything",
    "description": "Sub-agents spawned via the Task tool do not inherit the parent conversation. They cannot see what the user asked, what files were discussed, or what decisions were made. Every requirement, file path, and constraint must be explicitly stated in the task prompt. Vague delegation like 'fix the bug we discussed' will fail because the sub-agent has no idea what was discussed.",
    "severity": "high",
    "scar_type": "process",
    "is_starter": true,
    "counter_arguments": [
      "The sub-agent description says it has 'access to current context' — but only certain agent types do, and even then the full nuance of the conversation may not transfer",
      "I can just tell it to 'continue the work' — but without explicit requirements the sub-agent will interpret 'the work' differently than you intended"
    ],
    "keywords": ["sub-agent", "delegation", "prompt", "requirements", "context-loss", "multi-agent"],
    "domain": ["multi-agent", "delegation"],
    "project": "default",
    "source_date": "2026-02-22",
    "created_at": "2026-02-22T00:00:00Z"
  },
  {
    "id": "060389aa-c0fa-445d-bbfd-5d9250dc1e73",
    "learning_type": "scar",
    "title": "Don't Pre-read Files Before Delegating — Let the Sub-agent Read Them",
    "description": "Reading files into your context before spawning a sub-agent wastes your context window and doesn't help the sub-agent (it can't see what you read). Instead, tell the sub-agent which files to read. The sub-agent has its own context budget and its own file access. Pre-reading just burns tokens twice.",
    "severity": "medium",
    "scar_type": "process",
    "is_starter": true,
    "counter_arguments": [
      "I need to understand the code before I can write a good prompt — true for architecture decisions, but for 'read and fix' tasks the sub-agent can do its own reading",
      "What if the sub-agent reads the wrong files — provide specific file paths in the prompt rather than reading them yourself"
    ],
    "keywords": ["sub-agent", "context-window", "delegation", "file-reading", "tokens", "multi-agent"],
    "domain": ["multi-agent", "efficiency"],
    "project": "default",
    "source_date": "2026-02-22",
    "created_at": "2026-02-22T00:00:00Z"
  },
  {
    "id": "55b25d2e-41ad-47f4-8723-569b78586dff",
    "learning_type": "scar",
    "title": "Search Memory Before Creating Learnings — Duplicates Dilute Recall",
    "description": "Before creating a new scar, win, or pattern, search existing memory first. Duplicate entries dilute recall quality — when the same lesson exists three times with slightly different wording, search results waste slots on redundant matches instead of surfacing diverse, relevant knowledge. One well-written scar beats three near-duplicates.",
    "severity": "medium",
    "scar_type": "process",
    "is_starter": true,
    "counter_arguments": [
      "Creating duplicates reinforces the lesson — but recall is similarity-based, so duplicates just crowd out other useful results",
      "My wording is better than the existing one — then update the existing entry instead of creating a new one"
    ],
    "keywords": ["memory", "search", "duplicates", "recall", "learning", "scar-creation"],
    "domain": ["memory-hygiene", "gitmem"],
    "project": "default",
    "source_date": "2026-02-22",
    "created_at": "2026-02-22T00:00:00Z"
  },
  {
    "id": "867cf3f6-a0e5-4ca2-8d4d-43cb1f10d94d",
    "learning_type": "scar",
    "title": "Ask Clarifying Questions Before Coding — 5 Seconds Prevents a Rewrite",
    "description": "When requirements are ambiguous, ask a clarifying question before writing code. A 5-second question like 'Should this handle both cases or just the first?' prevents building the wrong thing and having to rewrite. Assumptions that seem obvious are often wrong. The cost of asking is near-zero; the cost of a wrong assumption is a full task redo.",
    "severity": "high",
    "scar_type": "process",
    "is_starter": true,
    "counter_arguments": [
      "Asking too many questions slows things down — but one targeted question is faster than a rewrite after building the wrong thing",
      "I can just build both options and let the user pick — but that's double the work and the user wanted a decision, not a menu"
    ],
    "keywords": ["requirements", "clarification", "assumptions", "communication", "rewrite"],
    "domain": ["communication", "planning"],
    "project": "default",
    "source_date": "2026-02-22",
    "created_at": "2026-02-22T00:00:00Z"
  }
]