dreamteamer 0.18.0 → 0.19.1

package/collections/collections.collection.yaml

@@ -115,14 +115,29 @@ schema:
         opened on its own. It is stated here as DATA precisely so the record layer never has to
         learn what a module is; a bare string list rather than `x-reference: collections`, because
         the whole point is that the target is absent.
+    module:
+      type: string
+      description: >-
+        The module that OWNS this concept, as its bare id — DERIVED by compile from the base source,
+        and the one field a `dt set` may write: `dt set collections/<c> module=<m>` MOVES the
+        descriptor into that module. An overlay adds fields to somebody else's collection and does
+        not take it over, so the owner is the source declaring no `extends`. This is the workspace's
+        real partition, and what the nav groups by.
+    overlays:
+      type: array
+      items: { type: string }
+      description: >-
+        DERIVED by compile, never authored — the modules contributing an `extends:` overlay to this
+        collection, by id. ABSENT when there are none: an empty list is a statement nobody made.
+        `dt get collections/<c> --module <m>` prints one contribution alone.
     owner:
       type: string
       x-reference: modules
       description: >-
-        The module that OWNS this concept — DERIVED by compile from the base source, never authored.
-        An overlay adds fields to somebody else's collection and does not take it over, so `meetings`
-        stays owned by crm even though the workspace module overlays it. This is the workspace's real partition, and
-        what the nav groups by.
+        ⚠ COMPAT, ONE RELEASE ONLY — superseded by `module`, which carries the same fact as the bare
+        id the operator actually types. Kept because a surface groups its nav by this key and reads
+        it as a reference; both are written by compile until that surface has moved. Removed in the
+        release after 0.19.0.
     group:
       type: string
       description: >-

package/collections/modules.collection.yaml

@@ -26,7 +26,7 @@ id:
 title_template: "{{ name }}"
 schema:
   type: object
-  required: [name, channel]
+  required: [name, location]
   properties:
     name:
       type: string
@@ -37,10 +37,32 @@ schema:
         What to CALL this module — authored as `dreamteamer.title` in its package.json, else derived
         from the id. Authored because deriving cannot know an acronym: titleCase("crm") is "Crm".
         A module names itself, which is what replaces a display-name map maintained in a surface.
-    channel:
+    description:
       type: string
-      enum: [path, git, npm, inline]
-      description: How this module reached the workspace. `inline` is the workspace's own sources.
+      description: >-
+        What this module is FOR, in one line — authored as `dreamteamer.description` in its
+        package.json, never derived. Written by `dt add modules --description` and
+        `dt set modules/<id> description=…`.
+    namespaces:
+      type: array
+      items: { type: string }
+      description: >-
+        The namespaces this module DECLARES and owns — authored as `dreamteamer.namespaces` in its
+        package.json (§8). The workspace's effective set is the union of every module's declarations
+        plus its own; two modules declaring one namespace is a compile error, and USING another
+        module's namespace requires that module in `dependencies`. ABSENT means this module ships
+        into the default namespace — the empty prefix, which is the commons.
+    location:
+      type: string
+      enum: [modules, git_modules, node_modules, root]
+      description: >-
+        WHERE this module's sources sit — the folder name the operator already knows, so `dt status`
+        needs no legend. `root` is the classic no-workspace-module layout, where the workspace's own
+        sources live at its root rather than under `modules/<id>/`.
+        ⚠ Renamed from `channel` in 0.19.0, and the enum's `path` value was DELETED rather than
+        renamed: discovery never emitted it, so it was an enum advertising work nobody had done.
+        `origin` was rejected (one token from `origin/main`, which `update` literally pulls) and
+        `shape` was rejected (`storage.shape` owns that word).
     path:
       type: string
       description: Workspace-relative root of the module's sources.
@@ -84,6 +106,9 @@ schema:
         type: string
         x-reference: collections
 order: 140
