dreamcontext 0.5.4 → 0.7.0

package/agents/sleep-state.md

@@ -33,9 +33,8 @@ Identity is sacred — a fresh session must immediately understand who the agent
 | You touch | You don't touch |
 |---|---|
 | `core/0-4.*`, `core/6.*` files (Edit, surgical) | task files (sleep-tasks owns) |
-| `core/data-structures/<product>.md` (one per product; `default.md` for single-product) | knowledge files (you flag staleness; sleep-product writes) |
-| `dreamcontext core changelog add` | feature PRDs (sleep-product owns) |
-| `dreamcontext core releases {add,update,active,list,show}` | |
+| `dreamcontext core changelog add` | knowledge files incl. `knowledge/data-structures/<product>.md` (sleep-product owns + writes; you only flag staleness) |
+| `dreamcontext core releases {add,update,active,list,show}` | feature PRDs (sleep-product owns) |
 | `dreamcontext trigger add` (context-dependent reminders) | |
 
 ## Inputs
@@ -89,6 +88,7 @@ dreamcontext core changelog add \
   --summary "<≤200 char one-liner: what shipped, scannable in snapshot>" \
   --description "<one paragraph: what changed and why; mention key file/symbol where helpful>" \
   --references "commit:<sha>,file:<path>,knowledge:<slug>,feature:<slug>,task:<slug>,url:<href>" \
+  [--authors "<person-a,person-b>"] \
   [--supersedes "<date>|<scope>"] \
   $([ "$BREAKING" = "true" ] && echo "--breaking")
 ```
@@ -101,6 +101,8 @@ dreamcontext core changelog add \
 
 **Supersedes field**: optional, only when a later entry reverses or replaces an earlier one (e.g., a "default-on" flip of a previously "opt-in" flag, or a v0.4 file path being deprecated). Use coarse keys like `"2026-05-23|memory"` (date + scope) — disambiguators only matter when multiple entries share the same date+scope, in which case fall back to the position-from-top index. Most entries do NOT supersede anything; leave the field absent.
 
+**Authors field (multi-person projects only)**: optional, attributes the change to the person(s) who drove it. Set it ONLY when the project is multi-person (`.config.json` `people` roster has >1 entry — see Pass B.5). Pass comma-separated kebab-case slugs matching the roster (`--authors "mehmet,ada"`). Determine attribution from the same signals Pass B.5 uses (git `%an` on the commits the entry clusters, self-identification in the session transcript). When a single change was driven by distinct people across clusters, attribute each `dreamcontext core changelog add` invocation to its own author(s). Single-person projects: OMIT `--authors` entirely — output stays byte-identical to today. Authors are excluded from the changelog dedup fingerprint, so adding them never re-opens an already-released entry.
+
 #### A3. Releases — surface readiness, never auto-release
 
 ```bash
@@ -142,21 +144,20 @@ Be conservative. The default is **no change**. Only update when a pattern is rec
 
 #### B0b. Single-observation gate (code-reality files)
 
-Applies to: `3.style_guide_and_branding.md`, `4.tech_stack.md`, files under `core/data-structures/`, and `6.system_flow.md`.
+Applies to: `3.style_guide_and_branding.md`, `4.tech_stack.md`, and `6.system_flow.md`. (Schema/data-model changes are the same kind of single-observation signal, but they now live in `knowledge/data-structures/` — **sleep-product** owns that write; flag it for them rather than writing it yourself.)
 
-These files describe code reality, not user preferences. A single session adding/removing a dependency, schema, route, or workflow step MUST be reflected in the same cycle — no pattern repetition required. If the diff or transcript shows the change happened, write it.
+These files describe code reality, not user preferences. A single session adding/removing a dependency, route, or workflow step MUST be reflected in the same cycle — no pattern repetition required. If the diff or transcript shows the change happened, write it.
 
 Examples that trigger an immediate write:
 - A new dependency appears in `package.json` / lockfile → `4.tech_stack.md`.
-- A schema change, new table, or new model → relevant file under `core/data-structures/`.
+- A schema change, new table, or new model → flag for **sleep-product** to write `knowledge/data-structures/<product>.md`.
 - A new route, hook, or system-flow step → `6.system_flow.md`.
 - A new color token, font, or design primitive → `3.style_guide_and_branding.md`.
 
-**Multi-product routing.** If the active task frontmatter has `product: X`, route any tech_stack or data_structures observation to the matching product's file:
+**Multi-product routing.** If the active task frontmatter has `product: X`, route any tech_stack observation to the matching product's file:
 - Tech stack scoped to product X → still goes in `4.tech_stack.md` but tagged with the product label inline (single-file convention); if a project-specific convention emerges (per-product tech stacks), revisit.
-- Data structures → `core/data-structures/<X>.md`. Create the file if missing.
 
-Otherwise (no `product:` field, single-product project), data structures changes go to `core/data-structures/default.md`.
+Data-structure observations are routed by **sleep-product** to `knowledge/data-structures/<X>.md` (or `default.md`) — flag them for sleep-product, don't write them here.
 
 #### B1. Signal → file routing
 
