dreamcontext 0.9.1 → 0.10.0

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

@@ -122,6 +122,11 @@ dreamcontext tasks status <slug> in_progress "plan validated; implementing"
 
 If `<slug>` already exists, de-collide (append a short suffix) rather than clobbering.
 
+If the project declares **custom task fields** (`_dream_context/overrides/task.md`), `tasks create`
+hard-fails (exit 1) on an unset `required` field — set each with `--field key=value` on create. For
+any field marked `ask: true`, ask the user for the value back in Phase 0 (it's a human judgment) rather
+than fabricating it. The SubagentStart briefing lists the active fields and their prompts.
+
 ### Phase 4 — IMPLEMENT
 
 Dispatch **one** `goal-implementer` (sonnet; escalate to opus for genuinely hard goals)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dreamcontext",
-  "version": "0.9.1",
+  "version": "0.10.0",
   "description": "dreamcontext — the persistent brain for your AI agents. Remembers what you built, knows how your project works.",
   "type": "module",
   "bin": {
@@ -11,6 +11,7 @@
     "skill",
     "skill-initializer",
     "skill-curator",
+    "skill-deep-research",
     "skill-packs",
     "agents",
     "README.md",
@@ -51,14 +52,19 @@
     "commander": "^13.1.0",
     "fast-glob": "^3.3.3",
     "gray-matter": "^4.0.3",
-    "nanoid": "^5.1.2"
+    "nanoid": "^5.1.2",
+    "ws": "^8.21.0"
   },
   "devDependencies": {
     "@playwright/test": "^1.60.0",
     "@types/node": "^22.13.4",
+    "@types/ws": "^8.18.1",
     "sharp": "^0.34.5",
     "tsup": "^8.4.0",
     "typescript": "^5.7.3",
     "vitest": "^3.0.6"
+  },
+  "optionalDependencies": {
+    "node-pty": "^1.1.0"
   }
 }

package/skill/SKILL.md

@@ -75,7 +75,7 @@ dreamcontext is **more than memory files**. Every capability below is real and s
 | Capability | What it is | Reference |
 |---|---|---|
 | **Structured memory** | soul/user/memory + knowledge + tasks, auto-loaded each session | this file |
-| **Tasks** | Working documents with changelog, RICE, due dates, status lifecycle, assignees | [tasks-and-features.md](references/tasks-and-features.md) |
+| **Tasks** | Working documents with changelog, RICE, status lifecycle, start/due date ranges, resolved assignees, and project-declared custom fields (`overrides/task.md`) | [tasks-and-features.md](references/tasks-and-features.md) |
 | **Features (PRDs)** | Retrospective product docs, updated only during sleep | [tasks-and-features.md](references/tasks-and-features.md) |
 | **Knowledge** | Tagged deep docs, pinning, staleness, Excalidraw diagrams | [knowledge-and-recall.md](references/knowledge-and-recall.md) |
 | **Memory recall** | Haiku/BM25 search over the whole corpus; auto-injected on prompts | [knowledge-and-recall.md](references/knowledge-and-recall.md) |
@@ -196,7 +196,7 @@ When in doubt about a command or flag, open [cli-reference.md](references/cli-re
 
 10. **Use `dreamcontext-explore`, not `Explore`.** The default Explore agent is blocked via a PreToolUse hook. `dreamcontext-explore` checks curated context first, saving thousands of tokens.
 
-11. **Tag before you create.** Before tagging a task/feature/knowledge, consult `dreamcontext taxonomy vocab` and reuse canonical faceted tags (`topic:recall`, `domain:security`) before inventing new ones. Fragmenting tags degrades recall.
+11. **Tag before you create.** Before tagging a task/feature/knowledge, consult `dreamcontext taxonomy vocab` and reuse canonical faceted tags (`topic:recall`, `domain:security`) before inventing new ones. Fragmenting tags degrades recall. To heal accumulated drift in one shot, run `dreamcontext taxonomy audit --fix` (bulk-normalizes alias/normalizable tags to canonical across the corpus — safe, idempotent, `--dry-run` to preview; orphans are reported, never guessed).
 
 12. **Be surgical.** Only touch what changed. ~150-line soft limit on context files — extract detail to knowledge, keep a summary + reference. LIFO inserts go at the top (CHANGELOG, task changelog, constraint sections).
 
@@ -280,6 +280,8 @@ dreamcontext tasks complete <name> "summary"                             # done
 
 Status: `todo → in_progress → in_review → completed`. Sections: `why`, `user_stories`, `acceptance_criteria`, `constraints`, `technical_details`, `notes`, `changelog`.
 
+**Custom fields (if this project declares them).** When `_dream_context/overrides/task.md` exists, every task carries project-defined custom fields. Their **values are surfaced to you inline** — in the snapshot's Active Tasks block and in `dreamcontext tasks list --long` — so you can see them without opening the file; unset **required** fields show as `⚠ UNSET (required)`. When you create or reconcile a task, **set every declared field** (`dreamcontext tasks field <slug> <key> <value>` or `tasks create --field key=value`). **REQUIRED fields are mandatory — never create or complete a task with a required field left empty.** Fields marked **[ASK THE USER]** (`ask: true`) capture a human judgment (e.g. a time estimate) — **ask the user for the value when creating the task instead of guessing it.** The full schema + sync behavior → [tasks-and-features.md](references/tasks-and-features.md).
+
 **RICE, due dates, tags/people, the Workflow flowchart, versioning, and multi-product** → [tasks-and-features.md](references/tasks-and-features.md).
 **Syncing tasks to a cloud backend (ClickUp _or_ GitHub — one at a time)** → [integrations.md](references/integrations.md).
 
@@ -299,7 +301,8 @@ Status: `todo → in_progress → in_review → completed`. Sections: `why`, `us
 
 ## Sub-Agents
 
-- **`dreamcontext-explore`** — context-accelerated codebase exploration. Use for ALL exploration (default Explore is blocked). Uses the SubagentStart briefing to narrow searches.
+- **`dreamcontext-explore`** — context-accelerated codebase exploration. Use for ALL exploration (default Explore is blocked). Uses the SubagentStart briefing to narrow searches. It is the **fast, single-pass** searcher — one agent, tight budget, one answer.
+- **`dreamcontext-deep-research` skill** — the **iterative, sub-agent-driven corpus-synthesis** orchestrator: the heavy counterpart to `dreamcontext-explore`. Invoke it via the `Skill` tool (or `/dreamcontext-deep-research`) when a question needs **synthesis across a large or multi-project / federated corpus** and one explore pass comes back thin or fragmented — "synthesize/reconcile everything we know about X across my vaults", "deep dive and cite it", "explore is too shallow for this". It fans out parallel `dreamcontext-explore` searchers over the whole curated corpus **and connected peer vaults**, adversarially verifies the load-bearing claims, and returns a **synthesized, cited** report — not raw hits. Read-only. **Escalation rule:** start with `dreamcontext-explore`; escalate to deep-research when one pass and one answer leave a cross-corpus question half-answered. Don't fan out a 10-agent research run at a tiny single-project brain.
 - **`initializer` skill** — the **interactive, sub-agent-driven brain bootstrap**. Invoke it via the `Skill` tool when this project has **no `_dream_context/`** or a **sparse** one (empty `knowledge/`, zero features, untouched template stubs). It orchestrates scout → confirm-hierarchy → progressive ingest → verify, migrating whatever material the user has into the proper knowledge/feature/task hierarchy. It drives its own sub-agents (`initializer-scout`, `initializer-ingestor`, `initializer-verifier`) and handles codebase-only repos too (a light scout + ingest pass) — there is no separate bootstrap agent.
 - **Sleep specialists** (`sleep-tasks`, `sleep-state`, `sleep-product`, `sleep-migration`) — dispatched by the main agent during the sleep flow only.
 
@@ -343,9 +346,12 @@ _dream_context/
 │   │   └── <title>/<title>.excalidraw.md  ← diagrams live INSIDE their context folder
 │   ├── data-structures/{default,<product>}.md   ← schemas (recall-indexed; ```sql body)
 │   └── products/<product>.md         ← per-product knowledge (multi-product)
