rhachet-roles-ehmpathy 1.15.13 → 1.15.14

package/dist/roles/bhrain/briefs/thinker.tactics/<diverge>._.[article].frame.tactical.md

@@ -1,89 +0,0 @@
-# 🧩 .brief: `diverge.refs`
-
-## .what
-**`diverge.refs`** is a **generation tactic** that creates multiple distinct `[concept][ref]` (reference) forms from a single seed question.
-instead of locking into one framing, it **branches** the expression into alternative answer-forms — each still anchored to the intent of the original question.
-
----
-
-## 🎯 goal
-- explore **variety in expression** while retaining core meaning
-- surface **different entry points** for the same underlying concept
-- identify **strongest, most resonant refs** for specific audiences or purposes
-
----
-
-## 📜 contract
-for `<diverge.refs>` to work as intended:
-
-input = [seed][question]
-  - **only questions** — the `[seed][ref]` **must** be phrased as a question that clearly guides what to diverge into.
-  - **no statements** — statement seeds are disallowed, as they create uncertainty about whether outputs should be synonyms, examples, or subtopics.
-
-output = [concept][ref]
-  - **only answers** — each divergence **must** be an **alternative answer reference** to the seed question.
-
-**why this contract exists:**
-- questions naturally define a **search space of possible answers**, capable of precise generation guidance
-- answers can be compared for **completeness and variety** relative to the same inquiry
-- keeps outputs consistently interpretable as **answer-forms** to the same guiding question
-
----
-
-## ⚙️ method
-1. **anchor to the seed question**
-   - start from a single clear question (seed `[ref]`)
-   - clarify the essential meaning to preserve across all divergences
-
-2. **generate branches**
-   - vary along one or more axes relevant to the goal
-   - ensure each `[ref]` is **meaningfully different**, not just cosmetic rewording
-
-3. **assess & refine**
-   - check for clarity, accuracy, and audience fit
-   - prune weak or redundant variations
-
----
-
-## 📐 when to use
-- when testing **messaging resonance**
-- when creating **menus of choices** or **navigation labels**
-- when brainstorming **campaign slogans, feature names, or thematic headers**
-
----
-
-## 🖼 examples
-
-### example 1
-
-**seed `[ref]`:** "what makes historic train travel memorable?"
-
-- "luxury journeys aboard restored locomotives"
-- "guided scenic tours through mountain passes"
-- "onboard dining with period-accurate menus"
-- "storytelling from railway historians"
-- "overnight sleeper cars with vintage charm"
-
----
-
-### example 2
-
-**seed `[ref]`:** "how can cooks work smarter in the kitchen?"
-
-- "by prepping ingredients in bulk ahead of time"
-- "by keeping knives sharpened for faster cutting"
-- "by labeling and dating all stored food"
-- "by cleaning as they go to save time"
-- "by organizing stations for smoother workflow"
-
----
-
-### example 3
-
-**seed `[ref]`:** "what are different types of ducks?"
-
-- "mallard"
-- "wood duck"
-- "northern pintail"
-- "muscovy duck"
-- "american black duck"

package/dist/roles/bhrain/briefs/thinker.tactics/<elaborate>_vs_<elucidate>.[seed].md

@@ -1 +0,0 @@
-To elucidate is to make something clear and easy to understand, essentially to shed light on it, while to elaborate is to provide more details, information, or examples to expand upon a topic or idea. The choice depends on whether the goal is to clarify a concept or to provide greater depth and breadth of information about it.

package/dist/roles/bhrain/briefs/thinker.tactics/<enquestion>._.[article].md