-list_fields: [title, name, channel, collections]
+# ⚠ ALL THREE IDENTITY SPELLINGS. A module is one string after `add modules` (folder = package name
+# = id), and three strings for anything that predates it — so the listing shows the id (always
+# printed first), the package `name` and the `path`, which is how an operator sees the fork at all.
+list_fields: [location, path, namespaces, name, collections]
 icon: deployed_code
 group: system

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "dreamteamer",
-	"version": "0.18.0",
+	"version": "0.19.1",
 	"description": "A workspace compiler for coding agents — schema-validated records as plain files over git, compiled into every harness",
 	"license": "Apache-2.0",
 	"author": "Gilad Khen <giladkhen@gmail.com>",

package/skills/using-dreamteamer/SKILL.md

@@ -53,7 +53,7 @@ id, materializes defaults, and its writes are pathspec-scoped; touch a record fi
 when the CLI cannot express the change (a long body, a nested map) — and then you owe `dt check`
 (`references/records.md`).
 
-**`dt help` is the complete command surface** — record verbs, schema verbs, workspace verbs, and
+**`dt help` is the complete command surface** — record verbs, system verbs, field verbs, workspace verbs, and
 their flags, on one page (there is no per-verb `--help`).
 
 the verb names, as a map (semantics and flags live in `help`; a test holds this list to the
@@ -61,7 +61,7 @@ dispatch, so it cannot drift):
 
 - read & measure — `list` `get` `values` `history` `diff` `commands` `relations` `resolve`
 - write & publish — `add` `set` `rm` `rename` `move` `revert` `commit` `ensure`
-- schema (sources, through the compile gate) — `schema` `add-collection` `rm-collection` `rename-collection` `add-field` `update-field` `remove-field` `add-view` `set-view` `rm-view`
+- fields (sources, through the compile gate) — `add-field` `update-field` `remove-field` `rename-field` (system entities — modules, collections, skills, ui-views… — take the RECORD verbs above)
 - workspace — `init` `install` `update` `compile` `check` `status` `start` `changes` `help` don't learn syntax from prose, this skill included: prose drifts, and `help` ships in
 the same file as the dispatch it documents. run it once before your first write of a session.
 what prose adds is judgment — *when* a verb is the right move, and the guarantees you can lean
@@ -81,7 +81,7 @@ Load by the map; nothing here is loaded "just in case".
 | read, create, update, rename, delete, commit — or UNDO — a record | `references/records.md` |
 | "what changed while I was away" | `references/changes.md` |
 | the workspace seems unable to do something — a new kind of thing, a missing capability, "don't we already have this?" | `references/before-you-build.md` (look first); a new model then continues `references/data-modeling.md` (decide) → `references/collections.md` (write it) |
-| a collection or field, mechanically — the descriptor, the `schema` verbs, `templates:`/`extends:`, a compile or check message | `references/collections.md` |
+| a collection or field, mechanically — the descriptor, the system and field verbs, `templates:`/`extends:`, a compile or check message | `references/collections.md` |
 | knowledge a session should find on its own | `references/skills.md` |
 | "let me type one word and have this done" | `references/commands.md` |
 | "which command applies to this record?" — a binding, a gate | `references/commands.md` |
@@ -105,6 +105,36 @@ domain work — meetings, patients, invoices, whatever this workspace is about
 and `repos`, and deliberately nothing else. workspace-level rules live in `CLAUDE.md`, and a
 workspace's decision log (where one exists) wins over older documents.
 
