rhachet-roles-bhrain 0.1.0

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

@@ -0,0 +1,45 @@
+# 🧩 .brief: `articulate`
+
+## .what
+**`articulate`** is a **focus.motion** primitive that transforms an in-progress concept into a **clear, explicit, and shareable form**.
+It takes an internal, often fuzzy understanding and **renders it into precise language or representation**, making it accessible for others — or for one’s own future self.
+
+---
+
+## 🎯 goal
+- convert **implicit understanding** into **explicit expression**
+- ensure the concept is **comprehensible, accurate, and usable**
+- provide a **stable reference** for discussion, reasoning, or implementation
+
+---
+
+## ⚙️ method
+1. **anchor**
+   - establish the core concept or seed you’re articulating
+   - lock in scope and avoid redefining mid-process
+
+2. **structure**
+   - choose an organizational frame (outline, template, narrative, gallery-based, etc.)
+   - match format to purpose and audience
+
+3. **express**
+   - render the concept in clear, direct language
+   - surface key attributes, context, and distinctions
+
+4. **refine**
+   - check for clarity, completeness, and fidelity to the original intent
+   - adjust wording or structure as needed
+
+---
+
+## 📐 when to use
+- when a concept needs to move from **thought** to **communicable form**
+- when collaborating, teaching, or documenting
+- when ambiguity is blocking decision-making or action
+
+---
+
+## 💡 notes
+- articulation is **not invention** — the core concept should already exist, even if only as a seed
+- the **acuity** of articulation depends on how well attributes, context, and boundaries are surfaced
+- can be combined with other tactics (e.g., template-driven, exemplar-driven) for different use cases

package/dist/roles/thinker/briefs/librarian.tactics/<articulate>.tactic.[catalog].md

@@ -0,0 +1,83 @@
+# 📚 .catalog: `<articulation>.tactics`
+
+## .what
+A reference set of professional strategies for improving the **clarity, completeness, and resonance** of a concept when composing an [article].
+
+---
+
+## 🛠 tactics
+
+### 1. **checklist-driven articulation**
+> use a predefined list of *must-cover* elements to ensure completeness.
+- best for compliance, standards, and repeatable formats
+- example: medical case reports, technical audits
+
+---
+
+### 2. **progressive refinement**
+> start broad, then iteratively zoom into detail (high → medium → low acuity).
+- prevents getting stuck in minutiae early
+- example: write `.what` at overview level, then deepen `.how` and `.why` in passes
+
+---
+
+### 3. **compare-and-contrast framing**
+> define the concept by placing it alongside similar or opposite concepts.
+- accelerates reader understanding via reference points
+- example: feature comparison charts, pros-vs-cons lists
+
+---
+
+### 4. **story-path anchoring**
+> embed the concept in a narrative arc — problem → struggle → resolution.
+- engages attention, aids memory
+- example: user journey stories, before/after scenarios
+
+---
+
+### 5. **taxonomy positioning**
+> locate the concept within a larger system or hierarchy.
+- clarifies scope, boundaries, and related concepts
+- example: placing a technology in a standards stack diagram
+
+---
+
+### 6. **question-driven expansion**
+> use targeted interrogatives (`what`, `why`, `how`, `when`, `who`, `where`) to systematically fill gaps.
+- works well with `<ponder>` and `<enquestion>`
+- example: investigative reporting, root-cause analysis
+
+---
+
+### 7. **pattern abstraction**
+> generalize from specific instances to reveal the underlying structure or principle.
+- good for reusable methods and cross-domain lessons
+- example: abstracting a “sales funnel” pattern from multiple case studies
+
+---
+
+### 8. **reverse articulation**
+> start from the end result or key takeaway and work backward to the core concept.
+- ensures purpose-driven clarity
+- example: explaining a research conclusion by retracing the evidence path
+
+---
+
+### 9. **visual scaffolding**
+> pair text with diagrams, charts, or schemas that mirror the article structure.
+- improves retention and helps readers navigate complex content
+- example: flowcharts for process explanations, mindmaps for relationships
+
+---
+
+### 10. **multi-perspective synthesis**
+> integrate views from different roles, disciplines, or stakeholders.
+- reveals hidden constraints and broader implications
+- example: combining engineer, designer, and end-user perspectives in a product spec
+
+---
+
+## 🔄 usage
+- select 1–3 tactics per [article] depending on **goal**, **audience**, and **acuity**
+- can be sequenced (e.g., start with **story-path anchoring**, end with **taxonomy positioning**)
+- most effective when paired with **templates-exemplars** to keep structure coherent

