rhachet-roles-bhrain 0.1.0

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

@@ -0,0 +1,125 @@
+---
+
+## 🎯 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/thinker/briefs/thinker.tactics/<enquestion>.tactic.perspectives.[article].md

@@ -0,0 +1,36 @@
+# `<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/thinker/briefs/thinker.tactics/<triage>._.[article].frame.tactical.md

@@ -0,0 +1,85 @@
+# 🧩 .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/thinker/briefs/thinker.tactics/<triage>.persp.grades_from_context.[article].md

@@ -0,0 +1,48 @@
+# 🧩 .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

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

@@ -0,0 +1,65 @@
+# 🧩 .brief: `perspective; triage as question-based tactic`
+
+## .what
+
+`triage` in thought processes is fundamentally a **question-based tactic**. This perspective suggests that triage is driven by **explicit or implicit questions** that determine the **dimensions** along which various elements or tasks are assessed and prioritized.
+
+---
+
+## 🎯 purpose
+- to **prioritize effectively** — identifying which elements need immediate attention and which can be postponed or discarded
+- to ensure that the **most critical issues** are addressed in a structured manner
+- to provide a clear framework for **decision-making** in complex or time-pressured situations
+
+---
+
+## 🌀 triage dynamics
+
+### 1. question-driven assessment
+- **defining criteria**: Each triage process is guided by specific questions that focus on what matters most.
+  - e.g., "Which tasks have the highest impact?" or "What must be solved immediately?"
+
+### 2. dimension selection
+- **criteria alignment**: Questions help in selecting the dimensions of assessment, such as urgency, importance, or risk.
+
+---
+
+## 🔍 triage examples
+
+### medical triage
+- **main question**: "Which patient needs care first?"
+  - **assessment dimensions**:
+    - severity of condition
+    - survival probability
+    - resource availability
+
+### project prioritization
+- **main question**: "Which project aligns best with our strategic goals?"
+  - **assessment dimensions**:
+    - potential ROI
+    - strategic alignment
+    - resource requirements
+
+### information overload management
+- **main question**: "Which information is most crucial to process immediately?"
+  - **assessment dimensions**:
+    - relevance to current objectives
+    - urgency of response required
+    - impact on future decisions
+
+---
+
+## 🌿 implications for practice
+
+- adopting a question-based triage framework can make prioritization more transparent and justifiable.
+- defining clear, shared questions ensures all involved parties understand **why decisions are made**, improving collaboration and buy-in.
+
+---
+
+## 💭 reflections
+
+Consider whether:
+- the questions used in your triage process effectively cover all necessary dimensions.
+- your team could benefit from revisiting and refining these questions to better align with current goals.
+
+> By treating triage as a question-based tactic, we can enhance focus, efficiency, and clarity in decision-making.

package/dist/roles/thinker/briefs/trait.chillnature.md

@@ -0,0 +1,14 @@
+prefer more chill, nature based emojis
+
+for example
+
+# src/skills/diagnose/queryApis/detectLambdaCrontasks.sh
+🌊 Wave for the main detection flow
+🌱 Seedling for Step 1 (starting/growing the list)
+🌿 Herb for successful enumeration
+🍂 Fallen leaf for when nothing is found
+🌾 Sheaf of rice for Step 2 (harvesting/checking data)
+🌸 Cherry blossom for Step 3 (results blooming)
+🌙 Crescent moon for no cron tasks found (peaceful/quiet)
+🌻 Sunflower for the summary (bright conclusion)
+

package/dist/roles/thinker/briefs/trait.ocd.md

@@ -0,0 +1,5 @@
+.ocd = obsessed with structure, precision, and clarity.
+- strives for maximum signal and minimal noise.
+- compulsively organizes, deduplicates, and compresses information.
+- intolerant of vagueness, drift, or redundant phrasing.
+- ensures consistent grammar, formatting, and taxonomy.

package/dist/roles/thinker/briefs/worders/core.matmuls_vecmuls_elemuls.md

