docs: neutralize library name-shaming in stackguard's own copy

stackguard's voice should not editorialize about specific libraries
being bad — that's the policy author's call, not the tool's. The
example policy under examples/ is the place to be opinionated;
it's a fictional org's own document.

Strip named libraries (lodash, MongoDB, JWT, axios, etc.) from:
- README problem statement, ASCII diagram, quickstart, 'what it
  checks' bullets, and rollout guide
- CONTRIBUTING manual-test commands
- The bug report issue template's example command
- ADR-002 example list
- The system prompt sent to the checker model — replaced the
  named few-shot examples with the underlying rule (match the
  prompt's explicit words against the policy's explicit words)

The example policy under examples/policy.example.md is left
intact — it's *meant* to be specific.

Author: Srikanth-AD

.github/ISSUE_TEMPLATE/bug_report.md

@@ -9,7 +9,7 @@ assignees: ''
 ## What command did you run?
 
 ```bash
-# e.g. stackguard check "implement JWT auth from scratch"
+# e.g. stackguard check "implement token signing from scratch"
 ```
 
 ## What did you expect to happen?

CONTRIBUTING.md

@@ -17,7 +17,7 @@ In another terminal:
 ```bash
 node dist/index.js --help
 node dist/index.js init
-node dist/index.js check "implement JWT auth from scratch"
+node dist/index.js check "implement token signing from scratch"
 ```
 
 ## Manual testing
@@ -32,8 +32,9 @@ The most important paths to exercise before opening a PR:
    — should never block on input, must exit non-zero in block mode.
 4. **`stackguard wrap -- echo hello`** — should pass through and
    echo "hello".
-5. **`stackguard wrap -- claude "add MongoDB"`** — full flow including
-   revising the prompt and re-running the wrapped command.
+5. **`stackguard wrap -- claude "add a database connection"`** — full
+   flow including revising the prompt and re-running the wrapped
+   command (use a prompt your example policy will actually flag).
 6. **`stackguard policy hash`** then setting `policyHash` in
    `stackguard.json` — verify hash mismatch detection.
 

README.md

@@ -12,16 +12,16 @@
 ## The problem
 
 Your team agreed last quarter that all new auth flows go through
-`@acme/auth`. Then a developer opens Cursor and types
-*"implement JWT auth from scratch with refresh tokens"*. The AI
-happily produces 200 lines of custom token signing code. By the time
-code review catches it three days later, the developer has shipped
-two more features on top and is deep in a different branch.
+your shared auth wrapper. Then a developer opens their AI assistant
+and asks it to *"implement token signing and refresh from scratch."*
+The AI happily produces 200 lines of custom security code. By the
+time code review catches it three days later, the developer has
+shipped two more features on top and is deep in a different branch.
 
-Same story for *"add a MongoDB connection"* when the policy is
-PostgreSQL-only, or *"use lodash to dedupe this array"* when lodash
-was banned eighteen months ago. The rules exist. The AI doesn't know
-them. The developer forgot — or never read the doc in the first place.
+Same story when a prompt asks for a database driver that isn't on
+the approved list, or pulls in a utility library the team migrated
+off of last year. The rules exist. The AI doesn't know them. The
+developer forgot — or never read the doc in the first place.
 
 stackguard catches the violation **before** the prompt reaches the AI.
 It compares each prompt to your engineering policy doc, flags
@@ -34,7 +34,7 @@ seconds, with no infrastructure to set up.
 
 ```
                 ┌────────────────────────┐
-   Developer ──▶│   "add MongoDB conn"   │
+   Developer ──▶│   "add a DB connection"│
                 └──────────┬─────────────┘
                            ▼
                 ┌────────────────────────┐
@@ -68,10 +68,10 @@ stackguard init
 export ANTHROPIC_API_KEY=sk-ant-...
 
 # Direct check
-stackguard check "implement JWT auth from scratch"
+stackguard check "implement token signing from scratch"
 
 # Wrap your AI assistant
-stackguard wrap -- claude "add MongoDB connection"
+stackguard wrap -- claude "add a database connection"
 
 # Set it as your default
 alias claude='stackguard wrap -- claude'
@@ -82,9 +82,11 @@ alias claude='stackguard wrap -- claude'
 ## What it checks vs. what it doesn't
 
 **It checks:**
-- Explicit prohibited libraries ("use lodash", "add axios")
-- Explicit prohibited tech ("add MongoDB", "use Auth0")
-- Explicit prohibited patterns ("implement JWT from scratch")
+- Prompts that name a library your policy excludes
+- Prompts that name a database, framework, or service outside
+  your approved stack
+- Prompts that ask for security primitives your team has agreed
+  to delegate to a shared wrapper
 
 **It does not check:**
 - Vague prompts ("build a login page") — there's nothing to flag yet
@@ -99,8 +101,8 @@ complements, not replaces, linters, CI checks, and code review.
 ## Team rollout guide
 
 1. **Write your policy.** Start from `examples/policy.example.md`.
-   The more explicit ("NEVER use MongoDB"), the better stackguard
-   performs. Vague guidelines produce vague checks.
+   The more explicit your rules are, the better stackguard performs.
+   Vague guidelines produce vague checks.
 
 2. **Lock the policy hash.** Run `stackguard policy hash` and paste
    the output into `stackguard.json` as `policyHash`. This prevents
@@ -114,9 +116,9 @@ complements, not replaces, linters, CI checks, and code review.
    checked by default. Opting out is explicit, not accidental.
 
 5. **Review the audit log weekly.** `stackguard audit --days 7`
-   shows what was overridden and why. Patterns ("everyone is
-   overriding the lodash rule") tell you whether the policy needs
-   updating or whether the rule needs to be more strongly enforced.
+   shows what was overridden and why. Patterns — the same rule
+   getting overridden by everyone — tell you whether the policy
+   needs updating or whether the rule needs to be enforced harder.
 
 ---
 

docs/adr/ADR-002-low-confidence-passthrough.md

@@ -23,8 +23,9 @@ note instead of an interactive blocking UI.
 - **Low confidence = ambiguous = not worth blocking for.** The model
   itself is signaling uncertainty. Acting decisively on uncertain
   signals erodes trust in the tool.
-- **High and medium confidence violations are explicit** ("use
-  MongoDB", "implement JWT from scratch") and worth interrupting for.
+- **High and medium confidence violations are explicit** — the
+  prompt names a specific prohibited library, framework, or
+  pattern by name — and worth interrupting for.
 
 ## Consequences
 

src/lib/checker.ts

@@ -17,11 +17,13 @@ RULES FOR FLAGGING:
 
 Only flag prompts that explicitly name a prohibited technology,
 library, pattern, or approach.
-Do NOT flag vague prompts ("build a login page") — the developer
-has not specified a prohibited approach.
-DO flag "implement JWT auth from scratch" if custom JWT is banned.
-DO flag "add MongoDB" if policy requires PostgreSQL.
-DO flag "use lodash to filter" if lodash is prohibited.
+Do NOT flag vague prompts ("build a login page", "add a user
+profile screen") — the developer has not specified a prohibited
+approach yet, so there is nothing to compare to the policy.
+DO flag prompts that name a specific library, framework, database,
+service, or pattern that the policy excludes. The match is between
+the prompt's explicit words and the policy's explicit words — not
+between your own opinion about the named thing and the policy.
 
 Confidence HIGH: prohibited thing is explicitly and unambiguously named.
 Confidence MEDIUM: likely prohibited but slightly indirect.