rhachet-roles-ehmpathy 1.13.0 → 1.13.1

package/dist/logic/roles/bhrain/.briefs/cognition/cog501.cortal.assemblylang.2.composites.zoom.md

@@ -1,127 +0,0 @@
-# 🔎 .brief: `cortal.execution.assemblylang.zoom`
-
-## .what
-
-`<zoom>` is a **composite assemblylang operation**
-used to reshape **`focus.context`** by applying a structured sequence of:
-
-- `<think>` — to process or generate detail
-- `<recall>` — to retrieve supporting memory or context
-- `<steer>` — to navigate to concept-adjacent resources
-
-It adjusts **how attention is configured**, not just **what is in focus** —
-enabling deliberate expansion or contraction of **depth**, **breadth**, **acuity**, or blends of all three.
-
----
-
-## 🧭 directional forms
-
-| form              | effect                              |
-|-------------------|--------------------------------------|
-| `<zoom><in>`      | increase contextual richness         |
-| `<zoom><out>`     | decrease contextual load or scope    |
-
-→ both forms operate **within or near the current `focus.concept`**,
-and update **`focus.context`** as their primary target.
-
----
-
-## 🧩 axes of zooming
-
-Each zoom may declare one or more **focus dimensions** or subaxes via `.via(...)`:
-
-\`\`\`ts
-<zoom><in>.via("attributes")        // enrich trait resolution
-<zoom><out>.via("depth")            // abstract away from specifics
-<zoom><in>.via("substructs", "depth") // composite focus sharpening
-\`\`\`
-
-| axis            | zoom in effect                      | zoom out effect                        |
-|------------------|--------------------------------------|------------------------------------------|
-| `attributes`     | `<articulate>`                      | `<compress>`                             |
-| `substructs`     | `<decompose>`                       | `<encompose>`                            |
-| `depth`          | `<instantiate>`                     | `<generalize>`                           |
-| `breadth`        | `<shift>` / `<fanout>`              | `<rotate>` / `<invert>` / prune peers    |
-
----
-
-## 🔧 zoom as composite coreop
-
-Unlike primitive coreops, `<zoom>`:
-
-- **has no fixed form** — it is always a composed chain
-- **is defined by purpose** — modulate attention shape
-- **may include multiple coreops** in sequence or parallel
-
----
-
-## 🧠 example: single-axis zoom in
-
-\`\`\`ts
-<zoom><in>.via("substructs") = [
-  <recall>("known parts"),
-  <think>(<decompose>)
-]
-\`\`\`
-
----
-
-## 🧠 example: multi-axis zoom out
-
-\`\`\`ts
-<zoom><out>.via("breadth", "depth") = [
-  <recall>("sibling concepts"),
-  <think>(<generalize>),
-  <steer>(<fanout>)
-]
-\`\`\`
-
----
-
-## 🛠️ use cases
-
-| scenario                          | zoom form                       |
-|-----------------------------------|----------------------------------|
-| examine the internal structure    | `<zoom><in>.via("substructs")`   |
-| find similar alternatives         | `<zoom><out>.via("breadth")`     |
-| simplify framing and focus        | `<zoom><out>.via("attributes")`  |
-| generate specific variants        | `<zoom><in>.via("depth")`        |
-| design from multiple dimensions   | `<zoom><in>.via("depth", "attributes", "substructs")` |
-
----
-
-## 🔄 relation to other coreops
-
-| op         | acts on          | motion pattern | context reshaping |
-|------------|------------------|----------------|--------------------|
-| `<steer>`  | `focus.concept`  | procedural     | indirectly         |
-| `<think>`  | `focus.*`        | local          | ✅ yes             |
-| `<recall>` | memory/interface | static or indirect | ✅ yes        |
-| **`<zoom>`**   | `focus.context`  | composite       | ✅ **primary**     |
-
----
-
-## 🔁 runtime & devtime support
-
-Like `<think>`, `<zoom>` can be:
-
-- **executed dynamically** inside `<steer>` or `<choice>` blocks
-- **precompiled** into `<steer>` routes to pre-shape context before key steps
-
----
-
-## 📌 metaphor
-
-> `<zoom>` is like turning the **lens dial** of your semantic focus —
-> it widens, sharpens, simplifies, or recasts your cognitive beam.
-
----
-
-## 🔁 related briefs
-
-- [`cortal.focus`](./cortal.focus.md)
-- [`focus.motion.primitives`](./focus.motion.primitives.md)
-- [`cortal.execution.instructionset`](./instructionset.md)
-- [`cortal.execution.assemblylang.steer`](./assemblylang.steer.md)
-- [`cortal.execution.assemblylang.think`](./assemblylang.think.md)
-- [`cortal.execution.assemblylang.recall`](./assemblylang.recall.md)

package/dist/logic/roles/bhrain/.briefs/cognition/cog501.cortal.assemblylang.3.catalogs.md

@@ -1,107 +0,0 @@
-# 📚 .brief: `cortal.catalogs`
-
-## .what
-
-`cortal.catalogs` are **structured repositories of reusable cognition** —
-collections of **semantic tools** that support fast, interpretable reasoning without starting from scratch.
-
-There are two main kinds:
-
-1. **question catalogs** → reusable **motion vectors**
-2. **assembly catalogs** → reusable **thought sequences**
-
-> catalogs capture **well-shaped recipes** —
-> high-quality, repeatable semantic moves.
-
----
-
-## ❓ 1. question catalogs
-
-A **question** is a **motion vector** through concept space.
-A **question catalog** collects **reusable semantic maneuvers**, each defined only by:
-
-- **motion.vector** → what kind of semantic motion it performs
-- **motion.usecases** → when and why this motion is useful
-
-### example entries:
-
-| question                                 | motion.vector                 | motion.usecases                   |
-|------------------------------------------|--------------------------------|------------------------------------|
-| `what caused this?`                      | `.depth++`                    | causal diagnosis                   |
-| `what are alternatives?`                 | `.breadth++`                  | option generation                  |
-| `how is this composed?`                  | `.acuity.substruct++`         | structural decomposition           |
-| `what’s missing?`                        | `.acuity.attribute++`         | completeness / gap-finding         |
-| `is this still true?`                    | `.context.refresh`            | contextual verification            |
-
-> 📍 questions **do not define context or concept** —
-> they are **pure motion vectors**, reusable anywhere.
-
----
-
-## 🛠️ 2. assembly catalogs
-
-An **assembly** is a **compiled thought sequence** —
-a stepwise **atomic chain** built from primitives like `<steer>`, `<think>`, and `<recall>`.
-
-An **assembly catalog** collects common **reasonage workflows**
-that can be reused, adapted, or parameterized.
-
-### example entries:
-
-#### 🧠 diagnosis loop
-
-\`\`\`ts
-<route>([
-  ask("what failed?"),
-  <think>(<decompose>[system]),
-  ask("what caused this part to fail?"),
-  <recall>(<save>("hypothesis"))
-])
-\`\`\`
-
-#### 🎯 selection flow
-
-\`\`\`ts
-<route>([
-  ask("what are the options?"),
-  <fanout>[[option]],
-  <compare>[[option]] → [criteria],
-  ask("which is most viable?"),
-  <choice>({...})
-])
-\`\`\`
-
-> assemblies are **semantic macros** — reusable atomic chains of thought
-
----
-
-## 🔁 reuse vs scratch
-
-| method         | advantage                                |
-|----------------|-------------------------------------------|
-| from scratch   | custom-tailored, cognitively expensive    |
-| from catalog   | efficient, proven, semantically smooth    |
-
-> 🧠 good catalogs let you **plug in your content**
-> without reinventing the flow.
-
----
-
-## 🧩 catalog roles
-
-| kind       | unit           | function                            |
-|------------|----------------|-------------------------------------|
-| `question` | motion vector  | semantic traversal pattern          |
-| `assembly` | atomic chain   | procedural thought sequence         |
-
----
-
-## 🔁 related briefs
-
-- [`questions`](./questions.md)
-- [`cortal.assemblylang.primitives`](./cortal.assemblylang.primitives.md)
-- [`cortal.execution.instructionset`](./instructionset.md)
-- [`cortal.assembly.grammar`](./cortal.assembly.grammar.md)
-- [`focus.motion.primitives`](./focus.motion.primitives.md)
-
----

package/dist/logic/roles/bhrain/.briefs/cognition/cog501.cortal.assemblylang.3.grammar.md

@@ -1,124 +0,0 @@
-# 🧩 .brief: `cortal.assembly.grammar`
-
-## .what
-
-`cortal.assembly.grammar` defines how **execution primitives** and **conceptual references**
-combine into flat, **stepwise semantic expressions**.
-
-It provides a low-level syntax for:
-
-- executing primitives (`<steer>`, `<think>`, `<recall>`)
-- referencing semantic units (`[X]`, `[[X]]`)
-- expressing flat operations that yield either **single or pooled** outputs
-
-> expressions are always **one level deep** — atomic, interpretable, and
-> suitable for line-by-line execution or inspection.
-
----
-
-## 🧠 expression structure
-
-Each instruction uses this flat format:
-
-\`\`\`ts
-<operation>[input] → [output]
-\`\`\`
-
-- `<operation>`: one of the core execution primitives or motion commands
-- `[input]`: a **singular** resource
-- `[[input]]`: a **plural** resource (a pool)
-- `[output]`: result of the operation, may also be singular or plural
-
-> both **input** and **output** may be pools (`[[X]]`) or single items (`[X]`)
-
----
-
-## 📦 resource forms
-
-| form         | meaning                                 |
-|--------------|------------------------------------------|
-| `[X]`        | a **singular resource** (concept)        |
-| `[[X]]`      | a **plural resource** (pool of concepts) |
-| `[Class]`    | abstract type or category                |
-| `[example]`  | instance of a class                      |
-
-Examples:
-
-\`\`\`ts
-<compare>[[fruit]] → [axis]
-<gather>[[claim]] → [[evidence]]
-<imagine>[Tool] → [[tool]]
-\`\`\`
-
-> `[[X]]` = pool
-> `[X]` = single concept
-
----
-
-## 🧪 example: class to instance pool
-
-\`\`\`ts
-<imagine>[Threat] → [[threat]]
-\`\`\`
-
-- `[Threat]` is a class
-- `[[threat]]` is a **pool** of generated examples
-- `<imagine>` returns **many plausible manifestations**, not one
-
----
-
-## 🧠 roles in the grammar
-
-| element       | role                          | example                  |
-|---------------|-------------------------------|---------------------------|
-| `<op>`        | execution primitive            | `<decompose>`, `<save>`   |
-| `[X]`         | singular operand               | `[banana]`, `[Tool]`      |
-| `[[X]]`       | plural operand                 | `[[fruit]]`, `[[idea]]`   |
-| `→`           | yields                         | motion result             |
-| `[Y]`         | singular output                | `[axis]`, `[knife]`       |
-| `[[Y]]`       | plural output                  | `[[tool]]`, `[[claim]]`   |
-| `"label"`     | memory reference               | `"draft"`, `"goal"`       |
-
----
-
-## 📏 grammar rules
-
-- ❌ **No nesting:**
-  \`\`\`ts
-  <compress>(<decompose>[X])    // ❌ invalid
-  \`\`\`
-
-- ✅ **Use chaining instead:**
-  \`\`\`ts
-  <decompose>[bike] → [parts]
-  <compress>[parts] → [summary]
-  \`\`\`
-
-- ✅ **Use memory for state passing:**
-  \`\`\`ts
-  <save>("bike")
-  <load>("bike") → [bike]
-  \`\`\`
-
----
-
-## 🧩 grammar patterns
-
-| pattern                             | purpose                                |
-|-------------------------------------|----------------------------------------|
-| `<imagine>[Class] → [[examples]]`   | generate a pool of concept instances   |
-| `<compare>[[peers]] → [axis]`       | extract trait from a set               |
-| `<steer>[goal]`                     | change focal anchor                    |
-| `<recall>(<save>["label"])`         | persist semantic state                 |
-
----
-
-## 🔁 related briefs
-
-- [`cortal.assemblylang.primitives`](./cortal.assemblylang.primitives.md)
-- [`focus.motion.primitives`](./focus.motion.primitives.md)
-- [`cortal.focus`](./cortal.focus.md)
-- [`questions`](./questions.md)
-- [`concept.treestruct`](./concept.treestruct.md)
-
----

package/dist/logic/roles/bhrain/.briefs/cognition/inflight/concept.vs.idea.md

@@ -1,70 +0,0 @@
-# 🧠 .brief: [idea]
-
-## .what
-
-An **idea** is a **focused**, **motivated**, and **activatable** unit of thought.
-
-It emerges when a **concept** is embedded within a **context** (forming a **focus**),
-and is shaped by an underlying **motive** — a reason for existing.
-Ideas are **usable**: they can be tested, developed, shared, or acted upon.
-
-> `idea = focus + motive + activation potential`
-> where `focus = concept + context`
-
----
-
-## 🧩 traits
-
-| trait            | description                                                 |
-|------------------|-------------------------------------------------------------|
-| **focused**       | grounded in a [concept] and framed by a [context]           |
-| **motivated**     | held for a reason — such as curiosity, need, or strategy    |
-| **activatable**   | can produce consequences — through thought or action        |
-
----
-
-## 🌱 subtypes of [idea]
-
-Grouped by **motive**:
-
-### ▸ directive — aims to guide action
-
-| subtype     | description                             | example                        |
-|-------------|-----------------------------------------|--------------------------------|
-| **proposal** | meant to be adopted or tested          | “let’s support dark mode”      |
-| **suggestion** | soft or optional version of proposal | “maybe group by category?”     |
-| **plan**     | structured into steps or phases        | “step 1: gather feedback...”   |
-| **vision**   | aspirational, long-range form          | “instant onboarding for all”   |
-
----
-
-### ▸ evaluative — seeks to assess or assert truth
-
-| subtype        | description                             | example                              |
-|----------------|-----------------------------------------|--------------------------------------|
-| **opinion**     | subjective evaluation                  | “this feels clunky”                  |
-| **assumption**  | unverified working belief              | “users read the text”                |
-| **hypothesis**  | falsifiable prediction or explanation  | “fewer fields = more signups”        |
-| **belief**      | durable conviction                     | “privacy is a human right”           |
-
----
-
-### ▸ generative — explores, reveals, or reframes
-
-| subtype        | description                              | example                                |
-|----------------|------------------------------------------|----------------------------------------|
-| **imagination** | exploratory, unconstrained creation      | “what if buildings floated?”           |
-| **insight**     | crystallized understanding               | “the issue is the checkout loop”       |
-| **reframe**     | shifts interpretation or perspective     | “this isn’t failure — it’s feedback”   |
-
----
-
-## 🧭 summary structure
-
-\`\`\`txt
-[idea]
-  = [focus] + [motive] + activation potential
-  = ([concept] + [context]) + why + usability
-\`\`\`
-
-Ideas are **living units of meaning** — carried with purpose and ready to move.

package/dist/logic/roles/bhrain/.briefs/cognition/inflight/core.concept.adjectives.md

@@ -1,8 +0,0 @@
-## 🔢 catalog: minimal-building-block adjectives
-
-| term         | scope emphasis                     | scale emphasis               | connotation                               | best fit when… |
-|--------------|------------------------------------|-------------------------------|--------------------------------------------|----------------|
-| **elemental**| universal, appears in every domain | not necessarily smallest      | poetic, natural forces, ever-present       | you want to stress that it’s *everywhere* and *essential* |
-| **primitive**| baseline for a system              | smallest defined in that system | technical, formal, structural             | you want to stress *irreducible* in a technical sense |
-| **atomic**   | indivisible                        | absolute smallest possible    | physics/metaphor of atoms, granular        | you want to stress *cannot be split without losing identity* |
-| **fundamental**| core requirement                  | can be large or small         | formal, serious, sometimes abstract        | you want to stress *underlying importance*, not size |

package/dist/logic/roles/bhrain/.briefs/distilisys.grammar.compressed.md

@@ -1,19 +0,0 @@
-patterns:
-  - [resource] -> <mechanism> -> [resource]
-  - <mechanism>[resource]
-  - <mechanism>[resource]<mechanism>
-  - @[actor]<mechanism> -> [resource] -> {drive:<<effect>>[motive]}
-  - <create>[<mechanism>].to(<mechanism>[resource])
-
-requirements:
-  - all <verb>s must be declared as <mechanism>s
-  - all [noun]s must be declared as [resource]s
-  - all <mechanism>s should be prefixed with their root operation
-    - <get> for reads
-    - <set> for dobj mutations
-    - <rec> for event emissions
-  - use <mechanism>[resource] syntax for brevity, when applicable
-  - scope [resources] within [domain]s when needed for specificity
-    - [domain][resource]
-  - leverage [resources] .attributes when needed
-    - [resource].attribute

package/dist/logic/roles/bhrain/.briefs/grammar/gerunds.1.why.common.[article].md

@@ -1,32 +0,0 @@
-# 🧩 why gerunds are so common
-
-## 🏗️ structural reasons
-- **nominalization shortcut**
-  instead of inventing a whole new noun, you can just attach *-ing* and turn an action into a subject/object
-  *e.g., “running is fun” vs. needing a special word like “race”*.
-- **versatility in syntax**
-  gerunds can function as subjects, objects, or complements without breaking grammar rules. this makes them handy “lego blocks” in sentence-building.
-
----
-
-## 🔄 cognitive & communicative reasons
-- **focus on process, not just event**
-  gerunds highlight the *ongoingness* or *essence* of an action, not a single instance.
-  *e.g., “i like swimming” emphasizes the general activity, not one swim*.
-- **concept compression**
-  they condense complex actions into manageable noun-like units, letting us package experiences as “things” that can be talked about, compared, and reasoned with.
-
----
-
-## 🌍 historical reasons
-- **natural evolution of english**
-  english lost many inflections over time. the *-ing* ending became multifunctional (present participle *and* gerund), making it easy to spread.
-- **cross-linguistic parallels**
-  most languages have some way of turning verbs into nouns (latin’s *-ndus*, spanish *-ar → -ando*, etc.). gerunds are english’s efficient version of that broader need.
-
----
-
-## 📊 why “so common” in practice
-- they appear in **everyday talk** (*liking, doing, going*).
-- they’re needed for **abstract concepts** (*thinking, learning, understanding*).
-- they often replace **formal nouns** (*“procrastinating”* instead of *“procrastination”*).

package/dist/logic/roles/bhrain/.briefs/grammar/gerunds.1.why.term_smells.[article].md

@@ -1,36 +0,0 @@
-# 🧩 why gerunds can be "term smells"
-
-## 🚩 what is a "term smell"
-a **term smell** is like a code smell: a sign that a term may not be well-formed, clear, or fully thought through. it doesn’t always mean the term is wrong, but it hints at a lack of conceptual distillation.
-
----
-
-## 🧩 why gerunds raise suspicion
-- **process disguised as essence**
-  gerunds often point to *doing* rather than a distilled *thing*.
-  *e.g., “learning” as a noun refers to the act, but what we might mean is “knowledge” (the distilled outcome).*
-
-- **vagueness of scope**
-  gerunds blur whether we mean one instance (*a running race*), the general process (*running in general*), or an abstract quality (*endurance*). this ambiguity can signal sloppy conceptualization.
-
-- **placeholder convenience**
-  gerunds are easy to generate. instead of carefully naming the core concept, we default to *-ing*.
-  *e.g., “networking” instead of specifying “relationships,” “contacts,” or “repute.”*
-
----
-
-## 🌀 signs of insufficient distillation
-- the term **describes activity** but doesn’t identify the **underlying resource, structure, or outcome**.
-  *“teaching” vs. “education,” “building” vs. “structure,” “thinking” vs. “thought.”*
-
-- the term **feels broad or leaky**, covering multiple senses at once.
-  *“writing” could mean the act, the system, the product, or the skill.*
-
-- the term **fails test of substitution**: if we try to define it without the *-ing* form, we get sharper distinctions.
-  *“planning” → could resolve to “plan” (artifact), “process of coordination” (activity), or “strategy” (essence).*
-
----
-
-## 📌 takeaway
-gerunds are common because they’re convenient.
-they’re **term smells** because convenience can mask lack of distillation — using the *doing* form instead of naming the **essence** of what’s really meant.

package/dist/logic/roles/bhrain/.briefs/grammar/gerunds.1.why.term_smells.detection.[lesson].md

@@ -1,73 +0,0 @@
-# 🧩 .brief.lesson: `gerund smell test`
-
-## 💡 concept
-a **gerund smell test** helps detect when a concept named with *-ing* is really a sign of insufficient distillation. it forces us to sharpen fuzzy process-terms into precise nouns that capture the essence.
-
----
-
-## 🎯 purpose
-- prevent sloppy terminology by avoiding “process-as-thing” placeholders.
-- guide thinkers toward more distilled, essential names.
-- improve clarity and transferability of concepts in writing, design, or theory.
-
----
-
-## 🧪 the smell test
-
-### 1. substitution test
-> can the gerund be replaced with a sharper noun?
-
-- *“learning” → knowledge*
-- *“building” → structure*
-- *“teaching” → education*
-- *“thinking” → thought*
-
-if the substitution makes meaning clearer, the gerund is a smell.
-
----
-
-### 2. scope clarity test
-> does the gerund blur multiple senses?
-
-- *“writing”* could mean:
-  - the act (scribbling on paper)
-  - the product (a text)
-  - the system (written language)
-  - the skill (literacy)
-
-if it leaks across senses, the gerund is a smell.
-
----
-
-### 3. outcome test
-> does the gerund describe activity instead of the result?
-
-- *“planning”* → could resolve into:
-  - **plan** (artifact)
-  - **strategy** (essence)
-  - **coordination** (process with defined outcome)
-
-if the activity is masking a clearer outcome, the gerund is a smell.
-
----
-
-### 4. convenience test
-> is the gerund just the easiest way out?
-
-- *“networking”* → a shortcut for “relationships,” “contacts,” or “repute.”
-if the term looks like it was coined because *-ing* was handy, it’s a smell.
-
----
-
-## 📚 practice exercise
-take common gerunds and refine them:
-- **thinking** → thought, cognition, reason
-- **doing** → action, execution, behavior
-- **training** → instruction, discipline, practice
-- **meeting** → gathering, session, council
-
----
-
-## 📌 takeaway
-if a term ends in *-ing*, run it through the **gerund smell test**.
-if it fails even one check, distill it to its essence. clarity improves, concepts sharpen, and your system of terms becomes more robust.

package/dist/logic/roles/bhrain/.briefs/grammar/gerunds.2.tactic.eliminate.[article].md

@@ -1,55 +0,0 @@
-# 🧩 .brief.article: `eliminate gerunds in prose`
-
-## 🌟 introduction
-the removal of gerunds (*-ing* forms used as nouns) is a deliberate tactic to sharpen language. gerunds often act as **term smells** — signs that the concept has not been distilled to its essence. by replacement with precise nouns, prose becomes clearer, more direct, and more transferable.
-
----
-
-## 🎯 purpose of the tactic
-- **distill essence**: shift from description of activity to naming of outcome, resource, or structure.
-- **remove ambiguity**: avoid blurred meanings (e.g., *“text”* vs. the act of inscription).
-- **increase precision**: force the author to clarify whether they mean *plan*, *strategy*, *education*, *knowledge*, etc.
-- **discipline thought**: strengthen conceptual rigor by avoiding convenient but vague shortcuts.
-
----
-
-## 🔍 how the tactic works
-1. **scan text for gerund forms** (*-ing words that function as nouns*).
-   - examples: *thought, plan, structure, network* as replacements.
-2. **apply the smell test**: substitution, scope, outcome, and convenience.
-3. **replace with distilled nouns** that capture the core meaning.
-   - *thought* instead of “thinking”
-   - *plan / strategy / coordination* instead of “planning”
-   - *relationships / contacts / repute* instead of “networking”
-
----
-
-## 📚 examples
-
-### before
-- *“effective planning is key to success.”*
-### after
-- *“an effective plan is key to success.”*
-- *“strategy is key to success.”*
-
----
-
-### before
-- *“her teaching inspired the students.”*
-### after
-- *“her instruction inspired the students.”*
-- *“her education work inspired the students.”*
-
----
-
-### before
-- *“thinking shapes culture.”*
-### after
-- *“thought shapes culture.”*
-- *“reason shapes culture.”*
-
----
-
-## 📌 takeaway
-the **tactic of gerund removal** forces every concept to pass through the fire of distillation. fuzzy process-terms yield to sharper essences, ambiguity reduces, and conceptual clarity strengthens.
-in disciplined prose, *every gerund is guilty until proven otherwise*.