rhachet-roles-ehmpathy 1.0.0 → 1.2.0

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

@@ -0,0 +1,79 @@
+## 🎨 `.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/logic/roles/designer/.briefs/declarative-over-imperative.stub.md

@@ -0,0 +1,14 @@
+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/logic/roles/designer/.briefs/pit-of-success.md

@@ -0,0 +1,70 @@
+## 🧠 `.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/logic/roles/designer/.briefs/pit-of-success.stub.md

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

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

@@ -15,7 +15,7 @@ const template = (0, rhachet_1.genTemplate)({
         briefs: await (0, rhachet_1.getTemplateValFromArtifacts)({
             artifacts: [
                 // cool to see explicit "cross-train" scenes
-                ...(0, getEcologistBrief_1.getEcologistBriefs)(['distilisys.md']),
+                ...(0, getEcologistBrief_1.getEcologistBriefs)(['distilisys/sys101.distilisys.grammar.md']),
                 ...(0, getDesignerBrief_1.getDesignerBriefs)(['declarative-over-imperative.md']),
                 ...(0, getMechanicBrief_1.getMechanicBriefs)([
                     'architecture/ubiqlang.md',
@@ -27,7 +27,9 @@ const template = (0, rhachet_1.genTemplate)({
         }),
         brief: {
             distilisys: await (0, rhachet_1.getTemplateValFromArtifacts)({
-                artifacts: [...(0, getEcologistBrief_1.getEcologistBriefs)(['distilisys.md'])],
+                artifacts: [
+                    ...(0, getEcologistBrief_1.getEcologistBriefs)(['distilisys/sys101.distilisys.grammar.md']),
+                ],
             }),
         },
         feedback: (await threads.caller.context.stash.art.feedback.get())?.content ?? '',

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

@@ -1 +1 @@
-{"version":3,"file":"stepOutlineDistilisys.js","sourceRoot":"","sources":["../../../../../src/logic/roles/designer/outlineDistilisys/stepOutlineDistilisys.ts"],"names":[],"mappings":";;;AAAA,qCAUiB;AAIjB,8DAA0E;AAC1E,mEAAgE;AAChE,yEAAuE;AACvE,sEAAoE;AACpE,0DAAwD;AA2BxD,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,eAAe,CAAC,CAAC;gBACxC,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,CAAC,GAAG,IAAA,sCAAkB,EAAC,CAAC,eAAe,CAAC,CAAC,CAAC;aACtD,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"}
+{"version":3,"file":"stepOutlineDistilisys.js","sourceRoot":"","sources":["../../../../../src/logic/roles/designer/outlineDistilisys/stepOutlineDistilisys.ts"],"names":[],"mappings":";;;AAAA,qCAUiB;AAIjB,8DAA0E;AAC1E,mEAAgE;AAChE,yEAAuE;AACvE,sEAAoE;AACpE,0DAAwD;AA2BxD,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/logic/roles/designer/outlineDistilisys/stepOutlineDistilisys.template.md

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

package/dist/logic/roles/designer/outlineRoadmap/stepOutlineRoadmap.js

@@ -15,7 +15,7 @@ const template = (0, rhachet_1.genTemplate)({
         briefs: await (0, rhachet_1.getTemplateValFromArtifacts)({
             artifacts: [
                 // cool to see explicit "cross-train" scenes
-                ...(0, getEcologistBrief_1.getEcologistBriefs)(['distilisys.md']),
+                ...(0, getEcologistBrief_1.getEcologistBriefs)(['distilisys/sys101.distilisys.grammar.md']),
                 ...(0, getDesignerBrief_1.getDesignerBriefs)(['declarative-over-imperative.md']),
                 ...(0, getMechanicBrief_1.getMechanicBriefs)([
                     'architecture/ubiqlang.md',

package/dist/logic/roles/designer/outlineRoadmap/stepOutlineRoadmap.js.map

@@ -1 +1 @@
-{"version":3,"file":"stepOutlineRoadmap.js","sourceRoot":"","sources":["../../../../../src/logic/roles/designer/outlineRoadmap/stepOutlineRoadmap.ts"],"names":[],"mappings":";;;AAAA,qCAUiB;AAIjB,8DAA0E;AAC1E,mEAAgE;AAChE,yEAAuE;AACvE,sEAAoE;AACpE,0DAAwD;AA2BxD,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,QAAQ,CAAC,OAAO,CAAC,KAAK,CAAC,GAAG;QACvC,MAAM,EAAE,MAAM,IAAA,qCAA2B,EAAC;YACxC,SAAS,EAAE;gBACT,4CAA4C;gBAC5C,GAAG,IAAA,sCAAkB,EAAC,CAAC,eAAe,CAAC,CAAC;gBACxC,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,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,OAAO,CAAC,GAAG,EAAE,CAAC,EAAE,OAAO,IAAI,EAAE;KAC1E,CAAC;CACH,CAAC,CAAC;AAEH,MAAM,WAAW,GAAG,IAAA,mCAAyB,EAAkB;IAC7D,IAAI,EAAE,uCAAuC;IAC7C,QAAQ,EAAE,UAAU;IACpB,MAAM,EAAE,+CAA+C;IACvD,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,SAAS;CACjB,CAAC,CAAC;AAEU,QAAA,kBAAkB,GAAG,IAAA,wBAAc,EAC9C,IAAA,wBAAc,EAAC;IACb,IAAI,EAAE,8BAA8B;IACpC,MAAM,EAAE,4CAA4C;IACpD,QAAQ,EAAE,CAAC,WAAW,EAAE,UAAU,CAAC;CACpC,CAAC,CACH,CAAC"}
+{"version":3,"file":"stepOutlineRoadmap.js","sourceRoot":"","sources":["../../../../../src/logic/roles/designer/outlineRoadmap/stepOutlineRoadmap.ts"],"names":[],"mappings":";;;AAAA,qCAUiB;AAIjB,8DAA0E;AAC1E,mEAAgE;AAChE,yEAAuE;AACvE,sEAAoE;AACpE,0DAAwD;AA2BxD,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,QAAQ,CAAC,OAAO,CAAC,KAAK,CAAC,GAAG;QACvC,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,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,OAAO,CAAC,GAAG,EAAE,CAAC,EAAE,OAAO,IAAI,EAAE;KAC1E,CAAC;CACH,CAAC,CAAC;AAEH,MAAM,WAAW,GAAG,IAAA,mCAAyB,EAAkB;IAC7D,IAAI,EAAE,uCAAuC;IAC7C,QAAQ,EAAE,UAAU;IACpB,MAAM,EAAE,+CAA+C;IACvD,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,SAAS;CACjB,CAAC,CAAC;AAEU,QAAA,kBAAkB,GAAG,IAAA,wBAAc,EAC9C,IAAA,wBAAc,EAAC;IACb,IAAI,EAAE,8BAA8B;IACpC,MAAM,EAAE,4CAA4C;IACpD,QAAQ,EAAE,CAAC,WAAW,EAAE,UAAU,CAAC;CACpC,CAAC,CACH,CAAC"}

package/dist/logic/roles/designer/outlineRoadmap/stepOutlineRoadmap.template.md

@@ -0,0 +1,88 @@
+@[designer]<outline><roadmap> for [desire]
+
+---
+
+.intent
+- break down a system or design into **sequential, layered implementation milestones**
+- organize by **least dependent layer first** (typically domain → logic → contract → infra)
+- clarify **what**, **why**, **where**, and **how** for each milestone
+- if feedback is provided, respond to the feedback against the prior inflight proposal
+
+---
+
+.traits
+- speak in all lowercase, for aesthetics
+- speak in down to earth terms, for grokability
+- speak in distilisys [resource] and <mechanism> syntax, for grokability
+
+---
+
+.format
+\`\`\`md
+1. {milestone.title}
+   .why
+      .needed: {what this milestone enables or unlocks}
+      .ordered: {why this comes before others}
+   .where
+      .layer: {domain | logic | contract | data | infra}
+      .pathExample: {src/...}
+   .what
+     .contract.desired
+       input = ...
+       output = ...
+     .change.required
+       - {list code or structural changes needed}
+\`\`\`
+
+---
+
+.rules
+- output a **flat, ordered list of numbered milestones**
+- start with the **least dependent resource** (usually in `domain/`)
+- each milestone must be **concrete and decomposable**
+- use `.contract.desired` to show the goal, and `.change.required` to describe implementation
+- milestones must **build on each other** in a logical top-down flow
+- avoid implementation detail until required by a milestone
+
+---
+
+.briefs
+$.rhachet{briefs}
+
+---
+
+.example
+\`\`\`md
+1. {define ShopperBasket types}
+   .why
+      .needed: foundational domain types shared across layers
+      .ordered: must be defined before domain mechanisms in logic layer can use them
+   .where
+      .layer: domain
+      .pathExample: src/domain/objects/Role.ts
+   .what
+     .contract.desired
+       input = none
+       output = { Role, Skill } types with metadata
+     .change.required
+       - create types with slug, description, and readme
+\`\`\`
+
+---
+
+.ask =
+```md
+$.rhachet{ask}
+```
+
+.inflight? =
+```md
+$.rhachet{inflight}
+```
+
+.feedback? =
+```md
+$.rhachet{feedback}
+```
+
+.output = structured roadmap in decomposable milestone format. if inflight is provided, update it based on the feedback

package/dist/logic/roles/designer/outlineVision/stepOutlineVision.template.md

@@ -0,0 +1,47 @@
+@[designer]<outline><vision> for [desire]
+
+---
+
+.intent
+- clarify the **core intent** of the desired system or product
+- define the **irreducible constraints** that must be respected
+- surface the **essential shape** implied by the intent
+- identify **open space** — parts left intentionally flexible or undecided
+
+---
+
+.format
+\`\`\`md
+# 🎯 intent
+- {short summary of what the system is trying to make possible}
+
+# 📏 constraints
+- {things this system must respect — e.g., must run as CLI, must not leak domain logic}
+
+# 🧩 implied shape
+- [resource] — {core object this system revolves around}
+- <mechanism> — {core transformation it must enable}
+- {driver} — {why this system is needed now}
+
+# 🔮 open space
+- {what’s not yet decided — interface, delivery method, structure, etc.}
+\`\`\`
+
+---
+
+.ask =
+\`\`\`md
+$.rhachet{desire}
+\`\`\`
+
+.inflight? =
+\`\`\`md
+$.rhachet{inflight}
+\`\`\`
+
+.feedback? =
+\`\`\`md
+$.rhachet{feedback}
+\`\`\`
+
+.output = a distilled vision summary with core intent, constraints, implied shape, and open space; if inflight provided, respond to the feedback

package/dist/logic/roles/ecologist/.briefs/.readme.md

@@ -0,0 +1,17 @@
+these are the briefs that are relevant to the ecologist role
+
+.scratch has inflight and deprecated briefs
+
+directories group briefs by relevance
+
+root may also have some ungrouped ones
+
+---
+
+look for ._.summary.md briefs for compressed representations
+
+---
+
+we try and declare briefs as if they were courses in college
+
+it's a pattern ghia imagined, and has a good parallel, as our aim is to distill as informative and useful of a brief as possible -> distill lessons