+├── overrides/
+│   └── task.md                       ← OPTIONAL: project task template + custom_fields schema (briefed to agents)
 ├── state/
-│   ├── <task>.md                     ← Active tasks (frontmatter may include product:)
+│   ├── <task>.md                     ← Active tasks (frontmatter may include product:, start_date, due_date, custom_fields)
 │   ├── .config.json                  ← platforms, packs, multiProduct, taskBackend, people…
+│   ├── .active-version.json          ← current sprint (active planning version)
 │   ├── .sleep.json  .secrets.json (gitignored)  .active-task
 ```
 

package/skill/references/cli-reference.md

@@ -36,19 +36,22 @@ Every command and flag, grouped. All commands are prefixed with `dreamcontext`.
 |---|---|
 | `tasks list` | List/filter/group tasks (excludes completed by default). Flags: `-s/--status`, `-a/--all`, `--tag <t>` (repeatable, AND), `--any-tag <t>` (repeatable, OR), `--version <id>`, `--priority <level>`, `--feature <slug>`, `-g/--group-by tag\|version\|priority\|status`, `--long`, `--tags`, `--json`. Filters compose (AND), case-insensitive. |
 | `tasks tags` | Distinct task tags with counts. `-a/--all`, `--json`. |
-| `tasks create <name>` | Create a task. Flags: `-d/--description`, `-p/--priority critical\|high\|medium\|low`, `-u/--urgency …`, `-s/--status`, `-t/--tags <csv>`, `-w/--why`, `-v/--version`, `--person <name>`, `--reach <1-10>`, `--impact <1-5>`, `--confidence 25\|50\|75\|100`, `--effort <weeks>`, `--due YYYY-MM-DD`. |
+| `tasks create <name>` | Create a task. Flags: `-d/--description`, `-p/--priority critical\|high\|medium\|low`, `-u/--urgency …`, `-s/--status`, `-t/--tags <csv>`, `-w/--why`, `-v/--version`, `--person <name>`, `--reach <1-10>`, `--impact <1-5>`, `--confidence 25\|50\|75\|100`, `--effort <weeks>`, `--start YYYY-MM-DD`, `--due YYYY-MM-DD`, `--field <key=value>` (repeatable; sets declared custom fields), `--allow-missing-required` (create a draft even when a required custom field is unset). **Fails** if a required custom field is unset and `--allow-missing-required` is not given. |
 | `tasks rice <name>` | Print or update RICE values. `--reach`/`--impact`/`--confidence`/`--effort`, `--clear`. |
-| `tasks due <name> <YYYY-MM-DD\|clear>` | Set or clear a due date. |
+| `tasks start <name> <YYYY-MM-DD\|clear>` | Set or clear a planned start date (range start). Must be ≤ the due date; setting it removes the `backlog` tag. |
+| `tasks due <name> <YYYY-MM-DD\|clear>` | Set or clear a due/end date (range end). |
 | `tasks tag <name> <tags...>` | Add (or `--remove`) tags. `person:<slug>` assigns a person. |
+| `tasks field <name> <key> [value\|clear]` | Set or clear a user-defined custom field declared in `overrides/task.md` (synced to ClickUp/GitHub). Validates select options + number types. |
 | `tasks insert <name> <section> <content...>` | Insert into a section: `why`, `user_stories`, `acceptance_criteria`, `constraints`, `technical_details`, `notes`, `changelog`. |
 | `tasks log <name> [content...]` | Add a changelog entry (cross-session continuity). **Use every session.** |
-| `tasks status <name> <todo\|in_progress\|in_review\|completed> [reason...]` | Change status (logs to changelog). |
+| `tasks status <name> <todo\|in_progress\|in_review\|completed> [reason...]` | Change status (logs to changelog). On the first move to `in_progress`, stamps `start_date` with today if it is unset (a planned start is never overwritten). |
 | `tasks complete <name> [summary...]` | Mark completed (convenience). |
 | `tasks delete <name>` | Delete a task (propagates to remote backend on sync). `--yes`. |
-| `tasks doctor [name]` | Validate the Workflow flowchart is in sync with Acceptance Criteria (all tasks if name omitted). |
-| `tasks sync [push\|pull\|both]` | Sync with the remote backend (no-op on local). `--hook`, `--json`. |
+| `tasks rename <name> <new-name>` | Rename a task: rewrites the name, moves the file to the new slug, and re-keys the sync mapping by the stable dcId so the **same** remote task/issue is updated on next sync — never duplicated. Use this instead of hand-editing `name:` + renaming the file. |
+| `tasks doctor [name]` | Validate the Workflow flowchart is in sync with Acceptance Criteria (all tasks if name omitted). `--remote` also checks the remote backend for assignee drift (needs a token). |
+| `tasks sync [push\|pull\|both]` | Sync with the remote backend (no-op on local). `--hook`, `--reconcile` (heal pre-existing assignee drift below the watermark — #78), `--json`. |
 | `tasks members` | People with access to the remote list (assignee candidates). `--json`. |
-| `tasks provision` | Create recommended custom fields on the remote list. |
+| `tasks provision` | Create recommended + override-declared custom fields on the remote backend (ClickUp list fields / GitHub labels). Reuses any that already exist by name. |
 | `tasks sync-hooks install\|uninstall` | Manage best-effort git sync triggers (post-commit, pre-push). |
 
 Sections for `tasks insert`: `why`, `user_stories`, `acceptance_criteria`, `constraints`, `technical_details`, `notes`, `changelog`. See [tasks-and-features.md](tasks-and-features.md) for the full protocol.
@@ -140,6 +143,7 @@ See [sleep.md](sleep.md) for the full flow.
 |---|---|
 | `taxonomy vocab` | Show the resolved vocabulary (defaults + `core/taxonomy.json`). `--json`, `--facet <facet>`. |
 | `taxonomy audit` | Audit corpus tags against the vocabulary (read-only). `--json`. |
+| `taxonomy audit --fix` | **Bulk-normalize** alias/normalizable tags → canonical faceted form across every knowledge/feature/task file. Safe + idempotent: already-canonical tags are untouched; orphan tags with no alias/canonical target are reported, never guessed. `--dry-run` previews the rewrite plan and writes nothing; `--json` for automation. Workflow is alias-then-fix: teach a mapping with `taxonomy alias`, then `audit --fix`. |
 | `taxonomy init` | Scaffold `core/taxonomy.json` (idempotent). |
 | `taxonomy add <tag>` | Add a tag to the vocabulary. |
 | `taxonomy alias <alias> <canonical>` | Add an alias→canonical mapping. |

package/skill/references/integrations.md

@@ -15,8 +15,9 @@ This reference covers everything beyond the local markdown brain. **If a user as
 #### What it does
 - **Bidirectional sync** (`push`, `pull`, or `both`) between local task files and a ClickUp list.
 - **Status mapping** between dreamcontext statuses (`todo/in_progress/in_review/completed`) and ClickUp statuses.
-- **RICE + custom fields**: provisions recommended ClickUp custom fields (urgency, summary, RICE reach/impact/confidence/effort, …) and round-trips them.
-- **Assignees**: `person:<slug>` tags map to ClickUp member IDs bidirectionally (multi-assignee; the full `assignees[]` set survives push/pull). See "People & assignees" in [tasks-and-features.md](tasks-and-features.md).
+- **RICE + custom fields**: provisions recommended ClickUp custom fields (urgency, summary, RICE reach/impact/confidence/effort, …) and round-trips them. **User-declared custom fields** (from `overrides/task.md`) also round-trip — `select` → native drop_down, others → native list field. See "Task format & custom-field overrides" in [tasks-and-features.md](tasks-and-features.md).
+- **Date ranges**: a task's planned `start` and `due`/end both map to ClickUp's native start/due fields (push, pull, LWW-merge, and clear all symmetric).
+- **Assignees**: `person:<slug>` tags map to ClickUp members bidirectionally (multi-assignee; the full `assignees[]` set survives push/pull). Names **resolve against the live roster** — exact/fuzzy match canonicalizes to the member's slug, an ambiguous name aborts, an unmatched name warns (recorded but won't sync, never silently reassigned to the token owner). See "People & assignees" in [tasks-and-features.md](tasks-and-features.md).
 - **Changelog as comments**: task changelog entries post as ClickUp comments (`changelogTarget: 'comments'`).
 - **Conflict safety**: conflicting edits are preserved as conflict files rather than silently overwritten; a sync ledger tracks a watermark, pending pushes, and an op queue.
 - **Rate-limit hardened**: throttles at 90 req/min (under ClickUp's 100/min cap), retries with Retry-After backoff, and a partial push can never look like success — `sleep done` auto-retries once on failed pushes, then errors loudly with the failed slugs.
@@ -53,7 +54,7 @@ dreamcontext tasks sync [push|pull|both]   # default: both; no-op on the local b
 dreamcontext tasks sync --hook             # best-effort mode for git hooks (never fails, exit 0)
 dreamcontext tasks sync --json             # machine-readable sync report
 dreamcontext tasks members [--json]        # people with access to the remote list (assignee candidates)
-dreamcontext tasks provision               # create the recommended custom fields on the list
+dreamcontext tasks provision               # create recommended + override-declared custom fields (reuses existing ones by name)
 dreamcontext tasks sync-hooks install|uninstall   # manage the git sync triggers
 ```
 
