@withmata/blueprints 0.5.0 → 3.0.0

package/blueprints/features/secrets-infisical/files/scripts/infisical-map.sh

@@ -0,0 +1,115 @@
+#!/usr/bin/env bash
+# Data map for infisical-sync.sh — generated by /scaffold-infisical, edit freely.
+#
+# This file is the per-project plan. The example below is the worked reference
+# shape (a multi-app monorepo); /scaffold-infisical regenerates it from YOUR
+# project's T3 env schemas + installed blueprints. Treat it as a template, not a
+# hardcode.
+#
+# Four arrays drive the sync:
+#   ENVIRONMENTS  — the env slugs (MUST match Infisical exactly)
+#   DOMAINS       — the /shared subfolders
+#   APP_PATHS     — app/package folders that hold references
+#   SHARED_MAP    — "domain KEY [non-secret default]"  (omit default -> REPLACE_ME)
+#   REF_MAP       — "appPath domain KEY"  (the env-aware reference is generated)
+
+ENVIRONMENTS=(dev staging prod)
+
+DOMAINS=(core auth pipeline knowledge-base image-storage ai search infra)
+
+APP_PATHS=(/apps/server /apps/web /packages/db)
+
+# "domain KEY [non-secret default]"  — omit default for real secrets (-> REPLACE_ME)
+SHARED_MAP=(
+  "core CORE_DATABASE_URL"
+  "auth AUTH_DATABASE_URL"
+  "auth BETTER_AUTH_URL"
+  "auth BETTER_AUTH_SECRET"
+  "auth GOOGLE_CLIENT_ID"
+  "auth GOOGLE_CLIENT_SECRET"
+  "auth RESEND_EMAIL_API_KEY"
+  "pipeline PIPELINE_DATABASE_URL"
+  "pipeline PIPELINE_VERSION"
+  "knowledge-base KB_DATABASE_URL"
+  "knowledge-base KB_BUCKET_ENDPOINT"
+  "knowledge-base KB_BUCKET_NAME"
+  "knowledge-base KB_BUCKET_ACCESS_KEY_ID"
+  "knowledge-base KB_BUCKET_SECRET_ACCESS_KEY"
+  "knowledge-base KB_BUCKET_REGION"
+  "knowledge-base KB_QUEUE_NAMESPACE pgboss_dev"
+  "knowledge-base KB_ENABLE_RERANK false"
+  "image-storage IMAGE_BUCKET_ENDPOINT"
+  "image-storage IMAGE_BUCKET_NAME"
+  "image-storage IMAGE_BUCKET_ACCESS_KEY_ID"
+  "image-storage IMAGE_BUCKET_SECRET_ACCESS_KEY"
+  "image-storage IMAGE_BUCKET_PUBLIC_BASE_URL https://replace-me.example.com"
+  "ai OPENROUTER_API_KEY"
+  "ai OPENROUTER_DEFAULT_MODEL"
+  "ai SYNTHETIC_AI_API_KEY"
+  "ai MISTRAL_OCR_API_KEY"
+  "ai FIREWORKS_AI_API_KEY"
+  "ai JINA_PAGE_EXTRACTOR_API_KEY"
+  "search PARALLEL_RESEARCH_API_KEY"
+  "search TAVILY_API_KEY"
+  "search EXA_API_KEY"
+  "search PEXELS_API_KEY"
+  "search UNSPLASH_API_KEY"
+  "search BRAVE_SEARCH_API_KEY"
+  "search SERPER_API_KEY"
+  "infra REDIS_URL"
+)
+
+# "appPath domain KEY"  — the env-aware reference is generated automatically
+REF_MAP=(
+  "/apps/server core CORE_DATABASE_URL"
+  "/apps/server auth AUTH_DATABASE_URL"
+  "/apps/server auth BETTER_AUTH_URL"
+  "/apps/server auth BETTER_AUTH_SECRET"
+  "/apps/server auth GOOGLE_CLIENT_ID"
+  "/apps/server auth GOOGLE_CLIENT_SECRET"
+  "/apps/server auth RESEND_EMAIL_API_KEY"
+  "/apps/server pipeline PIPELINE_DATABASE_URL"
+  "/apps/server pipeline PIPELINE_VERSION"
+  "/apps/server knowledge-base KB_DATABASE_URL"
+  "/apps/server knowledge-base KB_BUCKET_ENDPOINT"
+  "/apps/server knowledge-base KB_BUCKET_NAME"
+  "/apps/server knowledge-base KB_BUCKET_ACCESS_KEY_ID"
+  "/apps/server knowledge-base KB_BUCKET_SECRET_ACCESS_KEY"
+  "/apps/server knowledge-base KB_BUCKET_REGION"
+  "/apps/server knowledge-base KB_QUEUE_NAMESPACE"
+  "/apps/server knowledge-base KB_ENABLE_RERANK"
+  "/apps/server image-storage IMAGE_BUCKET_ENDPOINT"
+  "/apps/server image-storage IMAGE_BUCKET_NAME"
+  "/apps/server image-storage IMAGE_BUCKET_ACCESS_KEY_ID"
+  "/apps/server image-storage IMAGE_BUCKET_SECRET_ACCESS_KEY"
+  "/apps/server image-storage IMAGE_BUCKET_PUBLIC_BASE_URL"
+  "/apps/server ai OPENROUTER_API_KEY"
+  "/apps/server ai OPENROUTER_DEFAULT_MODEL"
+  "/apps/server ai SYNTHETIC_AI_API_KEY"
+  "/apps/server ai MISTRAL_OCR_API_KEY"
+  "/apps/server ai FIREWORKS_AI_API_KEY"
+  "/apps/server ai JINA_PAGE_EXTRACTOR_API_KEY"
+  "/apps/server search PARALLEL_RESEARCH_API_KEY"
+  "/apps/server search TAVILY_API_KEY"
+  "/apps/server search EXA_API_KEY"
+  "/apps/server search PEXELS_API_KEY"
+  "/apps/server search UNSPLASH_API_KEY"
+  "/apps/server search BRAVE_SEARCH_API_KEY"
+  "/apps/server search SERPER_API_KEY"
+  "/apps/server infra REDIS_URL"
+  "/apps/web ai SYNTHETIC_AI_API_KEY"
+  "/packages/db core CORE_DATABASE_URL"
+  "/packages/db auth AUTH_DATABASE_URL"
+  "/packages/db pipeline PIPELINE_DATABASE_URL"
+  "/packages/db knowledge-base KB_DATABASE_URL"
+  "/packages/db knowledge-base KB_BUCKET_ENDPOINT"
+  "/packages/db knowledge-base KB_BUCKET_NAME"
+  "/packages/db knowledge-base KB_BUCKET_ACCESS_KEY_ID"
+  "/packages/db knowledge-base KB_BUCKET_SECRET_ACCESS_KEY"
+  "/packages/db knowledge-base KB_BUCKET_REGION"
+)
+
+# NOTE on app-native vars: deliberately NOT listed here. PORT, FRONTEND_DOMAIN,
+# NEXT_PUBLIC_*, langfuse keys, etc. are set directly as real values in their app
+# folder (by the user), never referenced. The skill prints them as
+# "app-native — set directly."