package/dist/roles/thinker/briefs/librarian.tactics/<articulate>.tactic.concept_dimension.examples.[article][seed].md

@@ -0,0 +1,4 @@
+an # examples section on the [article] helps illustrate meaning via practice
+
+
+examples = concept practice; learn via usage

package/dist/roles/thinker/briefs/librarian.tactics/<articulate>.tactic.concept_dimension.invariants.[article].md

@@ -0,0 +1,36 @@
+# 🧩 .brief: `concept.dimensions.generic`
+
+## .what
+**`concept.dimensions.generic`** defines the **invariant semantic dimensions** that can be articulated for *any* [concept] in an [article], regardless of domain.
+these dimensions form a **semantic skeleton** — the minimal, always-present slots for fully describing a concept.
+
+---
+
+## 🎯 goal
+- provide a **universal template** for [article] articulation
+- ensure **concept descriptions** are complete, consistent, and comparable
+- enable automation in concept documentation and reasoning flows
+
+---
+
+## 📐 dimensions
+
+| dimension       | question it answers                | description | why it’s always articulable |
+|-----------------|------------------------------------|-------------|-----------------------------|
+| **.what**       | “what is it?”                      | definition and identity — what makes it this concept and not something else | every concept has an identity to distinguish it from others |
+| **.why**        | “why does it exist?”               | purpose, goal, or motivating function | every concept emerges from some need, cause, or intention |
+| **.how**        | “how does it work?”                | mechanisms, processes, or methods | every concept operates in some way, even abstractly |
+| **.where**      | “where does it apply?”             | domain, scope, or applicable contexts | every concept exists in a context or environment |
+| **.when**       | “when is it relevant?”             | temporal aspect — timing, lifecycle, or stage relevance | every concept has moments when it applies or manifests |
+| **.who**        | “who is involved?”                 | agents, roles, or entities that use, own, or are affected by it | every concept has some relationship to actors |
+| **.attributes** | “what qualities does it have?”     | intrinsic traits, descriptors, or parameters | every concept has distinguishable features |
+| **.relations**  | “what is it connected to?”         | links to other concepts — dependencies, contrasts, hierarchies | no concept exists in total isolation |
+| **.examples**   | “what does it look like in action?” | concrete instances or scenarios that embody it | every concept can be grounded by illustration |
+| **.variants**   | “what forms can it take?”          | versions, subtypes, or adaptations | concepts can be generalized or specialized |
+| **.tradeoffs**  | “what are its strengths & limits?” | pros, cons, constraints, and opportunity costs | every concept has both enabling and limiting factors |
+
+---
+
+## 🛠 usage
+use `concept.dimensions.generic` as the **default frame** when authoring any [article] about a [concept].
+even if some slots are left empty, their presence maintains **structural completeness** and improves cross-concept comparability.

package/dist/roles/thinker/briefs/librarian.tactics/<articulate>.tactic.from.examples.md

@@ -0,0 +1,44 @@
+# 🧩 .brief: `articulate.via.examples`
+
+## .what
+**`articulate.via.examples`** is an **articulation tactic** that uses a **curated set of illustrative examples** as the *source lens* for expression.
+instead of starting from abstract definition alone, we draw meaning and nuance from **specific, well-chosen examples**, then generalize or synthesize into a coherent articulation.
+
+---
+
+## 🎯 goal
+- ground articulation in **tangible, relatable instances**
+- capture **implicit patterns** and **hidden traits** that emerge from examples
+- ensure descriptions are **anchored to reality** rather than drifting into abstraction
+
+---
+
+## ⚙️ method
+1. **curate examples**
+   - gather a diverse yet representative set of examples that express the concept in action
+   - ensure variety in form, context, and perspective
+
+2. **observe & extract**
+   - identify recurring traits, contrasts, and anomalies
+   - note emotional, functional, and structural elements
+
+3. **abstract & articulate**
+   - generalize from observations into a clear, structured articulation
+   - weave in example references as anchors or supporting points
+
+4. **verify coverage**
+   - check that the articulation reflects the **breadth** of the examples, not just a single outlier
+
+---
+
+## 📐 when to use
+- when a concept is **experiential, aesthetic, or contextual**
+- when definitions alone fail to capture **richness or nuance**
+- when multiple audiences must relate through **concrete illustration**
+
+---
+
+## 💡 notes
+- the **quality of articulation** depends directly on the **quality of curation**
+- works well in combination with **template-driven articulation** for structure
+- danger: overfitting articulation to the quirks of chosen examples — mitigate with diverse selection

