rhachet-roles-ehmpathy 1.15.11 → 1.15.13

package/dist/roles/coach/.briefs/claude.context-caching.md

@@ -1,76 +0,0 @@
-# 🧠 .brief: Claude Context Caching
-
-## .what
-Claude's context caching mechanism that reduces token costs by caching prompt prefixes
-
-## .how.it.works
-
-### cache key = exact prefix match
-- Claude caches content based on the **exact sequence of tokens from the start** of the conversation
-- a cache hit requires the **exact same prefix** to be present
-- cache is valid for ~5 minutes of inactivity
-
-### prefix-based matching
-```
-Turn 1: [system prompt] + [briefs: 30k tokens] → writes to cache
-Turn 2: [system prompt] + [briefs: 30k tokens] + [user msg] + [response] → cache hit ✅
-Turn 3: [system prompt] + [briefs: 30k tokens] + [history] + [new msg] → cache hit ✅
-```
-
-### when cache hits occur
-
-✅ **cache hit (free reads)** when:
-- the content appears at the **exact same position** in the context
-- everything before it is **identical** to the cached version
-- less than ~5 minutes of inactivity
-
-❌ **cache miss (full tokens charged)** when:
-- anything changed in the context **before** the cached content (even a single token)
-- the content moved to a different position in the conversation
-- more than ~5 minutes passed with no activity
-- new conversation started (different session)
-
-## .implications.for.briefs
-
-### sessionstart hooks
-when loading briefs via sessionstart hooks:
-
-1. **first boot**: full tokens cached (e.g., 30k tokens written to cache)
-2. **within same session**: cached if prefix matches (free reads)
-3. **new session**: full tokens charged again (new conversation = different prefix)
-
-### optimization strategies
-to maximize cache hits:
-
-1. **load briefs once per session** (sessionstart hook pattern)
-2. **keep them at consistent position** (ideally at the start)
-3. **avoid regenerating them** if content hasn't changed
-4. **batch related work** in same session to reuse cache
-
-## .key.insight
-
-the cache **does not move tokens around** or do LRU eviction - it's purely prefix-based matching
-
-this means:
-- you can't "refresh" cached content by using it again
-- cached content must appear in the exact same position to hit
-- any prefix changes invalidate the entire cache for that position
-
-## .cost.model
-
-### cache writes
-- **first use**: 25% of normal input token cost
-- **cache write**: happens on first occurrence of new content
-
-### cache reads
-- **cache hit**: 10% of normal input token cost
-- **cache miss**: 100% of normal input token cost (no cache benefit)
-
-### example: 30k token briefs
-- **first load**: ~7.5k tokens charged (25% write cost)
-- **subsequent hits**: ~3k tokens charged (10% read cost)
-- **cache miss**: 30k tokens charged (100% cost)
-
-## .sources
-- based on Anthropic's context caching documentation
-- observed behavior in production usage

package/dist/roles/designer/.briefs/declarative-over-imperative.md

