dreamcontext 0.8.2 → 0.8.5

package/README.md

@@ -19,8 +19,10 @@
   <a href="#skills">Skills</a> &nbsp;&middot;&nbsp;
   <a href="#staying-up-to-date">Updating</a> &nbsp;&middot;&nbsp;
   <a href="#dashboard">Dashboard</a> &nbsp;&middot;&nbsp;
+  <a href="#desktop-app">Desktop App</a> &nbsp;&middot;&nbsp;
   <a href="#council">Council</a> &nbsp;&middot;&nbsp;
   <a href="#memory-recall">Memory Recall</a> &nbsp;&middot;&nbsp;
+  <a href="#federation">Federation</a> &nbsp;&middot;&nbsp;
   <a href="#commands">Commands</a> &nbsp;&middot;&nbsp;
   <a href="DEEP-DIVE.md">Deep Dive</a>
 </p>
@@ -139,7 +141,7 @@ flowchart LR
 curl -fsSL https://cdn.jsdelivr.net/npm/dreamcontext/install.sh | sh
 ```
 
-> Served from the published npm package via CDN — works with a private repo, no GitHub access needed.
+> Served from the published npm package via CDN — works with a private repo, no GitHub access needed. On macOS this also installs the optional [desktop app](#desktop-app) into `~/Applications` (skip with `DREAMCONTEXT_INSTALL_NO_APP=1`).
 
 **Manual install (npm):**
 
@@ -214,7 +216,9 @@ your-project/
 │   │   ├── dreamcontext-explore.md
 │   │   ├── sleep-tasks.md       # RemSleep specialists —
 │   │   ├── sleep-state.md       #   the agent fans out to
-│   │   └── sleep-product.md     #   these in parallel
+│   │   ├── sleep-product.md     #   these three in parallel
+│   │   ├── sleep-federation.md  # conditional: when peer connections exist
+│   │   └── sleep-migration.md   # conditional: when a migration is pending
 │   └── settings.json           # 7 hooks (see Commands → System)
 ```
 
@@ -357,6 +361,27 @@ It also ships a built-in **“What is this?”** explainer page — a full landi
 
 Light and dark mode with system preference detection. Brand palette: purple-to-magenta gradient. Visby CF font with system font fallback.
 