@@ -71,8 +72,9 @@ The same backend interface, talking **plain GitHub Issues over REST** (no GraphQ
 - **Bidirectional sync** (`push`/`pull`/`both`) between local task files and a repo's Issues.
 - **Status mapping:** `completed` → issue **closed** `state_reason: completed`; `todo`/`in_progress`/`in_review` → **open** + a `dc:*` sub-status label (`dc:in-progress`, `dc:in-review`; `todo` = no label); reopen → **open** `state_reason: reopened`.
 - **Soft-delete (the one divergence from ClickUp):** `tasks delete` **closes** the issue as `state_reason: not_planned` — it NEVER hard-deletes (GitHub REST can't, and issue history is preserved). Inbound, a `not_planned` close removes the local mirror (any unsaved local edits are preserved to `.conflicts/` first).
-- **Fields as labels:** priority/urgency/tags/version ride as labels (`priority:*`, `urgency:*`, `version:*`, plus your plain tags). RICE stays local-only (no custom fields on plain issues — see Tier-2).
-- **Assignees:** `person:<slug>` tags ↔ issue assignees (must be repo collaborators); a non-collaborator assignee is skipped gracefully, never a 4xx that aborts the sync. See "People & assignees" in [tasks-and-features.md](tasks-and-features.md).
+- **Fields as labels:** priority/urgency/tags/version ride as labels (`priority:*`, `urgency:*`, `version:*`, plus your plain tags). RICE stays local-only (no native custom fields on plain issues — see Tier-2).
+- **User custom fields + dates in the body:** override-declared `select` fields become `<key>:<value>` labels; other custom fields land in a `<!-- dc:fields -->` block, and a task's start/due dates in a `<!-- dc:dates -->` block — both composed above the prose and stripped before the 3-way merge so they never pollute the body diff.
+- **Assignees:** `person:<slug>` tags ↔ issue assignees (must be repo collaborators); a non-collaborator assignee is skipped gracefully, never a 4xx that aborts the sync. Names **resolve against the live roster** (same matcher as ClickUp: exact/fuzzy → canonical slug, ambiguous → abort, unmatched → warn, never silently dropped). See "People & assignees" in [tasks-and-features.md](tasks-and-features.md).
 - **Changelog as comments:** task changelog entries post as issue comments (union-merged, deduped — same pattern as ClickUp).
 - **Conflict safety + watermark:** reuses the SAME generic sync engine (ledger / watermark / op-queue / 3-way merge) as ClickUp, unchanged. Watermark is the issue `updated_at` (server time). Delta fetch is `GET /repos/{o}/{r}/issues?state=all&since=<ISO>` with **page-number pagination** (pull-requests filtered out).
 - **Rate-limit hardened:** paces under GitHub's 5000 req/hr cap with Retry-After backoff; a partial push can never look like success.
@@ -113,14 +115,21 @@ dreamcontext dashboard --launcher      # vault-agnostic launcher mode (resolves
 ```
 A SessionStart hook auto-opens it when a session starts and no server is running (opt out with `DREAMCONTEXT_AUTO_DASHBOARD=0`).
 
+The sidebar is grouped into **Workspace** (Sleepy, Tasks, Council), **Memory** (Core, Knowledge, Features, Taxonomy), **Brain** (Map, Sleep Cycle), and **Control** (Packs, Settings), plus a "What is this?" page.
+
 **What's in it:**
-- **Kanban board** — drag-and-drop, multi-select filters (status/priority/urgency/tags/version) with type-ahead, sorting, grouping; Notion-style task detail panel to create tasks, change status, add changelog entries.
+- **Sleepy** (Workspace) — the dashboard's Search + Ask surface: a scoped recall widget that runs the same engine as the CLI (empty query = browse; typing = live debounced BM25; "Intelligent" = a Haiku intent pass), plus an in-app **interactive Claude Code** agent (multi-session tabs, split panes; desktop-gated, read-only by default). This is the dashboard twin of the desktop Sleepy notch.
+- **Tasks board** — drag-and-drop Kanban with **saved views** (each carrying its own persisted filter/sort/grouping), a two-pane **include/exclude** filter (status/priority/tags/version/assignee) with type-ahead, a **Versions** popover, toggleable card **Properties** badges, and an **At-Risk alert**; view prefs persist shared (`overrides/board.json`) or local (`state/board.local.json`). Notion-style task detail panel to create tasks, change status, edit start/due dates and custom fields, add changelog entries. The **version filter is sprint-aware** — current / planning / released sprints with set-current + mark-complete actions (backed by `state/.active-version.json`).
 - **Eisenhower matrix** — priority×urgency quadrant planning; **Scatter view** uses RICE scores.
+- **Time-axis task views** — **Timeline (Gantt)** rendering each task's start→due range, a **Calendar**, and an **Activity heatmap** of completion cadence (all driven by the same `start_date`/`due_date` range).
 - **Core editor** — split-pane markdown editing + live preview for soul/user/memory/etc.
 - **Knowledge manager** — search, pin/unpin; **Feature PRD viewer**; **SQL ER diagram** preview for data-structures.
+- **Taxonomy** (Memory) — view and edit the tag vocabulary (facets, aliases) from the UI; mirrors `dreamcontext taxonomy`.
+- **Packs** (Control) — browse and install/refresh skill packs from the UI.
 - **Version manager** — plan and release versions.
-- **Sleep tracker** — debt gauge, session-history timeline, and a list of every manual change made through the dashboard (recorded to `.sleep.json` so the agent consolidates your edits during sleep).
-- **Brain graph** — interactive network of memory/knowledge/features/decisions with explicit + inferred edges.
+- **Settings — cloud tasks** — enter the ClickUp/GitHub API token from the UI (written to gitignored `state/.secrets.json`, masked, never echoed), Test Connection, and **preview-then-provision** custom fields (a dry run lists what would be created vs. already exists); plus a **Task Format & Custom Fields** editor for `overrides/task.md` (raw template + structured field schema).
+- **Sleep Cycle** (sleep tracker) — debt gauge, session-history timeline, and a list of every manual change made through the dashboard (recorded to `.sleep.json` so the agent consolidates your edits during sleep).
+- **Map** (brain graph) — interactive network of memory/knowledge/features/decisions with explicit + inferred edges.
 - **Council Hall** — every debate as a searchable card grid; detail view with Overview / Agents / Matrix tabs.
 - **"What is this?"** explainer page with live faculty diagrams.
 

package/skill/references/knowledge-and-recall.md

@@ -102,6 +102,11 @@ Writes a CHANGELOG entry (`type=note`, `scope=quick`); the sleep cycle reconcile
 - BM25 is keyword/stemming-based, not semantic — "ML practitioner" won't match "data scientist" (haiku mode mitigates this).
 - Recall does **not** replace the SessionStart snapshot (soul/user/memory/active-tasks/knowledge-index are always pre-loaded). It is not a vector DB or mem0; the corpus is the same set the sleep agents curate.
 
+### Two depths of search: explore vs deep-research
+Recall feeds two read surfaces — pick by how much synthesis the question needs:
+- **`dreamcontext-explore`** (fast, single-pass): one sub-agent, recall-then-grep, one answer. Use for "where is X?" / "how does Y work?" on one project. This is the default and handles the vast majority of lookups.
+- **`dreamcontext-deep-research` skill** (iterative, multi-agent): when a question needs **synthesis across a large or multi-project / federated corpus** and one explore pass comes back thin. The main agent decomposes the question, fans out parallel `dreamcontext-explore` searchers across the corpus **and connected peer vaults**, loops to close gaps, **adversarially verifies** the load-bearing claims, then writes a **synthesized, cited** report. Invoke via `/dreamcontext-deep-research`. **Escalation rule:** start with explore; escalate only when one pass and one answer leave a cross-corpus question half-answered. It is read-only — synthesis, not mutation.
+
 ---
 
 ## Root-cause analysis pattern
@@ -123,12 +128,15 @@ Consistent tags make recall sharp; fragmented near-duplicate tags degrade it. Be
 dreamcontext taxonomy vocab [--facet <facet>] [--json]   # resolved vocabulary (defaults + core/taxonomy.json)
 dreamcontext taxonomy resolve <tag>                       # normalized form, classification, canonical
 dreamcontext taxonomy audit [--json]                      # surface non-canonical / orphan tags (read-only)
+dreamcontext taxonomy audit --fix [--dry-run] [--json]    # BULK-normalize alias/normalizable tags → canonical
 dreamcontext taxonomy init                                # scaffold core/taxonomy.json (idempotent)
 dreamcontext taxonomy add <facet:value>                   # add a new vocabulary tag
 dreamcontext taxonomy alias <alias> <canonical>           # merge a shorthand into a canonical tag
 ```
 Standard bare tags: `architecture`, `api`, `frontend`, `backend`, `database`, `devops`, `security`, `testing`, `design`, `decisions`, `onboarding`, `domain`. **Never hand-edit `core/taxonomy.json`** — mutate via the CLI. `sleep-product` runs taxonomy maintenance during consolidation.
 
+**Bulk-healing tag drift (`audit --fix`).** `taxonomy audit` only *reports* drift; `taxonomy audit --fix` *fixes* it in one shot across every knowledge/feature/task file. For each frontmatter tag it computes `normalizeTag → resolveAlias`; if that yields a **different tag that is canonical** in the vocabulary it rewrites it (e.g. `search → topic:recall`, `excalidraw → topic:excalidraw` once you've added that alias, `Architecture → architecture`). It is **safe by construction**: already-canonical tags are never touched (so `decisions` is not churned to `decision`), and orphan tags with no alias/canonical target are left untouched and reported as *"needs a vocab decision"* — resolve those first with `taxonomy add`/`taxonomy alias`, then re-run. The workflow is **alias-then-fix**: `taxonomy alias <orphan> <canonical>` teaches the mapping once, `audit --fix` applies it everywhere. Preview with `--fix --dry-run` (writes nothing), apply with `--fix`, automate with `--fix --json`. Idempotent — a second run is a no-op.
+
 ---
 
 ## Excalidraw boards (diagrams)

package/skill/references/sleep.md

@@ -63,7 +63,7 @@ For non-file-change work (architecture discussion, a decision with no edits): `d
 
 | Specialist | Owns | Notes |
 |---|---|---|
-| `sleep-tasks` | Task files (`state/*.md`) | Reconciles task bodies to truth, bumps statuses, creates tasks for untracked work, attaches to the planning version. |
+| `sleep-tasks` | Task files (`state/*.md`) | Reconciles task bodies to truth, bumps statuses, creates tasks for untracked work, attaches to the planning version, sets the start/due range, and keeps declared custom fields current (never fabricating `ask` fields in the no-user sleep context). |
 | `sleep-state` | Core identity (soul, user, memory, core 3–6), CHANGELOG, RELEASES | Records patterns/decisions/preferences, writes a changelog entry per meaningful change since the epoch, surfaces release readiness, enforces anti-bloat ceilings, flags stale knowledge for `sleep-product`. |
 | `sleep-product` | Knowledge files + feature PRDs | Creates/reconciles `knowledge/*.md` and `core/features/*.md`, processes staleness flags, maintains the knowledge index + taxonomy. |
 | `sleep-migration` | Structure only | Moves/renames folders, normalizes frontmatter, wraps fences. Never alters body prose. |

package/skill/references/tasks-and-features.md

@@ -34,6 +34,7 @@ Sections: `why`, `user_stories`, `acceptance_criteria`, `constraints`, `technica
 ### Lifecycle commands
 ```bash
 dreamcontext tasks log <name> "what was done"        # changelog entry — MANDATORY each session
+dreamcontext tasks status <name> in_progress "reason" # bump status; first in_progress auto-stamps start_date if unset
 dreamcontext tasks status <name> in_review "reason"  # bump status (logs automatically)
 dreamcontext tasks complete <name> "summary"         # mark complete
 dreamcontext tasks delete <name> --yes               # delete (propagates to remote on sync)
@@ -66,11 +67,19 @@ dreamcontext tasks rice <name> --clear         # remove all RICE values
 - `--reach` integer 1–10 · `--impact` integer 1–5 · `--confidence` one of 25/50/75/100 (%) · `--effort` person-weeks (>0, ≤52, 0.5 steps).
 - Score = `(reach × impact × confidence/100) / effort`, computed server-side, stored in frontmatter.
 
-## Due dates & urgency
+## Dates & urgency
+A task has an optional **date range** — a planned `start` and a `due`/end. Either end is independently settable or clearable, and both sync to the remote backend.
 ```bash
-dreamcontext tasks due <name> 2026-07-01     # set
-dreamcontext tasks due <name> clear          # clear
+dreamcontext tasks start <name> 2026-06-25   # set planned start (range start)
+dreamcontext tasks due <name> 2026-07-01     # set due/end (range end)
+dreamcontext tasks start <name> clear        # clear the start
+dreamcontext tasks due <name> clear          # clear the due
+dreamcontext tasks create <name> --start 2026-06-25 --due 2026-07-01
 ```
+- `start` must be **on or before** `due` — an inverted range is rejected (clear one end first).
+- Setting either date on a `backlog`-tagged task **removes the `backlog` tag** (a dated task is planned, not backlog).
+- Both dates render in the dashboard timeline (Gantt) and calendar views.
+
 `urgency` (critical/high/medium/low) is the second Eisenhower axis (priority × urgency) for the dashboard matrix.
 
 ---
@@ -85,6 +94,7 @@ dreamcontext tasks tag <name> person:mehmet        # add another assignee
 dreamcontext tasks tag <name> person:ada --remove  # unassign
 ```
 - `person:<slug>` tags are the source of truth for assignment and support **multiple assignees**. The legacy scalar `assignee` field is deprecated (still read, not written).
+- When a cloud backend is active, `--person`/`tag person:<slug>` **resolves the name against the real member roster** (`tasks members`): an exact or fuzzy match is canonicalized to the member's slug, an **ambiguous** match aborts (be more specific), and an unmatched name is recorded but **warns** that it won't sync until that person is a member. Assignments are never silently dropped.
 - With ClickUp enabled, the full assignee set round-trips to ClickUp's native `assignees[]` bidirectionally; map each person to a member with `dreamcontext config clickup-member <person> <memberId>`. With **GitHub** enabled, `person:<slug>` tags round-trip to issue assignees (repo collaborators; a non-collaborator is skipped, never a sync error). (see [integrations.md](integrations.md)).
 - `DREAMCONTEXT_PERSON` env names the current person for attribution.
 
@@ -118,14 +128,60 @@ version: "v0.9.0"         # planning-version association (auto-set to active pla
 parent_task: null
 related_feature: null     # feature slug for cross-link
 product: null             # multi-product scoping (optional)
-due: null                 # YYYY-MM-DD
+start_date: null          # YYYY-MM-DD or null — planned start (range start)
+due_date: null            # YYYY-MM-DD or null — due / planned end (range end)
 rice: { reach: 5, impact: 3, confidence: 75, effort: 2, score: 5.625 }
+custom_fields: {}         # project-declared fields (only when overrides/task.md exists)
 ---
 ```
 Files live at `_dream_context/state/<slug>.md`. Lookup is fuzzy: exact slug → prefix → substring.
 
 ---
 
+## Task format & custom-field overrides (optional)
+
+A project can override the default task shape AND declare its own custom fields by adding **`_dream_context/overrides/task.md`**. Absent this file, everything behaves exactly as the defaults above (zero regression).
+
+The file carries two things:
+
+- **Frontmatter `custom_fields:`** — a user-defined field schema. Each field: `name`, `type` (`text` | `number` | `select` | `date`), optional `key` (the stable field id / `custom_fields:` map key — defaults to the snake_cased `name`, so a rename keeps the same id), `required` (`true` ⇒ the agent MUST set it on every task; default optional), `ask` (`true` ⇒ the field is a HUMAN judgment the agent must NOT guess — it asks you for the value at task-creation time; default false), `options` (for `select`), `sync` (`[clickup, github]`, default both), and optional `prompt` (a system instruction telling the agent HOW to fill the field — surfaced in your snapshot + every sub-agent briefing).
+- **Body** — the task TEMPLATE the CLI scaffolds from, plus an optional `## Agent Instructions` section that sub-agents read at runtime (it is stripped from scaffolded tasks).
+
+```markdown
+---
+custom_fields:
+  - { name: "Team", type: select, required: true, options: [platform, growth, infra], sync: [clickup, github], prompt: "The squad that owns the touched files." }
+  - { name: "Story Points", key: story_points, type: number, sync: [clickup, github] }
+  - { name: "Time estimate", key: time_estimate, type: text, required: true, ask: true, prompt: "How long will this take? Answer in ClickUp shorthand, e.g. 45m, 2h 30m, 1w 2d." }
+  - { name: "Sprint", type: text }
+---
+## Why
+{{WHY}}
+
+## Acceptance Criteria
+- [ ] First criterion
+
+## Agent Instructions
+Set Team to the owning squad before starting work.
+```
+
+When an override is active its briefing (the field list, each field's `required` + `ask` flags + `prompt`, and the Agent Instructions) is injected into your SessionStart snapshot and into every sub-agent. **Each active task's custom-field VALUES are also surfaced inline** — in the snapshot's Active Tasks block and in `dreamcontext tasks list --long` — with any unset **required** field flagged `⚠ UNSET (required)`. So you always see a task's fields without opening it: follow `overrides/task.md`'s layout and **set every declared custom field** when you create or reconcile a task — REQUIRED fields are mandatory, so never create or complete a task with a required field left empty. As a hard backstop, `dreamcontext tasks create` / `complete` / `status … completed|in_review` **fail (non-zero exit) and refuse the action** when a required field is unset — naming the field plus the exact fix command. Pass `--allow-missing-required` (or set `DREAMCONTEXT_ALLOW_MISSING_REQUIRED=1`) only for an intentional draft, which downgrades the failure to a warning.
+
+**`ask: true` fields — don't fabricate, ask.** Some fields capture a judgment only the user can make (a time estimate, a business-impact call). A field marked `ask` is flagged **[ASK THE USER]** in the briefing: when you create a task on the user's request, **ask the user for that value first** — one concise question per field, using the field's `prompt` as the framing (the `AskUserQuestion` tool if you have it, else just ask in chat) — and wait for the answer **before** creating the task. Never invent the value to satisfy a `required` gate. The one exception is a no-user context (an autonomous reconcile or a sleep cycle): there, leave the field unset and note it rather than guessing.
+
+**Setting values:** `dreamcontext tasks create … --field team=platform --field story_points=8`, or on an existing task `dreamcontext tasks field <slug> team platform` (`clear`/omit value to clear). Values are validated against the schema (select options, number coercion) and stored under a `custom_fields:` map in the task frontmatter.
+
+**Sync — values flow to both backends, reusing remote fields that already exist:**
+
+| Field type | ClickUp | GitHub |
+|---|---|---|
+| `select` | native list custom field (drop_down) | `<key>:<value>` **label** |
+| `text` / `number` / `date` | native list custom field | `<!-- dc:fields -->` **body block** in the issue |
+
+`dreamcontext tasks provision` creates any missing custom fields/labels on the remote and **reuses (never duplicates) ones that already exist by name**. `dreamcontext doctor` validates the override and warns (never silently ignores) on a malformed one.
+
+---
+
 ## Features (PRDs)
 
 Retrospective product documentation, **created and updated exclusively by the sleep agent**. During active work, everything goes in the task; sleep consolidates task content into the matching feature.

package/skill-deep-research/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: dreamcontext-deep-research
+description: >
+  Load when a question needs synthesis across a LARGE or MULTI-PROJECT dreamcontext corpus —
+  more than `dreamcontext-explore` can answer in a single fast pass — or the user invokes
+  `/dreamcontext-deep-research`. Triggers: "deep research the brain", "research this across my
+  projects", "synthesize what we know about X across everything", "deep dive across the
+  connected vaults", "explore is too shallow for this", "pull together everything on X and
+  cite it", "cross-project / cross-corpus question", or any "tons of data, federated/tagged
+  vault" question where one explore agent and one answer under-serves. This is the heavy,
+  iterative, sub-agent-driven counterpart to `dreamcontext-explore`: it fans out searchers over
+  the whole curated corpus (knowledge + features + tasks + memory + CHANGELOG) AND connected
+  peer vaults, adversarially verifies the load-bearing claims, and returns a SYNTHESIZED, CITED
+  report — not raw hits.
+user-invocable: true
+alwaysApply: false
+tags: [deep-research, recall, synthesis, federation, cross-project, orchestration, sub-agents, dreamcontext]
+---
+
+# Deep Research — iterative, sub-agent-driven corpus synthesis
+
+You are the **orchestrator**. Like `curator`, `initializer`, `multi-review`, and `council`,
+**you do not do the bulk of the searching yourself** — you decompose the question, fan out
+`dreamcontext-explore` searchers in parallel, read their cited findings, loop to close gaps,
+adversarially verify the claims that matter, and then **you** write the synthesized report. Your
+value is the decomposition, the gap loop, the verification gate, and the final synthesis — not
+running every `recall` and `grep` by hand.
+
+**Why this exists, vs `dreamcontext-explore`.** Explore is tuned for **speed and a single
+answer**: one Haiku agent, a tight tool-call budget, recall-then-grep, return the best hit. That
+is the right tool for "where is X?" / "how does Y work?" on one project. It **under-serves** the
+question that needs *synthesis across many files and many projects*: "what have we decided about
+recall across all my vaults?", "reconcile everything we know about federation", "pull the whole
+history of how the sleep cycle evolved and cite it". For those, a single fast pass returns a
+fragment and stops. Deep research is the escalation: **iterative fan-out → verify → synthesize a
+cited answer**.
+
+| | `dreamcontext-explore` | `dreamcontext-deep-research` (this) |
+|---|---|---|
+| Shape | one sub-agent, one pass | main agent orchestrates many searchers + verifiers, looped |
+| Budget | tight (1–20 tool calls) | scaled to the corpus; multiple waves |
+| Scope | one project, narrow | whole corpus + **connected peer vaults** |
+| Output | the best hit, fast | a **synthesized, cited** report reconciling sources |
+| Verify | none | adversarial pass on load-bearing claims |
+| Use when | "where / how is X?" | "synthesize / reconcile / research X across everything" |
+
+**It is read-only.** Deep research never mutates the corpus. It may *recommend* capturing a
+finding (a knowledge file, a feedback item) at the end — but only with the user's say-so, via the
+normal CLI. It is not a writer.
+
+**Recall is the engine; the corpus index + peer connections are the substrate.** Every wave starts
+from `dreamcontext memory recall` (BM25 + Haiku intent extraction over the curated corpus), which
+already spans readable peers and namespaces cross-vault hits `<vault>::<type>/<slug>`. You are not
+grepping a blind filesystem — you are mining a pre-indexed, cross-project brain.
+
+## When to invoke
+
+- `/dreamcontext-deep-research` (primary entry).
+- A `dreamcontext-explore` pass came back thin, fragmented, or "found a piece but not the whole
+  picture", and the real question spans many files.
+- The question is explicitly **cross-project / federated**: "across my vaults", "everything we
+  know about X", "reconcile what project A and project B decided".
+- "Synthesize", "reconcile", "pull together and cite", "deep dive", "research" over the brain.
+
+**Scale the machinery to the corpus.** A small single-project brain rarely needs this — say so and
+just run one `dreamcontext-explore`. Reserve the full fan-out for a genuinely large or multi-project
+tagged corpus where one agent and one answer leave the question half-answered.
+
+## Commitment ritual (do this FIRST)
+
+1. **Announce**: tell the user you're running deep research — that it fans out read-only searchers
+   across the whole corpus and any connected peer vaults, verifies the key claims, and ends in a
+   cited synthesis. Confirm the question and its scope (which vaults, which time range if any).
+2. **TodoWrite** the phases (1–6) so the gates are visible. A phase isn't done until its gate passes.
+3. **Sharpen the question.** If it's underspecified ("research recall"), narrow it with the user
+   first (recall *precision*? recall *architecture*? across *which* projects?) — a vague question
+   fans out into vague reports. One or two clarifying questions beat a 10-agent wild goose chase.
+
+## The flow (the main agent runs this directly — sub-agents can't nest)
+
+In this harness a sub-agent cannot dispatch sub-agents, so **you** own the loop and the fan-out —
+exactly like the sleep cycle. `dreamcontext-explore` is your searcher *and* your verifier; you are
+the planner and the synthesizer.
+
+### Phase 1 — Scope & seed (recall-driven)
+
+- Establish the corpus surface: read the **Connected projects** section of the snapshot, or run
+  `dreamcontext connections list` / `dreamcontext vaults list`. Decide the span:
+  - current vault only → recall as-is (already spans eligible peers by default),
+  - specific peers → `--vault <name>` (repeatable),
+  - everything readable → `--connected` (out/both peers) or `--all-vaults`.
+- **Seed with recall, in JSON, scoped by type:**
+  ```bash
+  dreamcontext memory recall "<facet>" --json --top 15 --types knowledge,feature,task,memory,changelog --connected
+  ```
+  Run it for **2–4 different phrasings/facets** of the question — recall is cheap (<100ms, zero
+  token overhead) and different keywords surface different docs. Collect the union of hits.
+- **Decompose** the question into 3–6 sub-questions / facets / per-project slices. This decomposition
+  is the fan-out plan. Write it into the Todo.
+
+### Phase 2 — Fan-out search (parallel `dreamcontext-explore`)
+
+- Dispatch **one `dreamcontext-explore` per sub-question / corpus slice / project, in parallel**
+  (one message, multiple `Agent` calls). Each searcher gets:
+  - its narrow sub-question,
+  - the seed hits relevant to it (file paths / `<vault>::<slug>` from Phase 1 — so it doesn't
+    re-discover them),
+  - an explicit instruction: **return findings WITH citations** (absolute path or
+    `<vault>::<type>/<slug>`), and flag anything that looks contradictory or stale.
+- Searchers are read-only and recall-first by design — that's the whole point of using them. Scope a
+  searcher to a peer when a specific sibling project owns that slice (it can `recall --vault`,
+  `snapshot --vault`, or read the peer's files directly).
+
+### Phase 3 — Gap loop (loop-until-dry)
+
+- Read every searcher's report. Build a running map: **claim → source(s)**.
+- Identify **gaps** (a facet nobody answered), **contradictions** (two sources disagree), and
+  **dangling references** (a doc cites another you haven't read). Dispatch a **second wave** of
+  `dreamcontext-explore` aimed only at those.
+- Stop when a wave returns nothing materially new (two dry waves) or the picture is complete enough
+  to answer. **Log what you chose not to chase** — silent truncation reads as "covered everything".
+
+### Phase 4 — Adversarial verification (the gate)
+
+- For each **load-bearing claim** (the ones the answer actually rests on), dispatch a
+  `dreamcontext-explore` **verifier** whose job is to *check the claim against its cited source* —
+  open the file, confirm the source says what the claim says, and look for a more recent doc that
+  supersedes it. Default to **"unverified"** when the source doesn't actually support the claim.
+- Drop or downgrade claims that don't survive. A plausible-but-uncited assertion does not enter the
+  report. This is what separates deep research from a confident hallucination.
+
+### Phase 5 — Synthesize (you write this — not a sub-agent)
+
+- **You** write the report from the verified claim→source map. It must be a *synthesis*, not a
+  concatenation of searcher outputs:
+  - **Answer** — the reconciled conclusion, organized by the question's structure.
+  - **Every claim carries a citation** — absolute path or `<vault>::<type>/<slug>`. No citation ⇒
+    it doesn't go in (or it's explicitly marked as inference).
+  - **Cross-project provenance** — when projects agree, say so; when they diverge, surface the
+    divergence with both sources rather than silently picking one.
+  - **Contradictions & open questions** — name them; don't paper over them.
+  - **Confidence** — note where evidence is thin or a source looked stale.
+
+### Phase 6 — Persist (optional, only on consent)
+
+- If durable findings emerged ("we actually decided X across A and B" / "these three docs are
+  near-duplicates"), **offer** to capture them — a `dreamcontext knowledge create`, or a
+  `dreamcontext feedback` if deep research exposed a recall/structure gap. Never auto-write; the
+  user confirms. Deep research is a reader.
+
+## Output contract
+
+A **synthesized, cited report** — never a raw hit dump. The minimum bar:
+- Citations are **mandatory** for every load-bearing claim (path or `<vault>::<type>/<slug>`).
+- Cross-vault hits are first-class, not noise — provenance is the point on a multi-project corpus.
+- Contradictions and gaps are surfaced, not hidden.
+- Any coverage you deliberately capped is stated.
+
+## Boundaries
+
+- **Read-only.** No writes except the optional, consent-gated Phase 6 capture via the normal CLI.
+- **Reuse `dreamcontext-explore`.** Don't reinvent a searcher — it's the tested, recall-accelerated,
+  read-only explorer. This skill is the *orchestration* around it.
+- **Stay in the decisions/knowledge lane.** For raw code *structure* ("who calls this function?")
+  the code-graph lane (graphify) owns it — deep research synthesizes curated decisions/knowledge, it
+  is not an AST indexer.
+- **Scale to the corpus.** Don't fan out 10 agents at a 12-file single-project brain. Match the
+  machinery to the data.
+
+## Relationship to the rest of dreamcontext
+
+- **vs `dreamcontext-explore`** — explore is the fast single-pass searcher; this is the iterative
+  multi-agent synthesizer that *uses* explore. Escalate from explore → deep-research when one pass
+  and one answer leave a cross-corpus question half-answered.
+- **vs `sleep`** — sleep *writes* (consolidates experience into memory); deep research *reads*
+  (synthesizes existing memory into an answer). Same fan-out shape, opposite direction.
+- **vs `curator`** — curator refactors the corpus's *shape*; deep research mines its *content*.
+- **vs the generic `deep-research` web skill** — that one researches the open web; this one researches
+  *your brain* (the curated corpus + connected vaults). Same harness shape, different substrate.

package/skill-packs/goal-skill/SKILL.md

@@ -122,6 +122,11 @@ dreamcontext tasks status <slug> in_progress "plan validated; implementing"
 
 If `<slug>` already exists, de-collide (append a short suffix) rather than clobbering.
 
+If the project declares **custom task fields** (`_dream_context/overrides/task.md`), `tasks create`
+hard-fails (exit 1) on an unset `required` field — set each with `--field key=value` on create. For
+any field marked `ask: true`, ask the user for the value back in Phase 0 (it's a human judgment) rather
+than fabricating it. The SubagentStart briefing lists the active fields and their prompts.
+
 ### Phase 4 — IMPLEMENT
 
 Dispatch **one** `goal-implementer` (sonnet; escalate to opus for genuinely hard goals)

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

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

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

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-4TB4RGXK-CpwYPUdR.js";import{_ as i}from"./index-CQkBs_Vm.js";import"./chunk-FMBD7UC4-CrbfOH-q.js";import"./chunk-YZCP3GAM-tvOjDART.js";import"./chunk-55IACEB6-CQ_4M3g4.js";import"./chunk-EDXVE4YY--HdVil0f.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-D8yKg5c-.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-4TB4RGXK-CpwYPUdR.js";import{_ as i}from"./index-CQkBs_Vm.js";import"./chunk-FMBD7UC4-CrbfOH-q.js";import"./chunk-YZCP3GAM-tvOjDART.js";import"./chunk-55IACEB6-CQ_4M3g4.js";import"./chunk-EDXVE4YY--HdVil0f.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-DkTWs9rv.js

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