@@ -0,0 +1,93 @@
+# 🧩 .brief: `llm inference = matmuls + vecmuls + elemuls`
+
+## .what
+llm inference is the process by which a trained language model transforms input tokens into output predictions. the computation can be reduced to three categories:
+
+- **matmuls** → large matrix multiplications (heavy, parameter-rich ops)
+- **vecmuls** → vector-scale multiplications/additions (normalization scale/shift, bias)
+- **elemuls** → elementwise nonlinear operations (activations, softmax, residuals)
+
+together, these form the skeleton of inference: heavy matmuls provide learned transformations, while vecmuls and elemuls act as the glue that gives nonlinearity and stability.
+
+---
+
+## 🎯 purpose
+- apply billions of learned parameters (matmuls) to transform token inputs
+- refine representations through normalization (vecmuls) and nonlinear activations (elemuls)
+- output logits over vocabulary for next-token prediction
+
+---
+
+## ⚙️ method
+
+### 🔑 what’s happening inside llm inference
+
+1. **token embedding**
+   - input tokens → dense vectors via embedding matrix (**matmul**).
+
+2. **transformer layers**
+   - **linear projections:** weight matrices × input (**matmuls**).
+   - **attention mechanism:** query × key → attention weights (**matmul**), then weights × value (**matmul**).
+   - **feed-forward networks:** matmuls with intermediate activation (**elemuls**).
+
+3. **non-linearities & normalization**
+   - **activations:** per-element functions (relu, gelu, etc.) = **elemuls**.
+   - **normalization:** mean/variance across vector + learned scale/shift = **vecmuls + elemuls**.
+
+4. **output layer**
+   - final hidden state × vocab matrix → logits (**matmul**).
+
+---
+
+## 🧮 operation classes
+- **matmuls:** embeddings, projections, attention (qkᵀ, softmax·v), feed-forward, output head.
+- **vecmuls:** layernorm scale/shift, bias addition.
+- **elemuls:** relu/gelu activations, softmax exponentials/divides, residual adds.
+
+---
+
+## 📊 insight
+- **yes:** matmuls dominate compute and parameter count.
+- **no:** inference is not *only* matmuls — vecmuls and elemuls are critical for expressivity and stability.
+- **so:** inference = “giant chains of matmuls, with vecmuls and elemuls woven in.”
+
+---
+
+## 💻 toy pseudocode skeleton
+
+\`\`\`python
+def llm_inference(tokens, weights):
+    # 1. embedding lookup (matmul)
+    x = embed(tokens, weights["embedding"])   # matmul
+
+    for layer in weights["layers"]:
+        # 2. linear projections (matmuls)
+        q = matmul(x, layer["Wq"])
+        k = matmul(x, layer["Wk"])
+        v = matmul(x, layer["Wv"])
+
+        # 3. attention (matmuls + elemuls)
+        attn_scores = matmul(q, k.T) / sqrt(d)    # matmul
+        attn_weights = softmax(attn_scores)       # elemul
+        attn_output  = matmul(attn_weights, v)    # matmul
+
+        # 4. residual connection (elemul)
+        x = x + attn_output                       # elemul
+
+        # 5. normalization (vecmul + elemul)
+        x = layernorm(x, layer["gamma"], layer["beta"])  # vecmul + elemul
+
+        # 6. feed-forward network
+        h = matmul(x, layer["W1"])                # matmul
+        h = gelu(h)                               # elemul
+        h = matmul(h, layer["W2"])                # matmul
+        x = x + h                                 # elemul
+
+    # 7. output projection (matmul)
+    logits = matmul(x, weights["output"])         # matmul
+    return logits
+\`\`\`
+
+---
+
+in short: **llm inference = matmuls (heavy lifting) + vecmuls (scaling/shift) + elemuls (nonlinear glue).**

package/dist/roles/thinker/briefs/worders/core.transformers.as_origin.md

@@ -0,0 +1,62 @@
+# 🧩 .brief: `the transformer architecture — birth of llms`
+
+## .what
+the **transformer** is the fundamental architecture that enabled large language models (llms). introduced in 2017 by vaswani et al. in *“attention is all you need”*, it replaced recurrence with **self-attention**, making it possible to train massive models on vast text corpora with efficient parallelization.
+
+---
+
+## 🎯 purpose
+- overcome the sequential bottlenecks of rnn/lstm models
+- capture long-range dependencies across entire sequences
+- enable scalable, parallel training on gpus/tpus
+- provide a flexible backbone that can grow with data and compute
+
+---
+
+## ⚙️ method
+
+### 1. **token embedding**
+- words/subwords mapped into dense vectors (matmuls).
+
+### 2. **positional encoding**
+- inject sequence order into embeddings, since attention is order-agnostic.
+
+### 3. **multi-head self-attention**
+- queries, keys, and values projected via matmuls.
+- attention scores = q·kᵀ → softmax → weighted sum with v.
+- multiple heads let the model learn diverse relational patterns.
+
+### 4. **feed-forward networks**
+- per-token mlps applied after attention.
+- matmuls + nonlinear activations (elemuls).
+
+### 5. **residual connections + normalization**
+- stabilize training, preserve gradients, and allow deep stacking.
+
+---
+
+## 🔑 why transformers were a leap
+
+- **parallelism:** attention lets all tokens be processed simultaneously.
+- **long-range context:** any token can directly attend to any other.
+- **scalability:** depth, width, and data scale smoothly (scaling laws).
+- **expressivity:** multi-head attention captures complex dependencies.
+
+---
+
+## 🌍 llm lineage
+
+- **2017 — transformer** (*attention is all you need*)
+- **2018 — bert, gpt-1** (first pretrained transformer language models)
+- **2019 — gpt-2** (scaling shows surprising emergent abilities)
+- **2020 — gpt-3** (175b parameters; llms become viable)
+- **2022+ — instruction-tuned & rlhf models** (chatgpt, claude, etc.)
+
+---
+
+## 📊 insight
+- the transformer is the **architectural skeleton** of llms.
+- llms are “just” massive stacks of transformers trained on enormous corpora.
+- rlhf, fine-tuning, and alignment methods refine the outputs — but the core engine is still the **transformer self-attention block**.
+
+in short: **transformers are the soil from which llms grew.**

package/dist/roles/thinker/briefs/worders/core.transformers.self_attention.[article].md

@@ -0,0 +1,93 @@
+# 🧩 .brief.article: `self-attention`
+
+## 🔑 what is self-attention
+
+self-attention is a mechanism that lets every token in a sequence **dynamically weigh its relationship to every other token** when computing its next representation.
+
+each token generates three vectors:
+- **query (q)** — what this token is “looking for”
+- **key (k)** — what this token “offers”
+- **value (v)** — the actual information carried
+
+the similarity of query vs key determines how much attention a token pays to another token’s value.
+
+mathematically:
+
+\[
+\text{Attention}(Q,K,V) = \text{softmax}\!\left(\frac{QK^\top}{\sqrt{d_k}}\right) V
+\]
+
+- **qkᵀ** → pairwise similarity scores (**matmul**)
+- **softmax** → normalize into attention weights
+- **weights × v** → weighted sum of values = new representation
+
+---
+
+## 🎯 purpose
+- let tokens reference and integrate information from anywhere in the sequence
+- capture long-range dependencies in a single operation
+- enable efficient, parallel computation across tokens
+- provide multiple relational views through multi-head attention
+
+---
+
+## ⚙️ method
+
+1. compute q, k, v for each token via linear projections (**matmuls**)
+2. calculate similarity scores q·kᵀ (**matmul**)
+3. normalize scores with softmax (**elemuls**)
+4. use normalized weights to combine values (**matmul**)
+5. update each token representation with the weighted sum
+
+---
+
+## 🔑 benefits
+
+1. **parallelism** — all q, k, v computed at once; no recurrence.
+2. **long-range context** — any token can directly attend to any other.
+3. **scalability** — uniform, repeatable structure scales with data/compute.
+4. **expressivity** — multi-head attention lets the model learn diverse relational patterns.
+
+---
+
+## 🧩 intuition example
+
+sentence:
+> “the cat sat on the mat because it was tired.”
+
+let’s track the token **“it”** and show how its q, k, v vectors interact with **“the cat.”**
+for illustration, assume a toy **5-dimensional hidden space**.
+
+### token: **“it”**
+- query (**q_it**) = `[0.9, 0.1, 0.0, 0.2, 0.3]`
+  - “looking for an antecedent noun with certain features”
+- key (**k_it**) = `[0.1, 0.3, 0.2, 0.0, 0.4]`
+  - “offers” self as a pronoun needing resolution
+- value (**v_it**) = `[0.2, 0.5, 0.1, 0.0, 0.7]`
+  - the information carried by “it” itself
+
+### token: **“cat”**
+- query (**q_cat**) = `[0.2, 0.4, 0.1, 0.3, 0.0]`
+- key (**k_cat**) = `[0.8, 0.2, 0.0, 0.1, 0.3]`
+  - describes the features of “cat” as a noun subject
+- value (**v_cat**) = `[0.7, 0.6, 0.2, 0.4, 0.1]`
+  - semantic content of “cat”
+
+### computing attention
+1. similarity score = q_it · k_cat =
+   `0.9*0.8 + 0.1*0.2 + 0.0*0.0 + 0.2*0.1 + 0.3*0.3 = 0.72 + 0.02 + 0 + 0.02 + 0.09 = 0.85`
+2. suppose normalized (softmax) weight for “cat” = **0.70**, for others tokens total 0.30.
+3. “it”’s updated representation =
+   `0.70 * v_cat + 0.30 * (weighted sum of other tokens’ values)`
+
+so “it”’s final vector is now strongly composed of “cat”’s value vector, making the model understand that **“it” refers to “the cat.”**
+
+---
+
+## 📊 insight
+- **queries = what a token seeks**
+- **keys = what a token provides**
+- **values = the information contributed**
+- weighted connections between them create **context-aware representations**.
+
+self-attention is how llms directly model relationships across a sequence — allowing “it” to learn its referent is “the cat.”