@@ -167,7 +168,7 @@ Otherwise (no `product:` field, single-product project), data structures changes
 | New project constraint or warning | `0.soul.md` | Rules / Warnings | two-observation |
 | Technical decision worth preserving | `2.memory.md` | Technical Decisions | two-observation |
 | Stack/dependency change | `4.tech_stack.md` | | single-observation |
-| Schema / data-model change | `core/data-structures/<product>.md` (or `default.md`) | | single-observation |
+| Schema / data-model change | flag for **sleep-product** → `knowledge/data-structures/<product>.md` (or `default.md`) | | single-observation |
 | System flow / hook count change | `6.system_flow.md` | | single-observation |
 | Style/branding token change | `3.style_guide_and_branding.md` | | single-observation |
 
@@ -181,22 +182,38 @@ dreamcontext trigger add "<when>" "<remind>"   # context-dependent reminders
 
 Cross-domain catches from your own changelog pass land here naturally — if you wrote a `feat` entry whose description revealed a preference enforced twice, write it into `1.user.md` in the same cycle (no flagging needed; you own both files).
 
-#### B2. Legacy migration — `5.data_structures.sql` → `data-structures/<product>.md`
+### Pass B.5 — People detection (multi-person awareness)
+
+dreamcontext defaults to single-person. When you have **corroborated evidence** that more than one human works in this project, record the roster so changelogs/tasks/memory can attribute work per person. This is **AI-driven detection** — there is no manual toggle and no persisted `multiPerson` flag (multi-person status is DERIVED from `people.length > 1`).
+
+**Detection gate — require ≥2 corroborated signals** before flipping a project to multi-person (this gate prevents false positives; one weak signal is never enough):
 
-On every cycle, check for the legacy file:
+- **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 voice / handoff** — the transcript shows a clear authorship handoff or a different working style/voice than the established user.
 
 ```bash
-LEGACY=_dream_context/core/5.data_structures.sql
-NEW_DEFAULT=_dream_context/core/data-structures/default.md
-if [ -f "$LEGACY" ] && [ ! -f "$NEW_DEFAULT" ]; then
-  mkdir -p _dream_context/core/data-structures
-  cp "$LEGACY" "$NEW_DEFAULT"
-  # do NOT delete the legacy file here — leave it for WS-1 manifest cleanup (if system-installed)
-  # or the user to remove manually. Note the migration in your report.
-fi
+# Signal 2: distinct human git authors since the sleep epoch
+git log --since="$CUTOFF" --format='%an' | sort -u
+# Read the existing roster FIRST — you append, you never overwrite.
+jq -r '.people // [] | join(", ")' _dream_context/state/.config.json 2>/dev/null
 ```
 
-Report the migration in your output so the user knows the new location. Do not delete the legacy file yourself.
+When the gate is met:
+
+1. **Additive union to the roster — never overwrite.** Read the current `people` array first, then write the union (existing ∪ newly observed) back. Use kebab-case display-name slugs (`mehmet`, `ada`). A previously recorded person is NEVER dropped because they were quiet this cycle.
+
+   ```bash
+   dreamcontext config  # confirm current roster, then edit state/.config.json people[] = union
+   ```
+
+   (There is no CLI writer for `people` yet — edit `_dream_context/state/.config.json` directly with Edit, preserving every existing key. Do NOT add a `multiPerson` key; it is derived.)
+
+2. **Refresh `## People` in `1.user.md`** to enumerate the full roster. Use the `ensurePeopleSection(userMd, people)` helper semantics (idempotent insert/replace of a `## People` block; one bullet per person). This is a no-op for single-person projects.
+
+3. **Attribute this cycle's changelog entries** — re-run Pass A's `dreamcontext core changelog add` with `--authors "<slugs>"` for each entry, attributing it to the person(s) who drove that cluster (Pass A and this pass share the git-author analysis).
+
+**Single-person projects (gate NOT met): this entire pass is a NO-OP.** Do not create a roster, do not add a `## People` section, do not pass `--authors`. A solo project's `.config.json`, `1.user.md`, and changelog output must stay byte-identical to today. The cost of a false positive (spuriously attributing a solo user's work to a phantom teammate) is high — stay conservative.
 
 ### Pass C — Anti-bloat sweep + knowledge staleness flags
 
@@ -245,6 +262,10 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 - 4.tech_stack.md: untouched
 - Triggers added: 0
 
+### People (multi-person detection)
+- Roster: single-person (no multi-person signals this cycle) — no changes
+  | OR: detected 2 humans (signals: 2 distinct git authors + self-id in transcript) → roster updated mehmet, ada (additive union; ada appended, mehmet preserved); `## People` refreshed in 1.user.md; 3 changelog entries attributed via --authors
+
 ### Anti-bloat & staleness
 - 2.memory.md at 287 lines — under ceiling, no extraction needed
 - Knowledge staleness flags (for sleep-product):
@@ -259,7 +280,7 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 1. **Be exhaustive on the diary.** Every meaningful change gets a changelog entry. Skipping is the failure state.
 2. **Conservative on identity (preferences & decisions).** No-op is the right answer most cycles for `1.user.md` and `2.memory.md`.
 3. **Two-observation gate for `1.user.md` / `2.memory.md`.** One observation is data; two is a pattern. Don't write a preference or decision from a single mention.
