dreamteamer 0.15.0 → 0.15.1

package/collections/collections.collection.yaml

@@ -37,7 +37,17 @@ schema:
       properties:
         path:
           type: string
-          description: Folder holding the records, workspace-relative. `data/` for content, `state/` for operational records, `system/` for sources.
+          description: >-
+            Folder holding the records, workspace-relative. `data/<collection>` — that is the answer
+            unless you can state a reason. `state/<collection>` is DEPRECATED as a convention since
+            2026-08-31: decision 4 created it for runs, triggers, registries and cursors, all seven
+            of those collections have been deleted, and the one real operational-data need that
+            arrived since went to a gitignored `.cache/*.jsonl` because append-only readings are the
+            wrong shape for records. The mechanism still works and is kept, exactly like `group`
+            below, so a workspace wanting a second root has one. ⚠ NEVER author `system/` — sources
+            have lived in `modules/<module>/<kind>/` since the 2026-08-05 flatten, and a `system/`
+            prefix is only how `runtime.js` recognises a RUNTIME collection in a descriptor compiled
+            by a pre-flatten engine.
         codec:
           type: string
           enum: [md, yaml, json, file]

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "dreamteamer",
-	"version": "0.15.0",
+	"version": "0.15.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/building-dreamteamer/references/data-modeling.md

@@ -268,12 +268,24 @@ model wants a shared **template** plus two thin descriptors — or a reference b
 base collection that exists only to be extended. An abstraction with one concrete consumer is a
 roadmap, not a model; wait for the second consumer.
 
-### 11. Where records live: `data/` vs `state/`, codecs, shapes
-
-- **`data/` holds content; `state/` holds operational records** — cursors, run markers, cached
-  readings; things a human never edits and would not mourn. The split is a `storage.path` choice
-  and it matters because `data/` is what gets read, searched and reasoned over; polluting it with
-  machinery makes every list noisier.
+### 11. Where records live: `data/`, codecs, shapes
+
+- **`data/` is where records go.** `storage.path` is free-form, so a collection can be pointed
+  anywhere in the workspace, but the answer is `data/<collection>` unless you have a reason you can
+  state.
+- ⚠ **`state/` is DEPRECATED as a convention — do not spend a decision on it.** It was created as
+  the home for "operational records": runs, triggers, registries, cursors. All seven of those
+  collections were later measured unused and deleted, so its entire reason went with them. The
+  mechanism still works end to end (a collection declaring `storage.path: state/<name>` writes,
+  lists and checks correctly) and is kept for anyone who wants a second root — but nothing ships
+  there, and `dt init` no longer creates the folder.
+- **The need it was aimed at is real; records were the wrong answer.** When genuine operational data
+  finally arrived — cached provider readings, thousands of append-only rows — it went to a
+  gitignored `.cache/<thing>.jsonl`, and that was right: one record per reading would have been
+  thousands of files nobody opens individually, churning git for nothing. So the rule is not "put
+  machinery in `state/`", it is **do not model machinery as records at all**. In descending order:
+  a field on a record that already exists · a line appended to a gitignored cache file · a real
+  collection, if and only if you will genuinely list, filter and read the things one at a time.
 - **`codec: md` whenever a human reads a body; `yaml` when nobody does.** A record that is all
   fields and no prose (a lab value, a transaction, a cursor) is `yaml` — the body would only ever
   be empty. `json` exists for tool-written records.

package/skills/using-dreamteamer/SKILL.md

@@ -33,7 +33,6 @@ demand:
 | provenance | `.dreamteamer/manifest.yaml` | which module shipped which entry |
 | sources (write) | `modules/<module>/` — **including the workspace's own**, the `dreamteamer.workspace-module` named in `package.json` | a source folder at the workspace ROOT is a compile ERROR. same-name collisions across modules are compile errors too. after ANY source change: `npm run compile` |
 | content records | `data/<collection>/` | per each descriptor's `storage.path` |
-| operational records | `state/<collection>/` | whatever a module declares there; core ships none |
 
 - a record is a `<id>.<suffix>.<ext>` file (or a folder, for folder-shape collections). **the id is
   the path** inside the collection folder minus suffix and extension — nested folders join in:

package/src/harnesses.js

@@ -305,8 +305,7 @@ function orientationBlock(flavor, skillsIndex, sourceLayout = 'flat', namespaces
 		'working with data.** schemas (read): `.dreamteamer/collections/` (provenance:',
 		'`.dreamteamer/manifest.yaml`). sources (write): ' + sourcesLine,
 		'`command-bindings/`, `ui-views/`, `collection-templates/`',
-		'(see manifest for channels). data: `data/`; operational records:',
-		'`state/`. records are `<id>.<suffix>.<ext>`',
+		'(see manifest for channels). data: `data/`. records are `<id>.<suffix>.<ext>`',
 		'files; ids are paths; references are `<collection>/<id>`. run `dreamteamer check` (`npm run',
 		'check`) after bulk edits; run `dreamteamer compile` (`npm run compile`) after changing any',
 		'source or installing modules.',

package/src/init.js

@@ -108,7 +108,14 @@ export function init({ flags = {} } = {}) {
 	const starter = path.join(systemRoot, 'collections', 'notes.collection.yaml');
 	if (!fs.existsSync(starter)) fs.writeFileSync(starter, STARTER_COLLECTION);
 	fs.mkdirSync(path.join(root, dataPath), { recursive: true });
-	fs.mkdirSync(path.join(root, 'state'), { recursive: true });
+	// NO `state/` is created. It was decision-4's home for operational records — runs, triggers,
+	// registries, cursors — and every one of those seven collections has since been deleted. When a
+	// real operational-data need finally arrived (cached provider readings) it went to a gitignored
+	// `.cache/*.jsonl` instead, because thousands of append-only readings are the wrong shape for
+	// records at all. So `state/` is a working facility with no users, and seeding an empty folder
+	// for it is the "capability that needs a record before it exists" smell. The MECHANISM is kept —
+	// `storage.path: state/<name>` still compiles, writes, lists and checks — so a workspace that
+	// wants a second root has one; the engine just stops advertising a fork nobody has taken.
 
 	// NO user record is seeded, and there is no `users` collection — both removed from core in 0.8.0.
 	// It failed the "does the ENGINE read it?" test on a circular justification: `users` was core