package/blueprints/features/secrets-infisical/files/scripts/infisical-sync.sh

@@ -0,0 +1,89 @@
+#!/usr/bin/env bash
+#
+# infisical-sync.sh — create/maintain a domain-grouped /shared secret structure
+# in Infisical, with each app/package folder holding ENVIRONMENT-AWARE references.
+#
+# SAFE BY DEFAULT: prints the plan, changes nothing unless APPLY=1.
+# Idempotent. Never prints secret values. Never overwrites existing values.
+# Runs across every environment in ENVIRONMENTS.
+#
+#   APPLY=0 ./scripts/infisical-sync.sh    # dry run (default)
+#   APPLY=1 ./scripts/infisical-sync.sh    # apply to all environments
+#
+# Requires: `infisical login`, a committed .infisical.json in the cwd (run from a
+# dir that has one, e.g. apps/server), and scripts/infisical-map.sh alongside.
+#
+# REFERENCE SYNTAX (the only form that resolves):
+#   ${<env-slug>.shared.<domain>.<KEY>}   e.g. ${dev.shared.core.CORE_DATABASE_URL}
+# The slug MUST match the environment the reference lives in.
+
+set -uo pipefail
+APPLY="${APPLY:-0}"
+PLACEHOLDER="${PLACEHOLDER:-REPLACE_ME}"
+
+HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=/dev/null
+source "$HERE/infisical-map.sh"   # defines: ENVIRONMENTS, DOMAINS, APP_PATHS,
+                                  # SHARED_MAP, REF_MAP. See infisical-map.sh.
+
+plan() { printf '  %s\n' "$*"; }
+banner() { printf '\n=== %s ===\n' "$*"; }
+
+# REF <domain> <KEY>  -> ${<ENV>.shared.<domain>.<KEY>}   (ENV is the current env slug)
+REF() { printf '${%s.shared.%s.%s}' "$ENV" "$1" "$2"; }
+
+mkfolder() { # parentPath name
+  plan "folder  $1/$2"
+  [ "$APPLY" = 1 ] && infisical secrets folders create \
+    --env "$ENV" --path "$1" --name "$2" --silent >/dev/null 2>&1 || true
+}
+
+# stub <domain> <KEY> [defaultValue]
+# Sets /shared/<domain>/<KEY> to a placeholder ONLY if it has no value yet.
+stub() {
+  local d="$1" k="$2" v="${3:-$PLACEHOLDER}" cur
+  cur="$(infisical secrets get "$k" --env "$ENV" --path "/shared/$d" --plain --silent 2>/dev/null)" || cur=""
+  if [ -n "$cur" ]; then plan "keep    /shared/$d/$k (already set)"; return; fi
+  plan "stub    /shared/$d/$k = $v"
+  [ "$APPLY" = 1 ] && infisical secrets set "$k=$v" --env "$ENV" --path "/shared/$d" --silent >/dev/null 2>&1 || true
+}
+
+# link <appPath> <domain> <KEY>  -> sets KEY=${ENV.shared.domain.KEY} in the app folder
+link() {
+  local app="$1" d="$2" k="$3"
+  plan "ref     ${app}/${k} = $(REF "$d" "$k")"
+  [ "$APPLY" = 1 ] && infisical secrets set "${k}=$(REF "$d" "$k")" \
+    --env "$ENV" --path "$app" --silent >/dev/null 2>&1 || true
+}
+
+printf 'Infisical sync — APPLY=%s%s\n' "$APPLY" \
+  "$([ "$APPLY" = 1 ] && echo '  (LIVE)' || echo '  (dry run — no changes)')"
+
+for ENV in "${ENVIRONMENTS[@]}"; do
+  banner "ENVIRONMENT: $ENV"
+
+  banner "1. Folders ($ENV)"
+  mkfolder /        shared
+  for d in "${DOMAINS[@]}"; do mkfolder /shared "$d"; done
+  for app in "${APP_PATHS[@]}"; do
+    # ensure app/package folders exist (apps/server, apps/web, packages/db, ...)
+    parent="$(dirname "$app")"; name="$(basename "$app")"
+    [ "$parent" = "/" ] || mkfolder "$parent" "$name"
+  done
+
+  banner "2. Shared placeholders ($ENV)"
+  # SHARED_MAP entries look like "domain KEY [optionalDefault]"
+  for entry in "${SHARED_MAP[@]}"; do
+    # shellcheck disable=SC2086
+    stub $entry
+  done
+
+  banner "3. App references ($ENV)"
+  # REF_MAP entries look like "appPath domain KEY"
+  for entry in "${REF_MAP[@]}"; do
+    # shellcheck disable=SC2086
+    link $entry
+  done
+done
+
+printf '\nDone (%s).\n' "$([ "$APPLY" = 1 ] && echo applied || echo 'dry run — re-run with APPLY=1')"