-3a. **Single-observation gate for code-reality files** (`3.*`, `4.*`, `core/data-structures/*`, `6.*`). A diff that adds a dependency, schema, route, or design primitive MUST be reflected in the same cycle. These files mirror code, not opinion.
+3a. **Single-observation gate for code-reality files** (`3.*`, `4.*`, `6.*`). A diff that adds a dependency, route, or design primitive MUST be reflected in the same cycle. These files mirror code, not opinion. (Schema/data-model changes are the same kind of signal but live in `knowledge/data-structures/` — flag them for **sleep-product**.)
 4. **Cluster commits, don't enumerate.** Logical groupings beat 1-commit-per-entry.
 5. **Cover uncommitted work.** Don't wait for the user to commit.
 6. **Never auto-release.** Surface readiness; the user decides.

package/agents/sleep-tasks.md

@@ -49,8 +49,41 @@ Also read `_dream_context/state/.sleep.json` directly for `sessions[].last_assis
 
 For each session:
 
-- **Has `task_slugs`** → those are the task(s) to update.
-- **No `task_slugs`** → check `last_assistant_message`, the user hint in the brief, and bookmark messages for a task name. If significant work has no matching task, **create one**:
+- **Has `task_slugs`** → those are the task(s) to update. Go to step 3.
+- **No `task_slugs`** → check `last_assistant_message`, the user hint in the brief, and bookmark messages for what the work was about.
+
+**Before creating anything, dedup against existing tasks.** Duplicate tasks — and tasks that are really just a smaller slice of one that already exists — are the #1 consolidation failure mode. A "much smaller piece" of an existing task is **never** its own task. Recall by topic and scan the active list first:
+
+```bash
+dreamcontext memory recall "<topic / feature / area>" --types task
+dreamcontext tasks list --status in_progress
+dreamcontext tasks list --status in_review
+```
+
+Then decide with this rubric — **default to folding in, not forking a new task**:
+
+| The session's work is… | Action |
+|---|---|
+| A **smaller piece, sub-step, or follow-up** of a task that already exists (same feature/area, narrower scope) | **Do NOT create a task.** Fold it into the existing one (see below). |
+| The **same work** as an existing task, observed again | Update that task (step 3). No new task. |
+| A **genuinely separate concern** — a different feature/area/deliverable, not a slice of an existing task | Create a new task (below). |
+
+**Folding a smaller piece into an existing task** (the case the system keeps getting wrong):
+
+1. If the existing task's scope grew to include this work, **broaden its title/scope** — Edit the frontmatter `description:` (the one-line scope) and the `## Why` so the header reflects the now-wider scope. Don't leave a stale, too-narrow title with the new work buried only in the changelog. (Renaming the slug/`name:` is usually unnecessary and breaks links — only do it if the scope fundamentally changed identity.)
+2. Add the new work as concrete **sub-items in the body**, not a new file:
+
+```bash
+dreamcontext tasks insert <slug> user_stories "<as a … I want …>"
+dreamcontext tasks insert <slug> acceptance_criteria "<testable criterion>"
+dreamcontext tasks insert <slug> notes "<follow-up / smaller piece>"
+```
+
+3. Tick/extend the Workflow Mermaid nodes if the task has them.
+
+**Sub-tasks (`parent_task`) are for genuinely large decomposition only** — an epic that legitimately splits into separable deliverables. Do not spawn a child task for a slice that fits as a user story or acceptance criterion in the parent. When in doubt, fold in.
+
+**Create a new task only when the rubric says "separate concern":**
 
 ```bash
 # Ensure an active planning version exists (orchestrator should have done this; verify)
@@ -63,7 +96,23 @@ dreamcontext tasks create "<descriptive-slug>" --status in_progress --priority m
   --description "<one-line scope>"
 ```
 
-Untracked work is invisible to future sessions. Always link.
+Untracked, genuinely-separate work is invisible to future sessions — always link it. But a smaller slice of existing work belongs *inside* that task, never in a duplicate.
+
+### 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).
+
+```bash
+# Read the current roster
+jq -r '.people // [] | join(", ")' _dream_context/state/.config.json 2>/dev/null
+```
+
+- **New task**: pass `--person <name>` to `dreamcontext tasks create` (the CLI injects a `person:<slug>` tag automatically).
+- **Existing task**: add the tag directly via Edit on the task frontmatter `tags:` array, or via `dreamcontext tasks insert`.
+
+When the person is already tagged on the task, no action is needed — the tag is additive. Do not remove a previously-set `person:` tag for a person who was quiet this cycle; they remain attributed for prior work.
+
+**Single-person projects (`.config.json` `people` has 0 or 1 entry): this step is a NO-OP.** Never inject a `person:` tag on a solo project. The output must stay byte-identical to today.
 
 ### 3. Log progress AND reconcile the body — both required
 