+## system entities take the RECORD verbs
+
+Modules, collections, skills, agents, commands, command-bindings, ui-views and collection-templates
+are collections in the runtime, and since 0.19.0 the ordinary verbs write them:
+
+```
+dt add modules --name core --description "The shared nouns."
+dt add collections --name people --module core --description "A person."
+dt add-field people --name email --type string --description "Where to write to them."
+dt rename-field people --name email --to work_email
+dt set collections/people module=hr          # MOVES it to another module
+dt set modules/hr namespaces=hr dependencies=modules/core
+dt rm modules/hr --force                     # --dry-run first; it prints its plan
+```
+
+`dt schema <op>` is **gone** since 0.19.0 and fails with the translation printed. `UPDATING.md` has
+the complete mapping table.
+
+⚠ **ONE difference, and it is POLICY rather than spelling: a SYSTEM write commits itself; a RECORD
+write does not.** An uncompilable or unpublished schema is not a state a workspace should sit in, so
+every system verb writes its source, proves it with a real compile, and commits — **in the repo that
+holds the source**, so a write into a `git_modules/` module commits there and says
+`ahead 1 — push when ready`. A record write lands on disk and `dt commit` publishes it.
+
+⚠ **Every verb that moves records or clears values takes `--dry-run` and prints its plan first:**
+`rename collections/…`, `rename-field`, `remove-field`, `set collections/… module=`,
+`rm modules/… --force`. The plan line is one shape — `records N · refs M · descriptors K · values
+cleared V` — so two dry runs are comparable, and a term that reads 0 means zero rather than
+unmeasured (where a number genuinely cannot be known before the run, the plan says so in words).
+
 ## the rules that hold in both acts
 
 1. **sources live in a module** — `modules/<module>/<kind>/`; the workspace's own go in its
@@ -124,7 +154,7 @@ workspace's decision log (where one exists) wins over older documents.
    overwritten and pruned on the next compile — if you found the thing to change there, you are
    in the wrong file.
 7. **the CLI refuses system-stored records on purpose** (`dt set skills/<id>` — no): edit the
-   module source and compile. the `schema` verbs are the sanctioned exception — they write
+   module source and compile. the SYSTEM verbs are the sanctioned exception — they write
    sources *through* a compile gate, so an uncompilable source can never land.
 8. **never duplicate a procedure across records.** a command body restating a skill, an agent
    inlining its skill's steps — two copies, and one drifts. reference the owner.

package/skills/using-dreamteamer/references/before-you-build.md

@@ -1,7 +1,7 @@
 # before you build — look for it first
 
 The situation: the operator asked for something the workspace does not seem to do, and you are one
-`schema add-collection` or one new skill away from making it exist. This reference is the pause
+`dt add collections` or one new skill away from making it exist. This reference is the pause
 before that. **When the workspace can't do something, look before you build — and when you do find
 something, propose concretely, never install or copy silently.** The operator decides what enters
 their workspace.
@@ -43,7 +43,7 @@ install. The looking still matters; the taking changed shape.
 | 1 | **this workspace's own modules** | the orientation block's COLLECTIONS list is already in your context — reread it with the concept's *synonyms* in mind; `.dreamteamer/manifest.yaml` names every module and entry; `dt help` shows the verbs and `dt commands <collection>` the bound ones; the skills index shows the techniques | the thing may already exist under a name you didn't guess. This is where misses actually happen, because it is the place you assume you already know |
 | 2 | **a recipes repo — where this workspace's own CLAUDE.md names one** (reference modules maintained to be **copied and adapted**) | read that repo's own instructions first; they ARE the adoption procedure. no recipes repo declared → skip this row | a working module with its reasoning attached — descriptors, skills, and the trap notes that each cost someone a day |
 | 3 | **a sibling workspace — where the operator has named one** | read-only; grep its `modules/` for the concept. none named → skip | another vault may have solved it concretely. That is a *reference*, not a source — it holds real personal data, so read the shape, never lift the content |
-| 4 | **the engine's own surface** | `dt help` — the complete verb surface, schema verbs included; read it rather than recalling it | the capability may already be a verb (`relations rebuild`, `resolve`, `ensure`) rather than a missing module |
+| 4 | **the engine's own surface** | `dt help` — the complete verb surface, system and field verbs included; read it rather than recalling it | the capability may already be a verb (`relations rebuild`, `resolve`, `ensure`) rather than a missing module |
 
 Only after all four: build it, in the module that owns the concept.
 

