rhachet-roles-ehmpathy 1.13.6 → 1.13.7

package/dist/logic/roles/bhrain/.briefs/tactician/trait.vs_skill.[article].md

@@ -0,0 +1,55 @@
+# 🧩 .brief.article: `traits vs skills`
+
+## 💡 concept
+**traits** and **skills** both shape how people act, but they operate on different levels:
+- a **trait** is a recurring disposition — a pattern of orientation, energy, or behavior.
+- a **skill** is a learned capability — a pattern of execution that can be trained and measured.
+
+understanding the distinction prevents us from mistaking innate tendencies for trainable abilities.
+
+---
+
+## 🔍 differences
+
+### 1. origin
+- **traits**: emerge from personality, temperament, or long-term conditioning. often stable across time.
+- **skills**: emerge from practice and instruction. flexible and trainable.
+
+---
+
+### 2. scope
+- **traits**: broad in effect; they color multiple domains.
+  - curiosity can shape art, science, or relationships.
+- **skills**: narrow in application; tied to specific domains.
+  - coding, carpentry, negotiation.
+
+---
+
+### 3. changeability
+- **traits**: shift slowly; can be balanced but not easily “installed.”
+- **skills**: shift quickly; can be learned, upgraded, or replaced.
+
+---
+
+### 4. evaluation
+- **traits**: assessed by patterns over time.
+  - someone *is disciplined* when reliability shows consistently.
+- **skills**: assessed by performance in tasks.
+  - someone *knows SQL* when they can query databases.
+
+---
+
+### 5. relation
+- **traits** set the posture.
+- **skills** execute within that posture.
+
+> example: a disciplined trait supports the steady practice needed to build the piano skill.
+> without discipline, the skill may stall despite talent.
+
+---
+
+## 📌 takeaway
+- **traits = disposition**: they orient and color behavior across contexts.
+- **skills = capability**: they enable specific acts within contexts.
+- both interact: traits provide the soil, skills provide the tools.
+together, they form the **architecture of ability** — traits set the stance, skills supply the execution.

package/dist/logic/roles/bhrain/.briefs/tactician/trait.vs_tactic.[article].md

@@ -0,0 +1,70 @@
+# 🧩 .brief.article: `traits as the foundation of tactics`
+
+## 💡 concept
+to **execute a tactic**, one must apply **skills** upon a baseline of **traits**.
+- **traits** = the dispositions that orient attention, energy, and behavior.
+- **skills** = the trainable capabilities that act within that orientation.
+without traits as the foundation, skills may not sustain, and tactics may not succeed.
+
+---
+
+## 🎯 why traits are foundational
+
+### 1. skills rest on traits
+a skill is only as stable as the trait beneath it.
+- chemistry requires **precision**.
+- leadership requires **confidence**.
+- negotiation requires **empathy**.
+without the trait, the skill cannot fully embed or function reliably.
+
+---
+
+### 2. traits sustain skills under pressure
+skills can be taught in a classroom, but in the field they falter unless traits hold steady.
+- **discipline** keeps practice consistent.
+- **resilience** prevents collapse under failure.
+- **curiosity** fuels the drive to refine.
+
+---
+
+### 3. traits shape the style of skill
+two people may wield the same skill differently depending on traits.
+- a communicator with **empathy** persuades through trust.
+- a communicator with **charisma** persuades through presence.
+- a communicator without anchoring traits risks manipulation or emptiness.
+
+---
+
+### 4. traits prevent mechanical execution
+a tactic applied by skill alone feels forced, brittle, or artificial.
+- traits give **natural posture**.
+- skills give **effective action**.
+- tactics require both.
+
+---
+
+## 📚 examples
+
+- **skill**: chemistry analysis
+  - **trait baseline**: precision, patience
+  - **tactic enabled**: rigorous experiment without error creep.
+
+- **skill**: carpentry
+  - **trait baseline**: steadiness, attention to detail
+  - **tactic enabled**: joints fit cleanly, structures hold.
+
+- **skill**: coding
+  - **trait baseline**: logic, persistence
+  - **tactic enabled**: debugging without giving up too soon.
+
+---
+
+## 📌 takeaway
+to execute a tactic:
+1. **trait** sets the baseline posture.
+2. **skill** provides the capability.
+3. **tactic** applies skill through the trait into real outcomes.
+
+> skills without traits collapse under pressure.
+> tactics without traits turn mechanical.
+> traits are the **foundation** that make both durable and alive.

package/dist/logic/roles/bhrain/.briefs/terms.motive.intent.goal.md

@@ -0,0 +1,46 @@
+🔥 [motive] — an internal pressure or desire
+.what = the underlying reason the actor wants anything at all
+
+.form = emotional, value-driven, often implicit
+
+.examples:
+[motive] = avoid failure
+[motive] = gain respect
+[motive] = feel in control
+
+---
+
+🎯 [intent] — a chosen next action
+.what = a specific thing the actor plans to do next
+
+.form = short-term, actionable, verb-shaped
+
+.examples:
+[intent] = schedule a call
+[intent] = submit proposal
+[intent] = clean the garage
+
+---
+
+🥅 [goal] — a desired future state
+.what = a future outcome the actor wants to reach
+
+.form = long-term, state-shaped, noun/condition
+
+.examples:
+[goal] = get more customers
+[goal] = have a clean house
+[goal] = win the bid
+
+---
+
+🧠 mental model
+[motive] = source of pressure
+[goal] = destination
+[intent] = chosen step toward it
+
+- `[motive]` fuels the journey
+- `[goal]` gives it direction
+- `[intent]` initiates motion
+
+> every `[intent]` serves a `[goal]`, and every `[goal]` is backed by a `[motive]` — but these are not always visible on the surface.

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