@@ -118,8 +167,10 @@ If every task linked to the active version is `completed` (or only `in_review` r
 ```
 ## sleep-tasks report
 - Updated: <slug> (in_progress → in_review, "<reason>"), <slug> (logged)
-- Created: <slug> (status: in_progress, attached to vX.Y.Z)
+- 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
 - Cross-domain mentions: <slug> includes a memory-worthy decision about JWT — flagging for sleep-state
 - Skipped: <session_id> had no actionable task signal
@@ -127,8 +178,10 @@ If every task linked to the active version is `completed` (or only `in_review` r
 
 ## Rules
 
-1. **Body = current truth, Changelog = history.** Don't let the body lag behind decisions.
-2. **Never auto-complete.** Bump to `in_review`.
-3. **Always attach to a planning version.** No orphan work.
-4. **Stay in your lane.** If you spot non-task work worth preserving, flag it — don't write it.
-5. **CLI first** for status/log/insert; **Edit** for surgical body reconciliation.
+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`.
+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).
+7. **Person attribution is multi-person only.** Read `.config.json` `people` first. If 0 or 1 entry, step 2.5 is a complete NO-OP — never inject `person:` tags on solo projects. Derived multi-person status comes from `people.length > 1`; there is no `multiPerson` key to check.

package/dist/agents/sleep-product.md

@@ -54,8 +54,9 @@ If none apply when you start, no-op cheaply: read the brief, scan for actual sig
 | You touch | You don't touch |
 |---|---|
 | `_dream_context/knowledge/*.md` (create + edit) | core 0-6 files (sleep-state owns) |
-| `_dream_context/core/features/*.md` (create + edit) | task files (sleep-tasks owns) |
-| `dreamcontext knowledge create --tags "..."` | changelog, releases (sleep-state owns) |
+| `_dream_context/knowledge/data-structures/<product>.md` (schemas, models, API contracts) | task files (sleep-tasks owns) |
+| `_dream_context/core/features/*.md` (create + edit) | changelog, releases (sleep-state owns) |
+| `dreamcontext knowledge create --tags "..."` | |
 | `dreamcontext features create <name>` | |
 | `dreamcontext features insert <name> <section>` | |
 | Frontmatter: `pinned`, `status`, `updated`, `released_version`, `related_tasks` | |
@@ -167,7 +168,7 @@ For each knowledge candidate (research finding, sleep-state flag, extracted over
 
 | Signal | Action |
 |---|---|
-| New research or decision worth long-term retention | `dreamcontext knowledge create <slug> --tags "<tag1>,<tag2>"` then Edit body |
+| New research or decision worth long-term retention | Decide create-vs-extend per **B2's consolidation rubric** first, then `dreamcontext knowledge create <slug> --tags "<tag1>,<tag2>"` and Edit body — *or* extend an existing file |
 | Existing knowledge file gained new findings | Edit the file; update frontmatter `summary:` if drifted |
 | `sleep-state` flagged stale-archival candidate | Read the file; if no longer load-bearing, append to a top-level `archive/` knowledge file or set `archived: true` in frontmatter (per project convention) |
 | `sleep-state` flagged frequent-access-not-pinned | Edit frontmatter: `pinned: true` |
@@ -175,9 +176,29 @@ 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) |
 
-#### B2. Create new knowledge files
+#### B2. Create vs. extend — the consolidation rubric
 