package/skills/using-dreamteamer/references/collections.md

@@ -11,7 +11,7 @@ reference is organized for both:
 | the question | read |
 |---|---|
 | what compile actually does to my source | the pipeline |
-| create or change shape with the CLI | the schema verbs |
+| create or change shape with the CLI | the system and field verbs |
 | a brand-new module for a domain | declaring a module |
 | a prefix / a folder per domain | namespaces |
 | the same field set on several collections | `templates:` |
@@ -54,13 +54,13 @@ order explains most "why does the compiled file say that" questions:
 Consequence: **read the compiled file to know what IS; edit the source to change it.** They
 differ by design, and diffing them is often the fastest way to see what compile decided for you.
 
-## the schema verbs — writes through a compile gate
+## the system and field verbs — writes through a compile gate
 
 The one sanctioned way to write schema without hand-editing. Every verb round-trips through a
 **compile gate**, so a change that would not compile is rejected before it lands — and unlike a
 record write, a schema verb **commits its source write itself**, because an uncompilable or
 unpublished schema is not a state the workspace should sit in. The verbs and every flag live in
-`dt help` under "schema verbs" — read that, not prose. What help cannot tell you:
+`dt help` under "system verbs" and "field verbs" — read that, not prose. What help cannot tell you:
 
 - **The field verbs write the WORKSPACE module.** On a collection another module owns, `add-field`
   and `update-field` author an `extends:` overlay in the workspace module — which compiles only
@@ -84,7 +84,7 @@ unpublished schema is not a state the workspace should sit in. The verbs and eve
 - **`add-field` inserts before the `x-body` field**, on the same rule as a `templates:` merge
   below: property order is form order, and a record's body belongs last. `update-field` never
   reorders — an existing field keeps the place its author gave it.
-- **`schema rename-collection <old> <new>`** moves the descriptor **in the module that ships it**
+- **`dt rename collections/<old> <new>`** moves the descriptor **in the module that ships it**
   (its guard is against writes an `npm install` would erase, not against modules), plus the
   records, the filenames and every inbound reference — `x-reference` targets in other descriptors
   and ui-views included — in ONE commit. It refuses: a runtime source, an **overlaid** collection
@@ -129,9 +129,15 @@ module graph (the reference contract, below).
 
 A collection name may carry a slash-delimited namespace, and it becomes real directory nesting:
 
-| declare in the workspace `package.json` | create it | lands in | referenced as |
+| declare in the OWNING MODULE's `package.json` | create it | lands in | referenced as |
 |---|---|---|---|
-| `"namespaces": ["health"]` | `dt schema add-collection --namespace health --name doctors` | `data/health/doctors/` | `health/doctors/dana-levi` |
+| `"dreamteamer": {"namespaces": ["health"]}` | `dt add collections --name doctors --module clinic` | `data/health/doctors/` | `health/doctors/dana-levi` |
+
+A module declaring exactly ONE namespace **infers** it, and the resolved name is always echoed
+(`✔ health/doctors (namespace inferred from module clinic)`). Two or more declared and it refuses
+to guess: `--namespace health`. `--namespace ''` means no namespace. `--namespace x` where nobody
+declares `x` writes the declaration into the target module — which is what travels when the module
+is copied.
 
 - **The default namespace is the empty prefix.** `tasks` stays `data/tasks/` and `tasks/kickoff`,
   so common entities need no prefix and adopting namespaces migrates nothing. `default` is
@@ -139,8 +145,22 @@ A collection name may carry a slash-delimited namespace, and it becomes real dir
 - ⚠ **The namespace MUST be declared before the collection compiles.** An id is also a slash path
   (`meetings/2026/07/kickoff`), so `a/b/c` is ambiguous without the declared set; an undeclared
   prefix is a compile error rather than a reference that silently names a different collection.
