dreamcontext 0.7.0 → 0.8.0

package/dist/skill-packs/excalidraw/SKILL.md

@@ -200,3 +200,73 @@ node examples/style_board.js                                # JS API: card/conne
 Then open the resulting board in Obsidian (Excalidraw view) to confirm it renders.
 
 See `reference/format.md` for the exact `.excalidraw.md` anatomy reverse-engineered from this vault.
+
+---
+
+## Boards as first-class knowledge in dreamcontext
+
+When the project uses dreamcontext, Excalidraw boards belong in `_dream_context/knowledge/diagrams/`.
+They are indexed and recalled just like any knowledge file — but memory extracts ONLY the
+`## Text Elements` section (never the scene JSON).
+
+### Required frontmatter
+
+Every board MUST have `name:` and `description:`. Boards with no `## Text Elements` content rely
+entirely on description for recall — make it descriptive.
+
+```yaml
+---
+name: My Board Title
+description: One-sentence summary of what this board visualises.
+tags: [architecture, excalidraw]
+excalidraw-plugin: parsed
+---
+```
+
+### Folder convention (preferred)
+
+```
+_dream_context/knowledge/diagrams/
+├── my-board/
+│   ├── my-board.excalidraw.md   ← generated board (do NOT hand-edit scene JSON)
+│   ├── my-board.board.cjs       ← generator (dark sibling — excluded from index/recall)
+│   └── my-board.json            ← spec / source of truth (dark sibling — excluded)
+└── legacy-flat.excalidraw.md    ← flat layout still works; no forced migration
+```
+
+**Dark siblings**: any file inside a `diagrams/<title>/` folder that is NOT the board itself
+is automatically excluded from the index, recall corpus, snapshot, and dashboard list.
+This includes generator scripts (`.board.cjs`), spec JSON, and any helper `.md` notes.
+They are tooling — they do not pollute memory.
+
+**Flat layout** (`diagrams/<title>.excalidraw.md`) works without any migration. Use the
+per-title folder when you want to keep the board + generator + spec together cleanly.
+
+### Memory contract
+
+- Memory indexes: frontmatter (`name`, `description`, `tags`) + `## Text Elements` labels.
+- Memory never indexes: scene JSON, base64 blobs, element ids, `## Embedded Files` map.
+- The dashboard renderer receives the raw body (full scene JSON) via the detail API route —
+  rendering is unaffected by extraction.
+- A 2 MB board with rich Text Elements and a tiny board with the same labels have the same
+  recall surface. Scene size does not affect recall or snapshot token cost.
+
+### Where does a board go?
+
+| Board nature | Location | Indexed? |
+|---|---|---|
+| Canonical / source-of-truth (architecture, system flows, roadmaps, durable plans the agent should recall in future sessions) | `_dream_context/knowledge/diagrams/<title>/` | Yes — indexed, recalled |
+| Temporary / scratch / exploratory / in-progress | `inbox/` or `workspace/` (dark by location) | No — not indexed, will not pollute recall |
+
+**Decision rule**: "Will a future session need to know this? → `knowledge/diagrams/`. Throwaway/working? → `inbox/` or `workspace/`."
+
+Promote a board from inbox/workspace to `knowledge/diagrams/` only once it becomes canonical.
+
+### Migration
+
+Flat boards in `knowledge/diagrams/` do NOT auto-migrate.
+
+- `dreamcontext migrations pending` — see pending migration task instructions (including 0.7.2 diagrams-folder-convention).
+- `dreamcontext migrations apply-diagrams` — opt-in: moves flat `knowledge/diagrams/*.excalidraw.md` boards into per-title folders AND rewrites all inbound [[wikilinks]] atomically. Safe to re-run. Do NOT hand-edit wikilinks manually.
+
+Only organize boards you confirm are canonical knowledge. Temp/scratch boards stay in inbox/workspace.

package/dist/templates/feature.md

@@ -5,6 +5,7 @@ created: "{{DATE}}"
 updated: "{{DATE}}"
 released_version: null
 tags: []
+# tags: use canonical faceted vocabulary (facet:value, kebab-case singular) — run: dreamcontext taxonomy vocab
 related_tasks: []
 ---
 

package/dist/templates/task.md

@@ -8,6 +8,7 @@ status: "{{STATUS}}"
 created_at: "{{DATE}}"
 updated_at: "{{DATE}}"
 tags: {{TAGS}}
