rhachet-roles-ehmpathy 1.12.1 → 1.13.1

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

@@ -1,90 +0,0 @@
-## `.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

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

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

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

@@ -1,12 +0,0 @@
-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

package/dist/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>._.[article].frame.cognitive.md

@@ -1,33 +0,0 @@
-# 🗣️ .brief: `<articulate>`
-
-## 🧭 .what
-`<articulate>` is a **focus.motion.acuity** primitive on the `.attributes` subaxis. it moves **inward** (`.attributes++`) to enrich the **same** anchor concept by surfacing explicit traits. the anchor does not change; only the **resolution** of its description increases.
-
----
-
-## 🎯 purpose
-- transform a minimal or vague seed into a **clear, operational brief**
-- answer guiding questions to surface **surface-level attributes**
-- unlock **variation potential** by increasing `focal.acuity`
-
----
-
-## 🔗 relation to `focus.motion.acuity`
-- **subaxis** → `.attributes`
-- **motion** → `++` (enrich)
-- **direction** → inward (sharpen)
-- **effect** → reveals finer surface traits without changing the anchor
-
----
-
-## 🌿 treestruct interaction
-- **anchor** stays fixed: `focus.concept` is not swapped
-- **acuity** increases: more traits are cognitively present
-- surfaced traits can be used immediately for `<cluster>`, `<compare>`, or `<generalize>`
-
----
-
-## 📎 notes
-- `<articulate>` is for **attributes** only — use `<decompose>` for internal parts (`.substructs++`).
-- It is often run **after `<gather>`** and **before `<cluster>`**.
-- Higher acuity increases cognitive load; apply when precision directly benefits the reasoning goal.

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

@@ -1,45 +0,0 @@
-# 🧩 .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/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.tactic.[catalog].md

@@ -1,83 +0,0 @@
-# 📚 .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/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.tactic.concept_dimension.examples.[article][seed].md

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

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

@@ -1,36 +0,0 @@
-# 🧩 .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/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.tactic.from.examples.md

@@ -1,44 +0,0 @@
-# 🧩 .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/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.tactic.from.seed.md

@@ -1,48 +0,0 @@
-# 🧩 .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/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.tactic.with.templates.[article].md

@@ -1,57 +0,0 @@
-# 🧩 .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/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.tactic.with.templates.[gallery][review].effective.md

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

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

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

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

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

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

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

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