rhachet-roles-ehmpathy 1.13.2 → 1.13.3

package/dist/logic/roles/bhrain/.briefs/knowledge/kno501.doc.enbrief.catalog.structure1.[article].md

@@ -0,0 +1,53 @@
+# 🧩 .brief.article: `catalog.structure.s1`
+
+## 💡 what
+**structure.s1** is a **common structure for a catalog**: it organizes a `$concept` into a set of `$subconcept` clusters, balancing a compressed overview with detailed expansions. while other structures are possible, this pattern appears frequently because it provides both scan-ability and depth.
+
+---
+
+## 🧱 core structure
+
+### 1. **compressed overview (table)**
+- **purpose:** provide a **scannable map** of the `$concept` space
+- **format:** a table whose **first column is always cluster** (naming each `$subconcept`)
+- **columns:** flexible, but commonly include **what** (definition) plus optional dimensions like *how*, *why*, *when*, or *where*
+- **role:** gives readers a **quick grasp** of the full landscape
+
+---
+
+### 2. **clusters (expanded sections)**
+- **purpose:** deepen understanding of each `$subconcept`
+- **format:** a section per cluster, consisting of:
+  1. **emoji-marked header** — each cluster begins with a **distinct emoji**, not a number, to serve as a visual marker that makes clusters easy to grok at a glance
+  2. **short description** — 1–3 sentences that summarize the cluster’s essence
+  3. **nested outline** — flexible bullet/subbullet structure that organizes the cluster’s details
+     - may vary in form: attributes, timelines, taxonomies, workflows, etc.
+- **role:** creates **depth and variation**, allowing each cluster to be expressed in the form that best fits its content
+
+---
+
+### 3. **insight (synthesis)**
+- **purpose:** extract patterns across clusters
+- **methods:**
+  - reduce clusters into **verbs** (e.g., “articles define,” “catalogs organize”)
+  - highlight **relationships** (complements, contrasts, overlaps)
+  - summarize the **system-level takeaway** (why the catalog matters as a whole)
+- **role:** turns the catalog into more than a list — a **lens for understanding** the `$concept`
+
+---
+
+## ✨ key properties
+- **overview + depth** → balances a **table for scanning** with **clusters for exploration**
+- **emoji headers** → clusters are introduced with **visual emoji markers** instead of numbers, supporting instant recognition and variety without implying sequence
+- **flexible substructure** → clusters are not rigid; each can adopt whatever outline best fits the `$concept`
+- **insight-oriented** → not a static inventory but an interpretive map that clarifies relationships and value
+
+---
+
+## 🧩 summary
+**structure.s1** is a **common structure for a catalog**:
+1. a **compressed overview** table to map the terrain,
+2. a set of **emoji-marked clusters** with short descriptions + nested outlines,
+3. an **insight section** that synthesizes meaning.
+
+it is widely useful because it supports both **quick reference** and **conceptual exploration**, making `$concept` domains easier to navigate.

package/dist/logic/roles/bhrain/.briefs/knowledge/kno501.doc.enbrief.catalog.structure1.[lesson].template.md