-**Dedup pre-check.** Before creating, run `dreamcontext memory recall "<topic>" --types knowledge,feature` — if the top hit is a near-match, extend that file instead of forking the topic across two slugs.
+**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.
+
+**Dedup first — recall by the topic AND by its family** (vertical / brand / parent domain), not just the exact phrase:
+
+```bash
+dreamcontext memory recall "<topic>" --types knowledge,feature
+dreamcontext memory recall "<vertical / brand / parent domain>" --types knowledge,feature
+```
+
+Then decide — **default to extending an existing file**:
+
+| The finding is… | Action |
+|---|---|
+| The **same vertical / brand / topic family** as an existing file, or a sub-aspect / increment / follow-up of a topic already covered (a *soft* distinction) | **Extend that file** — add a section, update `summary:` if it drifted. Don't fork a near-duplicate slug. Similar brands, similar verticals, similar topics belong together in the fewest files. |
+| A **genuinely separate topic / domain / concern** a future session would expect to find standing alone, where its own tag set sharpens discovery (a *sharp* distinction) | **Create a new file** (below). A clean topical boundary earns its own slug so tagging stays valuable. |
+
+The test for sharp-vs-soft: *Would a future recall expect this bundled with the existing file, or standing on its own? Would a separate file make the tag set more discriminating — or just split one topic across two slugs?* If splitting wouldn't sharpen the tags, extend.
+
+This is **not** "always make super-files." Distinct topics MUST get distinct files — that's exactly what makes tags worth having. It's the *soft* distinctions (same family, narrower slice, incremental finding) that fold into an existing file.
+
+**When the rubric says create:**
 
 ```bash
 dreamcontext knowledge create "<descriptive-slug>" \
@@ -230,6 +251,22 @@ Product-scoped knowledge. Cross-cutting findings still go to top-level `knowledg
 
 This is a one-time bootstrap per product; once the file exists, treat it like any other knowledge file (edit on demand, don't recreate).
 
+#### B6. Data structures (schemas / models / API contracts)
+
+Data structures live at `knowledge/data-structures/<product>.md` (`default.md` for single-product). They moved here from `core/` because schemas ARE domain knowledge — this gives them recall indexing, staleness flags, and the knowledge UI for free. **You own these writes now** (sleep-state only flags them for you).
+
+**Single-observation gate.** Unlike most knowledge (which waits for repetition), a schema/data-model change is reflected in the *same* cycle — no pattern repetition required. If `sleep-state` flagged a schema/table/model change, or the diff shows one, write it now.
+
+**Routing.**
+- Active task has `product: X` → `knowledge/data-structures/X.md` (create if missing).
+- Otherwise (single-product) → `knowledge/data-structures/default.md`.
+- Frontmatter: `type: data-structures`, `product: <name>`, `tags: [data-structures, database, schema]` (add domain tags as relevant).
+
+**Migration of the old locations** (idempotent; the dir move runs automatically on `dreamcontext sleep start`, but confirm + handle the legacy file):
+- If `core/data-structures/*.md` still exists and the knowledge copy is absent, it was (or should be) moved to `knowledge/data-structures/` — the `sleep start` migration handles this. Verify it landed.
+- If the even-older `core/5.data_structures.sql` exists and `knowledge/data-structures/default.md` does not, copy it there (add the data-structures frontmatter) — don't delete the legacy file.
+- **Never delete** the old `core/data-structures/` dir or the legacy `.sql` yourself — leave them for the user to remove after confirming (the `doctor` command nags about both). Note any migration in your report.
+
 ## Return — single combined report
 
 ```
@@ -247,8 +284,8 @@ This is a one-time bootstrap per product; once the file exists, treat it like an
 - No-op feature signals: 1 (signal "feature_advanced=marketing-dashboard-v0" — but PRD exists and no criteria moved)
 
 ### Knowledge
-- Created: knowledge/jwt-rotation-policy.md (tags: security, decisions; from sleep-state flag)
-- Updated: knowledge/competitive-analysis-ecc.md (added 2026-05-09 follow-up section)
+- 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:`
 - Pinned: knowledge/project-origin-and-prd.md (frequently accessed)
 - Archived: 0
 - No-op knowledge signals: 1 (`research_present` was a one-line decision already captured by sleep-state in 2.memory.md — not knowledge-worthy)
@@ -263,6 +300,7 @@ This is a one-time bootstrap per product; once the file exists, treat it like an
 5. **Create PRDs for buildable concepts** that don't have one — they will be lost otherwise.
 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. **Use standard tags only.** New tags fragment discovery.
-9. **Process all flags from sleep-state** in your report — don't silently drop them.
-10. **No-op cheaply** when signals don't actually warrant work.
+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.
+9. **Use standard tags only.** New tags fragment discovery.
+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

@@ -33,9 +33,8 @@ Identity is sacred — a fresh session must immediately understand who the agent
 | You touch | You don't touch |
 |---|---|
 | `core/0-4.*`, `core/6.*` files (Edit, surgical) | task files (sleep-tasks owns) |
-| `core/data-structures/<product>.md` (one per product; `default.md` for single-product) | knowledge files (you flag staleness; sleep-product writes) |
-| `dreamcontext core changelog add` | feature PRDs (sleep-product owns) |
-| `dreamcontext core releases {add,update,active,list,show}` | |
+| `dreamcontext core changelog add` | knowledge files incl. `knowledge/data-structures/<product>.md` (sleep-product owns + writes; you only flag staleness) |
+| `dreamcontext core releases {add,update,active,list,show}` | feature PRDs (sleep-product owns) |
 | `dreamcontext trigger add` (context-dependent reminders) | |
 
 ## Inputs
@@ -89,6 +88,7 @@ dreamcontext core changelog add \
   --summary "<≤200 char one-liner: what shipped, scannable in snapshot>" \
   --description "<one paragraph: what changed and why; mention key file/symbol where helpful>" \
   --references "commit:<sha>,file:<path>,knowledge:<slug>,feature:<slug>,task:<slug>,url:<href>" \
+  [--authors "<person-a,person-b>"] \
   [--supersedes "<date>|<scope>"] \
   $([ "$BREAKING" = "true" ] && echo "--breaking")
 ```
@@ -101,6 +101,8 @@ dreamcontext core changelog add \
 
 **Supersedes field**: optional, only when a later entry reverses or replaces an earlier one (e.g., a "default-on" flip of a previously "opt-in" flag, or a v0.4 file path being deprecated). Use coarse keys like `"2026-05-23|memory"` (date + scope) — disambiguators only matter when multiple entries share the same date+scope, in which case fall back to the position-from-top index. Most entries do NOT supersede anything; leave the field absent.
 
+**Authors field (multi-person projects only)**: optional, attributes the change to the person(s) who drove it. Set it ONLY when the project is multi-person (`.config.json` `people` roster has >1 entry — see Pass B.5). Pass comma-separated kebab-case slugs matching the roster (`--authors "mehmet,ada"`). Determine attribution from the same signals Pass B.5 uses (git `%an` on the commits the entry clusters, self-identification in the session transcript). When a single change was driven by distinct people across clusters, attribute each `dreamcontext core changelog add` invocation to its own author(s). Single-person projects: OMIT `--authors` entirely — output stays byte-identical to today. Authors are excluded from the changelog dedup fingerprint, so adding them never re-opens an already-released entry.
+
 #### A3. Releases — surface readiness, never auto-release
 
 ```bash
@@ -142,21 +144,20 @@ Be conservative. The default is **no change**. Only update when a pattern is rec
 
 #### B0b. Single-observation gate (code-reality files)
 
-Applies to: `3.style_guide_and_branding.md`, `4.tech_stack.md`, files under `core/data-structures/`, and `6.system_flow.md`.
+Applies to: `3.style_guide_and_branding.md`, `4.tech_stack.md`, and `6.system_flow.md`. (Schema/data-model changes are the same kind of single-observation signal, but they now live in `knowledge/data-structures/` — **sleep-product** owns that write; flag it for them rather than writing it yourself.)
 
-These files describe code reality, not user preferences. A single session adding/removing a dependency, schema, route, or workflow step MUST be reflected in the same cycle — no pattern repetition required. If the diff or transcript shows the change happened, write it.
+These files describe code reality, not user preferences. A single session adding/removing a dependency, route, or workflow step MUST be reflected in the same cycle — no pattern repetition required. If the diff or transcript shows the change happened, write it.
 
 Examples that trigger an immediate write:
 - A new dependency appears in `package.json` / lockfile → `4.tech_stack.md`.
-- A schema change, new table, or new model → relevant file under `core/data-structures/`.
+- A schema change, new table, or new model → flag for **sleep-product** to write `knowledge/data-structures/<product>.md`.
 - A new route, hook, or system-flow step → `6.system_flow.md`.
 - A new color token, font, or design primitive → `3.style_guide_and_branding.md`.
 
-**Multi-product routing.** If the active task frontmatter has `product: X`, route any tech_stack or data_structures observation to the matching product's file:
+**Multi-product routing.** If the active task frontmatter has `product: X`, route any tech_stack observation to the matching product's file:
 - Tech stack scoped to product X → still goes in `4.tech_stack.md` but tagged with the product label inline (single-file convention); if a project-specific convention emerges (per-product tech stacks), revisit.
-- Data structures → `core/data-structures/<X>.md`. Create the file if missing.
 
-Otherwise (no `product:` field, single-product project), data structures changes go to `core/data-structures/default.md`.
+Data-structure observations are routed by **sleep-product** to `knowledge/data-structures/<X>.md` (or `default.md`) — flag them for sleep-product, don't write them here.
 
 #### B1. Signal → file routing
 
@@ -167,7 +168,7 @@ Otherwise (no `product:` field, single-product project), data structures changes
 | New project constraint or warning | `0.soul.md` | Rules / Warnings | two-observation |
 | Technical decision worth preserving | `2.memory.md` | Technical Decisions | two-observation |
 | Stack/dependency change | `4.tech_stack.md` | | single-observation |
-| Schema / data-model change | `core/data-structures/<product>.md` (or `default.md`) | | single-observation |
+| Schema / data-model change | flag for **sleep-product** → `knowledge/data-structures/<product>.md` (or `default.md`) | | single-observation |
 | System flow / hook count change | `6.system_flow.md` | | single-observation |
 | Style/branding token change | `3.style_guide_and_branding.md` | | single-observation |
 
@@ -181,22 +182,38 @@ dreamcontext trigger add "<when>" "<remind>"   # context-dependent reminders
 
 Cross-domain catches from your own changelog pass land here naturally — if you wrote a `feat` entry whose description revealed a preference enforced twice, write it into `1.user.md` in the same cycle (no flagging needed; you own both files).
 
-#### B2. Legacy migration — `5.data_structures.sql` → `data-structures/<product>.md`
+### Pass B.5 — People detection (multi-person awareness)
+
+dreamcontext defaults to single-person. When you have **corroborated evidence** that more than one human works in this project, record the roster so changelogs/tasks/memory can attribute work per person. This is **AI-driven detection** — there is no manual toggle and no persisted `multiPerson` flag (multi-person status is DERIVED from `people.length > 1`).
+
+**Detection gate — require ≥2 corroborated signals** before flipping a project to multi-person (this gate prevents false positives; one weak signal is never enough):
 
-On every cycle, check for the legacy file:
+- **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 voice / handoff** — the transcript shows a clear authorship handoff or a different working style/voice than the established user.
 
 ```bash
-LEGACY=_dream_context/core/5.data_structures.sql
-NEW_DEFAULT=_dream_context/core/data-structures/default.md
-if [ -f "$LEGACY" ] && [ ! -f "$NEW_DEFAULT" ]; then
-  mkdir -p _dream_context/core/data-structures
-  cp "$LEGACY" "$NEW_DEFAULT"
-  # do NOT delete the legacy file here — leave it for WS-1 manifest cleanup (if system-installed)
-  # or the user to remove manually. Note the migration in your report.
-fi
+# Signal 2: distinct human git authors since the sleep epoch
+git log --since="$CUTOFF" --format='%an' | sort -u
+# Read the existing roster FIRST — you append, you never overwrite.
+jq -r '.people // [] | join(", ")' _dream_context/state/.config.json 2>/dev/null
 ```
 
-Report the migration in your output so the user knows the new location. Do not delete the legacy file yourself.
+When the gate is met:
+
+1. **Additive union to the roster — never overwrite.** Read the current `people` array first, then write the union (existing ∪ newly observed) back. Use kebab-case display-name slugs (`mehmet`, `ada`). A previously recorded person is NEVER dropped because they were quiet this cycle.
+
+   ```bash
+   dreamcontext config  # confirm current roster, then edit state/.config.json people[] = union
+   ```
+
+   (There is no CLI writer for `people` yet — edit `_dream_context/state/.config.json` directly with Edit, preserving every existing key. Do NOT add a `multiPerson` key; it is derived.)
+
+2. **Refresh `## People` in `1.user.md`** to enumerate the full roster. Use the `ensurePeopleSection(userMd, people)` helper semantics (idempotent insert/replace of a `## People` block; one bullet per person). This is a no-op for single-person projects.
+
+3. **Attribute this cycle's changelog entries** — re-run Pass A's `dreamcontext core changelog add` with `--authors "<slugs>"` for each entry, attributing it to the person(s) who drove that cluster (Pass A and this pass share the git-author analysis).
+
+**Single-person projects (gate NOT met): this entire pass is a NO-OP.** Do not create a roster, do not add a `## People` section, do not pass `--authors`. A solo project's `.config.json`, `1.user.md`, and changelog output must stay byte-identical to today. The cost of a false positive (spuriously attributing a solo user's work to a phantom teammate) is high — stay conservative.
 
 ### Pass C — Anti-bloat sweep + knowledge staleness flags
 