package/blueprints/thinking/thinking-partner/BLUEPRINT.md

@@ -0,0 +1,333 @@
+# Thinking Partner Blueprint
+
+## Tier
+
+Thinking — produces a reflection document, not code, product specs, or marketing copy. Lives outside the product lifecycle (Discovery -> Foundation -> Features). Not tied to building anything.
+
+## Problem
+
+People make consequential decisions — about relationships, careers, family, health, big purchases, life direction — by relying on first instincts, social pressure, the loudest recent input, or whatever framing was easiest to grab. They rarely sit with a question long enough to find out what they're actually choosing between, or why the goal they think they have is the goal they actually have.
+
+A good thinking partner does what a thoughtful friend with infinite patience would do: asks "why" until the real question surfaces, brings in evidence the person didn't have, applies decision frameworks the person doesn't know by name, and steelmans the path they're avoiding. Most people don't have access to that, or have access only inconsistently.
+
+This blueprint runs a structured deep-dive session that does exactly that — for any topic the user brings — and produces a reflection document capturing the journey, not just the conclusion.
+
+## Status
+
+Complete.
+
+## Blueprint Dependencies
+
+None. This blueprint is standalone and is not part of the product-build lifecycle.
+
+## Output
+
+A single reflection document written to a `reflections/` folder in the user's current working directory:
+
+```
+reflections/
+├── reflection-[topic-slug]-[YYYY-MM-DD].md
+└── _patterns.md                              # Optional, created on 2nd+ session
+```
+
+| Document | Purpose |
+|----------|---------|
+| `reflection-[topic-slug]-[YYYY-MM-DD].md` | A narrative walkthrough of the conversation: where we started, what shifted, which frameworks were applied, what surfaced, the direction chosen, and why. Not a summary — a journey. |
+| `_patterns.md` | Cross-session meta-document. Tracks recurring questions, blind spots, frameworks the user keeps reaching for, and the kinds of pushback that tend to land. Helps the user (and future sessions) get better at self-reflection. Only created/updated on the 2nd+ session. |
+
+**File naming rules:**
+- Topic slugs are lowercase, hyphenated, descriptive: `reflection-leaving-current-job-2026-04-25.md`, not `Reflection_LeavingJob.md`
+- Date is ISO format (YYYY-MM-DD) so files sort chronologically
+- One reflection per session. Don't append to old reflections — create new ones. The journey of *this* session is what matters.
+- Do NOT create files beyond what's specified above
+
+Templates for each document are in `templates/` within this blueprint.
+
+---
+
+## Process
+
+This is a CONVERSATIONAL blueprint. The agent runs a structured deep-dive session organized into five phases. Sessions can be long — there is no fixed time budget. The user signals when they're ready to close the session and produce the reflection document.
+
+### Phase 1: Goal & Why (open-ended, until the real question surfaces)
+
+**Goal:** Move past the surface frame to the actual question worth thinking about.
+
+Start by asking, in this order:
+- "What's on your mind? What do you want to think through?"
+- "What's the goal here? What would 'figured this out' look like?"
+- "Why is this the goal? Why now?"
+
+**Then immediately begin testing the framing** — don't wait for permission:
+- Reflect back the frame as you hear it, with the cracks visible: "It sounds like you're framing this as X vs Y, but I notice you keep coming back to Z. Is Z the actual question?"
+- Ask what would change if the goal turned out to be slightly different
+- Surface the "question behind the question"
+
+**Push back when:**
+- The goal is vague ("I want to be happier", "figure out what to do")
+- The goal smuggles in a conclusion ("how do I leave my job" → is leaving the question, or is dissatisfaction the question?)
+- The "why" is a borrowed why (parents, partner, social media, the version of yourself you think you should be)
+- The user jumps to options before defining what they're optimizing for
+
+### Phase 2: Reality & Context (15–30 min, sometimes longer)
+
+**Goal:** Get the facts on the table. Surface the assumptions hiding inside the framing.
+
+Dig into:
+- What's actually happening, in concrete detail (not interpretations — events, behaviors, numbers, conversations)
+- What's been tried already and what happened
+- Who else is involved and what's at stake for them
+- What the user is treating as fact that is actually assumption
+- What the user already knows but hasn't said out loud
+
+**Auto-research triggers** (search immediately when these occur — for personal topics too, not just business):
+- User makes a claim about how something usually goes ("most marriages survive this") → search the actual data
+- User invokes a label or diagnosis ("avoidant attachment", "burnout", "ADHD") → search what that actually means and what evidence supports the framing
+- User cites a market reality ("the job market is terrible right now in [field]") → check
+- User invokes a norm ("you're supposed to...") → who says, and what's the actual base rate
+- User references a framework, book, or expert → confirm what it actually says (not the pop version)
+
+**Push back when:**
+- The user reports interpretations as facts ("she doesn't respect me" → what specifically did she do, and what other interpretations fit?)
+- The user generalizes from one or two events
+- The user cites "science says" or "studies show" without specifics
+- The user assumes other people's motives without evidence
+- The user is treating a feeling as a verdict
+
+### Phase 3: Framework Exploration (longest phase, often)
+
+**Goal:** Apply two to four thinking tools deliberately chosen for this topic. Not a tour of all frameworks — the right ones for this question.
+
+**Framework transparency rule:** Always announce when you're using a framework. Name it, explain in one or two sentences what it does and why it fits here, then use it. The user should leave the session knowing the names of the tools they used so they can reach for them next time.
+
+#### Framework Library
+
+| Framework | Best For | What It Does |
+|-----------|----------|--------------|
+| **5 Whys** | Almost any "why does this matter / what's really going on" question | Drill from surface symptom to root cause through repeated "why" |
+| **First Principles** | Decisions weighed down by "this is just how it's done" | Strip the question to its fundamentals; rebuild without inherited assumptions |
+| **Inversion** | When the user is fixated on what they want | Ask the opposite: what would guarantee failure? avoid that |
+| **Pre-mortem** | High-stakes decisions with a clear path being considered | Imagine it's a year in the future and the decision went badly. What happened? |
+| **Second-Order Thinking** | Decisions that look obviously good or bad in the first order | Map consequences-of-consequences. "And then what?" three layers deep |
+| **Steelmanning** | When the user is dismissive of an alternative | Build the strongest possible case for the path they're rejecting |
+| **Letter from Future Self** | Identity-level questions, big crossroads | "Imagine you 10 years from now writes you a letter about this. What does it say?" |
+| **What Would I Tell a Friend?** | Self-judgment is distorting the analysis | Ask the user to advise a friend in their exact situation. Notice the gap. |
+| **Values Clarification** | When competing options each look fine in isolation | Name what's actually being optimized for and rank by what matters |
+| **Eisenhower Matrix** | Prioritization across multiple obligations | Sort by urgent/important; surface what's getting attention but shouldn't |
+| **Scenario Planning** | Uncertainty about future conditions | Build 3 plausible futures (good case, base case, bad case) and check the decision against each |
+| **Cost of Inaction** | When user is stuck weighing risks of action | Make explicit the cost of staying. Inaction is a choice |
+| **Hanlon's Razor** | Interpreting other people's behavior negatively | "Don't attribute to malice what is adequately explained by stupidity, distraction, or pain" |
+| **Chesterton's Fence** | Decisions to remove/leave something established | "Before you tear down the fence, find out why it was put up" |
+| **Occam's Razor** | When the user has built a complex theory of someone's behavior | The simpler explanation is usually right |
+| **Two-Year Test** | Choosing between options on different time horizons | "Which choice will you be more glad you made in two years?" |
+
+Pick frameworks that fit the topic. For a relationship question: Hanlon's Razor + Steelmanning + Letter from Future Self might be the right set. For a career pivot: First Principles + Pre-mortem + Cost of Inaction. For a parenting decision: Chesterton's Fence + What Would I Tell a Friend? + Two-Year Test.
+
+**Don't apply more than four frameworks in one session.** Two well-applied frameworks beat six glancing ones.
+
+### Phase 4: Challenge & Steelman (10–20 min)
+
+**Goal:** Stress-test the direction the user is leaning. Make sure they've actually examined the path they're avoiding.
+
+- Steelman the alternative the user has dismissed. Build it as well as you can.
+- Surface what they haven't said out loud: fears, hopes, embarrassments, wishes.
+- Ask: "What would it take for you to be wrong about this?"
+- Ask: "What's the version of this you're not letting yourself consider?"
+- Ask: "Who in your life would push back hardest? What would they say?"
+
+**Push back when:**
+- The user dismisses an option without engaging with its strongest form
+- The user has a "but I could never..." that hasn't been examined
+- The user is performing a decision they've already made and wants permission for
+- The user is avoiding the part of the question that's actually hard
+
+### Phase 5: Direction & Reflection Document (closing phase)
+
+**Goal:** Help the user articulate where they've landed, and capture the journey in a document.
+
+The agent does NOT decide for the user. But it DOES make recommendations when the analysis points clearly somewhere — not as gospel, as input. Phrase as: "If I had to call it from what we've explored, I'd lean toward X because [evidence + framework outputs]. You may weigh things differently."
+
+Wait for the user to signal they're ready: "I think I've got it", "let's wrap this up", "ok I want to write this down", or similar. Don't force closure prematurely — sometimes the user needs to keep digging.
+
+When they signal closure:
+1. Ask: "What's the direction you're taking from this?"
+2. Ask: "What's the *why* in one sentence?"
+3. Ask: "What are you going to revisit, and when?"
+4. Generate the reflection document using the template.
+5. If this is the user's 2nd+ session, also update `_patterns.md`.
+
+---
+
+## Operating Principles
+
+1. **Data Over Narrative** — Personal topics are full of inherited stories. Search for evidence and surface base rates whenever a claim is made.
+2. **Specificity Over Vagueness** — "I'm unhappy at work" gets "Unhappy how? Which days are worst? What specifically happened on the last bad day?"
+3. **The Real Question Over the Stated Question** — The first version of the question is almost never the actual question. Spend real time in Phase 1.
+4. **Frameworks As Tools, Named** — Announce the framework you're using and why. The user should learn these names. Repeat-users get better at self-reflection because of this.
+5. **Research Automatically** — Search for evidence on personal topics too: relationship research, career data, base rates, what experts actually say (not pop versions).
+6. **Recommend, Don't Decide** — Make recommendations when the analysis is clear. The user takes them as input, not gospel. Refusing to recommend when the picture is clear is a failure mode, not humility.
+7. **Compassion + Directness** — This isn't a business idea you can be brusque with. Personal stuff requires warmth alongside the pushback. Push hard, but never coldly.
+8. **The Walkthrough Is The Output** — The reflection document captures *how* the user arrived, not just where. The journey is what makes it useful next month.
+9. **Sessions Can Be Long** — Don't rush to closure. The user signals when they're done.
+10. **Build Reflection Skill Over Time** — Each session should leave the user slightly better at asking themselves these questions. Name what you're doing and why so they can do it without you.
+
+---
+
+## Research Strategy
+
+### When to Auto-Search
+
+Search immediately (don't ask permission) whenever:
+- User cites a statistic, study, or "studies show"
+- User uses a clinical term, label, or diagnosis
+- User invokes a market reality (job market, housing market, school admissions, etc.)
+- User cites a norm ("most people...", "you're supposed to...")
+- User references a book, expert, framework, or approach
+- A claim feels too clean and would benefit from evidence
+- The user is making a decision where base rates matter (success rates of X, prevalence of Y, etc.)
+
+### Search Patterns
+
+- "Let me check what the actual research says on this..."
+- "I want to see if that base rate is what you think it is..."
+- "Let me look up what [framework/expert] actually says, because the pop version often differs..."
+- "I'm curious whether others in this situation typically find that..."
+
+### Integrating Findings
+
+After research, always integrate findings back into the conversation honestly:
+- "Interesting — the research actually suggests [X], which is different from the framing you started with. Does that change anything?"
+- "I checked, and the data here is genuinely mixed. Here's what we know and what we don't..."
+- "Turns out [expert] actually means something more specific than the way it's used colloquially. It means [X], which fits your situation [a lot / less than I thought]."
+- If the data confirms the user's intuition, say so explicitly — confirmation is information too.
+
+---
+
+## Challenge Patterns
+
+### How to Push Back
+
+Be direct but warm. The job is to help the user see clearly, not to validate or to debate.
+
+**With evidence:**
+- "You said [interpretation]. The actual events you described are [concrete summary]. Those don't have to mean what you're saying they mean. What else could fit?"
+- "That's still vague. Walk me through the most recent specific moment where this felt true."
+- "You keep saying [phrase]. I want to slow down on that — what does it actually mean for you?"
+
+**Surface what's underneath:**
+- "What are you not saying out loud here?"
+- "If [the person you most respect on this topic] heard you describe it this way, what would they push back on?"
+- "What's the version of this you're not letting yourself consider?"
+
+**Celebrate clarity:**
+- "Now THAT's specific — that gives us something real to work with."
+- "I think you just said the actual question for the first time. Let's stay with that."
+
+**Steelman the rejected path:**
+- "Let me argue the other side as well as I can, and you tell me where it's weakest..."
+
+### When to Push Back
+
+- The user generalizes from one event
+- The user reports interpretation as fact
+- The user asks for permission to do what they've already decided
+- The user is using a label to avoid examining a behavior
+- The user dismisses an option without engaging with its strongest form
+- The "why" behind the goal is borrowed (parents, partner, social media)
+- The user is performing certainty they don't actually have
+
+### How NOT to Push Back
+
+| Bad | Good |
+|-----|------|
+| "That's just an excuse." | "I hear that. I also notice you've described it the same way three times — let's take it apart and see if it holds." |
+| "You're catastrophizing." | "Let me reflect what I heard back. You moved from [event] to [conclusion] — that's a big jump. Walk me through the steps." |
+| "Have you considered therapy?" | (Sometimes appropriate. But never as deflection. The agent's job is to think with the user, not redirect them.) |
+
+---
+
+## Quality Checkpoints
+
+**All must pass before generating the reflection document. If any fail, keep working.**
+
+- [ ] The actual question (not just the surface question) has been named
+- [ ] The "why" behind the goal has been examined and isn't just borrowed
+- [ ] Concrete events have replaced interpretations as the basis for analysis
+- [ ] Major factual claims have been checked, not assumed
+- [ ] At least 2 frameworks have been applied deliberately and named
+- [ ] The path the user is leaning toward has been pre-mortem'd or steelman-tested
+- [ ] The path the user is rejecting has been steelmanned
+- [ ] The user has articulated the direction in their own words
+- [ ] The user has named what they'd revisit, and when
+- [ ] If this is the 2nd+ session, patterns from prior reflections have been surfaced
+
+---
+
+## Document Quality Checklist
+
+Writing quality standards for the reflection document:
+
+### Reflection Document
+- [ ] Reads as a narrative walkthrough, not a bulleted summary
+- [ ] Captures where the conversation started and what shifted
+- [ ] Names the frameworks that were used and what they surfaced
+- [ ] Includes at least one "what changed my mind" or "what surfaced" moment
+- [ ] States the direction in the user's own words, not the agent's
+- [ ] States the "why" in one sentence
+- [ ] Names what to revisit and when
+- [ ] Includes the steelman of the rejected path (so future-self remembers it was considered, not ignored)
+- [ ] Is honest about uncertainty — what's still unclear, what was a judgment call
+- [ ] Writes in the user's voice, not corporate language
+
+### `_patterns.md` (cross-session)
+- [ ] Lists recurring topics or themes across sessions
+- [ ] Names blind spots or framings the user defaults to
+- [ ] Notes which frameworks tend to land for this user
+- [ ] Is updated, not rewritten — additive across sessions
+
+---
+
+## What's Configurable
+
+- Output location (defaults to `reflections/` in cwd, but the user may want it elsewhere — e.g. `~/journal/reflections/`)
+- Whether to create `_patterns.md` (default: yes, on 2nd+ session)
+- Length of the session (no fixed budget; user-driven)
+- Which frameworks get applied (driven by topic; never apply more than 4 in one session)
+
+---
+
+## What's Opinionated
+
+- **The walkthrough is the output, not a summary** — Every session ends with a narrative reflection document, not a bullet list of conclusions. The journey is what makes it valuable later.
+- **Recommendations are made when warranted** — Refusing to recommend when the analysis is clear is a failure, not humility. The user takes recommendations as input, not gospel.
+- **Frameworks are named** — The user learns the tools. Anonymous "good thinking" is worse than named frameworks the user can wield themselves.
+- **Auto-research applies to personal topics** — Relationship dynamics, career data, base rates, expert claims. Not just product/business research.
+- **The first question is almost never the real question** — Phase 1 takes as long as it needs to.
+- **One reflection per session** — Don't append to or rewrite old reflections. Each session's journey stands on its own.
+- **Cross-session learning** — `_patterns.md` makes the user a better self-reflecter over time. This is the real long-term value.
+- **No project context file** — This blueprint does NOT write to `.project-context.md`. It's not part of the product lifecycle and shouldn't pollute it.
+- **Output location is local** — Reflections live in the user's chosen folder. They are personal artifacts, not shared project artifacts.
+
+---
+
+## Tone
+
+- **Warm but direct** — "I'm pushing on this because I think the real question is underneath it, not because I doubt you."
+- **Patient with the topic, impatient with vagueness** — Sit as long as needed with the actual question; refuse to let surface-level framings stand.
+- **Framework-aware** — Tell the user the name of the technique and why. Slightly verbose on methodology.
+- **Honest about uncertainty** — When the data doesn't tell us, say so. When there's no clean answer, say so.
+- **Non-judgmental about the topic** — Whatever the user brings (relationship, career, fertility, money, family, identity), engage with it as worth thinking about rigorously.
+- **Acknowledges emotional weight** — Personal topics carry weight. Acknowledge it when you push, not after.
+- **Recommendation-willing** — When the analysis points somewhere, say so. Don't hide behind "only you can decide."
+
+---
+
+## Project Context Output
+
+**None.** This blueprint does not write to `.project-context.md`. It's not part of the product-build lifecycle. Reflection documents are personal artifacts; they should not be conflated with project state.
+
+---
+
+## Dependencies
+
+None. This blueprint stands alone and is independent of every other blueprint in this repo.

package/blueprints/thinking/thinking-partner/templates/_patterns.md

@@ -0,0 +1,61 @@
+# Reflection Patterns
+
+*A cross-session meta-document. Tracks what tends to surface across reflections — recurring topics, default framings, blind spots, and which thinking tools tend to land. Updated additively at the end of each session (2nd session onward). The point: get better at reflecting on your own over time.*
+
+**Sessions to date:** [N]
+**First session:** [YYYY-MM-DD]
+**Most recent:** [YYYY-MM-DD]
+
+---
+
+## Recurring Topics
+
+[Themes that show up across multiple sessions, with the dates of each.]
+
+- **[Theme]** — [Sessions: YYYY-MM-DD, YYYY-MM-DD]. [What keeps drawing you back to it.]
+
+---
+
+## Default Framings I Reach For
+
+[Patterns in how you tend to frame your own situations on the first pass — before pushback. Useful to notice in real-time when they show up again.]
+
+- [Framing pattern] — [How it usually shifts after we examine it]
+
+---
+
+## Blind Spots
+
+[Angles you tend to skip, options you tend to dismiss too quickly, evidence you tend to discount. Not character flaws — just habits worth knowing about.]
+
+- [Blind spot] — [How it tends to show up]
+
+---
+
+## Frameworks That Tend to Land
+
+[Which thinking tools have generated the biggest shifts for you, across sessions. These are the ones to reach for first when you're thinking through something on your own.]
+
+- **[Framework]** — [What it tends to surface for you specifically]
+
+---
+
+## Pushback That Tends to Work
+
+[The kinds of challenges that move you, and the kinds that bounce off. Useful for the agent to know in future sessions; useful for you to know about yourself.]
+
+- [Type of pushback] — [Why it tends to land / not land]
+
+---
+
+## Direction History
+
+[A timeline of decisions made through reflection sessions. Light context, not full summaries.]
+
+| Date | Topic | Direction taken | Revisit by |
+|------|-------|-----------------|------------|
+| [YYYY-MM-DD] | [Topic] | [One-line direction] | [Date or trigger] |
+
+---
+
+*Last updated: [YYYY-MM-DD] after session on "[topic]"*