@@ -1,79 +0,0 @@
-## 🎨 `.brief.designer.declarative-vs-imperative`
-
-### 🧠 topic: declarative vs. imperative design
-**why we prefer declarative design for building systems and interfaces**
-
----
-
-### 🎯 goal
-empower the designer to create systems that are **easier to understand, maintain, and scale**, by focusing on **what should happen**, not **how to do it**.
-
----
-
-### 🗺 core distinction
-
-| style           | imperative                               | declarative                                      |
-|-----------------|-------------------------------------------|--------------------------------------------------|
-| mindset         | tell the system *how* to do it            | tell the system *what* you want                 |
-| metaphor        | step-by-step instructions                 | a blueprint or desired outcome                  |
-| example (UI)    | manually update DOM on events             | declare a component tree (e.g. React)           |
-| example (infra) | run shell scripts to create servers       | declare infrastructure state (e.g. Terraform)   |
-
----
-
-### ✅ why declarative is better
-
-- **easier to read** — you see the structure and intent at a glance
-- **easier to write** — fewer details to manage = fewer bugs
-- **easier to maintain** — updates ripple automatically via system logic
-- **easier to scale** — declarative patterns are composable and predictable
-- **easier to debug** — the system owns the "how", so you debug at a higher level
-
----
-
-### 🛠 what it enables
-
-- **reusability** — components can be reused without re-specifying every step
-- **tooling & automation** — systems can analyze, optimize, or transform declarative specs
-- **flexibility** — changes in the underlying mechanics don’t require changing the design spec
-
----
-
-### ⚙️ trade-off to accept
-
-> declarative systems often need an **interpreter** — something that translates the high-level design into low-level instructions.
-
-this adds a little more **upfront work** —
-but it’s worth it, because:
-
-- it creates a **framework that abstracts away technical.domain details**
-- it keeps designers and builders focused on **behavioral.domain details**, where real value lives
-
----
-
-### 🧠 core belief
-
-> technical.domain work only adds value to developers, not to real people.
-
-- developer use is temporary → system builders
-- real folk use is forever → system engagers
-
-so we design declaratively —
-to serve people, not pipelines.
-
----
-
-### 💬 analogy
-
-> imperative = writing down GPS directions step by step
-> declarative = dropping a pin and letting the GPS figure it out
-
----
-
-### 🧩 final synthesis
-
-> declarative design keeps your focus on **what the user should experience**,
-> not on **how the system should behave step-by-step**.
-
-this keeps your mental model aligned with the human experience —
-not the machine’s internals.

package/dist/roles/designer/.briefs/declarative-over-imperative.stub.md

@@ -1,14 +0,0 @@
-todo: declare a brief that explains why we prefer to design systems w/ declarative instead of imperative
-
-e.g.,
-- easier to use
-- easier to read
-- easier to write
-- easier to maintain
-
-
-adds a little more upfront work in how to translate the declarations into imperative instructions, but its worth it, as that framework helps you abstract away the technical.domain details and keeps you in the behavioral.domain details instead, as desired
-
-remember: technical.domain work only adds value to developers, not to real people. we want to distribute value to real people
-- developer use is temporary -> system builders
-- real folk use is forever -> system engagers

package/dist/roles/designer/.briefs/pit-of-success.md

@@ -1,70 +0,0 @@
-## 🧠 `.brief.designer.pit-of-success`
-
-### 🧠 topic: the "pit of success"
-**why we design systems to naturally guide users toward the right outcome**
-
----
-
-### 🎯 goal
-build interfaces, flows, and defaults that make the **right path the easiest path** — where success isn’t just possible, it’s hard to miss.
-
----
-
-### 🕳 metaphor: pit of success
-
-> a system where users "fall into" the right outcome
-> — not by being perfect, but by following the path of least resistance.
-
-opposite of this is the **pit of despair**
-> where any slight move can throw you down into unexpected errors and wasted time.
-
----
-
-### ✅ why the "pit of success" matters
-
-- **reduces friction** — users don’t need deep understanding to get it right
-- **reduces support burden** — fewer errors, less need for rescue
-- **builds confidence** — users feel smart, not stupid
-- **supports scalability** — new users succeed without handholding
-- **encourages trust** — when success feels natural, users keep going
-
-> software should **make the right thing easy** and the wrong thing **hard or impossible**.
-
----
-
-### 🛠 tips to create it
-
-- **smart defaults** — sensible, safe choices pre-filled
-- **clear next steps** — obvious buttons, flows, and language
-- **constrained input** — prevent invalid states instead of reacting to them
-- **progressive disclosure** — complexity revealed only when needed
-- **stateful feedback** — show users what changed and why
-- **fail fast** — surface issues *immediately*, not after damage is done
-
----
-
-### 🧱 core design principle
-
-> success should be the **path of least resistance**
-> failure should require **active effort or deviation**
-
-we engineer **invisible safety rails**, not pop-up warning signs.
-
----
-
-### 🧠 behavioral insight
-
-users don’t read manuals — they feel their way forward.
-if success depends on correctness, users fail.
-if success depends on momentum, users win.
-
----
-
-### 🧩 final synthesis
-
-> software should **produce a pit of success** for the user:
-> the right path should feel obvious, safe, and rewarding —
-> and the wrong path should be hard to access or easy to recover from.
-
-design for **gravity** —
-so the system pulls people toward success, not traps them in failure.

