rhachet-roles-ehmpathy 1.12.1 → 1.13.1

package/dist/logic/roles/bhrain/.briefs/worders/knowledge.internal_vs_external.[demo].artist_vs_librarian.md

@@ -1,37 +0,0 @@
-# 🧩 .brief.demo: `contrasting internalized vs externalized knowledge`
-
----
-
-## 🎨 illustration: artist vs photo album
-- **internalized**: an artist paints a landscape in impressionist style. the scene is new, never painted before, but the *style* flows naturally from their training.
-- **externalized**: another person, instead of painting, flips open a photo album to show a picture of a real landscape. it is precise, factual, but limited to what’s in the album.
-
----
-
-## 🧠 llm parallel
-- **internalized knowledge (in weights)**
-  - llms generate from *patterns encoded in their parameters*.
-  - they “know” paris is the capital of france not because a fact is stored explicitly, but because the statistical patterns linking “capital of france” → “paris” are internalized during training.
-  - *strengths*: generalization, stylistic fluency, application to unseen contexts.
-  - *limits*: fuzziness, hallucination, imprecision.
-
-- **externalized knowledge (retrieval / database / rag)**
-  - systems query a source (wikipedia, sql table, search engine) to fetch the answer directly.
-  - paris is recalled exactly as written.
-  - *strengths*: precision, factual grounding, verifiability.
-  - *limits*: no fluency, no adaptation — must rely on what’s stored.
-
----
-
-## ⚖️ contrast takeaways
-- **internalized = style** → adaptive, expressive, compressed into structure.
-- **externalized = record** → exact, reliable, stored outside the system.
-- llms by default operate on **internalized knowledge**, but can be paired with external retrieval to combine *fluency* with *accuracy*.
-
----
-
-## 🔑 intuition anchor
-an llm is like a painter, not a librarian.
-- the **painter** expresses patterns they’ve internalized into their craft.
-- the **librarian** retrieves precise facts from shelves.
-both approaches are useful, but they represent fundamentally different forms of knowledge.

package/dist/logic/roles/bhrain/.briefs/worders/knowledge.internal_vs_external.[demo].domain.physics.md

@@ -1,39 +0,0 @@
-# 🧩 .brief.demo: `contrasting knowledge via physics`
-
----
-
-## ⚛️ illustration: physicist vs formula table
-- **internalized (physicist’s intuition)**
-  - an experienced physicist can look at a problem — say, a ball rolling down an incline — and **intuitively anticipate** its acceleration or trajectory.
-  - they don’t consciously recall each derivation; years of practice have **internalized the principles** of mechanics.
-  - this allows them to solve novel problems, even ones never covered in class, by applying generalized patterns of motion, force, and energy.
-
-- **externalized (formula reference table)**
-  - another student consults a table of equations: \(F=ma\), kinematic formulas, conservation laws.
-  - the reference ensures **exact correctness** when applied carefully, but it covers only the documented cases.
-  - without creativity, it cannot extend to unusual or unlisted scenarios.
-
----
-
-## 🧠 llm parallel
-- **internalized knowledge in weights**
-  - like the physicist, llms have absorbed statistical regularities across their training data.
-  - they can extend learned structures to **new prompts**, reasoning flexibly about unseen questions.
-  - limitation: they may make systematic errors when the internalized “intuition” misfires.
-
-- **externalized knowledge in retrieval**
-  - like the formula table, retrieval provides **precise, explicit answers** or derivations.
-  - it guarantees correctness for known facts but cannot innovate beyond stored entries.
-
----
-
-## 🔑 contrast takeaways
-- **internalized = physicist’s intuition** → adaptive, generalizing, creative but fallible.
-- **externalized = formula table** → precise, bounded, authoritative but rigid.
-- llms alone resemble physicists reasoning from intuition; with retrieval, they combine intuition with the reliability of exact formulas.
-
----
-
-## 📌 intuition anchor
-an llm without retrieval is like a **physicist solving problems from intuition** — quick, adaptive, but prone to slips.
-with retrieval, it becomes a physicist **plus a formula table** — intuition reinforced by exact references.

package/dist/logic/roles/bhrain/.briefs/worders/knowledge.internalized.[article].md