package/dist/roles/thinker/briefs/librarian.tactics/<articulate>.tactic.from.seed.md

@@ -0,0 +1,48 @@
+# 🧩 .brief: `articulate.tactic.from.seed`
+
+## .what
+**`articulate.tactic.from.seed`** is an **articulation tactic** that grows a complete, coherent expression of a concept starting from a **minimal viable seed**.
+instead of beginning with an elaborate structure, the articulation emerges through **progressive expansion** — the seed acts as the anchor that keeps the work aligned while details are developed.
+
+---
+
+## 🎯 goal
+- expand from a **single point of clarity** into a fully formed articulation
+- maintain **focus and scope control** during expansion
+- ensure the final form aligns with the original **intent encapsulated in the seed**
+
+---
+
+## ⚙️ method
+1. **capture the seed**
+   - define the smallest meaningful unit of the concept (e.g., [title], key phrase, keyword cluster)
+   - ensure it expresses the core intent without unnecessary detail
+
+2. **expand the context**
+   - recall or research relevant background, audience, and constraints
+   - collect related facts, patterns, and perspectives tied to the seed
+
+3. **structure the growth**
+   - organize expanded material into a clear framework
+   - decide on form: [brief] (instance) or other detailed structure
+
+4. **refine expression**
+   - iterate language, examples, and framing to match clarity and audience needs
+
+5. **finalize**
+   - produce the deliverable in the intended scope and form
+   - verify alignment with the seed’s intent
+
+---
+
+## 📐 when to use
+- when starting from **limited initial input**
+- when clarity of scope is critical and drift must be minimized
+- when evolving a [title] (reference) into a [brief] (instance)
+
+---
+
+## 💡 notes
+- the **seed** serves as a guardrail to prevent irrelevant expansion
+- works well with `<distill>` to reverse the process back into a compact seed form
+- danger: over-expanding beyond the seed’s intended boundaries — mitigate with regular scope checks

package/dist/roles/thinker/briefs/librarian.tactics/<articulate>.tactic.with.templates.[article].md

@@ -0,0 +1,57 @@
+# 🧩 .brief: `<articulation>.tactic.templates-exemplars`
+
+## .what
+**`<articulation>.tactic.templates-exemplars`** is a structured method for composing an [article] by **anchoring its form** to pre-established **templates** and **exemplars**.
+the tactic recognizes that **different usecases** — and different **focal.acuity** levels — require **different structural patterns** for clarity, completeness, and efficiency.
+
+---
+
+## 🎯 goal
+- **speed**: reduce cognitive load by starting from a proven structure
+- **consistency**: ensure similar usecases share a coherent form
+- **acuity-alignment**: match the article’s structure to the intended depth, breadth, and granularity of focus
+
+---
+
+## ⚙️ method
+
+1. **determine acuity profile**
+   - assess **focal.acuity**: how granular should the article be?
+   - align to purpose: is this a high-level overview, detailed technical spec, or deep analytical dive?
+
+2. **select a matching template**
+   - choose from a library of predefined skeletons, each optimized for certain acuity levels and audiences
+   - templates specify **section order**, **content slots**, and **minimum coverage**
+
+3. **review relevant exemplars**
+   - pull in past [articles] that match the chosen template and purpose
+   - note stylistic choices, flow, and any domain-specific conventions
+
+4. **map content to structure**
+   - fit your content into the **template slots**, adapting as needed
+   - use exemplars as **style and completeness guides**
+
+5. **iterate for fit**
+   - ensure the final shape reflects both the **content’s natural flow** and the **acuity requirements**
+   - adjust structure only if it improves clarity or precision
+
+---
+
+## 📐 why it works
+- **pattern reuse**: avoids reinventing structural logic each time
+- **cotext sensitivity**: ensures different acuities get different forms, avoiding under- or over-specification
+- **learning by example**: exemplars illustrate successful executions, reducing ambiguity in applying the template
+
+---
+
+## 🔄 relation to other `<articulation>` tactics
+- complements **freeform exploration** by providing **scaffolding** rather than constraints
+- pairs well with **checklist-driven articulation** to ensure completeness within the chosen template
+- can be combined with **acuity-zoom tactics** to progressively refine structure
+
+---
+
+## 🛠 example usage
+- **low acuity** (overview) → use a **3-section template**: `.what`, `.why`, `.impact`
+- **high acuity** (technical deep dive) → use a **multi-section template**: `.what`, `.why`, `.how`, `.tradeoffs`, `.examples`, `.references`
+- review past [articles] in the same category to emulate tone, ordering, and coverage