@@ -0,0 +1,85 @@
+# 🧩 .brief: `thought process of <cluster>`
+
+## .what
+
+The `<cluster>` operation involves grouping related concepts, ideas, or data points into cohesive units based on shared characteristics or themes. This process leverages pattern recognition and categorization principles to enhance understanding, comparison, and analysis.
+
+---
+
+## 🎯 purpose
+
+- to identify and form meaningful groups from disparate elements
+- to facilitate deeper insights through pattern recognition
+- to simplify complex information by breaking it into manageable parts
+
+---
+
+## ⚙️ method
+
+1. **identify elements**
+   - gather concepts, ideas, or data points that need clustering
+   - ensure a diverse and representative sample
+
+2. **determine criteria**
+   - establish the basis for clustering (e.g., shared attributes, function, purpose)
+   - criteria should be clear and consistent across all elements
+
+3. **analyze and group**
+   - assess each element against the criteria
+   - form clusters based on the most significant matches or relationships
+
+4. **review and refine**
+   - evaluate clusters for clarity, coherence, and relevance
+   - adjust groupings as necessary for optimal structure
+
+---
+
+## 🧠 cognitive basis
+
+Clustering relies on the brain's natural ability to recognize patterns and associations. It mimics cognitive processes involved in categorization, memory retrieval, and decision-making, thereby streamlining information processing and comprehension.
+
+---
+
+## 📐 when to use
+
+- when dealing with large volumes of information that need organization
+- when exploring relationships between concepts for strategic insight or analysis
+- when preparing data for presentation, highlighting key themes or trends
+
+---
+
+## 🔁 dynamic behavior
+
+Clustering is often iterative, with repeated cycles of grouping, reviewing, and refining. This helps to accommodate new information or evolving understanding, ensuring clusters remain relevant and actionable.
+
+---
+
+## ⚠️ caution: over-clustering
+
+Avoid creating too many clusters or overly complex structures, which can obscure rather than clarify. Clusters should strike a balance between granularity and cohesion.
+
+---
+
+## 🧰 use it for:
+
+- data analysis and research
+- strategic planning and brainstorming
+- knowledge management and taxonomy development
+
+---
+
+## 📊 examples
+
+1. **Market Segmentation**
+   - Grouping customers based on demographic, geographic, or behavioral characteristics to tailor marketing strategies.
+
+2. **Academic Research**
+   - Clustering academic papers or references by themes or topics to identify research gaps or emerging trends.
+
+3. **Product Categorization**
+   - Organizing products into categories like electronics, clothing, and home appliances to enhance user navigation in online stores.
+
+4. **Strategic Brainstorming**
+   - Grouping ideas from brainstorming sessions into actionable categories such as short-term tactics, long-term strategies, and innovative solutions.
+
+---

package/dist/logic/roles/bhrain/.briefs/thinker.tactics/<cluster>.vs_<diverge>.duality.[article].md

@@ -0,0 +1,43 @@
+# 🧩 .brief: `<diverge> ↔ <cluster>`
+
+## .what
+the **duality** between `<diverge>` and `<cluster>` describes a **complementary motion of thought**:
+- `<diverge>` expands a concept outward into **maximum variance instances**
+- `<cluster>` contracts many instances inward into **coherent groupings**
+
+together they form a **push–pull dynamic** of exploration and organization.
+
+---
+
+## 🎯 purpose
+- balance **creativity and clarity**: generate wide variety, then refine into structure
+- ensure **coverage and coherence**: divergence prevents blind spots, clustering prevents overload
+- support **iterative cycles of insight**: each informs and strengthens the other
+
+---
+
+## ⚙️ motion
+1. **<diverge>**
+   - spread focus to surface **differences, alternatives, and variations**
+   - motion is centrifugal — outward, increasing breadth
+
+2. **<cluster>**
+   - compress focus to reveal **patterns, affinities, and themes**
+   - motion is centripetal — inward, increasing coherence
+
+---
+
+## 🔄 interplay
+- divergence without clustering → noise, endless fragments, lack of synthesis
+- clustering without divergence → rigidity, premature convergence, missed options
+- **dual-cycle**:
+  1. diverge to gather possibilities
+  2. cluster to extract structure
+  3. repeat as needed, each cycle sharper
+
+---
+
+## 📐 metaphor
+- `<diverge>` = scattering seeds across a field
+- `<cluster>` = harvesting them into sheaves
+- the **crop of thought** emerges only through both motions in rhythm

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

@@ -0,0 +1,4 @@
+<diverge> is an extreme example of <vary>
+
+see cognition briefs for reference
+

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

@@ -0,0 +1,89 @@
+# 🧩 .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/logic/roles/bhrain/.briefs/thinker.tactics/<elaborate>_vs_<elucidate>.[seed].md

@@ -0,0 +1 @@
+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/logic/roles/bhrain/.briefs/thinker.tactics/<enquestion>._.[article].md

@@ -0,0 +1,113 @@
+# ❓ .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/logic/roles/bhrain/.briefs/thinker.tactics/<enquestion>._.[gallery].plumber.diagnose.md

@@ -0,0 +1,130 @@
+---
+
+## 🛠️ 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.
+
+---