+## Desktop App
+
+> **macOS beta.** A native **Tauri 2** app that wraps the same dashboard server, so you manage every project from one window instead of a localhost tab per repo. Ships via the desktop release (and the macOS one-line installer), not the npm package.
+
+```bash
+dreamcontext app install      # Install to ~/Applications (no admin, no quarantine prompt)
+dreamcontext app update       # Update the installed app to the latest release
+dreamcontext app status       # Show installed app version and state
+```
+
+- **Multi-vault launcher.** The app lists every registered [vault](#federation) and opens each project in its **own window** — multi-vault is multi-window over one shared Node server, with each window pinned to its vault via a request header. A per-project status dot (green up-to-date / yellow needs-update / red folder-gone) lets you run `update` from the UI.
+- **Federation network view.** The launcher also renders your projects as an interactive board (Excalidraw-style cards) where you wire two kinds of relationship by clicking source → target: **reads** (violet — one project reads another's memory live during recall, gated by the target being Readable) and **sync** (teal — at sleep, a project's new knowledge is pushed into a listener's brain). Drawing a sync sets both sides' consent in one gesture; a node panel and an always-on "Connections" list spell out in plain language who reads and who listens to whom, each removable with one click.
+- **In-app onboarding, no terminal.** A quiz-style wizard creates a brand-new project (native folder picker) or initializes an existing folder, scaffolds `_dream_context/`, runs `setup`, and best-effort installs the global CLI. It's deterministic and LLM-free; the success screen hands you a prompt to paste into Claude Code for the rich enrichment pass.
+- **Sleepy — notch quick-capture _(beta)_.** A global-hotkey companion that drops a transparent notch panel over whatever you're doing, with an animated mascot whose mood follows your sleep debt. Pick a vault, type a thought, and choose a mode:
+  - **Learn** — saves the note to project memory, then enriches it.
+  - **Ask** — one-shot Q&A about the project; nothing is saved.
+  - **Sleep** — triggers a full consolidation cycle for that vault from the notch.
+- **Continuous updates without Apple notarization.** The whole delivery path is CLI/curl-driven, so Gatekeeper's notarization check never fires (ad-hoc signing satisfies Apple Silicon). The app prefers your globally-installed, auto-upgrading CLI over its bundled copy, so ~95% of changes ride the normal CLI upgrade with no app rebuild. Downloaded artifacts require a matching `.sha256` or the install refuses.
+
+> The desktop app is a working local beta — not yet Apple-signed/notarized, so first launch may need a right-click → Open. Windows/Linux are nice-to-have for later.
+
 ## Council
 
 **Multi-persona debates for hard decisions.** When a question is too load-bearing for a single model pass — architecture calls, hiring reviews, risk-heavy migrations, brand critiques — a council lets you convene N personas, run them through N rounds of structured deliberation, and synthesize a verdict that cites the contributing voices.
@@ -426,6 +451,42 @@ Hook injection is **ON by default**: top hits are auto-surfaced to the agent on
 
 **Recent CHANGELOG in the snapshot is tiered**: top 3 entries detailed (summary + ~300 char body), next 10 titles-only under an "Older" subheading. Everything older still lives in `CHANGELOG.json` and is reachable through `memory recall --types changelog`.
 
+## Federation
+
+Most people end up with more than one dreamcontext project. **Federation** lets those projects discover each other, recall across each other, and quietly share consolidated knowledge — all opt-in, all local, no server in the middle.
+
+It starts with a **global vault registry** — every project you register is a *vault* the CLI (and the [desktop app](#desktop-app)) can address by name.
+
+```bash
+dreamcontext vaults add <name> <path>     # Register a project directory as a vault
+dreamcontext vaults discover [root]        # Find every _dream_context/ project under a tree
+dreamcontext vaults discover ~/projects --register  # …and register the new ones (idempotent)
+dreamcontext vaults list                   # List all registered vaults
+dreamcontext vaults remove <name>          # Unregister a vault
+```
+
+**Cross-vault recall.** Point a recall at other vaults and it spans them, returning hits tagged with their source vault. Only vaults you've marked shareable are reachable.
+
+```bash
+dreamcontext config shareable on                      # Allow this vault to be recalled by peers
+dreamcontext memory recall "<query>" --vault other-project   # Also search a named vault (repeatable)
+dreamcontext memory recall "<query>" --connected             # Span this vault + its out/both connections
+dreamcontext memory recall "<query>" --all-vaults            # Span this vault + every shareable vault
+```
+
+**Connections + the sleep-driven digest inbox.** Connect two vaults and, during sleep consolidation, a conditional `sleep-federation` specialist pushes a recall-filtered **digest** of what changed into each consenting peer's inbox. The receiving project ingests those entries as first-class knowledge on its next drain — so a decision made in one repo can surface in a sibling repo without copy-paste.
+
+```bash
+dreamcontext connect <vault> --direction both --topics api,auth   # Connect to a peer (out | in | both)
+dreamcontext connections                  # Inspect this vault's federation connections
+dreamcontext disconnect <vault>           # Remove a connection
+dreamcontext federation status            # Inbox counts + per-connection sync watermarks
+dreamcontext federation sync --dry-run    # Preview the digests a sleep cycle would push
+dreamcontext federation drain             # Ingest pending inbox entries as knowledge, then consume them
+```
+
+Federation is **read-only and consent-gated by construction**: the browser-reachable dashboard route can only *preview* digests, never write into a peer; all writes live in the CLI (run by the sleep specialist), where the consent rule and watermark advance stay in one auditable place. Every ingested entry carries its provenance (origin vault, entry id, source timestamp). Dead or unreachable peers are marked stale and skipped, warned once.
+
 ## Commands
 
 ### Core
@@ -503,8 +564,11 @@ dreamcontext tasks sync-hooks install               # best-effort post-commit/pr
 ```bash
 dreamcontext features create <name>       # Create a feature PRD
 dreamcontext features insert <name> <section> <content>
+dreamcontext features doctor              # Audit PRD freshness (stale / orphaned / dangling refs)
 ```
 
+Feature PRDs track freshness the same way knowledge does. `features doctor` reports which PRDs have gone stale, which have no linked task or release, and which reference things that no longer exist — so the sleep cycle (and you) can keep them in step with the code.
+
 ### Knowledge
 
 ```bash
@@ -523,6 +587,9 @@ Set `pinned: true` in frontmatter to auto-load a knowledge file in every snapsho
 dreamcontext memory recall <query...>                # BM25 search over knowledge + features + tasks + memory + changelog
 dreamcontext memory recall <query...> --top 10       # Number of hits (1-50, default 5)
 dreamcontext memory recall <query...> --types knowledge,task,changelog
+dreamcontext memory recall <query...> --vault other    # Also search a named vault (repeatable)
+dreamcontext memory recall <query...> --connected      # Span this vault + its connected peers
+dreamcontext memory recall <query...> --all-vaults     # Span every shareable registered vault
 dreamcontext memory recall <query...> --json         # Machine-readable
 dreamcontext memory recall <query...> --plain        # No ANSI colors
 dreamcontext memory remember "<text>"                # Writes a CHANGELOG entry (type=note, scope=quick by default)
@@ -605,6 +672,33 @@ dreamcontext council promote --to <knowledge-slug>    # Promote verdict to knowl
 
 See the [Council](#council) section above for the full workflow.
 
+### Vaults & Federation
+
+```bash
+dreamcontext vaults add <name> <path>    # Register a project as a vault
+dreamcontext vaults discover [root]      # Find every _dream_context/ project under a tree
+dreamcontext vaults discover [root] --register  # …and register the new ones
+dreamcontext vaults list                 # List registered vaults
+dreamcontext vaults remove <name>        # Unregister a vault
+dreamcontext config shareable <on|off>   # Allow/deny this vault being recalled by peers
+dreamcontext connect <vault> [--direction out|in|both] [--topics a,b]  # Connect to a peer
+dreamcontext connections                 # Inspect federation connections
+dreamcontext disconnect <vault>          # Remove a connection
+dreamcontext federation status           # Inbox counts + per-connection sync watermarks
+dreamcontext federation sync [--dry-run] # Push (or preview) digests into consenting peers
+dreamcontext federation drain            # Ingest pending inbox entries as knowledge
+```
+
+See the [Federation](#federation) section above for the full workflow.
+
+### Desktop App (macOS)
+
+```bash
+dreamcontext app install                 # Install the desktop app to ~/Applications
+dreamcontext app update                  # Update the installed app
+dreamcontext app status                  # Show installed app version and state
+```
+
 ### Dashboard
 
 ```bash
@@ -647,8 +741,9 @@ dreamcontext install-claude-md           # Legacy alias: CLAUDE.md only
 
 ## Works With
 
-- **Claude Code**: full support via skill, 5 core sub-agents (initializer, explore, and the three RemSleep specialists — sleep-tasks, sleep-state, sleep-product), 7 hooks, plus optional pack sub-agents (council persona/synthesizer, multi-review specialists, goal-skill orchestrators)
+- **Claude Code**: full support via skill, core sub-agents (initializer, explore, the three primary RemSleep specialists — sleep-tasks, sleep-state, sleep-product — plus conditional sleep-federation and sleep-migration specialists), 7 hooks, plus optional pack sub-agents (council persona/synthesizer, multi-review specialists, goal-skill orchestrators)
 - **Codex**: project-level skills (`.agents/skills`), managed `AGENTS.md`, native `.codex/agents/*.toml`, and managed `.codex/config.toml` hooks (best-effort parity where event semantics differ)
+- **Desktop app (macOS beta)**: native Tauri 2 multi-vault launcher with in-app onboarding and the Sleepy notch quick-capture companion — wraps the same dashboard server (`dreamcontext app install`)
 - **Web Dashboard**: local UI with Kanban, Core editor, Knowledge, Features, Brain graph, Sleep tracker, and Council Hall (ships in the package)
 - **Obsidian**: `_dream_context/` can be opened as an Obsidian vault; the directory is scaffolded with curated vault settings at `dreamcontext init` time
 

package/agents/sleep-product.md

@@ -162,6 +162,24 @@ If the relevant task has `product: X` in frontmatter, the PRD MAY be product-sco
 
 ### Pass B — Knowledge
 
+#### B0. Organize — folders, grouping, and placement
+
+Before curating content, keep the knowledge store's *structure* logical. `knowledge/**/*.md` is indexed recursively (`buildKnowledgeIndex` globs `**/*.md`), so subfolders are fully recall-safe — grouping a file never hides it.
+
+**Diagrams → per-title folders (idempotent, any depth).** Preferred layout is `knowledge/diagrams/<title>/<title>.excalidraw.md` — the board plus its dark-sibling `.board.cjs`/`.json` living together. New boards often land flat (`knowledge/diagrams/<title>.excalidraw.md` next to `<title>.board.cjs`). Fold *canonical* flat boards into per-title folders every cycle:
+
+```bash
+dreamcontext migrations apply-diagrams   # idempotent: moves flat canonical boards + same-basename siblings, rewrites inbound [[wikilinks]] atomically; prints "nothing to organize" when already clean
+```
+
+Placement judgment FIRST: only canonical boards (architecture, system flows, roadmaps, durable plans a future session should recall) belong under `knowledge/diagrams/`. Scratch/exploratory/in-progress boards belong in `inbox/` or `workspace/` (dark by location — not indexed) — leave those alone; do NOT pull them into knowledge. Never hand-edit board scene JSON or wikilinks — the command owns both. This catches boards created *after* the one-time `0.7.2/diagrams-folder-convention` migration already recorded in the ledger (which `sleep-migration` will not re-fire for).
+
+**Knowledge → logical subfolders (grouping; moves are deep-only).** When ≥3 top-level `knowledge/*.md` files form a clear topical cluster a future session would browse together (mirroring the existing `data-structures/` and `products/` subfolders), group them under `knowledge/<group>/`. Moving files + rewriting links is a structural op — gate it exactly like merge-with-delete (B1.5):
+- **light/standard:** do NOT move. **Flag the cluster in your report** (`group candidate: <group>/ ← a.md, b.md, c.md`) for the next deep cycle.
+- **deep:** archive-before (the B1.5 safety net), then move the files and rewrite inbound `[[old-slug]]` references — **target token only**, preserve `|alias` and `#anchor`. Verify every file still lists: `dreamcontext knowledge index --plain`.
+
+Group only on a **sharp** topical boundary — the same B2 create-vs-extend test, applied to folders. Don't fragment (one folder per file) and don't over-nest. After any group/move, re-check the moved files' tags in Pass C so the folder and the tags tell the same story.
+
 #### B1. Decide: create, update, archive, or pin
 
 For each knowledge candidate (research finding, sleep-state flag, extracted overflow):
@@ -176,6 +194,26 @@ For each knowledge candidate (research finding, sleep-state flag, extracted over
 | Overflow extracted from core file (one-line reference left there) | `dreamcontext knowledge create <slug>` and paste the extracted content |
 | Cross-cutting finding from your own features pass | Capture inline (no need to flag — you own both domains this cycle) |
 
+#### B1.5. Depth gating — what you may actually DO this cycle
+
+Your orchestrator brief states a `depth: <light|standard|deep>`. **Destructive/expensive knowledge ops run ONLY at `deep`.** Tag every action you are about to take:
+
+| Tier | Allowed at light/standard? | Actions |
+|---|---|---|
+| **Non-destructive** | ✅ yes (any depth) | create a new file, extend an existing file, retag, flip `pinned`, tick checkboxes, append a section |
+| **Deep-only** | ❌ no — `deep` required | merge-with-delete (fold two files into one and delete the loser), summarize-and-replace still-valid detail, archive/delete a stale file |
+
+**At light/standard:** if you spot a merge or deletion candidate, do NOT act on it — **flag it in your report** ("merge candidates: `<a>` + `<b>`") so the next deep cycle (or the user via `sleep start --deep` / desktop Sleep) handles it. The agent MAY bump one tier with a stated reason if signals clearly warrant it (e.g. two exact-duplicate files at standard), but state the bump and reason explicitly in your report.
+
+**Archive-before-delete safety net (deep only, MANDATORY):** before ANY deep-tier merge-with-delete or summarize-and-replace, FIRST copy the file you are about to lose to a dated archive:
+
+```bash
+mkdir -p _dream_context/knowledge/.archive
+cp _dream_context/knowledge/<slug>.md "_dream_context/knowledge/.archive/<slug>-$(date +%Y%m%d).md"
+```
+
+The dated archive copy is the recovery net; the "Dropped-but-load-bearing self-check" report line is the audit signal. Both are required for every destructive op.
+
 #### B2. Create vs. extend — the consolidation rubric
 
 **A knowledge file is a tag-able identity, not a dumping ground.** Aim for the *fewest* files that keep each topic cleanly findable. Fragmenting one topic across many near-duplicate slugs makes tags noisy and recall worse; cramming unrelated topics into one super-file makes tags meaningless. Pick the boundary on purpose.
@@ -330,6 +368,10 @@ dreamcontext taxonomy resolve <tag>
   - 5 user stories, 5 acceptance criteria
 - No-op feature signals: 1 (signal "feature_advanced=marketing-dashboard-v0" — but PRD exists and no criteria moved)
 
+### Organization
+- Diagrams: ran `apply-diagrams` — folded knowledge/diagrams/federation.excalidraw.md (+federation.board.cjs) into diagrams/federation/ (canonical board, was flat). 0 ambiguous.
+- Knowledge grouping: group candidate flagged for deep cycle — `decisions/` ← decision-mem0-vs-bm25-recall.md, decision-link-aware-vs-embedding-recall.md, decision-meta-marketing-skill-adoption.md (4 sibling `decision-*` files browse together). Not moved (standard depth).
+
 ### Knowledge
 - Created: knowledge/jwt-rotation-policy.md (tags: security, decisions; from sleep-state flag) — sharp boundary, new tag-able topic
 - Extended (no new file): knowledge/competitive-analysis-ecc.md — folded the new ECC pricing finding into the existing file (soft distinction, same topic family) instead of forking a near-duplicate slug; updated `summary:`
@@ -341,6 +383,8 @@ dreamcontext taxonomy resolve <tag>
 - taxonomy init: no-op (core/taxonomy.json already exists)
 - audit: 2 nonCanonical tags fixed (knowledge/auth-design.md: auth → domain:security; state/task-slug.md: db → domain:database)
 - Domain Vocabulary: added 'ripple' via `taxonomy add topic:ripple`, added alias 'bookmarking' → 'topic:sleep' via `taxonomy alias bookmarking topic:sleep`
+
+Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/research finding you saw but did NOT promote into a feature/knowledge file, with the reason>
 ```
 
 ## Rules
@@ -353,6 +397,7 @@ dreamcontext taxonomy resolve <tag>
 6. **Don't create knowledge that already fits in memory.** A short technical decision belongs in `2.memory.md` (sleep-state's domain), not its own knowledge file.
 7. **Knowledge file threshold**: ≥3 paragraphs of content, or material that will be re-read in future sessions.
 8. **Fewest files, sharp boundaries (B2 rubric).** Default to extending an existing file. Fold soft distinctions in — same vertical/brand/topic family, a narrower slice, an increment. Create a new file only for a genuinely separate topic whose own tags sharpen discovery. Not super-files, not fragmentation.
+8a. **Keep the store organized (B0).** Every cycle, fold canonical flat diagram boards into per-title folders (`apply-diagrams`, idempotent, any depth). Group clustered top-level knowledge into logical subfolders only at `deep` depth (flag candidates at light/standard). Subfolders are recall-safe — the index globs `**/*.md`. Folder and tags must tell the same story.
 9. **Use standard tags only (prefer taxonomy vocab).** New tags fragment discovery; always check `dreamcontext taxonomy vocab` before tagging. Add new vocabulary via `taxonomy add` or `taxonomy alias` — never hand-edit `core/taxonomy.json` directly.
 10. **Process all flags from sleep-state** in your report — don't silently drop them.
 11. **No-op cheaply** when signals don't actually warrant work.

package/agents/sleep-state.md

@@ -189,7 +189,7 @@ dreamcontext defaults to single-person. When you have **corroborated evidence**
 **Detection gate — require ≥2 corroborated signals** before flipping a project to multi-person (this gate prevents false positives; one weak signal is never enough):
 
 - **Self-identification in user turns** — a person names themselves or another teammate ("this is Ada", "Mehmet asked me to…", "I'm covering for Lina").
-- **Distinct git authors since the epoch** — `git log --since="$CUTOFF" --format='%an <%ae>' | sort -u` returns more than one real human author (ignore bots/CI like `github-actions`, `dependabot`).
+- **Distinct git authors since the epoch** — `git log --since="$CUTOFF" --format='%an <%ae>' | sort -u` returns more than one real human author. Apply the **shared bot-filter** (drop any author whose kebab-case slug contains `github-actions` or `dependabot`) — this is the same `BOT_SLUG_FRAGMENTS` list `attributeByPerson` in `src/lib/attribution.ts` uses, so per-person attribution stays consistent with detection.
 - **Distinct voice / handoff** — the transcript shows a clear authorship handoff or a different working style/voice than the established user.
 
 ```bash
@@ -273,6 +273,8 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 
 ### Cross-domain mentions (for other specialists)
 - (none) | OR: research finding worth long-term retention — flagging for sleep-product
+
+Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/decision you saw but did NOT promote into changelog/core/2.memory.md, with the reason>
 ```
 
 ## Rules

package/agents/sleep-tasks.md

@@ -100,7 +100,7 @@ Untracked, genuinely-separate work is invisible to future sessions — always li
 
 ### 2.5. Person attribution (multi-person projects only)
 
-When the project's `.config.json` `people` array has **>1 entry**, the person responsible for a task's progress this cycle must be recorded as a `person:<slug>` tag in the task's frontmatter `tags` array. Slug is kebab-case matching the roster (e.g., `person:mehmet`, `person:ada`). Determine attribution from the same signals sleep-state uses for Pass B.5 (git `%an` on the commits, self-identification in the session transcript).
+When the project's `.config.json` `people` array has **>1 entry**, the person responsible for a task's progress this cycle must be recorded as a `person:<slug>` tag in the task's frontmatter `tags` array. Slug is kebab-case matching the roster (e.g., `person:mehmet`, `person:ada`). Determine attribution from the same signals sleep-state uses for Pass B.5 (git `%an` on the commits, self-identification in the session transcript), applying the **shared bot-filter** — drop any author whose kebab-case slug contains `github-actions` or `dependabot` (the `BOT_SLUG_FRAGMENTS` list in `src/lib/attribution.ts`, consumed by `attributeByPerson`). Never tag a task `person:github-actions`.
 
 ```bash
 # Read the current roster
@@ -139,15 +139,24 @@ A fresh session opening this task file should see the *current plan*.
 
 **Tip — recall before reconciling.** If you're unsure whether a decision observed this session was already captured elsewhere (memory entry, sibling task, knowledge file), run `dreamcontext memory recall "<topic>"` to surface the top hits across the corpus before you edit. Cheaper than grep, deterministic, and helps you avoid duplicating a decision that already lives in `2.memory.md` (which `sleep-state` owns).
 
-### 4. Status — never auto-complete
+### 4. Status — review only when genuinely needed
 
-Default rule: if work meaningfully advanced the task, bump to `in_review`:
+Pick the status that matches reality. **Do NOT reflexively bump everything to `in_review`** — that buries the few tasks that actually need the user's eyes under a pile that didn't, and leaves finished work rotting half-closed.
+
+| The task this cycle is… | Status |
+|---|---|
+| **Demonstrably done, low-risk, and already validated** — acceptance criteria met, tests green, nothing a human must second-guess (chores, docs, mechanical refactors, well-covered fixes) | `completed` — close it. |
+| **Done but it genuinely needs the user's verification** — a user-facing behaviour change, a design/architecture decision, a risky or critical-path change, or a criterion that can't be mechanically proven | `in_review` with a one-line "what to verify". |
+| **Work clearly continues next session** | leave `in_progress`. |
 
 ```bash
-dreamcontext tasks status <slug> in_review "Ready for user verification — <one-line of what's done>"
+# Done + validated + nothing to second-guess → close it:
+dreamcontext tasks status <slug> completed "<what shipped — done, validated, no review needed>"
+# A human must actually confirm something → hand it over:
+dreamcontext tasks status <slug> in_review "Needs your eyes — <the specific thing to verify>"
 ```
 
-Stay in `in_progress` only when work clearly continues next session. **Never use `completed`** — the user reviews and completes themselves.
+The single test: **would the user actually want to look at this before it's closed?** If yes → `in_review`. If it's done and there's nothing to second-guess → `completed`. When you're genuinely unsure, prefer `in_review`. Only the never-done categories below (superseded / abandoned / obsoleted) ever go to `in_review` *for closing* — that's handing the user a close decision, not a completion.
 
 ### 5. Version readiness signal (no auto-release)
 
@@ -162,45 +171,57 @@ dreamcontext tasks list --status completed
 
 If every task linked to the active version is `completed` (or only `in_review` remains), surface this in your report. Do **not** release — that's the user's call.
 
-### 6. Staleness sweep — the active list must stay honest
+### 6. Backlog grooming — the active list must stay honest
 
-An "active" backlog that nobody has touched in weeks isn't active — it bloats every SessionStart snapshot (each non-completed task costs snapshot tokens on every session) and buries the work that actually matters. Each cycle, sweep the whole active list, not just this cycle's tasks:
+A backlog that nobody has touched in weeks, or that still describes a plan we've since pivoted away from, isn't "active" — it bloats every SessionStart snapshot (each non-completed task costs snapshot tokens on every session) and buries the work that actually matters. Each cycle, groom the whole active list, not just this cycle's tasks:
 
 ```bash
 dreamcontext tasks list          # every non-completed task, with updated dates
 ```
 
-For each task whose `updated` is **21+ days old** and that no session in this cycle touched, pick one:
+**(a) Direction changes & relevance.** If this cycle revealed a pivot — a new idea, a changed plan, a dropped direction — propagate it to the backlog, don't leave stale tasks describing the old plan:
+
+| Situation | Action |
+|---|---|
+| A task is partly obsoleted by the pivot | Reconcile its body (step 3): drop the obsolete user stories / criteria, replace stale Technical Details. Keep what's still relevant. |
+| A task is **wholly** made irrelevant by the pivot | Don't silently delete. `dreamcontext tasks status <slug> in_review "obsoleted by <pivot> — confirm close"` — closing someone's planned work is the user's call. |
+| A task now belongs to a different milestone/version | Fix its `version:` frontmatter (Edit the field directly — there's no status-time version verb) so it attaches to the right planning version. |
+
+**(b) Staleness.** For each task whose `updated` is **21+ days old** and that no session in this cycle touched, pick one:
 
 | Situation | Action |
 |---|---|
-| Work was actually done but never logged | Reconcile it now (steps 3-4) — that's a capture failure, fix it. |
+| Work was actually done but never logged | Reconcile it now (steps 3-4) — that's a capture failure, fix it. If it's done + validated, `completed`; if it needs eyes, `in_review`. |
 | Superseded / absorbed by another task | Log a final entry naming the successor, then `dreamcontext tasks status <slug> in_review "superseded by <other-slug> — confirm close"`. |
 | Still genuinely planned, just not started | Leave it, but verify its priority isn't inflated — a `high` task untouched for a month is not high priority; downgrade via Edit. |
 | Abandoned / no longer relevant | `dreamcontext tasks status <slug> in_review "stale 21+ days, appears abandoned — confirm close"`. |
 
-Never silently delete a task and never auto-complete — `in_review` with an explicit reason hands the close decision to the user. List every staleness action in your report.
+**(c) Tagging.** Tags drive recall — sharpen them every cycle. Normalize every task's frontmatter `tags` to the taxonomy vocab (`dreamcontext taxonomy vocab`), and *add* missing facets (area / type / feature) where a task is under-tagged. A well-tagged backlog is found; a poorly-tagged one is re-derived blind.
+
+Never silently delete a task, and never `completed` a task that was never actually done — for superseded/abandoned/obsoleted work, `in_review` with an explicit reason hands the close decision to the user. List every grooming action in your report.
 
 ## Return — short report
 
 ```
 ## sleep-tasks report
-- Updated: <slug> (in_progress → in_review, "<reason>"), <slug> (logged)
+- Updated: <slug> (in_progress → completed, "<done, validated, no review needed>"), <slug> (in_progress → in_review, "<the specific thing the user must verify>"), <slug> (logged)
 - Folded in (no new task): <existing-slug> — broadened scope + added 2 user stories / 1 criterion for <smaller-piece> instead of forking a duplicate
 - Created: <slug> (status: in_progress, attached to vX.Y.Z) — genuinely separate concern
 - Body reconciled: <slug> (dropped phase 1 from User Stories; replaced Technical Details auth section)
 - Person attribution: <slug> tagged person:ada (multi-person project, ada drove this cycle's work) | OR: single-person project — no person tags injected
 - Version readiness: vX.Y.Z — 4/5 tasks ready for review
-- Staleness sweep: <slug> in_review ("stale 21+ days, appears abandoned"), <slug> priority high→medium (untouched 30d), 2 tasks left as-is (genuinely planned)
+- Backlog grooming: <slug> obsoleted by pivot → in_review ("confirm close"), <slug> re-attached v0.8.x→v0.9.0, <slug> tags normalized + facets added, <slug> priority high→medium (untouched 30d), 2 tasks left as-is (genuinely planned)
 - Cross-domain mentions: <slug> includes a memory-worthy decision about JWT — flagging for sleep-state
 - Skipped: <session_id> had no actionable task signal
+
+Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/task signal you saw but did NOT fold into a task changelog/body, with the reason>
 ```
 
 ## Rules
 
 1. **Dedup before creating.** Recall first; fold a smaller slice into the task that already covers it — broaden its title + insert sub-items — instead of forking a duplicate or a needless sub-task. A new task is only for a genuinely separate concern.
 2. **Body = current truth, Changelog = history.** Don't let the body lag behind decisions.
-3. **Never auto-complete.** Bump to `in_review`.
+3. **Status reflects reality, not a reflex.** `completed` for done + low-risk + already-validated work; `in_review` only when a human genuinely must verify something (or to hand over a close decision on superseded/abandoned/obsoleted work). Never `completed` a task that was never actually done; never silently delete.
 4. **Always attach to a planning version.** No orphan work.
 5. **Stay in your lane.** If you spot non-task work worth preserving, flag it — don't write it.
 6. **CLI first** for status/log/insert; **Edit** for surgical body reconciliation (including broadening `description:` / `## Why` when scope grows).

package/dist/agents/sleep-product.md

@@ -162,6 +162,24 @@ If the relevant task has `product: X` in frontmatter, the PRD MAY be product-sco
 
 ### Pass B — Knowledge
 
+#### B0. Organize — folders, grouping, and placement
+
+Before curating content, keep the knowledge store's *structure* logical. `knowledge/**/*.md` is indexed recursively (`buildKnowledgeIndex` globs `**/*.md`), so subfolders are fully recall-safe — grouping a file never hides it.
+
+**Diagrams → per-title folders (idempotent, any depth).** Preferred layout is `knowledge/diagrams/<title>/<title>.excalidraw.md` — the board plus its dark-sibling `.board.cjs`/`.json` living together. New boards often land flat (`knowledge/diagrams/<title>.excalidraw.md` next to `<title>.board.cjs`). Fold *canonical* flat boards into per-title folders every cycle:
+
+```bash
+dreamcontext migrations apply-diagrams   # idempotent: moves flat canonical boards + same-basename siblings, rewrites inbound [[wikilinks]] atomically; prints "nothing to organize" when already clean
+```
+
+Placement judgment FIRST: only canonical boards (architecture, system flows, roadmaps, durable plans a future session should recall) belong under `knowledge/diagrams/`. Scratch/exploratory/in-progress boards belong in `inbox/` or `workspace/` (dark by location — not indexed) — leave those alone; do NOT pull them into knowledge. Never hand-edit board scene JSON or wikilinks — the command owns both. This catches boards created *after* the one-time `0.7.2/diagrams-folder-convention` migration already recorded in the ledger (which `sleep-migration` will not re-fire for).
+
+**Knowledge → logical subfolders (grouping; moves are deep-only).** When ≥3 top-level `knowledge/*.md` files form a clear topical cluster a future session would browse together (mirroring the existing `data-structures/` and `products/` subfolders), group them under `knowledge/<group>/`. Moving files + rewriting links is a structural op — gate it exactly like merge-with-delete (B1.5):
+- **light/standard:** do NOT move. **Flag the cluster in your report** (`group candidate: <group>/ ← a.md, b.md, c.md`) for the next deep cycle.
+- **deep:** archive-before (the B1.5 safety net), then move the files and rewrite inbound `[[old-slug]]` references — **target token only**, preserve `|alias` and `#anchor`. Verify every file still lists: `dreamcontext knowledge index --plain`.
+
+Group only on a **sharp** topical boundary — the same B2 create-vs-extend test, applied to folders. Don't fragment (one folder per file) and don't over-nest. After any group/move, re-check the moved files' tags in Pass C so the folder and the tags tell the same story.
+
 #### B1. Decide: create, update, archive, or pin
 
 For each knowledge candidate (research finding, sleep-state flag, extracted overflow):
@@ -176,6 +194,26 @@ For each knowledge candidate (research finding, sleep-state flag, extracted over
 | Overflow extracted from core file (one-line reference left there) | `dreamcontext knowledge create <slug>` and paste the extracted content |
 | Cross-cutting finding from your own features pass | Capture inline (no need to flag — you own both domains this cycle) |
 
+#### B1.5. Depth gating — what you may actually DO this cycle
+
+Your orchestrator brief states a `depth: <light|standard|deep>`. **Destructive/expensive knowledge ops run ONLY at `deep`.** Tag every action you are about to take:
+
+| Tier | Allowed at light/standard? | Actions |
+|---|---|---|
+| **Non-destructive** | ✅ yes (any depth) | create a new file, extend an existing file, retag, flip `pinned`, tick checkboxes, append a section |
+| **Deep-only** | ❌ no — `deep` required | merge-with-delete (fold two files into one and delete the loser), summarize-and-replace still-valid detail, archive/delete a stale file |
+
+**At light/standard:** if you spot a merge or deletion candidate, do NOT act on it — **flag it in your report** ("merge candidates: `<a>` + `<b>`") so the next deep cycle (or the user via `sleep start --deep` / desktop Sleep) handles it. The agent MAY bump one tier with a stated reason if signals clearly warrant it (e.g. two exact-duplicate files at standard), but state the bump and reason explicitly in your report.
+
+**Archive-before-delete safety net (deep only, MANDATORY):** before ANY deep-tier merge-with-delete or summarize-and-replace, FIRST copy the file you are about to lose to a dated archive:
+
+```bash
+mkdir -p _dream_context/knowledge/.archive
+cp _dream_context/knowledge/<slug>.md "_dream_context/knowledge/.archive/<slug>-$(date +%Y%m%d).md"
+```
+
+The dated archive copy is the recovery net; the "Dropped-but-load-bearing self-check" report line is the audit signal. Both are required for every destructive op.
+
 #### B2. Create vs. extend — the consolidation rubric
 
 **A knowledge file is a tag-able identity, not a dumping ground.** Aim for the *fewest* files that keep each topic cleanly findable. Fragmenting one topic across many near-duplicate slugs makes tags noisy and recall worse; cramming unrelated topics into one super-file makes tags meaningless. Pick the boundary on purpose.
@@ -330,6 +368,10 @@ dreamcontext taxonomy resolve <tag>
   - 5 user stories, 5 acceptance criteria
 - No-op feature signals: 1 (signal "feature_advanced=marketing-dashboard-v0" — but PRD exists and no criteria moved)
 
+### Organization
+- Diagrams: ran `apply-diagrams` — folded knowledge/diagrams/federation.excalidraw.md (+federation.board.cjs) into diagrams/federation/ (canonical board, was flat). 0 ambiguous.
+- Knowledge grouping: group candidate flagged for deep cycle — `decisions/` ← decision-mem0-vs-bm25-recall.md, decision-link-aware-vs-embedding-recall.md, decision-meta-marketing-skill-adoption.md (4 sibling `decision-*` files browse together). Not moved (standard depth).
+
 ### Knowledge
 - Created: knowledge/jwt-rotation-policy.md (tags: security, decisions; from sleep-state flag) — sharp boundary, new tag-able topic
 - Extended (no new file): knowledge/competitive-analysis-ecc.md — folded the new ECC pricing finding into the existing file (soft distinction, same topic family) instead of forking a near-duplicate slug; updated `summary:`
@@ -341,6 +383,8 @@ dreamcontext taxonomy resolve <tag>
 - taxonomy init: no-op (core/taxonomy.json already exists)
 - audit: 2 nonCanonical tags fixed (knowledge/auth-design.md: auth → domain:security; state/task-slug.md: db → domain:database)
 - Domain Vocabulary: added 'ripple' via `taxonomy add topic:ripple`, added alias 'bookmarking' → 'topic:sleep' via `taxonomy alias bookmarking topic:sleep`
+
+Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/research finding you saw but did NOT promote into a feature/knowledge file, with the reason>
 ```
 
 ## Rules
@@ -353,6 +397,7 @@ dreamcontext taxonomy resolve <tag>
 6. **Don't create knowledge that already fits in memory.** A short technical decision belongs in `2.memory.md` (sleep-state's domain), not its own knowledge file.
 7. **Knowledge file threshold**: ≥3 paragraphs of content, or material that will be re-read in future sessions.
 8. **Fewest files, sharp boundaries (B2 rubric).** Default to extending an existing file. Fold soft distinctions in — same vertical/brand/topic family, a narrower slice, an increment. Create a new file only for a genuinely separate topic whose own tags sharpen discovery. Not super-files, not fragmentation.
+8a. **Keep the store organized (B0).** Every cycle, fold canonical flat diagram boards into per-title folders (`apply-diagrams`, idempotent, any depth). Group clustered top-level knowledge into logical subfolders only at `deep` depth (flag candidates at light/standard). Subfolders are recall-safe — the index globs `**/*.md`. Folder and tags must tell the same story.
 9. **Use standard tags only (prefer taxonomy vocab).** New tags fragment discovery; always check `dreamcontext taxonomy vocab` before tagging. Add new vocabulary via `taxonomy add` or `taxonomy alias` — never hand-edit `core/taxonomy.json` directly.
 10. **Process all flags from sleep-state** in your report — don't silently drop them.
 11. **No-op cheaply** when signals don't actually warrant work.

package/dist/agents/sleep-state.md

@@ -189,7 +189,7 @@ dreamcontext defaults to single-person. When you have **corroborated evidence**
 **Detection gate — require ≥2 corroborated signals** before flipping a project to multi-person (this gate prevents false positives; one weak signal is never enough):
 
 - **Self-identification in user turns** — a person names themselves or another teammate ("this is Ada", "Mehmet asked me to…", "I'm covering for Lina").
-- **Distinct git authors since the epoch** — `git log --since="$CUTOFF" --format='%an <%ae>' | sort -u` returns more than one real human author (ignore bots/CI like `github-actions`, `dependabot`).
+- **Distinct git authors since the epoch** — `git log --since="$CUTOFF" --format='%an <%ae>' | sort -u` returns more than one real human author. Apply the **shared bot-filter** (drop any author whose kebab-case slug contains `github-actions` or `dependabot`) — this is the same `BOT_SLUG_FRAGMENTS` list `attributeByPerson` in `src/lib/attribution.ts` uses, so per-person attribution stays consistent with detection.
 - **Distinct voice / handoff** — the transcript shows a clear authorship handoff or a different working style/voice than the established user.
 
 ```bash
@@ -273,6 +273,8 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 
 ### Cross-domain mentions (for other specialists)
 - (none) | OR: research finding worth long-term retention — flagging for sleep-product
+
+Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/decision you saw but did NOT promote into changelog/core/2.memory.md, with the reason>
 ```
 
 ## Rules

package/dist/agents/sleep-tasks.md

@@ -100,7 +100,7 @@ Untracked, genuinely-separate work is invisible to future sessions — always li
 
 ### 2.5. Person attribution (multi-person projects only)
 
-When the project's `.config.json` `people` array has **>1 entry**, the person responsible for a task's progress this cycle must be recorded as a `person:<slug>` tag in the task's frontmatter `tags` array. Slug is kebab-case matching the roster (e.g., `person:mehmet`, `person:ada`). Determine attribution from the same signals sleep-state uses for Pass B.5 (git `%an` on the commits, self-identification in the session transcript).
+When the project's `.config.json` `people` array has **>1 entry**, the person responsible for a task's progress this cycle must be recorded as a `person:<slug>` tag in the task's frontmatter `tags` array. Slug is kebab-case matching the roster (e.g., `person:mehmet`, `person:ada`). Determine attribution from the same signals sleep-state uses for Pass B.5 (git `%an` on the commits, self-identification in the session transcript), applying the **shared bot-filter** — drop any author whose kebab-case slug contains `github-actions` or `dependabot` (the `BOT_SLUG_FRAGMENTS` list in `src/lib/attribution.ts`, consumed by `attributeByPerson`). Never tag a task `person:github-actions`.
 
 ```bash
 # Read the current roster
@@ -139,15 +139,24 @@ A fresh session opening this task file should see the *current plan*.
 
 **Tip — recall before reconciling.** If you're unsure whether a decision observed this session was already captured elsewhere (memory entry, sibling task, knowledge file), run `dreamcontext memory recall "<topic>"` to surface the top hits across the corpus before you edit. Cheaper than grep, deterministic, and helps you avoid duplicating a decision that already lives in `2.memory.md` (which `sleep-state` owns).
 
-### 4. Status — never auto-complete
+### 4. Status — review only when genuinely needed
 
-Default rule: if work meaningfully advanced the task, bump to `in_review`:
+Pick the status that matches reality. **Do NOT reflexively bump everything to `in_review`** — that buries the few tasks that actually need the user's eyes under a pile that didn't, and leaves finished work rotting half-closed.
+
+| The task this cycle is… | Status |
+|---|---|
+| **Demonstrably done, low-risk, and already validated** — acceptance criteria met, tests green, nothing a human must second-guess (chores, docs, mechanical refactors, well-covered fixes) | `completed` — close it. |
+| **Done but it genuinely needs the user's verification** — a user-facing behaviour change, a design/architecture decision, a risky or critical-path change, or a criterion that can't be mechanically proven | `in_review` with a one-line "what to verify". |
+| **Work clearly continues next session** | leave `in_progress`. |
 
 ```bash
-dreamcontext tasks status <slug> in_review "Ready for user verification — <one-line of what's done>"
+# Done + validated + nothing to second-guess → close it:
+dreamcontext tasks status <slug> completed "<what shipped — done, validated, no review needed>"
+# A human must actually confirm something → hand it over:
+dreamcontext tasks status <slug> in_review "Needs your eyes — <the specific thing to verify>"
 ```
 
-Stay in `in_progress` only when work clearly continues next session. **Never use `completed`** — the user reviews and completes themselves.
+The single test: **would the user actually want to look at this before it's closed?** If yes → `in_review`. If it's done and there's nothing to second-guess → `completed`. When you're genuinely unsure, prefer `in_review`. Only the never-done categories below (superseded / abandoned / obsoleted) ever go to `in_review` *for closing* — that's handing the user a close decision, not a completion.
 
 ### 5. Version readiness signal (no auto-release)
 
@@ -162,45 +171,57 @@ dreamcontext tasks list --status completed
 
 If every task linked to the active version is `completed` (or only `in_review` remains), surface this in your report. Do **not** release — that's the user's call.
 
-### 6. Staleness sweep — the active list must stay honest
+### 6. Backlog grooming — the active list must stay honest
 
-An "active" backlog that nobody has touched in weeks isn't active — it bloats every SessionStart snapshot (each non-completed task costs snapshot tokens on every session) and buries the work that actually matters. Each cycle, sweep the whole active list, not just this cycle's tasks:
+A backlog that nobody has touched in weeks, or that still describes a plan we've since pivoted away from, isn't "active" — it bloats every SessionStart snapshot (each non-completed task costs snapshot tokens on every session) and buries the work that actually matters. Each cycle, groom the whole active list, not just this cycle's tasks:
 
 ```bash
 dreamcontext tasks list          # every non-completed task, with updated dates
 ```
 
-For each task whose `updated` is **21+ days old** and that no session in this cycle touched, pick one:
+**(a) Direction changes & relevance.** If this cycle revealed a pivot — a new idea, a changed plan, a dropped direction — propagate it to the backlog, don't leave stale tasks describing the old plan:
+
+| Situation | Action |
+|---|---|
+| A task is partly obsoleted by the pivot | Reconcile its body (step 3): drop the obsolete user stories / criteria, replace stale Technical Details. Keep what's still relevant. |
+| A task is **wholly** made irrelevant by the pivot | Don't silently delete. `dreamcontext tasks status <slug> in_review "obsoleted by <pivot> — confirm close"` — closing someone's planned work is the user's call. |
+| A task now belongs to a different milestone/version | Fix its `version:` frontmatter (Edit the field directly — there's no status-time version verb) so it attaches to the right planning version. |
+
+**(b) Staleness.** For each task whose `updated` is **21+ days old** and that no session in this cycle touched, pick one:
 
 | Situation | Action |
 |---|---|
-| Work was actually done but never logged | Reconcile it now (steps 3-4) — that's a capture failure, fix it. |
+| Work was actually done but never logged | Reconcile it now (steps 3-4) — that's a capture failure, fix it. If it's done + validated, `completed`; if it needs eyes, `in_review`. |
 | Superseded / absorbed by another task | Log a final entry naming the successor, then `dreamcontext tasks status <slug> in_review "superseded by <other-slug> — confirm close"`. |
 | Still genuinely planned, just not started | Leave it, but verify its priority isn't inflated — a `high` task untouched for a month is not high priority; downgrade via Edit. |
 | Abandoned / no longer relevant | `dreamcontext tasks status <slug> in_review "stale 21+ days, appears abandoned — confirm close"`. |
 
-Never silently delete a task and never auto-complete — `in_review` with an explicit reason hands the close decision to the user. List every staleness action in your report.
+**(c) Tagging.** Tags drive recall — sharpen them every cycle. Normalize every task's frontmatter `tags` to the taxonomy vocab (`dreamcontext taxonomy vocab`), and *add* missing facets (area / type / feature) where a task is under-tagged. A well-tagged backlog is found; a poorly-tagged one is re-derived blind.
+
+Never silently delete a task, and never `completed` a task that was never actually done — for superseded/abandoned/obsoleted work, `in_review` with an explicit reason hands the close decision to the user. List every grooming action in your report.
 
 ## Return — short report
 
 ```
 ## sleep-tasks report
-- Updated: <slug> (in_progress → in_review, "<reason>"), <slug> (logged)
+- Updated: <slug> (in_progress → completed, "<done, validated, no review needed>"), <slug> (in_progress → in_review, "<the specific thing the user must verify>"), <slug> (logged)
 - Folded in (no new task): <existing-slug> — broadened scope + added 2 user stories / 1 criterion for <smaller-piece> instead of forking a duplicate
 - Created: <slug> (status: in_progress, attached to vX.Y.Z) — genuinely separate concern
 - Body reconciled: <slug> (dropped phase 1 from User Stories; replaced Technical Details auth section)
 - Person attribution: <slug> tagged person:ada (multi-person project, ada drove this cycle's work) | OR: single-person project — no person tags injected
 - Version readiness: vX.Y.Z — 4/5 tasks ready for review
-- Staleness sweep: <slug> in_review ("stale 21+ days, appears abandoned"), <slug> priority high→medium (untouched 30d), 2 tasks left as-is (genuinely planned)
+- Backlog grooming: <slug> obsoleted by pivot → in_review ("confirm close"), <slug> re-attached v0.8.x→v0.9.0, <slug> tags normalized + facets added, <slug> priority high→medium (untouched 30d), 2 tasks left as-is (genuinely planned)
 - Cross-domain mentions: <slug> includes a memory-worthy decision about JWT — flagging for sleep-state
 - Skipped: <session_id> had no actionable task signal
+
+Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/task signal you saw but did NOT fold into a task changelog/body, with the reason>
 ```
 
 ## Rules
 
 1. **Dedup before creating.** Recall first; fold a smaller slice into the task that already covers it — broaden its title + insert sub-items — instead of forking a duplicate or a needless sub-task. A new task is only for a genuinely separate concern.
 2. **Body = current truth, Changelog = history.** Don't let the body lag behind decisions.
-3. **Never auto-complete.** Bump to `in_review`.
+3. **Status reflects reality, not a reflex.** `completed` for done + low-risk + already-validated work; `in_review` only when a human genuinely must verify something (or to hand over a close decision on superseded/abandoned/obsoleted work). Never `completed` a task that was never actually done; never silently delete.
 4. **Always attach to a planning version.** No orphan work.
 5. **Stay in your lane.** If you spot non-task work worth preserving, flag it — don't write it.
 6. **CLI first** for status/log/insert; **Edit** for surgical body reconciliation (including broadening `description:` / `## Why` when scope grows).

package/dist/dashboard/assets/{BrainCanvas3D-CNDjMlun.js → BrainCanvas3D-D8PjCqhM.js}

@@ -1,4 +1,4 @@
-import{bt as jc,bu as I0,aH as pS,bv as xt,bw as Ip,bx as mS,by as gS,bz as _S,bA as xS,bB as yS,bq as vS,br as bS,bC as B0,aC as SS,bD as TS,bE as MS,bF as ES,bG as xg,bH as yg,bI as AS,bJ as k,bK as $s,bL as wS,bM as RS,bN as CS,bO as NS}from"./index-C9VT2u9E.js";import{_ as Bi}from"./extends-CF3RwP-h.js";function PS(r){var e=jc(.1),t,n,i;typeof r!="function"&&(r=jc(r==null?0:+r));function s(a){for(var l=0,c=t.length,u;l<c;++l)u=t[l],u.vz+=(i[l]-u.z)*n[l]*a}function o(){if(t){var a,l=t.length;for(n=new Array(l),i=new Array(l),a=0;a<l;++a)n[a]=isNaN(i[a]=+r(t[a],a,t))?0:+e(t[a],a,t)}}return s.initialize=function(a){t=a,o()},s.strength=function(a){return arguments.length?(e=typeof a=="function"?a:jc(+a),o(),s):e},s.z=function(a){return arguments.length?(r=typeof a=="function"?a:jc(+a),o(),s):r},s}/**
+import{bt as jc,bu as I0,aH as pS,bv as xt,bw as Ip,bx as mS,by as gS,bz as _S,bA as xS,bB as yS,bq as vS,br as bS,bC as B0,aC as SS,bD as TS,bE as MS,bF as ES,bG as xg,bH as yg,bI as AS,bJ as k,bK as $s,bL as wS,bM as RS,bN as CS,bO as NS}from"./index-CPZ-rEGO.js";import{_ as Bi}from"./extends-CF3RwP-h.js";function PS(r){var e=jc(.1),t,n,i;typeof r!="function"&&(r=jc(r==null?0:+r));function s(a){for(var l=0,c=t.length,u;l<c;++l)u=t[l],u.vz+=(i[l]-u.z)*n[l]*a}function o(){if(t){var a,l=t.length;for(n=new Array(l),i=new Array(l),a=0;a<l;++a)n[a]=isNaN(i[a]=+r(t[a],a,t))?0:+e(t[a],a,t)}}return s.initialize=function(a){t=a,o()},s.strength=function(a){return arguments.length?(e=typeof a=="function"?a:jc(+a),o(),s):e},s.z=function(a){return arguments.length?(r=typeof a=="function"?a:jc(+a),o(),s):r},s}/**
  * @license
  * Copyright 2010-2026 Three.js Authors
  * SPDX-License-Identifier: MIT