package/dist/roles/thinker/briefs/librarian.tactics/<articulate>.tactic.with.templates.[gallery][review].effective.md

@@ -0,0 +1 @@
+this tactic has been very effective in practice

package/dist/roles/thinker/briefs/librarian.tactics/<articulate>.tone.bluecollar.[article][seed].md

@@ -0,0 +1,5 @@
+tone:bluecollar applied to reframe [article]s heavily simplifies and reduces frill; makes things much more intuitive
+
+the cool aspect is, it doesn't necessitate loss of specificity
+
+seems like the concepts are still articulated clearly, with the same level of detail. just, more intuitively in verbiage

package/dist/roles/thinker/briefs/librarian.tactics/<catalogize>._.[article][seed].md

@@ -0,0 +1,3 @@
+catalogize produces a [catalog] of useful variants of some [concept]
+
+

package/dist/roles/thinker/briefs/librarian.tactics/<catalogize>.observation.via_clusterage_over_via_imagination.[seed].md

@@ -0,0 +1,6 @@
+seen over and over that...
+
+
+attempting to catalogize via imagination leads to unhelpful/wrong generalizations
+
+but via examples works rapidly and consistently

package/dist/roles/thinker/briefs/librarian.tactics/<catalogize>.vs_diverge.[article].persp.save_compute.md

@@ -0,0 +1,46 @@
+# 🧩 .brief: `perspective on <catalogize> as a tactic`
+
+## .what
+**`<catalogize>`** is a tactic designed to systematically organize a wide array of concepts into a coherent structure or system. It aims to identify, classify, and relate distinct concepts within a given scope, providing clarity and facilitating understanding through structured representation.
+
+---
+
+## 🎯 core perspective
+`<catalogize>` has parallels with the tactic known as **`<diverge>`**, particularly in its ability to handle diverse concepts. However, while **`<diverge>`** seeks to generate concepts expansively and without immediate structure, `<catalogize>` benefits from leveraging pre-diverged content to focus on the task of organizing and classifying these ideas effectively.
+
+> 🧩 Diverging first provides a rich dataset for `<catalogize>` to work with, enhancing the quality and scope of the cataloging process.
+
+---
+
+## ⚙️ operational insight
+- **similarity to `<diverge>`**:
+  - both can zero shot concepts, initiating from nothing to create content.
+  - both aim to cover a wide range of concepts, albeit with different end goals.
+
+- **difference from `<diverge>`**:
+  - `<diverge>` focuses on ideation, while `<catalogize>` focuses on organization.
+  - `<catalogize>` benefits from having pre-diverged outputs in the focus.concept, allowing it to allocate cognitive resources towards effective cataloging rather than ideation.
+
+- **optimization hypothesis**:
+  - with pre-diverged outputs, `<catalogize>` saves LLM compute for cataloging activities, enhancing efficiency and depth without spending resources on divergence.
+
+- **best practice**:
+  - ideally, one uses **`<diverge>`** initially to ensure a broad and diverse set of concepts, then employs `<catalogize>` to impose structure and order.
+
+---
+
+## 📐 strategic use
+- Initialization: `<diverge>` generates a wide-ranging set of concepts.
+- Progression: Leveraged **divergent outputs** in focus.concept for `<catalogize>`.
+- Convergence: `<catalogize>` filters, categorizes, and arranges these into a meaningful, structured framework.
+
+---
+
+## 🎯 benefits
+- **Efficiency**: By separating the divergent and cataloging phases, you conserve mental energy and optimize the capacity of each tactic.
+- **Comprehensiveness**: Ensures a thorough exploration of the concept space prior to imposing a structure.
+- **Clarity**: Results in a refined, organized output that enhances understanding of complex ideas.
+
+> Adopting this approach means `<catalogize>` doesn't waste compute on generating, but focuses on delivering a structured and meaningful catalog.
+
+---