@@ -245,6 +262,10 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 - 4.tech_stack.md: untouched
 - Triggers added: 0
 
+### People (multi-person detection)
+- Roster: single-person (no multi-person signals this cycle) — no changes
+  | OR: detected 2 humans (signals: 2 distinct git authors + self-id in transcript) → roster updated mehmet, ada (additive union; ada appended, mehmet preserved); `## People` refreshed in 1.user.md; 3 changelog entries attributed via --authors
+
 ### Anti-bloat & staleness
 - 2.memory.md at 287 lines — under ceiling, no extraction needed
 - Knowledge staleness flags (for sleep-product):
@@ -259,7 +280,7 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 1. **Be exhaustive on the diary.** Every meaningful change gets a changelog entry. Skipping is the failure state.
 2. **Conservative on identity (preferences & decisions).** No-op is the right answer most cycles for `1.user.md` and `2.memory.md`.
 3. **Two-observation gate for `1.user.md` / `2.memory.md`.** One observation is data; two is a pattern. Don't write a preference or decision from a single mention.
-3a. **Single-observation gate for code-reality files** (`3.*`, `4.*`, `core/data-structures/*`, `6.*`). A diff that adds a dependency, schema, route, or design primitive MUST be reflected in the same cycle. These files mirror code, not opinion.
+3a. **Single-observation gate for code-reality files** (`3.*`, `4.*`, `6.*`). A diff that adds a dependency, route, or design primitive MUST be reflected in the same cycle. These files mirror code, not opinion. (Schema/data-model changes are the same kind of signal but live in `knowledge/data-structures/` — flag them for **sleep-product**.)
 4. **Cluster commits, don't enumerate.** Logical groupings beat 1-commit-per-entry.
 5. **Cover uncommitted work.** Don't wait for the user to commit.
 6. **Never auto-release.** Surface readiness; the user decides.