@@ -1,113 +0,0 @@
-# ❓ .brief: `<enquestion>`
-
-## 🧭 .what
-**`<enquestion>`** is a **structural traversal mechanism** that **leverages the `<ponder>` framework**
-to generate the **questions needed to advance toward a goal**.
-
-It consumes:
-- **`ponder`** — curated or pre-authored questions organized into `<contextualize>` and `<conceptualize>` subgoals (per the `<ponder>` contract)
-- **`focus`** — the current state of questioning (`focus.concept`) and the situational frame (`focus.context`)
-
-It produces:
-1. An **enriched `ponder`** with context-aware insights for each seed question.
-2. A **`produce.questions`** set — the refined, ready-to-ask questions that bridge context to goal.
-
-Because `<enquestion>` itself **uses `<ponder>`** internally:
-- It can be **chained with downstream `<ponder>` calls** — producing questions that feed into subsequent pondering stages.
-- It can **loop with itself** — where the output `produce.questions` becomes the new `focus.concept`, allowing iterative deepening of inquiry.
-
----
-
-## 🔗 relationship to `focus.sufficiency`
-In `focus.sufficiency`, most failures come from:
-1. **Context gap** → missing something in `focus.context`
-2. **Concept gap** → missing something in `focus.concept`
-
-`<enquestion>` helps overcome both failure modes by:
-- Using `<ponder>`’s `<contextualize>` to fill gaps in `focus.context`.
-- Using `<ponder>`’s `<conceptualize>` to shift or refine the `focus.concept` anchor.
-
----
-
-## 🧠 input / output contract
-
-### 📥 input
-\`\`\`ts
-type PonderQuestions = {
-  contextualize: string[],
-  conceptualize: string[]
-}
-
-type EnquestionInput = {
-  ponder: PonderQuestions,
-  focus: {
-    concept: Maybe<PonderQuestions>, // enquestion upserts ponder questions
-    context: {
-      goal: string,            // required for ponder
-      ...other context facts   // optional, domain-specific
-    }
-  }
-}
-\`\`\`
-- `ponder` = question seeds from `<ponder>`, structured by subgoal.
-- `focus.concept` = the *current state* of questioning.
-- `focus.context` = the situation, **must** include `.goal`.
-
----
-
-### 📤 output
-\`\`\`ts
-type PonderAnswers = {
-  contextualize: Record<string, string>,
-  conceptualize: Record<string, string>
-}
-
-type EnquestionOutput = {
-  ponder: PonderAnswers,
-  produce: {
-    questions: PonderQuestions
-  }
-}
-\`\`\`
-- Output `ponder` enriches the seeds with contextual rationale.
-- Output `produce.questions` contains the **final, ready-to-use** question set.
-- These `produce.questions` can be used as **input to downstream `<ponder>` calls** or to the **next `<enquestion>` iteration**.
-
----
-
-## 🌿 exploration of the question treestruct fabric
-Questions inhabit a **semantic treestruct** — a branching space defined by:
-- **Axes** (categorical, temporal, causal, etc.)
-- **Depth** (abstraction vs. instantiation)
-- **Breadth** (variation in attribute or structure)
-- **Acuity** (articulation or decomposition)
-
-`<enquestion>` explores this fabric to:
-- Identify **possible branches** from `<ponder>`’s seeds.
-- Expand or condense branches based on goal utility.
-- Map **follow-up pathways** so inquiry flows logically.
-
----
-
-## 📦 system pattern
-\`\`\`ts
-<enquestion>.with({ contextualize, conceptualize })({
-  ponder,
-  focus
-})
-→ { ponder: {...}, produce: { questions: {...} } }
-\`\`\`
-
----
-
-## 💡 runtime / devtime reflection
-- **Runtime**: dynamically adapt questions as focus/context changes.
-- **Devtime**: tune `<ponder>` question seeds for domain-specific flows.
-
----
-
-## 📎 notes
-- `<enquestion>` is a **consumer** of `<ponder>`; it applies `<ponder>`’s `<contextualize>` and `<conceptualize>` subgoals to generate, adapt, and arrange questions into a goal-driven sequence.
-- **Downstream use**: The resulting `produce.questions` can directly seed new `<ponder>` calls for further semantic refinement.
-- **Looping**: Since it uses `<ponder>`, `<enquestion>` can call itself iteratively, deepening or broadening inquiry as needed.
-- Treats inquiry as **navigating the question treestruct fabric**, not generating in isolation.

package/dist/roles/bhrain/briefs/thinker.tactics/<enquestion>._.[gallery].plumber.diagnose.md

@@ -1,130 +0,0 @@
----
-
-## 🛠️ example — <enquestion> a devtime PonderQuestions kit for `@[plumber]<diagnose>` → runtime reuse
-
-**intent**
-Produce a **general-purpose devtime `PonderQuestions` kit** for `<diagnose>` in plumbing.
-At **runtime**, any plumber plugs in case-specific facts and **reuses the same kit** to save time and keep diagnosis consistent.
-
----
-
-### 📥 devtime input to `<enquestion>`
-\`\`\`ts
-ponder: {
-  contextualize: [
-    // meta-questions whose answers generate case-ready questions
-    "which observable conditions would *spawn* follow-up diagnostics?",
-    "which environment factors would *change* the diagnostic path?",
-    "which usage/repair history would *influence* failure likelihood?"
-  ],
-  conceptualize: [
-    "which subsystems, treated as suspects, *generate* distinct tests?",
-    "which minimal discriminators best *split* root causes early?",
-    "which symptom patterns should *trigger* immediate checks?"
-  ]
-},
-focus: {
-  concept: null,
-  context: { goal: "design a reusable diagnosis question set for plumbing" }
-}
-\`\`\`
-
----
-
-### 📤 devtime output from `<enquestion>` (the reusable kit)
-\`\`\`ts
-{
-  ponder: {
-    contextualize: {
-      "which observable conditions would *spawn* follow-up diagnostics?":
-        "visible moisture points, pooling patterns, pressure/flow anomalies",
-      "which environment factors would *change* the diagnostic path?":
-        "freezing temps, recent renovations, water quality/pressure changes",
-      "which usage/repair history would *influence* failure likelihood?":
-        "installation age, prior repairs, high-demand cycles"
-    },
-    conceptualize: {
-      "which subsystems, treated as suspects, *generate* distinct tests?":
-        "supply (hot/cold), fixture assemblies, drainage (trap/joints), venting, appliances (DW/disposal/heater)",
-      "which minimal discriminators best *split* root causes early?":
-        "static (pressurized, no-flow) vs dynamic (flow/drain) behavior; local vs distributed wetness",
-      "which symptom patterns should *trigger* immediate checks?":
-        "base gasket wet after run, trap joint first-wet on dump, hammering after valve close"
-    }
-  },
-
-  produce: {
-    questions: {
-      contextualize: [
-        "where is first-wet observed (fitting, hose, base, joint)?",
-        "does moisture appear with supply pressurized but all fixtures OFF?",
-        "does moisture appear only with faucet ON and no drain flow?",
-        "does moisture appear only during/after a full-basin drain?",
-        "have fixtures or appliances been installed/repaired recently?",
-        "are there freeze events, renovations, or pressure changes on site?"
-      ],
-      conceptualize: [
-        "if static leak: which pressurized components are in range (stop valves, lines, connectors)?",
-        "if dynamic/no-drain leak: which fixture seals or bodies are suspect?",
-        "if drain-only leak: which trap/compression joints or tees are first-wet?",
-        "does the pattern map to supply, fixture body, drain, vent, or appliance branch?",
-        "what single test will most decisively split supply vs drain?",
-        "which repair path corresponds to each confirmed source?"
-      ]
-    }
-  }
-}
-\`\`\`
-
-> This **devtime kit** is authored once and becomes the standard **starting point** for any plumbing diagnosis.
-
----
-
-### 🧩 runtime reuse — plugging in case specifics
-
-**scenario**
-Customer reports water pooling under a kitchen sink after use.
-
-**runtime inputs**
-- The plumber keeps the **devtime kit** unchanged.
-- They add **case facts** via `focus.context` and use the kit’s `produce.questions` as the runbook.
-
-\`\`\`ts
-focus: {
-  concept: null, // or last run's questions if continuing
-  context: {
-    goal: "identify leak source and repair steps",
-    symptoms: "pooling under sink after faucet use",
-    recent_changes: "faucet replaced last month",
-    environment: "unheated exterior wall; freeze last week"
-  }
-}
-\`\`\`
-
-**runtime application**
-- Ask the kit’s **contextualize** set (now grounded by the case):
-  - "where is first-wet observed?" → *bottom of faucet base*
-  - "static or dynamic?" → *only when faucet ON; not on pressurized idle*
-  - "drain-only?" → *no, dry on full-basin dump; wet only with ON/no-drain*
-  - "recent changes?" → *new faucet last month*
-
-- Use answers to pick **conceptualize** branches:
-  - Pattern maps to **fixture body/base** (not supply idle; not drain dump).
-  - **Decisive test**: run 30s ON with no drain, inspect base and supply nut.
-  - If base wets first → **replace/seat base gasket**; if supply nut wets → **re-crimp/replace line**.
-
-**runtime result**
-- Source isolated: **faucet base gasket**.
-- **Repair path** chosen from the kit’s mapping: reseat/replace gasket; retest static/dynamic.
-
----
-
-### 🔁 why this split (devtime → runtime) is valuable
-
-- **Consistency at scale**: every technician starts with the same high-leverage questions, reducing misses.
-- **Speed**: devtime questions are already optimized to **produce** decision-making questions; no ad-hoc thinking at the curb.
-- **Coverage**: the kit bakes in static vs dynamic splits, first-wet logic, and subsystem mapping.
-- **Composability**: outputs from one run can become `focus.concept` for a second `<enquestion>` pass (deeper probing).
-- **Maintainability**: improve the kit once at devtime; all future diagnoses benefit automatically.
-
----

package/dist/roles/bhrain/briefs/thinker.tactics/<enquestion>._.[gallery].thinker.enquestion.md

@@ -1,125 +0,0 @@
----
-
-## 🎯 example — `<enquestion>` devtime PonderQuestions kit for `<envision>` a `[product][journey]` → runtime reuse
-
-**intent**
-Produce a **general-purpose devtime `PonderQuestions` kit** for `<envision>` a `[product][journey]`.
-At **runtime**, a product strategist, designer, or founder can plug in case-specific facts about the product and its audience, reusing this kit for **every journey-mapping session** to ensure nothing critical is overlooked.
-
----
-
-### 📥 devtime input to `<enquestion>`
-\`\`\`ts
-ponder: {
-  contextualize: [
-    "which key stages should *spawn* exploration of user touchpoints?",
-    "which external constraints or dependencies might *alter* the journey flow?",
-    "which success/failure signals at each stage would *generate* follow-up mapping?"
-  ],
-  conceptualize: [
-    "which types of users or segments should *spawn* separate journey branches?",
-    "which journey paths should be *visualized* first for greatest clarity?",
-    "which cross-stage patterns should be *highlighted* to reveal bottlenecks or accelerators?"
-  ]
-},
-focus: {
-  concept: null,
-  context: { goal: "design a reusable envision question set for mapping a product journey" }
-}
-\`\`\`
-
----
-
-### 📤 devtime output from `<enquestion>` (the reusable kit)
-\`\`\`ts
-{
-  ponder: {
-    contextualize: {
-      "which key stages should *spawn* exploration of user touchpoints?":
-        "awareness, consideration, onboarding, active use, support, retention/loyalty, advocacy",
-      "which external constraints or dependencies might *alter* the journey flow?":
-        "regulatory steps, technical onboarding limits, seasonal buying cycles, external integrations",
-      "which success/failure signals at each stage would *generate* follow-up mapping?":
-        "conversion rates, drop-off points, repeat engagement, feature adoption patterns"
-    },
-    conceptualize: {
-      "which types of users or segments should *spawn* separate journey branches?":
-        "new vs returning, free vs paid, novice vs expert, B2B vs B2C",
-      "which journey paths should be *visualized* first for greatest clarity?":
-        "most common conversion flow, highest revenue flow, most problematic drop-off flow",
-      "which cross-stage patterns should be *highlighted* to reveal bottlenecks or accelerators?":
-        "time-to-first-value, handoff delays between teams, repeated support touchpoints"
-    }
-  },
-
-  produce: {
-    questions: {
-      contextualize: [
-        "what is the first trigger or awareness moment for the target user?",
-        "what touchpoints exist at awareness, consideration, onboarding, active use, and retention?",
-        "what constraints or dependencies shape each stage?",
-        "what measurable outcomes indicate success or failure at each stage?",
-        "where do handoffs occur and what risks exist there?"
-      ],
-      conceptualize: [
-        "which user segments require separate mapping due to differing behaviors?",
-        "which journey flow should be visualized first to clarify the main path?",
-        "what alternative or edge-case flows must also be mapped?",
-        "what repeating patterns across stages suggest systemic strengths or weaknesses?",
-        "which single improvement could shorten time-to-first-value?",
-        "what flow variations could be tested for performance impact?"
-      ]
-    }
-  }
-}
-\`\`\`
-
----
-
-### 🧩 runtime reuse — plugging in case specifics
-
-**scenario**
-A SaaS startup is mapping the journey for their **new AI-driven analytics platform**.
-
-**runtime inputs**
-- The **devtime kit** stays the same.
-- Case-specific facts are added to `focus.context`:
-\`\`\`ts
-focus: {
-  concept: null,
-  context: {
-    goal: "map product journey for AI analytics SaaS",
-    target_segments: ["SMB owners", "mid-level data analysts"],
-    launch_region: "North America",
-    constraint: "initial onboarding must complete within 15 minutes",
-    success_metric: "conversion to paid within 14 days"
-  }
-}
-\`\`\`
-
-**runtime application**
-- **Contextualize** questions adapted to case:
-  - First awareness moment? → *LinkedIn ad or industry blog review*.
-  - Stage touchpoints? → *ad → landing page → signup → guided setup → dashboard insights*.
-  - Constraints? → *must integrate with Google Sheets in setup*.
-  - Stage success signals? → *dashboard accessed 3+ times in week 1*.
-
-- **Conceptualize** questions to frame mapping:
-  - Segment split? → *separate flows for SMB owners vs analysts*.
-  - Visualize first? → *SMB owner’s full journey to paid plan*.
-  - Cross-stage bottlenecks? → *handoff from setup to first insights*.
-
-**runtime result**
-- Journey map drafted with two parallel flows.
-- Bottleneck identified: **delay in generating first insights**.
-- Next iteration: add onboarding tweak to surface sample insights instantly.
-
----
-
-### 🔁 why this split (devtime → runtime) is valuable
-- **Framework stability**: devtime kit ensures every journey map starts with full stage coverage.
-- **Efficiency**: runtime mapping skips reinvention, focuses on populating specifics.
-- **Comparability**: journeys across products share the same backbone, making patterns visible.
-- **Scalability**: improvements to the kit (e.g., adding “advocacy” stage) propagate to all future mappings.
-
----

package/dist/roles/bhrain/briefs/thinker.tactics/<enquestion>.tactic.perspectives.[article].md

@@ -1,36 +0,0 @@
-# `<enquestion>.tactic.perspectives` — parallel multi-perspective question generation
-
-*generate, curate, and catalog diverse questions from many perspectives in parallel.*
-
-**purpose**
-generate the richest, most diverse, and well-structured set of questions possible by leveraging parallelized, high-variance thinking across multiple perspectives.
-
----
-
-## steps
-
-1. **run `<enquestion>` repeatedly**
-   - **parallel:** execute many `<enquestion>` calls simultaneously
-   - **high temperature:** encourage creative divergence by increasing variability
-   - **multi-perspective:** supply each run with different [context] or [role] to surface unique angles
-
-2. **`<curate>` → produce a `[gallery]` of questions**
-   - `<collect>` all raw questions from every run
-   - `<cluster>` by thematic or semantic similarity
-   - `<triage>` to remove duplicates, irrelevancies, and low-value items
-
-3. **`<catalogize>` → produce a `[catalog]` of questions**
-   - organize final questions into a structured, reusable index
-   - annotate with tags, difficulty, scope, or intended audience
-
----
-
-## outcome
-a `[catalog]` containing the best, most contextually diverse set of questions — **curated from many perspectives** and ready for structured use.
-
----
-
-## example syntax
-\`\`\`
-<enquestion>.with(perspectives) -> [catalog]
-\`\`\`

package/dist/roles/bhrain/briefs/thinker.tactics/<triage>._.[article].frame.tactical.md

@@ -1,85 +0,0 @@
-# 🧩 .brief: `<triage>`
-
-## .what
-
-The `<triage>` operation involves **prioritizing, sorting, and categorizing** concepts, issues, or data points to address the most critical items first. It leverages criteria such as urgency, importance, and impact to allocate resources efficiently and tackle problems in a strategically sound order.
-
----
-
-## 🎯 purpose
-
-- to allocate attention and resources effectively, particularly under constraints
-- to manage complex sets of tasks, concepts, or issues by determining priority
-- to achieve greater efficiency and impact in decision-making processes
-
----
-
-## ⚙️ method
-
-1. **gather elements**
-   - compile the full scope of tasks, issues, or data points needing triage
-   - ensure a comprehensive representation to inform prioritization
-
-2. **establish criteria**
-   - define criteria for urgency, importance, and potential impact
-   - criteria should be clear, consistent, and aligned with strategic goals
-
-3. **evaluate and prioritize**
-   - assess each element against the criteria
-   - rank based on priority, grouping into immediate, short-term, and long-term categories
-
-4. **execute and monitor**
-   - address elements according to their prioritization
-   - continuously monitor for changes in context or priority requiring adjustment
-
----
-
-## 🧠 cognitive basis
-
-Triage utilizes cognitive functions related to decision-making, prioritization, and problem-solving. It relies on both analytical assessments and judgment calls to manage complexity effectively and ensure the most crucial actions are taken first.
-
----
-
-## 📐 when to use
-
-- during crises or time-sensitive situations where quick decision-making is essential
-- when managing extensive lists of tasks, responsibilities, or issues needing resolution
-- when aligning team focus and resources with high-impact objectives
-
----
-
-## 🔁 dynamic behavior
-
-Triage is inherently dynamic, often involving frequent re-evaluation as context shifts or new information emerges. This flexibility ensures continued relevance and efficacy in response to changing priorities.
-
----
-
-## ⚠️ caution: over-triage
-
-Avoid excessive triaging, which can lead to analysis paralysis or neglect of less critical but still important tasks. Ensure balance between granular prioritization and broad-sketch planning.
-
----
-
-## 🧰 use it for:
-
-- emergency management and crisis response
-- project management and workflow optimization
-- strategic planning and resource allocation
-
----
-
-## 📊 examples
-
-1. **Emergency Room Triage**
-   - Assessing incoming patients to prioritize those with life-threatening conditions over less urgent cases.
-
-2. **Project Management**
-   - Prioritizing project tasks based on deadlines, resource availability, and potential impact on project success.
-
-3. **Strategic Planning**
-   - Sorting organizational goals and initiatives to focus on those most likely to drive long-term success.
-
-4. **Customer Support**
-   - Filtering support tickets to address high-priority or escalated issues before general inquiries.
-
----

package/dist/roles/bhrain/briefs/thinker.tactics/<triage>.persp.grades_from_context.[article].md

@@ -1,48 +0,0 @@
-# 🧩 .brief: `context-dependent grading in <triage>`
-
-## .what
-`<triage>` involves prioritizing tasks or issues based on their urgency, importance, and impact. This process necessitates the use of different grading scales tailored to the specific context in which the triage is applied. Each context has distinct criteria for evaluation, resulting in unique sets of grades.
-
----
-
-## 🎯 purpose
-- create a flexible grading system adaptable to varying contextual needs
-- ensure accurate prioritization by aligning grading criteria with specific context requirements
-- improve decision-making and resource allocation in diverse scenarios
-
----
-
-## 📐 contexts and grading variations
-
-### 1. **medical triage**
-- **criteria:** severity of condition, life-threatening potential, resource availability
-- **grades:** critical, urgent, stable, non-urgent
-
-### 2. **project management**
-- **criteria:** deadline proximity, resource dependency, client priority
-- **grades:** high priority, medium priority, low priority, optional
-
-### 3. **IT incident management**
-- **criteria:** service impact, number of users affected, workaround availability
-- **grades:** high impact, moderate impact, low impact, informational
-
----
-
-## 📊 benefits of context-specific grading
-- enhances responsiveness by focusing on context-relevant factors
-- increases accuracy of prioritization due to alignment with specific needs
-- facilitates efficient resource allocation by understanding context-driven importance levels
-
----
-
-## 🛠 usage
-- define clear criteria specific to each context for consistent grading
-- regularly review and adjust grading systems to reflect changing contextual demands
-- train stakeholders on context-specific grading criteria for seamless implementation
-
----
-
-## 💡 notes
-- context-dependent grading should be updated as contexts evolve
-- integration of feedback from stakeholders is essential for refining grading accuracy
-- leverage analytical tools to periodically evaluate the effectiveness of grading systems