+# tags: use canonical faceted vocabulary (facet:value, kebab-case singular) — run: dreamcontext taxonomy vocab
 parent_task: null
 related_feature: null
 version: {{VERSION}}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dreamcontext",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "description": "dreamcontext — the persistent brain for your AI agents. Remembers what you built, knows how your project works.",
   "type": "module",
   "bin": {

package/skill/SKILL.md

@@ -209,6 +209,7 @@ These files vary across projects. Do not assume a fixed list. Always discover dy
 12a. **Keep the Workflow flowchart in sync.** Every task file has a `## Workflow` mermaid block at the top — one node per acceptance criterion, grouped under milestone subgraphs, with status classes `done` / `active` / `todo` / `blocked`. Whenever you check off a criterion, start work on one, add/remove a criterion, or hit a blocker: update the corresponding node's `:::class`. Run `dreamcontext tasks doctor <name>` to verify sync. The flowchart is the load-bearing summary of the task — drift makes future sessions misread progress.
 13. **Reuse before create.** Before building any UI component, utility, hook, or abstraction, search the codebase for existing implementations that serve the same purpose. Use `dreamcontext-explore` to find reusable candidates. If a match exists, use it or extend it. Never duplicate functionality that already exists. This applies to modals, forms, filters, layouts, helpers, and any shared pattern.
 14. **Recall before grep.** Before grepping `_dream_context/` for prior decisions, design rationale, or "did we already address X?", run `dreamcontext memory recall "<query>"`. BM25 ranks across knowledge, features, tasks, and memory entries in one shot — cheaper and more on-target than blind Grep.
+15. **Tag before you create.** Before tagging any task, feature, or knowledge file, consult the project taxonomy vocabulary (`dreamcontext taxonomy vocab`). Reuse canonical faceted tags (`topic:recall`, `domain:security`, etc.) or bare standard tags before inventing new ones — fragmenting tags degrades recall quality. To add new vocabulary: `dreamcontext taxonomy add <tag>` (new domain terms) or `dreamcontext taxonomy alias <alias> <canonical>` (merging shorthands). Use `dreamcontext taxonomy resolve <tag>` to verify classification.
 
 ---
 
@@ -317,6 +318,8 @@ Sleep debt reminders are injected on every user message (via UserPromptSubmit ho
      - a session advanced ≥1 acceptance criterion, OR introduced a feature concept with ≥2 acceptance criteria, OR the user named something "a feature" / "we should add X", OR a task has `feature:` frontmatter pointing to a non-existent PRD
      - user hint mentions knowledge or a feature
    - When unsure, **over-fire** `sleep-product` — it no-ops cheaply.
+   - **Conditional fire**: `sleep-migration` when `dreamcontext migrations pending` produces output (pending agent migration tasks exist). Contract: no-content changes only (structure/paths/frontmatter/fences); writes ledger via `dreamcontext migrations record` on completion.
+   - **Conditional fire**: `sleep-federation` when `state/.connections.json` has active (non-stale) links OR the federation inbox has pending entries (check `dreamcontext federation status`). Contract: **drain THEN distribute** — `dreamcontext federation drain` (ingest peer digests into first-class `knowledge/*--from-*.md` with `federated:true` provenance, surface conflict-notes as bookmarks, never auto-resolve) then `dreamcontext federation sync` (consent-gated, recall-filtered push into connected peers' inboxes, watermark advances). Owns ONLY `.connections.json` + `.federation-inbox/` + `knowledge/*--from-*.md`. Idempotent — over-fire cheaply.
    - Pass each specialist a small text brief in its prompt: epoch, session IDs, active task slugs, planning version, signals relevant to that specialist, optional user hint. Do **not** include transcript content — specialists call `dreamcontext transcript distill <id>` themselves.
    - **Consolidation discipline (remind both specialists in the brief):** prefer *updating/extending* an existing entity over creating a new one. `sleep-tasks` folds a smaller slice into the task that already covers it (broaden its title + insert sub-items) rather than forking a duplicate or a needless sub-task; `sleep-product` keeps similar verticals/brands/topics in the fewest knowledge files, splitting only on a sharp topical boundary that sharpens tags. Duplicate tasks and fragmented near-duplicate knowledge are the top consolidation failure modes — but genuinely separate concerns/topics still get their own task/file.
 5. Wait for all specialist reports. Each returns a short structured report.
@@ -428,7 +431,36 @@ Task insert sections: `why`, `user_stories`, `acceptance_criteria`, `constraints
 
 **Knowledge**: Index auto-loaded each session. Pin frequently-needed files (`pinned: true` in frontmatter). Read non-pinned on demand. Create with `dreamcontext knowledge create <name>`.
 
-Standard tags: `architecture`, `api`, `frontend`, `backend`, `database`, `devops`, `security`, `testing`, `design`, `decisions`, `onboarding`, `domain`. Custom tags allowed.
+Standard tags: `architecture`, `api`, `frontend`, `backend`, `database`, `devops`, `security`, `testing`, `design`, `decisions`, `onboarding`, `domain`. Custom tags allowed. For the full resolved project vocabulary (including faceted tags and aliases), run `dreamcontext taxonomy vocab`. The project vocabulary is maintained in `core/taxonomy.json`; scaffold it with `dreamcontext taxonomy init`. Mutate vocabulary via CLI — never hand-edit the JSON: `dreamcontext taxonomy add <facet:value>` for new tags, `dreamcontext taxonomy alias <alias> <canonical>` for merges, `dreamcontext taxonomy resolve <tag>` to check classification. sleep-product runs taxonomy maintenance during Pass C.
+
+**Taxonomy**: Tags drive BM25 recall precision. Prefer canonical faceted tags (`topic:recall`, `domain:database`) over bare duplicates. Run `dreamcontext taxonomy audit` to surface non-canonical or orphan tags.
+
+### Excalidraw boards in knowledge/diagrams/
+
+Excalidraw boards (`.excalidraw.md`) are first-class knowledge files. Two layouts are both supported:
+
+**Flat** (legacy, still works): `knowledge/diagrams/<title>.excalidraw.md`
+
+**Per-title folder** (preferred convention): `knowledge/diagrams/<title>/<title>.excalidraw.md`
+
+Rules:
+- **REQUIRED frontmatter**: every board MUST have `name:` and `description:` fields. Boards with no `## Text Elements` section fall back to description-only recall — make it descriptive.
+- **Do NOT hand-edit scene JSON.** The `.excalidraw.md` file is generated output. Build a spec and run the generator (`.board.cjs`). Edit the spec, not the board.
+- **Spec is the source of truth.** If the spec and the board ever disagree, the spec wins. Commit both.
+- **Dark siblings**: all files inside a `knowledge/diagrams/<title>/` folder that are NOT the board itself (generator scripts `.board.cjs`, spec `.json`, helper `.md`) are excluded from the index, recall corpus, snapshot, and dashboard. They are tooling artifacts — they do NOT surface in memory.
+- **Memory indexes only frontmatter + ## Text Elements**: scene JSON, base64, and element ids are stripped before indexing. A 2 MB board with rich Text Elements is as searchable as a tiny board. The dashboard renderer still receives the raw body (with full scene JSON) via the detail API route.
+- **Migration is opt-in**: flat boards stay flat unless you explicitly ask for reorganization. Use `dreamcontext migrations pending` to see pending migration tasks; use `dreamcontext migrations apply-diagrams` to opt-in to organizing flat boards into per-title folders.
+
+#### Where does a board go?
+
+| Board nature | Location | Indexed? |
+|---|---|---|
+| Canonical / source-of-truth (architecture, system flows, roadmaps, durable plans the agent should recall in future sessions) | `knowledge/diagrams/<title>/` | Yes — indexed, recalled |
+| Temporary / scratch / exploratory / in-progress | `inbox/` or `workspace/` (dark by location) | No — not indexed, will not pollute recall |
+
+**Decision rule**: "Will a future session need to know this? → `knowledge/diagrams/`. Throwaway/working? → `inbox/` or `workspace/`."
+
+Promote a board from `inbox/workspace` to `knowledge/diagrams/` only once it becomes canonical. Use `dreamcontext migrations apply-diagrams` to move flat boards + rewrite inbound [[wikilinks]] atomically — do NOT hand-edit wikilinks.
 
 ---
 
@@ -457,6 +489,34 @@ dreamcontext memory status
 
 ---
 
+## Cross-Project Federation (issue #25)
+
+Every `_dream_context/` is normally an island. Federation lets you reach across projects — recall what you worked out in *another* vault — using nothing but the local filesystem (no network, ever). Phase 1 is **read-only**: discovery + cross-vault recall + peer snapshots.
+
+```bash
+dreamcontext vaults discover [root] [--register]   # find every _dream_context/ under a tree (node_modules ignored, depth-bounded)
+dreamcontext memory recall <query...> --vault <name>   # also search a peer vault (repeatable)
+dreamcontext memory recall <query...> --all-vaults     # search current + every SHAREABLE registered vault
+dreamcontext memory recall <query...> --connected      # search current + out/both connections (degenerate=local until Phase 2)
+dreamcontext snapshot --vault <name>               # print a peer vault's context snapshot
+dreamcontext config shareable on|off               # opt this project IN/OUT of peer recall (default: off)
+```
+
+**Trust model — shareable gates READS, private by default.** A vault is invisible to peer recall until its owner runs `config shareable on`. New and migrated projects default to `shareable: false`. `shareable` is asymmetric: it controls whether OTHERS may pull *your* corpus — it never blocks *you* from reading a shareable peer, and the current vault is always searched regardless of its own flag. Non-shareable peers are silently excluded from `--all-vaults` (never an error). Cross-vault hits are namespaced `<vault>::<type>/<slug>` so the same slug in two vaults never collides.
+
+**When to reach across.** Use `--vault`/`--all-vaults` for "how did I solve this in project X?" / "did we already build Y somewhere?" before re-deriving knowledge that already exists in a sibling project.
+
+**Per-link connections (Phase 2).** `dreamcontext connect <vault> --direction out|in|both [--topics a,b]` builds an outgoing mesh in `state/.connections.json`; `connections list` / `disconnect <vault>` manage it. Direction is asymmetric: `out` = your digest may flow TO the peer, `in` = you accept the peer's digest, `both` = bidirectional. The dashboard Settings → Cross-Project Federation card edits all of this plus the shareable switch.
+
+**Sleep-driven digest inbox (Phase 3).** Federated knowledge crosses a boundary as a *directory of one-file-per-entry JSON digests* under `state/.federation-inbox/` (consumed entries archive to `consumed/`). The `sleep-federation` specialist runs two idempotent steps, ALWAYS in this order:
+
+1. **Drain** (`dreamcontext federation drain`) — ingest each pending inbox entry as **first-class** local `knowledge/<slug>.md` carrying `federated: true` + `origin{vault,entryId,sourceTimestamp}` provenance. A slug collision lands at `knowledge/<slug>--from-<vault>.md` (the local doc is never clobbered). A `conflict-note` entry is ingested AND surfaced as a bookmark for the user — never auto-resolved. Version-incompatible entries are quarantined in place.
+2. **Distribute** (`dreamcontext federation sync`) — for each `out`/`both` connection, the sender reads the RECEIVER's `.connections.json` and writes ONLY if the receiver declares `in`/`both` back (the **consent rule**); it computes a recall-filtered digest since `last_synced_at`, writes one file per entry into the peer's inbox, and advances the watermark. Draining first means freshly-ingested peer knowledge is in the corpus when the outbound digest is computed — and is then EXCLUDED from it, because `federated: true` docs are dropped from BOTH digest computation AND cross-vault recall serving (the transitive-leak guard: a third vault never sees what merely passed through this one). Filename dedup + watermark + that exclusion make an A↔B cycle echo-free.
+
+The SessionStart snapshot stays on the hot path: it only ever does a single local `pendingInboxCount` readdir to nudge "N pending peer digests — drain them"; it NEVER resolves a peer or builds a peer corpus. Dashboard previews via `POST /api/federation/sync` are **dry-run by construction** (no write function reachable from any server route).
+
+---
+
 ## Structure
 
 ```
@@ -474,6 +534,13 @@ _dream_context/
 |   +-- data-structures/              <- Per-product schemas (recall-indexed knowledge)
 |   |   +-- default.md                <-   single-product fallback
 |   |   +-- <product>.md              <-   one per product if monorepo
+|   +-- diagrams/                     <- Excalidraw boards (flat or per-title folder)
+|   |   +-- <title>.excalidraw.md     <-   flat layout (still works; legacy OK)
+|   |   +-- <title>/                  <-   preferred: per-title folder
+|   |   |   +-- <title>.excalidraw.md <-     generated board (do NOT hand-edit scene JSON)
+|   |   |   +-- <title>.board.cjs     <-     generator script (dark sibling — excluded from index/recall)
+|   |   |   +-- <title>.json          <-     spec/source of truth (dark sibling — excluded)
+|   |   |   +-- notes.md              <-     any helper .md (dark sibling — excluded)
 |   +-- products/<product>.md         <- Per-product knowledge (multi-product)
 +-- state/
 |   +-- <task>.md                     <- Active tasks (frontmatter may include product:)
@@ -482,6 +549,27 @@ _dream_context/
 
 ---
 
+## Improving dreamcontext (Agent Feedback)
+
+You are not just a *user* of dreamcontext — you are its field reporter. When dreamcontext gets in your way, the system can only improve if that friction reaches its maintainers. Take responsibility: file it.
+
+**Trigger — the moment you notice any of these, consider filing feedback:**
+- You expected a fact to be in memory but `memory recall` didn't surface it (a recall gap, not a missing fact).
+- You wished a CLI command existed and there was no path (e.g. "I want to reopen a completed task" and no `tasks reopen`).
+- A command, hook, or doc behaved wrong, was confusing, or crashed.
+- The structure forced an awkward workaround to do something the system should support directly.
+
+Do **not** silently work around it. A workaround fixes today; feedback fixes the system.
+
+**The loop (this is the only sanctioned way to file — never run `gh issue create` by hand):**
+1. **Draft.** Run `dreamcontext feedback --dry-run` with the category and a complete scenario. Fill `-s` (what you were doing), `-e` (what you expected), `-g` (what was missing/broken), `-r` (exact commands), `-p` (your proposed improvement). A maintainer who has never seen your session must understand it from the issue alone — include the whole scenario.
+2. **Confirm with the user.** Show them the rendered draft and ask permission. This writes to a public repo on their behalf — never file without an explicit yes.
+3. **File.** Re-run the same command without `--dry-run` and with `--yes`. It checks for near-duplicate open issues, applies the `agent-feedback` label, and files to the dreamcontext project (`meanllbrl/dreamcontext`) — **not** the user's own repo.
+
+**No GitHub access?** If the command reports `gh` is missing or unauthenticated, relay its guidance to the user: install `gh` + run `gh auth login`, and if they have no GitHub account, ask them to create a free one at github.com/signup. They need an account to file. Once they're signed in, re-run the loop.
+
+**Quality bar:** one issue per distinct gap, concrete title, full scenario, a concrete proposal. Vague feedback ("recall is bad") is noise; a reproducible scenario with a proposed command is signal.
+
 ## Command Reference
 
 All commands prefixed with `dreamcontext`. For reading/searching, use native tools directly.
@@ -543,6 +631,7 @@ All commands prefixed with `dreamcontext`. For reading/searching, use native too
 | `config show` | Print project config (platforms, packs, native-memory state) |
 | `config native-memory <enable\|disable>` | Toggle Claude's native auto-memory; disabled by default so dreamcontext owns project memory |
 | `upgrade [--check]` | Update the dreamcontext CLI itself to the latest npm release |
+| `feedback -c <category> -t <title> -s <scenario> [-e expected] [-g gap] [-r repro] [-p proposal] [--dry-run] [--yes]` | File a structured gap/bug as a GitHub issue to the **dreamcontext project** (upstream, not the user's repo). Use `--dry-run` to render a draft for the user; file with `--yes` only after they approve. Categories: `bug \| missing-cli \| unseen-memory \| feature \| docs \| other`. See "Improving dreamcontext" below. |
 
 Feature insert sections: `changelog`, `notes`, `technical_details`, `constraints`, `user_stories`, `acceptance_criteria`, `why`
 Task insert sections: `why`, `user_stories`, `acceptance_criteria`, `constraints`, `technical_details`, `notes`, `changelog`

package/skill-packs/excalidraw/SKILL.md

@@ -200,3 +200,73 @@ node examples/style_board.js                                # JS API: card/conne
 Then open the resulting board in Obsidian (Excalidraw view) to confirm it renders.
 
 See `reference/format.md` for the exact `.excalidraw.md` anatomy reverse-engineered from this vault.
+
+---
+
+## Boards as first-class knowledge in dreamcontext
+
+When the project uses dreamcontext, Excalidraw boards belong in `_dream_context/knowledge/diagrams/`.
+They are indexed and recalled just like any knowledge file — but memory extracts ONLY the
+`## Text Elements` section (never the scene JSON).
+
+### Required frontmatter
+
+Every board MUST have `name:` and `description:`. Boards with no `## Text Elements` content rely
+entirely on description for recall — make it descriptive.
+
+```yaml
+---
+name: My Board Title
+description: One-sentence summary of what this board visualises.
+tags: [architecture, excalidraw]
+excalidraw-plugin: parsed
+---
+```
+
+### Folder convention (preferred)
+
+```
+_dream_context/knowledge/diagrams/
+├── my-board/
+│   ├── my-board.excalidraw.md   ← generated board (do NOT hand-edit scene JSON)
+│   ├── my-board.board.cjs       ← generator (dark sibling — excluded from index/recall)
+│   └── my-board.json            ← spec / source of truth (dark sibling — excluded)
+└── legacy-flat.excalidraw.md    ← flat layout still works; no forced migration
+```
+
+**Dark siblings**: any file inside a `diagrams/<title>/` folder that is NOT the board itself
+is automatically excluded from the index, recall corpus, snapshot, and dashboard list.
+This includes generator scripts (`.board.cjs`), spec JSON, and any helper `.md` notes.
+They are tooling — they do not pollute memory.
+
+**Flat layout** (`diagrams/<title>.excalidraw.md`) works without any migration. Use the
+per-title folder when you want to keep the board + generator + spec together cleanly.
+
+### Memory contract
+
+- Memory indexes: frontmatter (`name`, `description`, `tags`) + `## Text Elements` labels.
+- Memory never indexes: scene JSON, base64 blobs, element ids, `## Embedded Files` map.
+- The dashboard renderer receives the raw body (full scene JSON) via the detail API route —
+  rendering is unaffected by extraction.
+- A 2 MB board with rich Text Elements and a tiny board with the same labels have the same
+  recall surface. Scene size does not affect recall or snapshot token cost.
+
+### Where does a board go?
+
+| Board nature | Location | Indexed? |
+|---|---|---|
+| Canonical / source-of-truth (architecture, system flows, roadmaps, durable plans the agent should recall in future sessions) | `_dream_context/knowledge/diagrams/<title>/` | Yes — indexed, recalled |
+| Temporary / scratch / exploratory / in-progress | `inbox/` or `workspace/` (dark by location) | No — not indexed, will not pollute recall |
+
+**Decision rule**: "Will a future session need to know this? → `knowledge/diagrams/`. Throwaway/working? → `inbox/` or `workspace/`."
+
+Promote a board from inbox/workspace to `knowledge/diagrams/` only once it becomes canonical.
+
+### Migration
+
+Flat boards in `knowledge/diagrams/` do NOT auto-migrate.
+
+- `dreamcontext migrations pending` — see pending migration task instructions (including 0.7.2 diagrams-folder-convention).
+- `dreamcontext migrations apply-diagrams` — opt-in: moves flat `knowledge/diagrams/*.excalidraw.md` boards into per-title folders AND rewrites all inbound [[wikilinks]] atomically. Safe to re-run. Do NOT hand-edit wikilinks manually.
+
+Only organize boards you confirm are canonical knowledge. Temp/scratch boards stay in inbox/workspace.

package/dist/dashboard/assets/channel-w_Bp182N.js

@@ -1 +0,0 @@
-import{aq as o,ar as n}from"./index-Bo5CUa_M.js";const t=(r,a)=>o.lang.round(n.parse(r)[a]);export{t as c};

package/dist/dashboard/assets/classDiagram-6PBFFD2Q-CcQxcqy9.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-4TB4RGXK-DKJFLaTC.js";import{_ as i}from"./index-Bo5CUa_M.js";import"./chunk-FMBD7UC4-ixXe5R10.js";import"./chunk-YZCP3GAM-yztvsKR-.js";import"./chunk-55IACEB6-CKZPWZRu.js";import"./chunk-EDXVE4YY-k1y4mGUJ.js";var u={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{u as diagram};

package/dist/dashboard/assets/classDiagram-v2-HSJHXN6E-CcQxcqy9.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-4TB4RGXK-DKJFLaTC.js";import{_ as i}from"./index-Bo5CUa_M.js";import"./chunk-FMBD7UC4-ixXe5R10.js";import"./chunk-YZCP3GAM-yztvsKR-.js";import"./chunk-55IACEB6-CKZPWZRu.js";import"./chunk-EDXVE4YY-k1y4mGUJ.js";var u={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{u as diagram};

package/dist/dashboard/assets/clone-_znoR_ci.js

@@ -1 +0,0 @@
-import{b as r}from"./graph-DpIXS1G1.js";var e=4;function a(o){return r(o,e)}export{a as c};