package/dist/agents/sleep-tasks.md

@@ -49,8 +49,41 @@ Also read `_dream_context/state/.sleep.json` directly for `sessions[].last_assis
 
 For each session:
 
-- **Has `task_slugs`** → those are the task(s) to update.
-- **No `task_slugs`** → check `last_assistant_message`, the user hint in the brief, and bookmark messages for a task name. If significant work has no matching task, **create one**:
+- **Has `task_slugs`** → those are the task(s) to update. Go to step 3.
+- **No `task_slugs`** → check `last_assistant_message`, the user hint in the brief, and bookmark messages for what the work was about.
+
+**Before creating anything, dedup against existing tasks.** Duplicate tasks — and tasks that are really just a smaller slice of one that already exists — are the #1 consolidation failure mode. A "much smaller piece" of an existing task is **never** its own task. Recall by topic and scan the active list first:
+
+```bash
+dreamcontext memory recall "<topic / feature / area>" --types task
+dreamcontext tasks list --status in_progress
+dreamcontext tasks list --status in_review
+```
+
+Then decide with this rubric — **default to folding in, not forking a new task**:
+
+| The session's work is… | Action |
+|---|---|
+| A **smaller piece, sub-step, or follow-up** of a task that already exists (same feature/area, narrower scope) | **Do NOT create a task.** Fold it into the existing one (see below). |
+| The **same work** as an existing task, observed again | Update that task (step 3). No new task. |
+| A **genuinely separate concern** — a different feature/area/deliverable, not a slice of an existing task | Create a new task (below). |
+
+**Folding a smaller piece into an existing task** (the case the system keeps getting wrong):
+
+1. If the existing task's scope grew to include this work, **broaden its title/scope** — Edit the frontmatter `description:` (the one-line scope) and the `## Why` so the header reflects the now-wider scope. Don't leave a stale, too-narrow title with the new work buried only in the changelog. (Renaming the slug/`name:` is usually unnecessary and breaks links — only do it if the scope fundamentally changed identity.)
+2. Add the new work as concrete **sub-items in the body**, not a new file:
+
+```bash
+dreamcontext tasks insert <slug> user_stories "<as a … I want …>"
+dreamcontext tasks insert <slug> acceptance_criteria "<testable criterion>"
+dreamcontext tasks insert <slug> notes "<follow-up / smaller piece>"
+```
+
+3. Tick/extend the Workflow Mermaid nodes if the task has them.
+
+**Sub-tasks (`parent_task`) are for genuinely large decomposition only** — an epic that legitimately splits into separable deliverables. Do not spawn a child task for a slice that fits as a user story or acceptance criterion in the parent. When in doubt, fold in.
+
+**Create a new task only when the rubric says "separate concern":**
 
 ```bash
 # Ensure an active planning version exists (orchestrator should have done this; verify)
@@ -63,7 +96,23 @@ dreamcontext tasks create "<descriptive-slug>" --status in_progress --priority m
   --description "<one-line scope>"
 ```
 