@@ -1,35 +0,0 @@
-# 🧩 .brief: `internalized knowledge in llm weights`
-
----
-
-## 🧠 how knowledge lives in llm weights
-
-- **statistical associations**
-  during training, the model adjusts billions of parameters (weights) so that certain patterns of tokens predict others. what emerges are high-dimensional representations that capture regularities across text: facts, grammar, reasoning patterns, world structures.
-
-- **distributed representation**
-  no single weight corresponds to a single fact (like “paris is the capital of france”). instead, many weights collectively encode the probability structure of phrases and contexts. knowledge is *smeared* across the parameter space.
-
-- **emergent concepts**
-  neurons and attention heads sometimes specialize in representing particular structures (e.g. gendered pronouns, syntax boundaries, factual relationships). but these are still part of a network of overlapping functions, not isolated “fact cells.”
-
----
-
-## 📊 what this implies
-
-- **implicit knowledge**
-  the model *has* facts (e.g., it can usually complete “the capital of france is ___”), but it doesn’t “store” them in a database-like table. retrieval is probabilistic and context-dependent.
-
-- **fuzziness & errors**
-  because knowledge is embedded as distributed patterns, recall isn’t guaranteed. the model may confuse similar facts or “hallucinate” when patterns overlap.
-
-- **generalization**
-  knowledge in weights isn’t just memorized; it’s also compressed into *general rules*. that’s why llms can apply concepts to novel contexts they weren’t explicitly trained on.
-
----
-
-## ⚖️ analogy
-
-think of llm weights like the structure of a muscle trained through repetition:
-- they don’t “remember” every exact movement, but they *embody* the regularities of movement.
-- similarly, llm weights embody statistical regularities of language and facts.

package/dist/logic/roles/bhrain/.briefs/worders/knowledge.internalized.[demo].artist.md

@@ -1,36 +0,0 @@
-# 🧩 .brief.demo: `style transfer for internalized knowledge`
-
----
-
-## 🎨 essence of the frame
-style transfer highlights how exposure to repeated patterns (in art, language, or reasoning) becomes **internalized capacity** rather than **explicit recall**.
-- the artist does not carry a mental library of every impressionist canvas.
-- instead, they have **absorbed the structure of impressionism**: how to layer colors, how to break light into strokes, how to balance softness with vibrancy.
-- this “knowledge” manifests not as stored facts but as *fluid capability* to reproduce and adapt style in new contexts.
-
----
-
-## 🧠 mapping to llms
-- **training as exposure**
-  llms are exposed to vast corpora just as the artist is immersed in impressionist works. through gradient descent, the weights adapt to reflect these patterns.
-
-- **weights as embodiment**
-  the learned style of language — grammar, facts, idioms, reasoning steps — becomes embedded in the weight matrix. no individual weight is “the fact,” but the whole structure embodies it.
-
-- **generation as expression**
-  when prompted, the llm doesn’t “remember” training text. it **expresses** the internalized style of text it has absorbed, much like an artist expressing impressionism in a novel painting.
-
----
-
-## 🔑 insights revealed
-- **knowledge ≈ style**: both are *latent patterns* embodied in a system’s structure.
-- **generalization over memorization**: an llm, like the artist, can apply its internalized patterns to situations it has never encountered before.
-- **creative reconstruction**: outputs are not reproductions of training data but reconstructions consistent with internalized distributions.
-- **hallucinations as byproduct**: just as an artist might invent an impressionist scene that never existed, llms may produce plausible but fabricated content.
-
----
-
-## 📌 practical intuition
-- **teaching style**: explaining llm knowledge as *“style internalized in weights”* makes it clear that the model isn’t storing a database, but embodying a way of *expressing patterns*.
-- **limits of fidelity**: just as an artist cannot perfectly replicate a particular monet without copying, llms cannot guarantee perfect recall of a training fact.
-- **adaptability**: both can transfer their internalized style onto new subjects (artist painting a modern skyline; llm generating in a new domain).

package/dist/logic/roles/bhrain/.briefs/worders/knowledge.internalized.[demo].neural.md