@@ -0,0 +1,101 @@
+# 🧩 .brief.lesson: `catalogize` via `template`
+
+## 💡 concept
+to **catalogize** is to organize a set of `$subconcept`s under a `$concept` by arranging them into a structured overview and expanded clusters, so relationships become clear and referenceable.
+
+---
+
+## 📚 materials
+> the template you will use to practice catalogizing
+
+\`\`\`md
+# 🧩 .brief.catalog: `$concept`
+
+## 📊 compressed overview
+
+| **cluster** | **what** | **[optional column]** |
+|-------------|----------|------------------------|
+| 🍎 [$subconcept a] | [short definition or identifying phrase] | [optional info] |
+| 🍌 [$subconcept b] | [short definition or identifying phrase] | [optional info] |
+| 🍇 [$subconcept c] | [short definition or identifying phrase] | [optional info] |
+
+---
+
+## 🎨 clusters
+
+### 🍎 **[$subconcept a] — [role/essence]**
+[short description of this cluster]
+- point one
+- point two
+  - subpoint a
+  - subpoint b
+- point three
+
+---
+
+### 🍌 **[$subconcept b] — [role/essence]**
+[short description of this cluster]
+- attribute one
+- attribute two
+
+---
+
+### 🍇 **[$subconcept c] — [role/essence]**
+[short description of this cluster]
+- step one
+  - detail a
+  - detail b
+    - finer detail i
+    - finer detail ii
+- step two
+
+---
+
+## ✨ insight
+- [synthesis across clusters]
+\`\`\`
+
+---
+
+## 🛠️ practice
+> how to fill out the template
+
+1. **select a `$concept` domain**
+   - choose the overarching concept you want to organize (e.g., “document archetypes,” “fruit types,” “project risks”).
+   - this sets the *scope* of your catalog — too broad and it becomes messy, too narrow and it loses utility.
+
+2. **define your table columns**
+   - the first column must always be **cluster** (naming each `$subconcept`).
+   - add columns that match what you want to compare:
+     - **what** → short definition (default, highly recommended)
+     - **how** → method, process, or mechanism
+     - **why** → purpose, role, or motivation
+     - **when / where** → context or conditions of relevance
+   - remember: the table is a compressed overview, not a data dump.
+
+3. **draft the compressed overview**
+   - list each `$subconcept` cluster with:
+     - a **name/label** (clear and recognizable)
+     - a **one-liner “what”** definition
+     - optional supporting info in extra columns
+   - aim for *scan-ability*: someone should understand the whole landscape at a glance.
+
+4. **expand each cluster**
+   - mark each cluster header with a **unique emoji**, not a number.
+     - emojis act as **visual tags**, making clusters distinct and instantly recognizable.
+     - choose emojis that symbolize or hint at the `$subconcept`.
+   - begin with a **short description** (1–3 sentences) that anchors what the cluster is about.
+   - follow with a **nested outline** that is **flexible and topic-dependent**.
+     - some clusters may take the shape of attributes, others steps, others categories, or even mixed forms.
+     - outlines should not all look the same; in fact, if every cluster matches the example above exactly, it’s a sign the catalog is being filled mechanically rather than thoughtfully.
+
+5. **distill insights**
+   - once all clusters are drafted, look across them:
+     - **verbs** → reduce each cluster to its action (“articles define,” “catalogs organize”)
+     - **relationships** → highlight how clusters contrast, complement, or overlap
+     - **system takeaway** → explain why the `$concept` matters as a whole, beyond the sum of parts
+
+---
+
+## 🎯 goal
+after completing this lesson, you should be able to **catalogize any `$concept` into its `$subconcept` clusters** with a flexible combination of overview tables + emoji-marked descriptive outlines. the *shape of each outline should vary with the topic*, ensuring the catalog balances quick reference with deeper exploration.

package/dist/logic/roles/bhrain/.briefs/librarian.context/article.variant.vision.[article].md

@@ -0,0 +1,60 @@
+# 🧩 .brief: `[vision]`
+
+## .what
+a **vision** is an imaginative depiction or scenario illustrating a potential future state of a concept, entity, or project. it serves as a creative projection aimed at inspiring and guiding transformative thinking or strategic planning by showcasing what is possible.
+
+---
+
+## 🎯 purpose
+- to **inspire innovation** and broad thinking about potential futures
+- to **guide strategic decision-making** by providing a target state to work towards
+- to **engage stakeholders** by vividly portraying the benefits and impact of pursuing the vision
+
+---
+
+## 🛠 components
+
+### 1. **imagination**
+   - creatively constructed possibilities that envision a future state
+   - may involve speculative scenarios or conceptual explorations
+
+### 2. **impact**
+   - describes the anticipated results or changes if the vision is realized
+   - typically highlights positive transformations or advancements
+
+### 3. **feasibility**
+   - considers the practicality and potential challenges in achieving the vision
+   - often includes contingency thoughts to address uncertainties
+
+### 4. **engagement**
+   - a compelling narrative that captures the interest of diverse audiences
+   - calls for alignment and participation from stakeholders
+
+---
+
+## 🔍 features
+- **vivid and illustrative** to make abstract ideas tangible
+- **aspirational tone** to elevate thinking beyond current limitations
+- includes **elements of storytelling** to foster emotional connection
+
+---
+
+## 🏗 creating a vision
+1. **research trends and scenarios**: understand ongoing changes and potential future shifts.
+2. **brainstorm creatively**: think imaginatively about what is possible without current constraints.
+3. **storyboard your vision**: craft a narrative that conveys the exciting, transformative potential.
+4. **seek feedback and iteratively refine**: engage others in reviewing and enhancing the vision for broader resonance.
+
+---
+
+## 📚 examples
+- vision of a sustainable future city: "the city of tomorrow is a zero-emission urban paradise where nature and technology coexist, providing a thriving, inclusive, and adaptive ecosystem for all."
+- vision for an education system: "an educational landscape where personalized learning and novel pedagogies empower every student to realize their full potential, unbounded by their starting point."
+
+---
+
+## 💡 notes
+- a vision can be abstract and speculative, unlike a mission or strategy, which are typically more grounded and specific.
+- ensure a vision remains **flexible** to evolve with new insights and realities.
+
+---

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.expectation.vs_assumption._.md

@@ -0,0 +1,60 @@
+# 🧩 .brief: `assumption vs expectation`
+
+## .what
+**assumption** and **expectation** are two closely related concepts that shape how we perceive and interact with the world. An **assumption** is a belief or supposition taken as true without proof or concrete evidence. It often functions unconsciously to fill gaps in what we think we know. An **expectation**, on the other hand, is a belief about the anticipated outcome or behavior of someone or something; it is often based on past experience, communication, or desire.
+
+---
+
+## 🎯 purpose
+- distinguish between passive beliefs (assumptions) and active forecasts (expectations)
+- clarify how each informs decision-making and mindset
+- prevent misunderstandings and misalignments in communication and planning
+
+---
+
+## 📐 dimensions
+
+### assumption
+- **definition**: a belief taken for granted without substantiation; a starting point for reasoning that lacks direct evidence.
+- **origin**: emerges from prior experiences, cultural norms, or incomplete data.
+- **effect**: shapes perspective subtly, often unacknowledged; can lead to blind spots if unexamined.
+  
+### expectation
+- **definition**: an anticipated outcome or behavior considered likely or desired, inferred from patterns of past interactions or guidance.
+- **origin**: formed from past experience, explicit statements, or personal goals and desires.
+- **effect**: guides behavior and emotional responses; unmet expectations can result in disappointment or frustration.
+
+---
+
+## 🔗 relations
+- **assumptions can influence expectations**: unacknowledged assumptions can set unrealistic or inaccurate expectations.
+- **expectations shape interactions**: clear expectations improve communication and collaboration, reducing surprises and conflict.
+  
+---
+
+## 💡 examples
+
+### assumptions
+- assuming someone knows how to operate a device without instruction.
+- believing a project will take a standard amount of time without considering unique complexities.
+
+### expectations
+- expecting a colleague to reply to emails within 24 hours based on previous patterns.
+- anticipating software to perform a specific function because it was advertised to do so.
+
+---
+
+## 🌀 contrast & synthesis
+
+### distinguish
+- assumptions are often less conscious and lack immediate validation.
+- expectations are typically more explicit and testable against reality.
+
+### integrate
+- actively recognizing and questioning assumptions can refine expectations into more effective tools for predicting and navigating future scenarios.
+
+---
+
+## 📌 application
+- **in planning**: explicitly state and validate assumptions to ensure realistic expectations and successful outcomes.
+- **in communication**: acknowledge and align on expectations to foster understanding and collaboration.

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.frame.vs_perspective.[article].md

@@ -0,0 +1,96 @@
+# 🧩 .brief: `frame vs perspective`
+
+## .what
+**frame** and **perspective** are paired tools for concept articulation:
+- **frame** = a **structural skeleton** — a variant pattern of slots and relations that can be applied to a concept to shape *how* it is organized in articulation. Multiple frames may be applied to the same concept to produce structurally different materializations.
+- **perspective** = the **viewpoint** or **angle of approach** used to fill that skeleton with content, shaping emphasis, tone, and interpretation.
+
+---
+
+## 🎯 goal
+- **frame**: provide an organizing pattern for a concept’s articulation.
+- **perspective**: give a contextual lens for filling the pattern.
+- together: allow re-framing (structural variation) and re-viewing (interpretive variation) of the same concept.
+
+---
+
+## 🔎 core distinctions
+
+| aspect | **frame** | **perspective** |
+|---|---|---|
+| nature | structural pattern (variant skeleton) | interpretive angle (role, motive, context) |
+| function | determines *what slots exist* and *how they relate* | determines *how slots are filled* and *what’s emphasized* |
+| multiplicity | many possible per concept | many possible per concept |
+| change effect | reorganizes the articulation | shifts tone, focus, interpretation |
+| metaphor | skeleton blueprint | lens |
+
+---
+
+## 🧭 minimal definitions
+
+### frame
+- **slots**: named fields/dimensions (e.g., `.what`, `.why`, `.how`)
+- **relations**: how slots link or depend on each other
+- **order/shape**: sequence, grouping, or hierarchy
+- **constraints**: invariants within that frame variant
+- **acuity rules**: expected detail per slot
+
+### perspective
+- **vantage**: whose view or role is filling the frame
+- **tone/style**: language and metaphor choices
+- **priority**: which slots get richer vs minimal detail
+- **filter**: what’s omitted or downplayed
+- **interpretation**: how the facts are cast in meaning
+
+---
+
+## ⚙️ workflow pattern
+
+1. **<select.frame>** — choose the skeleton variant best suited to the goal.
+2. **<choose.perspective>** — pick the lens: role, priorities, style.
+3. **<materialize>** — fill the frame from that perspective.
+4. **<compare.perspectives>** — same frame, varied fills.
+5. **<compare.frames>** — same concept, varied skeletons.
+
+---
+
+## 🧷 interplay rules
+
+- **frame** = structural variation; **perspective** = interpretive variation.
+- multiple **frames** allow reorganizing the same concept into different slot structures.
+- multiple **perspectives** allow different voices or priorities for the same structure.
+- changing **frame** may change the relationships between elements; changing **perspective** does not.
+
+---
+
+## 🧯 blue-collar example
+
+**concept**: “buying a work truck”
+
+- **frame A** (decision frame):
+  1. purpose
+  2. requirements
+  3. options
+  4. decision
+  5. rationale
+
+- **frame B** (risk–benefit frame):
+  1. risks
+  2. mitigations
+  3. benefits
+  4. trade-offs
+  5. selection
+
+- **perspectives** for either frame:
+  - **owner**: ROI, fuel, maintenance cost.
+  - **foreman**: uptime, ruggedness.
+  - **driver**: comfort, safety.
+
+Same **concept**, different **frames** change *structure*, different **perspectives** change *interpretation*.
+
+---
+
+## 📌 summary
+- **frame** = skeleton variant — structural pattern that organizes articulation.
+- **perspective** = lens — interpretive angle that colors the fill.
+you can re-frame for structural changes, re-view for interpretive changes, or combine both for maximum variation.

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.invariant.[article].md

@@ -0,0 +1,29 @@
+# 🧩 .brief: def(`invariant`)
+
+## .what
+an **invariant** is a property, condition, or quantity that remains unchanged while other elements of a system vary — as long as the system’s rules or constraints are respected.
+
+---
+
+## 🎯 goal
+to define and preserve **consistency** across changes, ensuring that certain truths or conditions hold steady regardless of variation in other factors.
+
+---
+
+## 📍 scope
+- **mathematics** — values or relationships that remain constant under specific transformations
+- **programming** — conditions that must always be true during program execution
+- **physics** — measurable properties that do not change across frames of reference or states
+- **logic / reasoning** — truths that persist across all considered cases
+
+---
+
+## 💡 examples
+- **math**: in euclidean geometry, the distance between two points is invariant under rotation.
+- **programming**: in a sorted array, `array[i] <= array[i+1]` is an invariant.
+- **physics**: the speed of light in a vacuum is invariant for all inertial observers.
+
+---
+
+## 🔍 note
+violating an invariant often signals a **break in the system’s rules** or a **logical error** in reasoning or implementation.

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.lesson._vs_article.[article].md

@@ -0,0 +1,36 @@
+# 🧩 .brief: lesson vs article
+
+## .what
+**lesson** and **article** are both structured forms of knowledge delivery, but they differ in **purpose, orientation, and test of success**.
+- a **lesson** is pedagogical — built to **teach** through the fusion of **explain × articulate**.
+- an **article** is expository — built to **inform or persuade**, relying primarily on **articulation**, sometimes with partial explanation.
+
+---
+
+## .why (purpose)
+- **lesson:** to transfer ability → the learner should *do, apply, or restate*.
+- **article:** to convey information or stance → the reader should *understand, believe, or reflect*.
+
+---
+
+## .model
+
+| axis              | **lesson**                                   | **article**                               |
+|-------------------|-----------------------------------------------|-------------------------------------------|
+| **core fusion**   | explain × articulate                          | articulate (may include explain)           |
+| **orientation**   | audience-centered (learner progression)       | content-centered (author’s theme)         |
+| **structure**     | scoped, stepwise, with checks/examples        | expository/narrative, theme-driven         |
+| **tone**          | directive, guiding, scaffolded                | declarative, expressive, author-driven     |
+| **success test**  | learner can apply or restate concept          | reader grasps or resonates with argument   |
+
+---
+
+## .examples
+- **lesson:** “solving quadratic equations” → rule explained, worked example, practice, recap.
+- **article:** “why quadratic equations matter in physics” → narrative of relevance, context, implications.
+
+---
+
+## .tl;dr
+- **lesson = packaged teaching**: explain + articulate, bounded, learner-focused.
+- **article = expository writing**: articulate, theme-focused, author-driven.

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.ref._vs_brief.md

@@ -0,0 +1,90 @@
+## `.brief: ref.vs_brief`
+## `.brief: concept.form`
+
+a **concept** may be stored in one of two primary forms, distinguished by the length, completeness, and intended usage of their content:
+
+| form     | role        | description | length scope | typical usage |
+|----------|-------------|-------------|--------------|---------------|
+| **[brief]** | instance  | a complete, self-contained work that may be of arbitrary length. represents the *full file* body, containing all details, structure, and data needed for its intended use. | unlimited | final documents, source code, datasets |
+| **[ref]**   | reference | a short, single-sentence concept reference. names or anchors a concept without providing substantive content. | one sentence | quick reference, index listings, choice menus |
+
+**notes**
+- `[brief]` is the **instance** form; `[ref]` is the **reference** form.
+- concepts can transition between forms — a `[ref]` (reference) can later expand into a `[brief]` (instance), and a `[brief]` can be condensed into a `[ref]`.
+- in storage, `[brief]` consumes more resources and may require versioning; `[ref]` is lightweight and suitable for fast retrieval or indexing contexts.
+
+---
+
+## examples
+
+---
+
+**[ref] example**
+\`\`\`md
+raspberry
+\`\`\`
+
+**[brief] example**
+\`\`\`md
+# `.brief: raspberry`
+
+## .what
+a **raspberry** is a small, edible fruit composed of numerous tiny drupelets, typically red, black, purple, or golden in color. it grows on the perennial plant *rubus idaeus* and related species.
+
+## goal
+to provide nutrition, flavor, and culinary versatility as a fruit in human diets.
+
+## core elements
+1. **botanical family** — rosaceae
+2. **growth habit** — perennial shrub with biennial canes
+3. **nutritional value** — rich in fiber, vitamin c, and antioxidants
+4. **culinary uses** — eaten fresh, made into jams, baked goods, or beverages
+\`\`\`
+
+---
+
+**[ref] example**
+\`\`\`md
+duck
+\`\`\`
+
+**[brief] example**
+\`\`\`md
+# `.brief: duck`
+
+## .what
+a **duck** is a waterfowl belonging to the family anatidae, characterized by its broad bill, webbed feet, and short legs. ducks are found worldwide in both freshwater and marine environments.
+
+## goal
+to thrive as part of aquatic ecosystems and serve as a source of food, feathers, and cultural symbolism for humans.
+
+## core elements
+1. **habitat** — lakes, rivers, marshes, and coastal waters
+2. **diet** — aquatic plants, invertebrates, and small fish
+3. **behavior** — dabbling, diving, migratory patterns
+4. **human uses** — meat, eggs, feathers, ornamental breeding
+\`\`\`
+
+---
+
+**[ref] example**
+\`\`\`md
+ship
+\`\`\`
+
+**[brief] example**
+\`\`\`md
+# `.brief: ship`
+
+## .what
+a **ship** is a large vessel designed for transporting people, cargo, or equipment across bodies of water. ships can be powered by sails, engines, or other propulsion methods.
+
+## goal
+to facilitate transportation, trade, exploration, and defense across oceans, seas, and other navigable waters.
+
+## core elements
+1. **types** — cargo ship, passenger ship, warship, research vessel
+2. **propulsion** — sail, steam, diesel, nuclear
+3. **construction materials** — wood, steel, composite materials
+4. **functions** — commerce, military, scientific research, recreation
+\`\`\`

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.referent.[article].md

@@ -0,0 +1,43 @@
+# 🧩 .brief: `referent`
+
+## .what
+a **referent** is the actual thing in the world (object, person, event, or idea) that a word, phrase, or symbol points to. it is the entity being referred to, distinct from the sign itself (the word or symbol) and from the concept it evokes in the mind.
+
+---
+
+## 🎯 purpose
+- anchors language to reality by specifying *what exactly* is being indicated
+- distinguishes between linguistic form (signifier), mental concept (sense), and the external entity (referent)
+- enables precision in communication, logic, and semantics
+
+---
+
+## 🔍 contrasts
+- **signifier vs referent**
+  - *signifier* = the form (e.g., the word "dog")
+  - *referent* = the actual creature running in the yard
+- **sense vs referent**
+  - *sense* = the mental concept or descriptive content ("domesticated four-legged canine")
+  - *referent* = the particular dog you’re pointing at
+
+---
+
+## 📐 examples
+1. saying *"the Eiffel Tower"*
+   - **signifier:** the phrase “Eiffel Tower”
+   - **sense:** concept of “a famous tower in Paris”
+   - **referent:** the specific iron structure standing in Paris
+
+2. in a classroom, pointing to a triangle on the board while saying “this shape”
+   - **signifier:** the phrase “this shape”
+   - **referent:** that specific chalk triangle
+
+3. in logic:
+   - the expression “2 + 2” → **referent = 4**
+
+---
+
+## 📊 applications
+- **linguistics & semantics:** clarifies meaning by tying words to things
+- **logic & philosophy:** distinguishes between naming, meaning, and existence
+- **computer science (NLP, programming):** a variable may act as a signifier, its value as the referent

package/dist/logic/roles/bhrain/.briefs/librarian.context/usage.lesson_vs_article.[lesson].md

@@ -0,0 +1,31 @@
+# 🧩 .brief: lessons vs articles in llm context
+
+## .what
+within an llm’s **context window**, the choice between feeding it **lessons** or **articles** determines how it will generalize and respond.
+- **lessons** = structured, causal, example-driven scaffolds → optimized for clarity and reuse.
+- **articles** = expository, narrative, stylistic content → optimized for articulation and tone.
+
+---
+
+## .why (purpose)
+- **lessons:** maximize transfer of reasoning patterns, problem-solving steps, and teaching clarity.
+- **articles:** maximize stylistic fidelity, genre mimicry, and rhetorical richness.
+
+---
+
+## .model
+
+| axis              | **lessons in context**                          | **articles in context**                     |
+|-------------------|-------------------------------------------------|---------------------------------------------|
+| **core fusion**   | explain × articulate (scaffolded knowledge)     | articulate (may include explain)            |
+| **strengths**     | clarity, stepwise structure, reusable templates | tone, breadth, rhetorical and stylistic form |
+| **weaknesses**    | narrow scope, less stylistic variety            | verbose, less causal scaffolding             |
+| **best use**      | teaching, tutoring, applied reasoning tasks     | style transfer, perspective capture          |
+
+---
+
+## .takeaway
+- **lessons compress more usable value per token** → best for clarity, reasoning, and consistency.
+- **articles provide articulation patterns** → best for stylistic or rhetorical goals.
+
+**in llm context:** if the task is *teach or solve*, prefer **lessons**. if the task is *sound like or persuade*, prefer **articles**.

package/dist/logic/roles/bhrain/.briefs/librarian.context/usage.lesson_vs_article_vs_demo.[lesson].md

@@ -0,0 +1,37 @@
+# 🧩 .brief: lessons vs articles vs demos in llm context
+
+## .what
+within an llm’s **context window**, you can load knowledge in the form of **lessons**, **articles**, or **demos**. each has a distinct function:
+- **lessons** = structured scaffolds → optimize for clarity & transfer.
+- **articles** = expository text → optimize for articulation & tone.
+- **demos** = concrete examples → optimize for showing *how it looks in practice*.
+
+---
+
+## .why (purpose)
+- **lessons:** to make the llm *reproduce structured reasoning* and stepwise clarity.
+- **articles:** to make the llm *mirror articulation, genre, and style*.
+- **demos:** to make the llm *imitate patterns through example-based learning*.
+
+---
+
+## .model
+
+| axis              | **lessons in context**                          | **articles in context**                        | **demos in context**                        |
+|-------------------|-------------------------------------------------|------------------------------------------------|---------------------------------------------|
+| **core fusion**   | explain × articulate (scaffolded knowledge)     | articulate (may include explain)               | example (observable instance)                |
+| **strengths**     | clarity, stepwise structure, reusable templates | tone, breadth, rhetorical and stylistic form   | concreteness, fast pattern transfer          |
+| **weaknesses**    | narrow scope, less stylistic variety            | verbose, less causal scaffolding               | shallow (shows *what*, not *why*)           |
+| **best use**      | teaching, tutoring, problem-solving             | style transfer, persuasion, context-rich tasks | training-by-example, template replication   |
+
+---
+
+## .takeaway
+- **lessons** compress rules into structured, reusable scaffolds.
+- **articles** convey style and breadth of articulation.
+- **demos** shortcut learning by showing *what to do*, often with minimal explanation.
+
+**in llm context:**
+- for *clarity & reasoning* → use **lessons**.
+- for *style & rhetoric* → use **articles**.
+- for *pattern mimicry* → use **demos**.

package/dist/logic/roles/bhrain/.briefs/librarian.tactics/.readme.md

@@ -0,0 +1,12 @@
+librarian tactics are all [brief]work
+- [article]s (<articulate>)
+- [catalog]s (<catalogize>)
+- [gallery][example]s (<illustrate>)
+- [gallery][review]s (<?>) (no generator for them? since they're detected / pulled / measured)
+
+the librarian gets and sets [brief]s
+
+the librarian is commonly asked to mutate focus
+- get briefs
+- compress per goal
+- set focus.context