-- **Namespaces are declared by the WORKSPACE only, never by a module** — a module that could
-  declare one could rename where another module's records live.
+- **A MODULE declares the namespaces it owns** — `"dreamteamer": { "namespaces": ["hr"] }` in its
+  own `package.json`, and the workspace's effective set is the **union** with its own
+  `dreamteamer.namespaces`. This reversed in 0.19.0. The old rule ("the workspace only, never a
+  module") had a real reason — a module that can declare a namespace can rename where another
+  module's records live — but it made decision 130's own acceptance test, *"a module compiles alone
+  in a bare workspace"*, unpassable for any namespaced module: the consuming workspace had to edit
+  its manifest first, which is exactly the coupling that rule forbids.
+  - **One owner per namespace.** Two modules declaring it is a compile error naming both.
+  - **Using another module's namespace requires the dependency** — shipping `hr/<c>` while only
+    `hr` declares `hr` means listing `hr` in your `dreamteamer.dependencies`. Without this rule the
+    union would let you squat in another module's namespace silently.
+  - **A workspace-level declaration a module also declares is a WARNING**, not an error, and
+    `dt set modules/<m> namespaces=<ns>` removes the redundant workspace entry in the same write.
+  - **The set is a function of the INSTALLED MODULE SET.** Removing or disabling a namespace-owning
+    module re-splits every reference into it; `check` reports the dangle, and the compile error says
+    the namespace was declared by a module you just removed. `default` stays reserved.
 - `--namespace health --name doctors` and `--name health/doctors` are the same thing. The
   descriptor lands at `collections/health/doctors.collection.yaml` — `collections/` is enumerated
   recursively, so the source tree mirrors the runtime — and the `suffix` comes off the bare name
@@ -203,7 +223,7 @@ Two gates around it:
   hardest dependency there is (the overlay does not compile at all without its base), so compile
   refuses the undeclared case. The workspace module gets **no exemption here** (unlike the
   mirror-stamp and wildcard gates, which do exempt it) — this is exactly the refusal you meet
-  when a field verb targets a module-owned collection (the schema verbs, above).
+  when a field verb targets a module-owned collection (the field verbs, above).
 - ⚠ **An overlay can add fields but cannot remove an inherited one.** If the shape is wrong for
   the module rather than just for this workspace, fix the base.
 

package/skills/using-dreamteamer/references/data-modeling.md

@@ -4,7 +4,7 @@ The user states a requirement — "track the clinic's visits", "stop losing lab
 a data architect. This reference is what stands between that sentence and a model: it turns the
 requirement into collections, fields and relations that are searchable, filterable, legible in any
 surface, cheap to keep, and still right a year in. Method and judgment live here; mechanics (the
-meta verbs, namespaces, `templates:`, registering an existing folder) live in `collections.md`.
+system and field verbs, namespaces, `templates:`, registering an existing folder) live in `collections.md`.
 
 It is long on purpose. It is the reference for the single highest-leverage act in a dreamteamer
 workspace — a model outlives every skill and command written against it — and the reader is usually
@@ -189,7 +189,7 @@ The interview's output is **not prose**. Show, before anything is written:
    verbatim. Seeding one real record before declaring the schema catches half the field mistakes —
    the missing unit, the enum value the domain actually spells differently, the id that comes out
    wrong.