@@ -1,37 +0,0 @@
-# 🧩 .brief.demo: `internalized knowledge in llm weights — neural memory frame`
-
----
-
-## 🧠 demonstration
-
-imagine recalling the fact: **“paris is the capital of france.”**
-in a human brain, there is no single neuron labeled “capital of france.” instead:
-
-- thousands of neurons encode fragments — sounds, associations, map images, cultural cues.
-- when prompted, these neurons fire in **coordinated patterns** that reconstruct the memory.
-- the *pattern of activation* is the knowledge, not any one unit.
-
----
-
-## 🔗 llm parallel
-
-- llm weights work the same way:
-  - no parameter contains “paris = france’s capital.”
-  - instead, billions of weights together create a high-dimensional pattern that *activates* when the model sees a related cue.
-  - output emerges from **distributed representations** aligning to the prompt.
-
----
-
-## 📊 implications
-
-- **not a database** — knowledge isn’t stored as discrete rows or entries.
-- **probabilistic recall** — outputs can vary depending on context, like humans remembering fuzzily.
-- **generalization** — internalized patterns allow extrapolation beyond explicit memorization.
-
----
-
-## ⚖️ takeaway
-
-just as human memory is **patterned activation** rather than a single storage cell,
-llm knowledge is **internalized in distributed weight patterns**,
-reconstructed dynamically when queried.

package/dist/logic/roles/bhrain/.briefs/worders/knowledge.internalized.[demo].pianist.md

@@ -1,34 +0,0 @@
-# 🧩 .brief.demo: `internalized knowledge in llm weights — muscle memory frame`
-
----
-
-## 🏋️‍♂️ demonstration
-
-imagine a pianist sitting at the keyboard:
-- their fingers glide through a complex sonata without consciously recalling each individual note.
-- the *knowledge of the music* isn’t stored as a verbal list of notes in their mind — it is internalized in the coordination of muscles and neural circuits.
-- when prompted with the opening bars, the full sequence flows out through trained patterns.
-
----
-
-## 🔑 intuition
-
-- **distributed**: no single muscle or neuron “contains” the sonata — it is spread across the system.
-- **implicit**: the pianist cannot always verbalize *how* they play; the knowledge is enacted, not explicitly recalled.
-- **emergent**: repeated practice shapes a network of pathways that allow fluent performance.
-
----
-
-## 📊 mapping to llms
-
-- llm weights = the pianist’s trained muscles and neural pathways
-- prompts = the opening bars that trigger the sequence
-- completions = the flowing music generated from internalized patterns
-- internalized knowledge = the capacity to recall and generalize without explicit storage of “facts”
-
----
-
-## ⚖️ takeaway
-
-just as a pianist embodies a song in trained muscle memory, llms embody world knowledge in their parameters.
-- both systems *don’t remember every detail explicitly* — instead, they perform by drawing on **internalized, distributed patterns** of practice.

package/dist/logic/roles/bhrain/.briefs/worders/limits.rhyme.md

@@ -1,46 +0,0 @@
-# 🧩 .brief: `llm ability to understand rhyme`
-
-## 🔑 what it implies
-
-since each token starts as a static embedding but then diverges into contextual hidden states, rhyme is not encoded in the hidden state by default — it has to be learned through patterns across embeddings and contexts.
-
-rhyme is about **phonological similarity** (shared suffix sounds). llms don’t hear sounds; they see tokens. so:
-
-- if the tokenizer splits words like “cat” and “hat” into full tokens, then their embeddings might end up closer in vector space because they co-occur in similar phonetic/poetic training data.
-- if the tokenizer breaks words into subwords, e.g. “##at”, rhyme similarity is captured more directly (both “cat” and “hat” share the suffix embedding).
-- during self-attention, heads could learn to connect tokens with similar endings, especially in rhyme-heavy text (poetry, song lyrics). this would look a lot like the “bank” demo: two different tokens forming stronger similarity in some heads because of shared suffix representations.
-
----
-
-## 🎯 implications for rhyme recognition
-
-- **subword overlap**
-  - if the tokenizer preserves suffix chunks (`-at`, `-ight`), rhyme is easier.
-  - embeddings for those suffixes can become strong cues.
-
-- **attention heads**
-  - some heads may specialize in form-based similarity (orthographic/phonetic).
-  - others focus on semantics or syntax.
-  - multi-head attention enables parallel “views”: one could be capturing rhymes while another tracks meaning.
-
-- **disambiguation vs rhyme**
-  - in the “bank” case, heads attend differently to disambiguate meaning.
-  - in rhyme, heads might attend similarly across different words, reinforcing their phonetic link regardless of semantics.
-
----
-
-## 🧩 example
-
-> “the **cat** wore a funny **hat**.”
-
-- **embeddings:** “cat” ≠ “hat,” but both contain suffix “-at.”
-- **hidden states:** self-attention might increase similarity because the q of “cat” matches the k of “hat” in a rhyme-sensitive head.
-- **value vectors:** both updated to reflect “these words rhyme.”
-
----
-
-## 📊 insight
-
-- llms don’t have an innate sense of sound, but **subword embeddings + attention** let them approximate rhyme by picking up on visual/orthographic patterns.
-- rhyme perception is therefore **statistical, not phonological** — it depends on the tokenizer and training data distribution.
-- but the mechanism is parallel to disambiguating “bank”: attention binds tokens through **learned similarity in q/k space.**

package/dist/logic/roles/bhrain/.briefs/worders/limits.spell.md

@@ -1,49 +0,0 @@
-# 🧩 .brief: `llm ability to spell`
-
-## 🔑 what it implies
-
-since each token starts as a **static embedding** and spelling is distributed across subwords, an llm’s ability to spell is **not innate** but emerges from:
-
-- the **tokenizer**: if words are whole tokens, the model never “sees” individual letters, so it can only memorize spelling patterns for known words.
-- if the tokenizer breaks words into **character-like subwords**, the model can generalize spelling more flexibly (assemble words from parts).
-- **contextual hidden states**: spelling consistency isn’t reinforced the same way semantics or rhyme are. most training data emphasizes meaning, not orthographic correctness.
-- **self-attention**: heads may capture common letter/suffix chunks, but nothing forces them to maintain letter-by-letter accuracy unless trained specifically (e.g., code models, spelling correction).
-
----
-
-## 🎯 implications for spelling ability
-
-- **memorization over generation**
-  - llms can reproduce spellings they’ve seen often.
-  - rare or novel words are harder because embeddings don’t break down fully into letters.
-
-- **tokenizer bias**
-  - byte-pair encodings (bpe) bias toward common subwords, not individual letters.
-  - spelling errors occur when tokenization splits a word into unusual or unseen chunks.
-
-- **generalization**
-  - some subword overlap allows limited spelling generalization (e.g., “##tion,” “##ing”).
-  - but full orthographic rules are weak unless trained at character level.
-
-- **multi-head dynamics**
-  - some heads may track morpheme or suffix consistency.
-  - others prioritize syntax or semantics, so spelling accuracy is not their focus.
-
----
-
-## 🧩 example
-
-> generating “pharaoh”
-
-- **embedding level:** tokenization may split as `[“ph”, “ara”, “oh”]` or something arbitrary.
-- **hidden state evolution:** model predicts plausible continuation from context but may choose an alternate form (“pharoah”) if that variant appears in data.
-- **output:** correct spelling depends on frequency balance in training data, not explicit rules.
-
----
-
-## 📊 insight
-
-- llms **do not inherently know spelling rules** — they approximate them statistically from text distributions.
-- good spelling emerges in proportion to **training data quality and tokenizer granularity**.
-- unlike rhyme (which can be reinforced by subword overlaps), spelling requires **fine-grained character awareness**, which many tokenizers blur.
-- in short: **llms spell by memory and pattern frequency, not by rule.**

package/dist/logic/roles/bhrain/.briefs/worders/teach.via.library.examples.md

@@ -1,28 +0,0 @@
-# 📊 effectiveness of teaching llms via example libraries
-
-## ✅ strengths
-- **highly effective for style & format control**
-  - the model will reliably mimic demonstrated structures (e.g. JSON schema, markdown brief, SQL pattern).
-- **task-specific alignment**
-  - if the examples cover the distribution of tasks, the model adapts very well in-session.
-- **fast & flexible**
-  - no retraining, just update the example set.
-
----
-
-## ⚠️ limits
-- **shallow generalization**
-  - effectiveness drops if the input strays outside what the examples illustrate.
-- **rigid mimicry**
-  - the model tends to overfit: it copies examples rather than abstracting.
-- **context overhead**
-  - effectiveness shrinks as the example library grows beyond the model’s active attention window.
-- **no persistence**
-  - nothing is learned across sessions — you must re-teach every time.
-
----
-
-## 🎯 bottom line
-- **short tasks, narrow domains:** very effective.
-- **broad reasoning, novel domains:** much less effective.
-- think of it as *teaching the llm to “act trained”* for one prompt — not actual durable learning.

package/dist/logic/roles/bhrain/.briefs/worders/teach.via.library.explanations_vs_examples.md

@@ -1,40 +0,0 @@
-# 🎛️ in-context tuning: explanations vs examples
-
-## 🧩 examples
-- **what they do:** show *how* to perform the task by demonstration.
-- **strengths:**
-  - precise control over output **format** and **style**
-  - model can “copy the pattern” with little ambiguity
-  - fast to apply, low cognitive overhead for the model
-- **weaknesses:**
-  - brittle if task deviates from the pattern
-  - encourages mimicry rather than reasoning
-
----
-
-## 🧩 explanations
-- **what they do:** tell *why* and *how* the task should be done via rules, instructions, or reasoning steps.
-- **strengths:**
-  - supports **generalization** beyond shown cases
-  - encourages **reasoning chains** instead of rote mimicry
-  - more compact than many examples (token-wise)
-- **weaknesses:**
-  - less consistent for rigid formats (the model may improvise)
-  - requires the model to “translate” abstract rules into concrete actions, which can be noisy
-
----
-
-## ⚖️ effectiveness comparison
-- **examples win** when:
-  - the task is about *output form* (e.g. json schemas, sql syntax, markdown briefs)
-  - consistency is more important than novelty
-- **explanations win** when:
-  - the task is about *reasoning* or handling unseen variations
-  - flexibility and abstraction matter more than surface mimicry
-
----
-
-## 🎯 hybrid strategy
-- the strongest “in-context tunage” usually comes from **explanations + 1–2 examples**.
-  - explanation gives the **reasoning scaffold**
-  - examples ground it with **concrete reference points**

package/dist/logic/roles/bhrain/.briefs/worders/trend.prefer_reuse.[seed].md

@@ -1,10 +0,0 @@
-llms prefer reuse input tokens
-
-why?
-- why do they do that (rationale)
-- why do we care? (causal)
-  - how we can use it
-
----
-
-i.e., most of the time, safe to expect it'll only change the bare minimum

package/dist/logic/roles/bhrain/brief.articulate/stepArticulate.integration.test.d.ts

@@ -1 +0,0 @@
-export {};

package/dist/logic/roles/bhrain/brief.articulate/stepArticulate.integration.test.js

@@ -1,92 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-const uni_time_1 = require("@ehmpathy/uni-time");
-const rhachet_1 = require("rhachet");
-const rhachet_artifact_git_1 = require("rhachet-artifact-git");
-const test_fns_1 = require("test-fns");
-const genContextLogTrail_1 = require("../../../../.test/genContextLogTrail");
-const genContextStitchTrail_1 = require("../../../../.test/genContextStitchTrail");
-const getContextOpenAI_1 = require("../../../../.test/getContextOpenAI");
-const getBhrainBrief_1 = require("../getBhrainBrief");
-const stepArticulate_1 = require("./stepArticulate");
-jest.setTimeout((0, uni_time_1.toMilliseconds)({ minutes: 5 }));
-describe('stepArticulate', () => {
-    const context = {
-        ...(0, genContextLogTrail_1.genContextLogTrail)(),
-        ...(0, genContextStitchTrail_1.genContextStitchTrail)(),
-        ...(0, getContextOpenAI_1.getContextOpenAI)(),
-    };
-    const route = stepArticulate_1.stepArticulate;
-    const goal = `
-articulate the term "joke"; declare both the etymology and definition; include examples
-  `.trim();
-    const artifacts = {
-        caller: {
-            feedback: (0, rhachet_artifact_git_1.genArtifactGitFile)({ uri: __dirname + '/.temp/stepArticulate/caller.feedback.md' }, { versions: true }),
-            'foci.goal.concept': (0, rhachet_artifact_git_1.genArtifactGitFile)({
-                uri: __dirname + '/.temp/stepArticulate/caller.foci.goal.concept.md',
-            }, { versions: true }),
-            'foci.goal.context': (0, rhachet_artifact_git_1.genArtifactGitFile)({
-                uri: __dirname + '/.temp/stepArticulate/caller.foci.goal.context.md',
-            }, { versions: true }),
-        },
-        thinker: {
-            'focus.concept': (0, rhachet_artifact_git_1.genArtifactGitFile)({ uri: __dirname + '/.temp/stepArticulate/thinker.focus.concept.md' }, { versions: true }),
-            'focus.context': (0, rhachet_artifact_git_1.genArtifactGitFile)({ uri: __dirname + '/.temp/stepArticulate/thinker.focus.context.md' }, { versions: true }),
-        },
-    };
-    (0, test_fns_1.given)('we want to articulate term joke', () => {
-        beforeEach(async () => {
-            await artifacts.caller.feedback.set({ content: '' });
-            await artifacts.caller['foci.goal.concept'].set({ content: goal });
-            await artifacts.thinker['focus.context'].set({
-                content: ['psychology', 'evolution', 'ecology'].join('\n'),
-            });
-            await artifacts.thinker['focus.concept'].set({
-                content: [].join('\n'),
-            });
-        });
-        (0, test_fns_1.when)('executed', () => {
-            const threads = (0, test_fns_1.usePrep)(async () => ({
-                caller: await (0, rhachet_1.enrollThread)({
-                    role: 'caller',
-                    stash: {
-                        ask: goal,
-                        art: {
-                            'foci.goal.concept': artifacts.caller['foci.goal.concept'],
-                            'foci.goal.context': artifacts.caller['foci.goal.context'],
-                            feedback: artifacts.caller.feedback,
-                            templates: [],
-                        },
-                        refs: [],
-                    },
-                }),
-                thinker: await (0, rhachet_1.enrollThread)({
-                    role: 'thinker',
-                    stash: {
-                        art: {
-                            'focus.context': artifacts.thinker['focus.context'],
-                            'focus.concept': artifacts.thinker['focus.concept'],
-                        },
-                        briefs: [],
-                    },
-                    inherit: {
-                        traits: (0, getBhrainBrief_1.getBhrainBriefs)(['trait.ocd.md']),
-                    },
-                }),
-            }));
-            (0, test_fns_1.then)('upserts the thinker output', async () => {
-                const result = await (0, rhachet_1.enweaveOneStitcher)({ stitcher: route, threads }, context);
-                console.log(JSON.stringify(result.stitch, null, 2));
-                console.log(artifacts);
-                console.log(artifacts.thinker['focus.concept']);
-                const { content } = await artifacts.thinker['focus.concept']
-                    .get()
-                    .expect('isPresent');
-                expect(content.toLowerCase()).toContain('.brief.article');
-                expect(content.toLowerCase()).toContain('joke');
-            });
-        });
-    });
-});
-//# sourceMappingURL=stepArticulate.integration.test.js.map

package/dist/logic/roles/bhrain/brief.articulate/stepArticulate.integration.test.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"stepArticulate.integration.test.js","sourceRoot":"","sources":["../../../../../src/logic/roles/bhrain/brief.articulate/stepArticulate.integration.test.ts"],"names":[],"mappings":";;AAAA,iDAAoD;AACpD,qCAA2D;AAC3D,+DAA0D;AAC1D,uCAAsD;AAEtD,6EAA0E;AAC1E,mFAAgF;AAChF,yEAAsE;AACtE,sDAAoD;AACpD,qDAAkD;AAElD,IAAI,CAAC,UAAU,CAAC,IAAA,yBAAc,EAAC,EAAE,OAAO,EAAE,CAAC,EAAE,CAAC,CAAC,CAAC;AAEhD,QAAQ,CAAC,gBAAgB,EAAE,GAAG,EAAE;IAC9B,MAAM,OAAO,GAAG;QACd,GAAG,IAAA,uCAAkB,GAAE;QACvB,GAAG,IAAA,6CAAqB,GAAE;QAC1B,GAAG,IAAA,mCAAgB,GAAE;KACtB,CAAC;IACF,MAAM,KAAK,GAAG,+BAAc,CAAC;IAE7B,MAAM,IAAI,GAAG;;GAEZ,CAAC,IAAI,EAAE,CAAC;IAET,MAAM,SAAS,GAAG;QAChB,MAAM,EAAE;YACN,QAAQ,EAAE,IAAA,yCAAkB,EAC1B,EAAE,GAAG,EAAE,SAAS,GAAG,0CAA0C,EAAE,EAC/D,EAAE,QAAQ,EAAE,IAAI,EAAE,CACnB;YACD,mBAAmB,EAAE,IAAA,yCAAkB,EACrC;gBACE,GAAG,EAAE,SAAS,GAAG,mDAAmD;aACrE,EACD,EAAE,QAAQ,EAAE,IAAI,EAAE,CACnB;YACD,mBAAmB,EAAE,IAAA,yCAAkB,EACrC;gBACE,GAAG,EAAE,SAAS,GAAG,mDAAmD;aACrE,EACD,EAAE,QAAQ,EAAE,IAAI,EAAE,CACnB;SACF;QACD,OAAO,EAAE;YACP,eAAe,EAAE,IAAA,yCAAkB,EACjC,EAAE,GAAG,EAAE,SAAS,GAAG,gDAAgD,EAAE,EACrE,EAAE,QAAQ,EAAE,IAAI,EAAE,CACnB;YACD,eAAe,EAAE,IAAA,yCAAkB,EACjC,EAAE,GAAG,EAAE,SAAS,GAAG,gDAAgD,EAAE,EACrE,EAAE,QAAQ,EAAE,IAAI,EAAE,CACnB;SACF;KACF,CAAC;IAEF,IAAA,gBAAK,EAAC,iCAAiC,EAAE,GAAG,EAAE;QAC5C,UAAU,CAAC,KAAK,IAAI,EAAE;YACpB,MAAM,SAAS,CAAC,MAAM,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,OAAO,EAAE,EAAE,EAAE,CAAC,CAAC;YACrD,MAAM,SAAS,CAAC,MAAM,CAAC,mBAAmB,CAAC,CAAC,GAAG,CAAC,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC,CAAC;YAEnE,MAAM,SAAS,CAAC,OAAO,CAAC,eAAe,CAAC,CAAC,GAAG,CAAC;gBAC3C,OAAO,EAAE,CAAC,YAAY,EAAE,WAAW,EAAE,SAAS,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;aAC3D,CAAC,CAAC;YAEH,MAAM,SAAS,CAAC,OAAO,CAAC,eAAe,CAAC,CAAC,GAAG,CAAC;gBAC3C,OAAO,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,CAAC;aACvB,CAAC,CAAC;QACL,CAAC,CAAC,CAAC;QAEH,IAAA,eAAI,EAAC,UAAU,EAAE,GAAG,EAAE;YACpB,MAAM,OAAO,GAAG,IAAA,kBAAO,EAAC,KAAK,IAAI,EAAE,CAAC,CAAC;gBACnC,MAAM,EAAE,MAAM,IAAA,sBAAY,EAAC;oBACzB,IAAI,EAAE,QAAQ;oBACd,KAAK,EAAE;wBACL,GAAG,EAAE,IAAI;wBACT,GAAG,EAAE;4BACH,mBAAmB,EAAE,SAAS,CAAC,MAAM,CAAC,mBAAmB,CAAC;4BAC1D,mBAAmB,EAAE,SAAS,CAAC,MAAM,CAAC,mBAAmB,CAAC;4BAC1D,QAAQ,EAAE,SAAS,CAAC,MAAM,CAAC,QAAQ;4BACnC,SAAS,EAAE,EAAE;yBACd;wBACD,IAAI,EAAE,EAAE;qBACT;iBACF,CAAC;gBACF,OAAO,EAAE,MAAM,IAAA,sBAAY,EAAC;oBAC1B,IAAI,EAAE,SAAS;oBACf,KAAK,EAAE;wBACL,GAAG,EAAE;4BACH,eAAe,EAAE,SAAS,CAAC,OAAO,CAAC,eAAe,CAAC;4BACnD,eAAe,EAAE,SAAS,CAAC,OAAO,CAAC,eAAe,CAAC;yBACpD;wBACD,MAAM,EAAE,EAAE;qBACX;oBACD,OAAO,EAAE;wBACP,MAAM,EAAE,IAAA,gCAAe,EAAC,CAAC,cAAc,CAAC,CAAC;qBAC1C;iBACF,CAAC;aACH,CAAC,CAAC,CAAC;YAEJ,IAAA,eAAI,EAAC,4BAA4B,EAAE,KAAK,IAAI,EAAE;gBAC5C,MAAM,MAAM,GAAG,MAAM,IAAA,4BAAkB,EACrC,EAAE,QAAQ,EAAE,KAAK,EAAE,OAAO,EAAE,EAC5B,OAAO,CACR,CAAC;gBACF,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,MAAM,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;gBACpD,OAAO,CAAC,GAAG,CAAC,SAAS,CAAC,CAAC;gBACvB,OAAO,CAAC,GAAG,CAAC,SAAS,CAAC,OAAO,CAAC,eAAe,CAAC,CAAC,CAAC;gBAEhD,MAAM,EAAE,OAAO,EAAE,GAAG,MAAM,SAAS,CAAC,OAAO,CAAC,eAAe,CAAC;qBACzD,GAAG,EAAE;qBACL,MAAM,CAAC,WAAW,CAAC,CAAC;gBAEvB,MAAM,CAAC,OAAO,CAAC,WAAW,EAAE,CAAC,CAAC,SAAS,CAAC,gBAAgB,CAAC,CAAC;gBAC1D,MAAM,CAAC,OAAO,CAAC,WAAW,EAAE,CAAC,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC;YAClD,CAAC,CAAC,CAAC;QACL,CAAC,CAAC,CAAC;IACL,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC"}

package/dist/logic/roles/bhrain/brief.articulate/stepArticulate.template.md

@@ -1,120 +0,0 @@
-# 🗣️ prompt: `<articulate>` — generate a .brief article for a given [concept]
-
-you are a **skilled explainer** performing the **focus.motion** primitive `<articulate>`.
-
----
-
-## 📜 contract
-for `<articulate>` to work as intended:
-
-input = [concept][brief] = `focus.concept`
-  - may be **empty** (start from scratch)
-  - may be a **seed** (partial brief to expand)
-  - may be **inflight** (actively being refined)
-  - must define a **single, coherent concept** — not a bundle of unrelated topics
-
-output = [concept][brief]
-  - a high-signal markdown `.brief` that captures the concept in clear, accessible form
-  - must be **complete** enough to serve as a stable reference for others or your future self
-  - all sections should maximize **signal-to-noise** and avoid filler
-
-**why this contract exists:**
-- articulation turns **implicit understanding** into **explicit, structured form**
-- consistent `.brief` structure ensures clarity, comparability, and reuse
-- constraints prevent drift away from the core concept
-
----
-
-## ⚙️ method
-1. **anchor to the seed**
-   - 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
-   - when producing the brief:
-     - leverage **the provided templates** when relevant
-     - and/or **imagine the most useful aspects to articulate** for the concept, based on its nature and context
-
-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
-
----
-
-## 📐 output format
-- return **only** the `.md` brief — no extra commentary
-- always start with:
-  `# 🧩 .brief.article: \`[concept]\``
-- all section headers use `##` or `---` separators
-- prose must be lowercase except proper nouns
-- use concise lists and short paragraphs; avoid long blocks of text
-
-
----
-
-## 📚 briefs
-
-here are the .briefs you've studied for this skill and actively strive to leverage
-
-$.rhachet{skill.briefs}
-
----
-
-## 📥 inputs
-
-the following inputs define the semantic frame for `<articulate>`:
-
----
-
-## 📎 references
-
-here are possibly relevant references you may need
-
-$.rhachet{references}
-
----
-
-## 📒 templates
-
-here are the templates you should leverage
-
-$.rhachet{templates}
-
----
-
-### 🧘 @[focus.context]
-> the context in focus available for leverage
-
-\`\`\`md
-$.rhachet{focus.context}
-\`\`\`
-
----
-
-### 🫐 @[focus.concept]
-> the **inflight document of output** — the seed brief being refined by `<articulate>`
-> if this is empty, treat it as **no seed** and start from scratch
-
-\`\`\`md
-$.rhachet{focus.concept}
-\`\`\`
-
----
-
-### 🎯 @[guide.goal]
-\`\`\`md
-$.rhachet{guide.goal}
-\`\`\`
-
----
-
-### 💬 @[guide.feedback]
-\`\`\`md
-$.rhachet{guide.feedback}
-\`\`\`

package/dist/logic/roles/bhrain/brief.catalogize/stepCatalogize.integration.test.d.ts

@@ -1 +0,0 @@
-export {};