package/dist/roles/designer/.briefs/pit-of-success.stub.md

@@ -1,3 +0,0 @@
-software should produce a pit-of-success for the user
-
-it should be hard to do the wrong thing

package/dist/roles/designer/getDesignerBrief.Options.codegen.d.ts

@@ -1,10 +0,0 @@
-/**
- * .what = the options for the briefs available to role Designer
- * .note = codegened via:
- * ```sh
- *  npx tsx src/contract/commands/codegenBriefOptions.ts
- * ```
- */
-declare const options: readonly ["declarative-over-imperative.md", "pit-of-success.md"];
-export type BriefOptionDesigner = (typeof options)[number];
-export {};

package/dist/roles/designer/getDesignerBrief.Options.codegen.js

@@ -1,14 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-/**
- * .what = the options for the briefs available to role Designer
- * .note = codegened via:
- * ```sh
- *  npx tsx src/contract/commands/codegenBriefOptions.ts
- * ```
- */
-const options = [
-    'declarative-over-imperative.md',
-    'pit-of-success.md',
-];
-//# sourceMappingURL=getDesignerBrief.Options.codegen.js.map

package/dist/roles/designer/getDesignerBrief.Options.codegen.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"getDesignerBrief.Options.codegen.js","sourceRoot":"","sources":["../../../src/roles/designer/getDesignerBrief.Options.codegen.ts"],"names":[],"mappings":";;AAAA;;;;;;GAMG;AACH,MAAM,OAAO,GAAG;IACd,gCAAgC;IAChC,mBAAmB;CACX,CAAC"}

package/dist/roles/designer/getDesignerBrief.d.ts

@@ -1,13 +0,0 @@
-import type { Artifact } from 'rhachet-artifact';
-import { type GitFile } from 'rhachet-artifact-git';
-import type { BriefOptionDesigner } from './getDesignerBrief.Options.codegen';
-/**
- * .what = loads an artifact:brief distilled for the mechanic to reference, from the `.briefs` directory
- * .why = enables reusable knowledge downloads for mechanic contexts (e.g., matrix-movie style)
- */
-export declare const getDesignerBrief: (key: BriefOptionDesigner) => Artifact<typeof GitFile>;
-/**
- * .what = loads multiple artifact:brief distilled for the mechanic to reference, from the `.briefs` directory
- * .why = enables reusable knowledge downloads for mechanic contexts (e.g., matrix-movie style)
- */
-export declare const getDesignerBriefs: (keys: BriefOptionDesigner[]) => Artifact<typeof GitFile>[];

package/dist/roles/designer/getDesignerBrief.js

@@ -1,21 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.getDesignerBriefs = exports.getDesignerBrief = void 0;
-const rhachet_artifact_git_1 = require("rhachet-artifact-git");
-/**
- * .what = loads an artifact:brief distilled for the mechanic to reference, from the `.briefs` directory
- * .why = enables reusable knowledge downloads for mechanic contexts (e.g., matrix-movie style)
- */
-const getDesignerBrief = (key) => {
-    return (0, rhachet_artifact_git_1.genArtifactGitFile)({
-        uri: `${__dirname}/.briefs/${key}`,
-    });
-};
-exports.getDesignerBrief = getDesignerBrief;
-/**
- * .what = loads multiple artifact:brief distilled for the mechanic to reference, from the `.briefs` directory
- * .why = enables reusable knowledge downloads for mechanic contexts (e.g., matrix-movie style)
- */
-const getDesignerBriefs = (keys) => keys.map(exports.getDesignerBrief);
-exports.getDesignerBriefs = getDesignerBriefs;
-//# sourceMappingURL=getDesignerBrief.js.map

package/dist/roles/designer/getDesignerBrief.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"getDesignerBrief.js","sourceRoot":"","sources":["../../../src/roles/designer/getDesignerBrief.ts"],"names":[],"mappings":";;;AACA,+DAAwE;AAIxE;;;GAGG;AACI,MAAM,gBAAgB,GAAG,CAC9B,GAAwB,EACE,EAAE;IAC5B,OAAO,IAAA,yCAAkB,EAAC;QACxB,GAAG,EAAE,GAAG,SAAS,YAAY,GAAG,EAAE;KACnC,CAAC,CAAC;AACL,CAAC,CAAC;AANW,QAAA,gBAAgB,oBAM3B;AAEF;;;GAGG;AACI,MAAM,iBAAiB,GAAG,CAC/B,IAA2B,EACC,EAAE,CAAC,IAAI,CAAC,GAAG,CAAC,wBAAgB,CAAC,CAAC;AAF/C,QAAA,iBAAiB,qBAE8B"}

package/dist/roles/designer/outlineDistilisys/loopOutlineDistilisys.d.ts

@@ -1,26 +0,0 @@
-import { type GStitcher, type RoleContext, type Threads } from 'rhachet';
-import type { Artifact } from 'rhachet-artifact';
-import type { GitFile } from 'rhachet-artifact-git';
-import type { ContextOpenAI } from '../../../access/sdk/sdkOpenAi';
-type StitcherDesired = GStitcher<Threads<{
-    designer: RoleContext<'designer', {
-        art: {
-            roadmap: Artifact<typeof GitFile>;
-            distilisys: Artifact<typeof GitFile>;
-        };
-    }>;
-    caller: RoleContext<'caller', {
-        ask: string;
-        art: {
-            feedback: Artifact<typeof GitFile>;
-        };
-    }>;
-}>, ContextOpenAI & GStitcher['context'], {
-    content: string;
-}>;
-/**
- * .what = loop until caller confirms no more notes
- * todo: generalize this loop wrapper onto any stitcher
- */
-export declare const loopOutlineDistilisys: import("rhachet").Stitcher<StitcherDesired>;
-export {};

package/dist/roles/designer/outlineDistilisys/loopOutlineDistilisys.js

@@ -1,53 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.loopOutlineDistilisys = void 0;
-const rhachet_1 = require("rhachet");
-const genStepGrabCallerFeedbackToArtifact_1 = require("../../../domain.operations/artifact/genStepGrabCallerFeedbackToArtifact");
-const stepOutlineDistilisys_1 = require("./stepOutlineDistilisys");
-/**
- * .what = await feedback
- */
-const stepGetFeedback = (0, genStepGrabCallerFeedbackToArtifact_1.genStepGrabCallerFeedbackToArtifact)({
-    stitchee: 'designer',
-    artee: 'distilisys',
-});
-/**
- * .what = iteration of imagine + feedback
- */
-const routeImagineThenFeedback = (0, rhachet_1.asStitcher)((0, rhachet_1.genStitchRoute)({
-    slug: '[designer]<outline>[distilisys]<iterate>-><feedback>',
-    readme: '@[designer]<outline>[distilisys] then @[caller]<feedback>',
-    sequence: [stepOutlineDistilisys_1.stepOutlineDistilisys, stepGetFeedback],
-}));
-/**
- * .what = looks at feedback artifact to decide whether to repeat or halt
- */
-const stepDecideHasNotes = new rhachet_1.StitchStepCompute({
-    form: 'COMPUTE',
-    slug: `[caller]<feedback><hasNotes?>`,
-    stitchee: 'caller',
-    readme: 'checks if the last feedback was null (no notes)',
-    invoke: async ({ threads }) => {
-        const feedback = await threads.caller.context.stash.art.feedback.get();
-        return {
-            input: { feedback },
-            output: { choice: feedback ? 'repeat' : 'release' },
-        };
-    },
-});
-/**
- * .what = loop until caller confirms no more notes
- * todo: generalize this loop wrapper onto any stitcher
- */
-exports.loopOutlineDistilisys = (0, rhachet_1.asStitcherFlat)((0, rhachet_1.genStitchCycle)({
-    slug: '[designer]<outline>[distilisys]<🌀loop>',
-    readme: '@[designer]<outline> -> @[caller]<feedback> -> { notes? repeat, none?: <release>[distilisys] }',
-    repeatee: routeImagineThenFeedback,
-    decider: stepDecideHasNotes,
-    halter: {
-        threshold: {
-            repetitions: 10,
-        },
-    },
-}));
-//# sourceMappingURL=loopOutlineDistilisys.js.map

package/dist/roles/designer/outlineDistilisys/loopOutlineDistilisys.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"loopOutlineDistilisys.js","sourceRoot":"","sources":["../../../../src/roles/designer/outlineDistilisys/loopOutlineDistilisys.ts"],"names":[],"mappings":";;;AAAA,qCASiB;AAKjB,6HAA0H;AAE1H,mEAAgE;AA2BhE;;GAEG;AACH,MAAM,eAAe,GAAG,IAAA,yEAAmC,EAAC;IAC1D,QAAQ,EAAE,UAAU;IACpB,KAAK,EAAE,YAAY;CACpB,CAAC,CAAC;AAEH;;GAEG;AACH,MAAM,wBAAwB,GAAG,IAAA,oBAAU,EACzC,IAAA,wBAAc,EAAC;IACb,IAAI,EAAE,sDAAsD;IAC5D,MAAM,EAAE,2DAA2D;IACnE,QAAQ,EAAE,CAAC,6CAAqB,EAAE,eAAe,CAAC;CACnD,CAAC,CACH,CAAC;AAEF;;GAEG;AACH,MAAM,kBAAkB,GAAG,IAAI,2BAAiB,CAM9C;IACA,IAAI,EAAE,SAAS;IACf,IAAI,EAAE,+BAA+B;IACrC,QAAQ,EAAE,QAAQ;IAClB,MAAM,EAAE,iDAAiD;IACzD,MAAM,EAAE,KAAK,EAAE,EAAE,OAAO,EAAE,EAAE,EAAE;QAC5B,MAAM,QAAQ,GAAG,MAAM,OAAO,CAAC,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,QAAQ,CAAC,GAAG,EAAE,CAAC;QACvE,OAAO;YACL,KAAK,EAAE,EAAE,QAAQ,EAAE;YACnB,MAAM,EAAE,EAAE,MAAM,EAAE,QAAQ,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,SAAS,EAAE;SACpD,CAAC;IACJ,CAAC;CACF,CAAC,CAAC;AAEH;;;GAGG;AACU,QAAA,qBAAqB,GAAG,IAAA,wBAAc,EACjD,IAAA,wBAAc,EAAC;IACb,IAAI,EAAE,yCAAyC;IAC/C,MAAM,EACJ,gGAAgG;IAClG,QAAQ,EAAE,wBAAwB;IAClC,OAAO,EAAE,kBAAkB;IAC3B,MAAM,EAAE;QACN,SAAS,EAAE;YACT,WAAW,EAAE,EAAE;SAChB;KACF;CACF,CAAC,CACH,CAAC"}

package/dist/roles/designer/outlineDistilisys/stepOutlineDistilisys.d.ts

@@ -1,22 +0,0 @@
-import { type GStitcher, type RoleContext, type Threads } from 'rhachet';
-import type { Artifact } from 'rhachet-artifact';
-import type { GitFile } from 'rhachet-artifact-git';
-import { type ContextOpenAI } from '../../../access/sdk/sdkOpenAi';
-type StitcherDesired = GStitcher<Threads<{
-    designer: RoleContext<'designer', {
-        art: {
-            roadmap: Artifact<typeof GitFile>;
-            distilisys: Artifact<typeof GitFile>;
-        };
-    }>;
-    caller: RoleContext<'caller', {
-        ask: string;
-        art: {
-            feedback: Artifact<typeof GitFile>;
-        };
-    }>;
-}>, ContextOpenAI & GStitcher['context'], {
-    content: string;
-}>;
-export declare const stepOutlineDistilisys: import("rhachet").Stitcher<StitcherDesired>;
-export {};

package/dist/roles/designer/outlineDistilisys/stepOutlineDistilisys.js

@@ -1,57 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.stepOutlineDistilisys = void 0;
-const rhachet_1 = require("rhachet");
-const sdkOpenAi_1 = require("../../../access/sdk/sdkOpenAi");
-const genStepArtSet_1 = require("../../../domain.operations/artifact/genStepArtSet");
-const getDesignerBrief_1 = require("../../../roles/designer/getDesignerBrief");
-const getEcologistBrief_1 = require("../../../roles/ecologist/getEcologistBrief");
-const getMechanicBrief_1 = require("../../../roles/mechanic/getMechanicBrief");
-const template = (0, rhachet_1.genTemplate)({
-    ref: { uri: __filename.replace('.ts', '.template.md') },
-    getVariables: async ({ threads }) => ({
-        ...(await (0, rhachet_1.getTemplateVarsFromRoleInherit)({ thread: threads.designer })),
-        ask: threads.caller.context.stash.ask,
-        briefs: await (0, rhachet_1.getTemplateValFromArtifacts)({
-            artifacts: [
-                // cool to see explicit "cross-train" scenes
-                ...(0, getEcologistBrief_1.getEcologistBriefs)(['distilisys/sys101.distilisys.grammar.md']),
-                ...(0, getDesignerBrief_1.getDesignerBriefs)(['declarative-over-imperative.md']),
-                ...(0, getMechanicBrief_1.getMechanicBriefs)([
-                    'architecture/ubiqlang.md',
-                    'style.names.treestruct.md',
-                    'architecture/directional-dependencies.md',
-                    'architecture/bounded-contexts.md',
-                ]),
-            ],
-        }),
-        brief: {
-            distilisys: await (0, rhachet_1.getTemplateValFromArtifacts)({
-                artifacts: [
-                    ...(0, getEcologistBrief_1.getEcologistBriefs)(['distilisys/sys101.distilisys.grammar.md']),
-                ],
-            }),
-        },
-        feedback: (await threads.caller.context.stash.art.feedback.get())?.content ?? '',
-        inflight: (await threads.designer.context.stash.art.distilisys.get())?.content ??
-            '',
-        roadmap: (await threads.designer.context.stash.art.roadmap.get())?.content ?? '',
-    }),
-});
-const stepImagine = (0, rhachet_1.genStepImagineViaTemplate)({
-    slug: '[designer]<outline>[distilisys]<imagine>',
-    stitchee: 'designer',
-    readme: 'intent(design an outline.distilisys for the ask)',
-    template,
-    imagine: sdkOpenAi_1.sdkOpenAi.imagine,
-});
-const stepArtSet = (0, genStepArtSet_1.genStepArtSet)({
-    stitchee: 'designer',
-    artee: 'distilisys',
-});
-exports.stepOutlineDistilisys = (0, rhachet_1.asStitcherFlat)((0, rhachet_1.genStitchRoute)({
-    slug: '[designer]<outline>[distilisys]',
-    readme: '@[designer]<outline>[distilisys] -> [distilisys]',
-    sequence: [stepImagine, stepArtSet],
-}));
-//# sourceMappingURL=stepOutlineDistilisys.js.map

package/dist/roles/designer/outlineDistilisys/stepOutlineDistilisys.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"stepOutlineDistilisys.js","sourceRoot":"","sources":["../../../../src/roles/designer/outlineDistilisys/stepOutlineDistilisys.ts"],"names":[],"mappings":";;;AAAA,qCAUiB;AAIjB,yDAA0E;AAC1E,iFAA8E;AAC9E,2EAAyE;AACzE,8EAA4E;AAC5E,2EAAyE;AA2BzE,MAAM,QAAQ,GAAG,IAAA,qBAAW,EAA6B;IACvD,GAAG,EAAE,EAAE,GAAG,EAAE,UAAU,CAAC,OAAO,CAAC,KAAK,EAAE,cAAc,CAAC,EAAE;IACvD,YAAY,EAAE,KAAK,EAAE,EAAE,OAAO,EAAE,EAAE,EAAE,CAAC,CAAC;QACpC,GAAG,CAAC,MAAM,IAAA,wCAA8B,EAAC,EAAE,MAAM,EAAE,OAAO,CAAC,QAAQ,EAAE,CAAC,CAAC;QACvE,GAAG,EAAE,OAAO,CAAC,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,GAAG;QACrC,MAAM,EAAE,MAAM,IAAA,qCAA2B,EAAC;YACxC,SAAS,EAAE;gBACT,4CAA4C;gBAC5C,GAAG,IAAA,sCAAkB,EAAC,CAAC,yCAAyC,CAAC,CAAC;gBAClE,GAAG,IAAA,oCAAiB,EAAC,CAAC,gCAAgC,CAAC,CAAC;gBACxD,GAAG,IAAA,oCAAiB,EAAC;oBACnB,0BAA0B;oBAC1B,2BAA2B;oBAC3B,0CAA0C;oBAC1C,kCAAkC;iBACnC,CAAC;aACH;SACF,CAAC;QACF,KAAK,EAAE;YACL,UAAU,EAAE,MAAM,IAAA,qCAA2B,EAAC;gBAC5C,SAAS,EAAE;oBACT,GAAG,IAAA,sCAAkB,EAAC,CAAC,yCAAyC,CAAC,CAAC;iBACnE;aACF,CAAC;SACH;QACD,QAAQ,EACN,CAAC,MAAM,OAAO,CAAC,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,QAAQ,CAAC,GAAG,EAAE,CAAC,EAAE,OAAO,IAAI,EAAE;QACxE,QAAQ,EACN,CAAC,MAAM,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,UAAU,CAAC,GAAG,EAAE,CAAC,EAAE,OAAO;YACpE,EAAE;QACJ,OAAO,EACL,CAAC,MAAM,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,OAAO,CAAC,GAAG,EAAE,CAAC,EAAE,OAAO,IAAI,EAAE;KAC1E,CAAC;CACH,CAAC,CAAC;AAEH,MAAM,WAAW,GAAG,IAAA,mCAAyB,EAAkB;IAC7D,IAAI,EAAE,0CAA0C;IAChD,QAAQ,EAAE,UAAU;IACpB,MAAM,EAAE,kDAAkD;IAC1D,QAAQ;IACR,OAAO,EAAE,qBAAS,CAAC,OAAO;CAC3B,CAAC,CAAC;AAEH,MAAM,UAAU,GAAG,IAAA,6BAAa,EAAC;IAC/B,QAAQ,EAAE,UAAU;IACpB,KAAK,EAAE,YAAY;CACpB,CAAC,CAAC;AAEU,QAAA,qBAAqB,GAAG,IAAA,wBAAc,EACjD,IAAA,wBAAc,EAAC;IACb,IAAI,EAAE,iCAAiC;IACvC,MAAM,EAAE,kDAAkD;IAC1D,QAAQ,EAAE,CAAC,WAAW,EAAE,UAAU,CAAC;CACpC,CAAC,CACH,CAAC"}

package/dist/roles/designer/outlineDistilisys/stepOutlineDistilisys.template.md

@@ -1,173 +0,0 @@
-@[ecologist]<distill><system> from roadmap
-
----
-
-.intent
-- extract the **underlying ecosystem** described by an implementation roadmap
-- map the roadmap into structured [resources], <mechanisms>, and {drivers}, and {drivers}, via distilisys language
-- treat the roadmap as describing the system that will exist — not the story of how it was built
-- if feedback is provided, revise or expand the diagram accordingly
-- **treat the roadmap as describing the system that will exist — not the story of how it was built**
-
-
-.mnemonic
-> don’t describe the construction site
-> describe the building once it’s open and running
-
-.illustrate
-- how will folks use it? -> what cascade of [resource] -> <mechanism> -> [resource] will that produce?
-- why will folks use it? -> what {drivers} propel them to do so?
-
-.required
-- distinguish ![system:maintainer] type actors -vs- @[system:user] type actors
-- focus primarily on @[system:users]. its ok to ignore ![system:maintainer]
-- we only care about how actors will <use>, <operate>, or <engage-with> the system
-- all terms must be exclusively camelCase, never PascalCase
-
----
-
-.format.example
-```md
-
-# 👤 @[actors]
-
-  - @[actorA] - who uses the system, why we care
-  - @[actorB] - who uses the system, why we care
-  - ![actorC] - who maintains the system, why we care
-  - ... // can be many
-
----
-
-# 📦 [resources]
-
-  - [resourceA] — what it is, why we care
-  - [resourceB] — ..
-  - ... // can be many
-
----
-
-# ⚙️ <mechanisms>
-
-  - <mechanismA> — what it does
-  - <mechanismB> — what it transforms or enables
-  - ... // can be many
-
----
-
-# ⚡ {drivers}
-
-  ## 💰 actor
-
-    - @[actorN]{+incentive:A} - some motivator; why does this actor engage with the system? and how is it relevant
-    - @[actorN]{+incentive:B} - some motivator; (e.g., {want:[time]++}, {want:[money]++}, {want:[status]++}, {want:[safety]++}, etc)
-    - @[actorY]{-decentive:A} - some dissuader, why does this actor disengage w/ the system? and how is it relevant
-    - ... // can be many
-
-  ## 🌪️ world
-
-    - &[causeZ]{+tailwind:effectA} — some accelerant / catalyst, why we care
-    - &[causeY]{+tailwind:effectB} —
-    - &[causeX]{-headwind:effectA} — some barrier / friction, why we care
-    - &[causeA]{-headwind:effectB} —
-    - ... // can be many
-    // note: there may also be none, if this is not a real-world system (e.g,. software only)
-
----
-
-## 🔁 system flows
-
-### {flow:slug-1}
-
-  summary:
-    @[actorA] applies <mechanismSummary1> against [resourceM] to produce [resourceN], because they want {+incentive:xyz}
-
-
-  distilisys:
-    ```sys
-    @[actorA]<mechanismSummary1>[resourceM] => [resourceN]
-
-    =
-
-      @[actorA][resorceX]
-        -> <mechanismC>
-        -> [resourceB]
-        -> <mechanismA>
-        -> ... // actually fill this out, to some terminal output
-
-          => {+incentive:xyz}
-    ```
-
-### {flow:slug-2}
-
-  summary:
-    @[actorB] applies <mechanismSummaryN> against [resourceY] to produce [resourceZ], because they wany {+incentive:123}, in spite of {-decentive:abc}
-
-  distilisys:
-    ```sys
-    @[actorB]<mechanismSummaryN>[resourceY] => [resourceZ]
-
-    =
-      @[actorB][ResourceY]
-      -> ... // actually fill this out
-      -> [resourceN]
-      -> <mechanismN>
-      -> ... // actually fill this out, to some terminal output
-
-        => {+decentive:123}
-        => {-decentive:abc}
-    ```
-
-### {flow.slug-n+...}
-
-```
-
-
----
-
-.tips
-- for api's, a common actor name is @[caller], if they dont have a more specific role
-- lookout for ![maintainer] actors like ![developers], if they're actually applicable.
-
----
-
-.rules
-- [resources] = any object, entity, material, or product that exists *within the produced system itself*
-- <mechanisms> = any behavior or flow that the system performs once constructed
-- {drivers} = forces that enable or resist the system’s intended behavior
-- use grouping to show dependencies or oppositional forces (e.g., tailwinds vs headwinds)
-- the output should **stand alone** as a structural diagram, separate from the roadmap steps
-
----
-
-.example.input = a decomposable roadmap with milestones for implementing a CLI system
-
-.example.output = a distilisys diagram that models the ecosystem of that implementation plan
-
----
-
-.brief.distilisys
-$.rhachet{brief.distilisys}
-
----
-
-.ask =
-```md
-$.rhachet{ask}
-```
-
-.roadmap =
-```md
-$.rhachet{roadmap}
-```
-
-.inflight? =
-```md
-$.rhachet{inflight}
-```
-
-.feedback? =
-```md
-$.rhachet{feedback}
-```
-
-.output = a `distilisys` diagram that models the structure and dynamics of the roadmap. if inflight is provided, EXCLUSIVELY FOCUS ON THE FEEDBACK