-3. The **`dt schema` commands** (or the hand-written descriptor when the collection is
+3. The **system verbs** (`dt add collections`, `dt add-field`, …) (or the hand-written descriptor when the collection is
    module-owned or carries comments worth keeping).
 4. The **"deliberately not modelled"** list, each with its one-line reason.
 5. For each relation: which side owns, whether an inverse is declared, and the answer to "which X
@@ -222,9 +222,17 @@ alone in a bare workspace.** Everything else follows from that.
 - **A cross-module relation is a declared dependency.** An inverse stamps a generated field onto
   another module's collection, so compile refuses it unless the declaring module lists the
   target's module in its dependencies — a module may not grow fields on a stranger silently. (The
-  workspace module is exempt; it overlays everything by design.)
-- **Start in the workspace module; extract on the second consumer, not the first hunch.** The meta
-  verbs write the workspace module, and that is the right first home for everything. A module is
+  workspace module's exemption is rule 6 ONLY — see below.)
+- ⚠ **The workspace module's exemption is rule 6 ONLY, and rule 6 is `x-reference: '*'`.** It may
+  reference anything, including collections that do not exist yet — that is what `tasks.item`
+  means, and anywhere else a wildcard draws a warning (an unverifiable cross-module surface). It is
+  **NOT** exempt from the `extends` dependency gate: an overlay in the workspace module on another
+  module's collection still requires that module in `dreamteamer.dependencies`, exactly as any
+  other overlay does. Measured 2026-09-01 — and the reason the two read as one exemption is that
+  they are both "the workspace module is special", which it is, in exactly one of the two places.
+- **Start in the workspace module; extract on the second consumer, not the first hunch.** The
+  system verbs default to the workspace module (`--module <m>` names another), and that is the
+  right first home for everything. A module is
   worth extracting when its collections form a closed reference graph, when a second workspace
   wants it, or when its vocabulary has stabilised — not before. Premature extraction buys a
   boundary you will immediately need to breach.
@@ -251,7 +259,7 @@ sane:
   owned by a "meeting" namespace).
 - Declare the namespace before the first collection compiles — an id is also a slash path, so an
   undeclared prefix is ambiguous and compile refuses it rather than guessing.
-- Namespacing an existing collection later is `dt schema rename-collection <old> --namespace <ns>`
+- Namespacing an existing collection later is `dt rename collections/<old> --namespace <ns>`
   — one commit, every inbound reference rewritten, safe at any point. Cheapest early, though: the
   rewrite is O(records × files), measured at ~3 minutes for a 2,291-record collection — tolerable
   for a one-time migration, not free. So do not agonise up front; just decide sooner rather than
@@ -807,15 +815,19 @@ useless until the flood is drained.
 
 ### 41. Renames
 
-- **Collections**: `dt schema rename-collection <old> <new>` — descriptor, records, filenames and
+- **Collections**: `dt rename collections/<old> <new>` — descriptor, records, filenames and
   every inbound reference in one commit. Safe, and cheapest early — the rewrite is
   O(records × files), measured ~3 minutes at ~2,300 records — so do it the day the name is wrong,
   not the year after.
-- **Fields**: there is no rename verb, deliberately (a rename that rewrites every record is a
-  migration, and pretending otherwise invites half-renames). The honest sequence: add the new
-  field; a one-shot script moving the values (committed with the records it rewrote, the commit
-  message being the ledger); `schema remove-field` the old one — which clears any leftovers and
-  reports the count.
+- **Fields**: `dt rename-field <c> --name <f> --to <g>`, since 0.19.0 — one commit, and it
+  rewrites far more than the records: `list_fields`, `sort_field`, `x-inverse`, `x-inverse-of`,
+  `title_template`, `id.generate`, a ui-view's `options.columns` and `filter`, and a
+  command-binding's `can-enter`/`can-exit`. A field is referenced BY NAME rather than as a
+  `<collection>/<id>` reference, so `store.rewriteRefs` can see none of those — which is exactly
+  why this used to be "no rename verb, deliberately", with the honest sequence being add-new,
+  script the values, `remove-field` the old. That sequence still works and is what you want when
+  the values themselves have to CHANGE shape; when only the name changes, the verb is one command
+  and takes `--dry-run`.
 - **Values** (an id, a reference target): `dt rename <collection>/<old> <new>` rewrites inbound
   references. Prose wikilinks are followed in both spellings — `[[collection/id]]` always, and a
   bare `[[id]]` when that basename names exactly ONE record in the workspace; when something else