-Untracked work is invisible to future sessions. Always link.
+Untracked, genuinely-separate work is invisible to future sessions — always link it. But a smaller slice of existing work belongs *inside* that task, never in a duplicate.
+
+### 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).
+
+```bash
+# Read the current roster
+jq -r '.people // [] | join(", ")' _dream_context/state/.config.json 2>/dev/null
+```
+
+- **New task**: pass `--person <name>` to `dreamcontext tasks create` (the CLI injects a `person:<slug>` tag automatically).
+- **Existing task**: add the tag directly via Edit on the task frontmatter `tags:` array, or via `dreamcontext tasks insert`.
+
+When the person is already tagged on the task, no action is needed — the tag is additive. Do not remove a previously-set `person:` tag for a person who was quiet this cycle; they remain attributed for prior work.
+
+**Single-person projects (`.config.json` `people` has 0 or 1 entry): this step is a NO-OP.** Never inject a `person:` tag on a solo project. The output must stay byte-identical to today.
 
 ### 3. Log progress AND reconcile the body — both required
 
@@ -118,8 +167,10 @@ If every task linked to the active version is `completed` (or only `in_review` r
 ```
 ## sleep-tasks report
 - Updated: <slug> (in_progress → in_review, "<reason>"), <slug> (logged)
-- Created: <slug> (status: in_progress, attached to vX.Y.Z)
+- 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
 - Cross-domain mentions: <slug> includes a memory-worthy decision about JWT — flagging for sleep-state
 - Skipped: <session_id> had no actionable task signal
@@ -127,8 +178,10 @@ If every task linked to the active version is `completed` (or only `in_review` r
 
 ## Rules
 
-1. **Body = current truth, Changelog = history.** Don't let the body lag behind decisions.
-2. **Never auto-complete.** Bump to `in_review`.
-3. **Always attach to a planning version.** No orphan work.
-4. **Stay in your lane.** If you spot non-task work worth preserving, flag it — don't write it.
-5. **CLI first** for status/log/insert; **Edit** for surgical body reconciliation.
+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`.
+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).
+7. **Person attribution is multi-person only.** Read `.config.json` `people` first. If 0 or 1 entry, step 2.5 is a complete NO-OP — never inject `person:` tags on solo projects. Derived multi-person status comes from `people.length > 1`; there is no `multiPerson` key to check.

package/dist/dashboard/assets/{BrainCanvas3D-1HMiA14F.js → BrainCanvas3D-lFgJbbhZ.js}

@@ -1,4 +1,4 @@
-import{bs as jc,bt as I0,aM as pS,bu as xt,bv as Ip,bw as mS,bx as gS,by as _S,bz as xS,bA as yS,bp as vS,bq as bS,bB as B0,aC as SS,bC as TS,bD as MS,bE as ES,bF as xg,bG as yg,bH as AS,bI as k,bJ as $s,bK as wS,bL as RS,bM as CS,bN as NS}from"./index-Ds-JXWtr.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{bs as jc,bt as I0,aM as pS,bu as xt,bv as Ip,bw as mS,bx as gS,by as _S,bz as xS,bA as yS,bp as vS,bq as bS,bB as B0,aC as SS,bC as TS,bD as MS,bE as ES,bF as xg,bG as yg,bH as AS,bI as k,bJ as $s,bK as wS,bL as RS,bM as CS,bN as NS}from"./index-Bo5CUa_M.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