package/dist/roles/thinker/briefs/librarian.tactics/<demonstrate>._.[article].frame.colloquial.i2.by_grok.md

@@ -0,0 +1,64 @@
+# 🧩 .brief.article: `demonstrate`
+
+## .what
+**demonstrate** refers to the act of clearly showing or explaining a concept’s essence, structure, or functionality through a tangible instance, often producing a `.brief.demo` artifact to make abstract or complex ideas accessible. In the context of `.brief.demo`, it involves instantiating a concept in a structured Markdown format to reveal its interconnected components, like a tree-like hierarchy, for clear understanding.
+
+---
+
+## 🎯 purpose
+- **clarify** the concept’s core traits, structure, or application by presenting a concrete instance.
+- **showcase** how the concept functions through a specific, relatable example in a `.brief.demo`.
+- **educate** audiences by organizing the concept’s elements into a clear, hierarchical structure.
+- **persuade** readers of the concept’s value by demonstrating its practical or theoretical significance.
+
+---
+
+## 📏 methods of demonstration
+1. **Instantiation in .brief.demo**
+   - Present a concept through a specific instance (e.g., a use case template, a physical scenario) within a `.brief.demo` artifact.
+   - Effective for making abstract or technical concepts tangible, like quantum entanglement via a Bell test.
+
+2. **Structured Explanation**
+   - Use a detailed outline in the `.brief.demo` to explain how the instance embodies the concept’s traits.
+   - Suitable for breaking down complex ideas into clear, interconnected components.
+
+3. **Example-Driven Presentation**
+   - Highlight a single, relatable example to anchor the demonstration, ensuring accessibility.
+   - Ideal for engaging diverse audiences, from novices to experts, with familiar instances.
+
+4. **Hierarchical Organization**
+   - Arrange the demonstration to reflect the concept’s tree-like structure, connecting its elements logically.
+   - Helps reveal the concept’s internal relationships, like branches in a tree, for deeper understanding.
+
+---
+
+## 🔄 when to use
+- When introducing a new concept, such as a technical term or abstract idea, to make it concrete.
+- During educational efforts to clarify complex topics through structured `.brief.demo` artifacts.
+- To communicate system requirements or functionalities, as in software development use cases.
+- When explaining updates or innovations to stakeholders, using clear, instantiated examples.
+
+---
+
+## 📐 examples
+- **Software Development**: Demonstrating a “use case” by presenting a `.brief.demo` for “Booking a Flight on a Travel Website,” using a structured template to show user-system interactions.
+- **Physics Education**: Demonstrating “shear force” with a `.brief.demo` for “Scissors Cutting Paper,” highlighting parallel forces and material deformation.
+- **Cultural Studies**: Demonstrating “tea” via a `.brief.demo` on “Darjeeling Tea,” detailing its production and cultural role.
+- **Scientific Research**: Demonstrating “quantum entanglement” through a `.brief.demo` on a Bell test experiment, showing non-local correlations.
+
+---
+
+## 📚 benefits
+- Enhances understanding by grounding abstract concepts in tangible, relatable instances.
+- Builds credibility through structured, clear `.brief.demo` artifacts that showcase expertise.
+- Encourages engagement by using familiar examples to connect with diverse audiences.
+- Facilitates exploration of a concept’s tree-like structure, revealing its interconnected components.
+
+---
+
+## ⚠️ potential pitfalls
+- Choosing an overly complex instance that obscures the concept instead of clarifying it.
+- Failing to tailor the `.brief.demo` structure to the concept’s nature, reducing its effectiveness.
+- Overloading the artifact with excessive detail, leading to confusion or disengagement.
+
+> A well-executed demonstration via a `.brief.demo` transforms abstract concepts into clear, structured, and engaging insights, bridging theory and application through instantiation.

package/dist/roles/thinker/briefs/librarian.tactics/<demonstrate>.variants.[catalog].md

@@ -0,0 +1,106 @@
+# .brief.catalog: `demonstrate variants`
+
+
+\`\`\`
+concept demonstration (demo, genus)
+│
+├── instance
+│   ├── example
+│   │   ↳ question: "what counts as it?"
+│   │   ↳ example: "downtown portland is highly walkable —
+│   │              groceries, schools, and cafes within 10 minutes."
+│   │
+│   ├── counter
+│   │   ↳ question: "what is it not?"
+│   │   ↳ example: "los angeles suburbs where every errand
+│   │              requires a car — this is not walkability."
+│   │
+│   ├── contrast
+│   │   ↳ question: "how is this different from that?"
+│   │   ↳ example: "compare downtown portland (walkable) to
+│   │              houston sprawl (car-dependent)."
+│   │
+│   └── gradation
+│       ↳ question: "how does it vary along a spectrum?"
+│       ↳ example: "low → medium → high walkability across three block patterns."
+│
+├── medium
+│   ├── visual
+│   │   ↳ question: "what does it look like?"
+│   │   ↳ example: "map sketch with a house at the center,
+│   │              icons for grocery, school, café,
+│   │              all within a shaded 10-minute radius."
+│   │
+│   └── emotional
+│       ↳ question: "what does it feel like?"
+│       ↳ example: "the calm of strolling to a café vs the stress of sitting in traffic."
+│
+├── transfer
+│   ├── analogy
+│   │   ↳ question: "what is it like, in structure?"
+│   │   ↳ example: "walkability is like a circulatory system:
+│   │              sidewalks are arteries, intersections are valves,
+│   │              parks are lungs, stores are nutrients."
+│   │
+│   ├── metaphor
+│   │   ↳ question: "what is it, figuratively?"
+│   │   ↳ example: "walkability is oxygen for a city."
+│   │
+│   ├── simile
+│   │   ↳ question: "what is it like, figuratively?"
+│   │   ↳ example: "a walkable neighborhood feels like a living room —
+│   │              everything close, familiar, and reachable."
+│   │
+│   └── allegory
+│       ↳ question: "what story-world can stand in for it?"
+│       ↳ example: "a city without walkability is a kingdom without paths:
+│                  villages isolated, markets starved, citizens trapped.
+│                  when paths connect, culture and trade flow."
+│
+├── sequence
+│   ├── walkthrough
+│   │   ↳ question: "how does it proceed?"
+│   │   ↳ example: "walk from this apartment to the grocery store,
+│   │              noting the sidewalks, crosswalks, and distances."
+│   │
+│   ├── narrative
+│   │   ↳ question: "how does it unfold as lived experience?"
+│   │   ↳ example: "maria leaves her home, strolling past the bakery smells,
+│   │              greeting a neighbor, and reaching the grocery in five minutes."
+│   │
+│   ├── causal
+│   │   ↳ question: "how do inputs lead to outcomes?"
+│   │   ↳ example: "short blocks → more walking → health + economy + climate gains."
+│   │
+│   └── temporal
+│       ↳ question: "how does it change across time?"
+│       ↳ example: "1950 streetcar suburb → 1980 arterial strip → 2025 main street retrofit."
+│
+└── model
+    ├── simulation
+    │   ↳ question: "how would it behave if modeled?"
+    │   ↳ example: "urban planning software shows how
+    │              adding sidewalks shifts daily trips from cars to walking."
+    │
+    ├── prototype
+    │   ↳ question: "what form could it take?"
+    │   ↳ example: "build a model block with wide sidewalks,
+    │              corner cafés, and bike racks to embody walkability."
+    │
+    └── factorization
+        ↳ question: "what are its components?"
+        ↳ example: "proximity, safety, comfort, interest, connectivity as factors of walkability."
+\`\`\`
+
+
+---
+
+## 🎯 notes
+- **five clusters** organize the space of concept-demos:
+  1. **instance** → cases & boundaries
+  2. **medium** → change of representation
+  3. **transfer** → meaning carried across concepts
+  4. **sequence** → unfolding over time
+  5. **model** → embodiment in models/artifacts
+
+- each subtype has a **walkability demo** attached for clarity.

package/dist/roles/thinker/briefs/librarian.tactics/<demonstrate>.variants.contrast.[demo].usecase.vs_userjourney.by_chatgpt.md

@@ -0,0 +1,45 @@
+# .brief.demo: `use case` via `contrast` = `use case vs user journey`
+
+## 💡 concept
+a use case describes how a user interacts with a system to achieve a specific goal, while a user journey maps the broader, often emotional, experience of a user across multiple touchpoints with a product or service.
+
+## ❓ question
+> how does a use case contrast with a user journey?
+
+## 📌 contrast: use case vs user journey
+
+### 📌.📖 what
+
+> what are use cases and user journeys?
+
+- **use case**
+  - focuses on *functional interaction* between user and system.
+  - defines *actors, steps, and system responses* leading to a specific outcome.
+  - *example:* “a customer books a flight on an airline’s website.”
+
+- **user journey**
+  - focuses on *holistic experience* across touchpoints.
+  - includes *motivations, emotions, and pain points* before, during, and after interaction.
+  - *example:* “a traveler researches destinations, compares prices, books a flight, receives updates, travels, and later reviews the airline.”
+
+### 📌.🔍 how
+
+> how does this contrast demonstrate the concept of use case?
+
+- **scope**
+  - a use case is **narrow**, zooming into a single functional interaction.
+  - a user journey is **broad**, mapping multiple interactions across a timeline.
+
+- **focus**
+  - a use case emphasizes **system behavior**: “what happens when the user does X?”
+  - a user journey emphasizes **user experience**: “how does the user feel at each stage?”
+
+- **artifact**
+  - use case outputs are structured step-by-step flows of user + system actions.
+  - user journey outputs are visual maps, storyboards, or timelines showing phases and emotions.
+
+- **example contrast**
+  - **use case:** “customer selects flight → enters details → system confirms booking.”
+  - **user journey:** “customer dreams of vacation → compares airlines → struggles with hidden fees → books → feels reassured by confirmation → experiences anxiety waiting for boarding.”
+
+this contrast clarifies that a **use case is about functionality**, while a **user journey is about experience**. together, they complement each other, but they are not the same.

package/dist/roles/thinker/briefs/librarian.tactics/<demonstrate>.variants.counter.[demo].usecase.flyer.by_chargpt.md

@@ -0,0 +1,38 @@
+# .brief.demo: `usecase` via `counter` = `restaurant menu flyer`
+
+## 💡 concept
+a use case describes how a user interacts with a system to achieve a specific goal, detailing the steps, actors, and system responses involved in the interaction.
+
+## ❓ question
+> what is a counter-example of a use case?
+
+## 📌 counter-example: restaurant menu flyer
+
+### 📌.📖 what
+
+> what is the restaurant menu flyer?
+
+a printed restaurant menu flyer is a static list of food items and prices distributed for advertising purposes. it provides information but does not describe any user interactions, system responses, or step-by-step goals.
+
+- **static content**
+  - lists meals, prices, and phone number
+  - *example:* a pizza shop flyer with daily specials
+- **no interactive process**
+  - customer may see the flyer, but the flyer itself does not facilitate ordering
+- **no system responses**
+  - the flyer cannot process actions or provide feedback
+- **actors missing**
+  - does not define the roles of customer, staff, or delivery process
+
+### 📌.🔍 how
+
+> how is a restaurant menu flyer a counter-example of a use case?
+
+the menu flyer illustrates what a use case is *not*, because it lacks:
+
+- **interaction**: there is no dynamic exchange between user and system—only one-way information.
+- **steps**: no sequence of actions leading to a goal is described.
+- **actors and responses**: the flyer does not specify participants or their roles, nor does it capture how a system responds to user input.
+- **goal structure**: while the flyer hints at a potential outcome (ordering food), it does not map the process of achieving that outcome.
+
+this counter-example shows that a use case requires **structured interaction** and **defined roles**, not just information or content.