package/skills/using-dreamteamer/references/getting-started.md

@@ -60,9 +60,10 @@ real records. Not five collections, not a namespace plan, not a module layout.
 2. **Propose small, then stop.** The proposal contract (`data-modeling.md` §7): the descriptor
    YAML, one sample record as its `dt add` line, and what is deliberately NOT modelled. The
    operator says yes before anything lands.
-3. **Create it in the workspace module** — `dt schema add-collection` (it compiles and publishes
-   itself). The workspace module is the right first home for everything (`data-modeling.md` §8);
-   extraction is a decision for the second consumer, months away.
+3. **Create it** — `dt add collections --name <c> [--module <m>]` (it compiles and publishes
+   itself). It lands in the module you NAME, defaulting to the workspace module — which is the
+   right first home for everything (`data-modeling.md` §8); extraction is a decision for the
+   second consumer, months away.
 4. **Seed three to five REAL records immediately** with `dt add` — not test data. Seeding real
    records before declaring the model finished catches half the field mistakes: the missing unit,
    the enum the domain spells differently, the id that comes out wrong.
@@ -90,7 +91,7 @@ The pile is evidence; read it before modeling anything.
    folder), and a record points at each via a `${env:VAR}` template — the filing convention and
    the mechanics are in `records.md`.
 4. **Restructure later, with the tools that keep references true** — `dt rename`,
-   `dt schema rename-collection` — not during the first pass. Model reality first; `check` will
+   `dt rename collections/<old> <new>` — not during the first pass. Model reality first; `check` will
    tell you what reality violates, and that list, not taste, drives the cleanup.
 
 ## path C — into a repo that already holds code
@@ -108,6 +109,6 @@ prefers. Nothing about the code moves; `check` and `compile` read only what desc
 | test data in the seed records | real records are what catch the model's mistakes |
 | skipping git as "too technical" | one local command, no account — and it is the history, the undo and the publish step |
 | inventing ids by hand | `id.generate` owns identity — pass `--id` only when the operator named one |
-| hand-writing the first descriptor | `dt schema add-collection` is compile-gated and publishes itself; hand-written sources owe `dt compile` |
+| hand-writing the first descriptor | `dt add collections` is compile-gated and publishes itself; hand-written sources owe `dt compile` |
 | rewriting existing files to fit a guessed schema | describe reality, compile, `check` — then decide which violations are worth fixing in the data |
 | waiting for a UI before starting | the CLI and the records are the complete system; any surface renders them later, unchanged |

package/skills/using-dreamteamer/references/ui-views.md

@@ -128,7 +128,7 @@ same record. A misspelled key is read by nobody, silently. The two edges that bi
   (`options.arrangement`) has only the JSON spelling.
 - ⚠ **`options.sort` must be written even when empty** (`sort: ''`), or "unsorted" cannot
   round-trip and silently reverts to a fallback ordering on the next load. The spelling is a
-  QUOTED value — `dt schema set-view <id> 'options.sort=""'` — because a bare `options.sort=`
+  QUOTED value — `dt set ui-views/<id> 'options.sort=""'` — because a bare `options.sort=`
   removes the key, as an empty value does everywhere else. Quoting any value makes it a literal
   string (`options.sort='"-date"'` is the same as `options.sort=-date`).
 
@@ -152,7 +152,7 @@ One shape, one home, both agent-writable, both diffable in git.
 
 ## the CLI can write these
 
-`dt schema add-view | set-view | rm-view` — `add-view` derives the record id from `path` with the
+`dt add ui-views` / `dt set ui-views/<id>` / `dt rm ui-views/<id>` — `add` derives the record id from `path` with the
 descriptor's own template, so a view saved from the CLI and one saved from the UI land on the
 **same record**; `set-view <id>` takes dotted keys (`options.sort=-date`, `nav.label=Recent`). This is the one system-stored
 kind with full CLI write support, because it goes through the same compile gate. Two edges: