dreamteamer 0.6.0

package/skills/building-dreamteamer/references/skills.md

@@ -0,0 +1,73 @@
+# skills
+
+A folder-shape record: `modules/<module>/skills/<name>/SKILL.md`. The folder name IS the id,
+and extra files (references, scripts, assets) travel with the folder.
+
+## create — and don't
+
+**Create:** a technique that wasn't obvious, will recur, and applies beyond one record.
+**Don't:** one-off fixes (just do them), workspace conventions (`CLAUDE.md`), or anything a
+validator can enforce mechanically — automate that instead and save prose for judgment calls.
+
+## the description is a TRIGGER, never a summary
+
+The description is what a session scans to decide whether to load the skill. It must state **when to
+use it** — symptoms, situations, verbs — and must NOT summarize the workflow: a description that
+summarizes the process becomes a shortcut the agent follows *instead of reading the skill*, silently
+skipping the steps the summary dropped.
+
+```yaml
+# ✖ workflow summary — the agent may follow this and never read the body
+description: transcribes audio via whisper then fills the speaker map then commits
+# ✔ trigger only
+description: use when a meeting recording or pasted transcript needs to land in its meeting record
+```
+
+Third person, lead with "use when", pack in searchable keywords (error strings, symptoms, synonyms,
+tool names). Name = verb-first gerund (`writing-x`, `detecting-y`).
+
+## body craft
+
+- **Lean.** Aim under ~500 words in `SKILL.md`; concrete over complete — what to read first, the
+  exact shape to produce, the runnable commands. Cross-reference sibling skills instead of repeating
+  them.
+- **Progressive disclosure for anything larger.** Keep `SKILL.md` as the digest — routing plus the
+  rules that apply everywhere — and put per-topic detail in `references/<topic>.md` that the digest
+  points at by name. A session then pays for the map, not the whole territory. `building-dreamteamer`
+  and `using-dreamteamer` are both built this way.
+- **One excellent example** beats many mediocre ones; real, adapted from a live workspace.
+- **Discipline skills** (rules under pressure) must close loopholes explicitly: name the workarounds
+  and forbid them, add a rationalization table ("excuse → reality") and a red-flags list. A rule
+  without its loopholes named will be rationalized around.
+- Flowcharts only for genuinely non-obvious decisions; tables for reference.
+- **Write down the traps.** The most valuable line in most of these skills is a measured failure
+  mode — a limit, a silent-success bug, a stale-config symptom — because it transfers perfectly and
+  cost someone a day to find. Include the measurement; drop the identities around it.
+
+## no personal or account data
+
+Skills ship with modules and are read by any operator — never bake in secrets, keys, names, emails
+or account-specific paths. Per-install values go through `.env` (gitignored); the skill names the
+variable it reads and what happens when it is missing.
+
+## heavy assets
+
+Models, caches and venvs live in dot-prefixed subfolders (`.models/`, `.cache/`, `.venv/`) with a
+**skill-local `.gitignore`**. Compile skips dot-prefixed names, and local ignore rules travel with
+the folder through extraction.
+
+⚠ **Runnable assets must be referenced at their SOURCE path**, not under `.claude/skills/…` — that
+is generated output, wiped and rebuilt every compile, and anything with local dependencies
+(a `package.json`, a venv) only works where it was installed. Note the cost: a source path embeds
+the module name, so renaming a module means updating every skill that names its own scripts.
+
+## verify before calling it done
+
+Compile, check, and — for any skill whose misreading would cost real work — **dispatch a
+fresh-context subagent with a realistic task** and watch whether it finds, loads and follows the
+skill correctly. What it gets wrong is what the skill still fails to say; fix and re-run. Reading
+your own skill proves nothing.
+
+**The reference bar:** the superpowers plugin skillset. Study a few of its skills before writing
+one — its structure (overview / when-to-use with symptoms / quick reference / common mistakes), its
+discipline patterns and its lean prose are the standard dreamteamer skills are held to.

package/skills/building-dreamteamer/references/ui-components.md

@@ -0,0 +1,78 @@
+# ui components
+
+**Components are prebuilt code, not records.** There is no ui-components collection, no descriptor,
+no compile step for the component itself. This is an ordinary Vue coding session against a module's
+`studio/` source tree — *code registers everything renderable; yaml records configure and assemble.*
+
+⚠ **Reach for a record first.** A `ui-view` pointing an existing `layout`/`edit`/`view` id at your
+data costs no build and no code to maintain. Write a component only when nothing registered can do
+the job.
+
+## the registries
+
+| registry | what it holds | bound by |
+|---|---|---|
+| `edits` | field editors + whole-record Edit pages | a field's `edit` meta; `scope: 'record'` for a page |
+| `views` | field read-renderers + whole-record View pages | a field's `view` meta |
+| `lists` | collection browse arrangements (table, cards, kanban, …) | a `ui-view` record's `layout` |
+| `apps`, `panels`, `operations` | routed subtrees, dashboard panels, flow operations | registration alone |
+
+The host's own built-ins register through the exact same door a module uses — read its
+`register-defaults.ts` as the reference.
+
+## the module contract
+
+A module ships a browser entry (`studio/app.js`, or a built `studio/dist/app.js`) that compile stages
+to `.dreamteamer/ui/<module>/app.js`; its **default export** is a register function:
+
+```js
+export default ({ registerEdit, registerView, registerList, registerApp, registerPanel }) => {
+  registerList({ id: 'kanban', name: 'Kanban', component: MyKanban, fillsHeight: true });
+};
+```
+
+- **Never bundle Vue.** The host exposes its own Vue as `window.Vue` *before* importing any module
+  entry; two copies break reactivity silently. Use `window.Vue`, or mark `vue` external and map it to
+  the global.
+- **Give every entry an explicit stable `id`.** That string is what a `ui-view.layout` or a field's
+  `edit`/`view` meta names. Changing it breaks every binding.
+- **`types: []` opts an Edit/View out of kind-inference.** A non-empty `types` array makes it a *kind
+  default* for that wire type — which means a bare `string` or `json` field anywhere in the workspace
+  silently gets your bespoke widget. Most custom components should stay `types: []`.
+- **`fillsHeight: true`** declares that this List owns its own scrolling; the page then stops
+  scrolling vertically and hands the List the leftover height. Layouts that should grow the page
+  (table, cards) must not set it.
+- **Failures are isolated, not surfaced.** A module whose entry fails to import or throws while
+  registering is caught, warned and skipped — the surface still loads, your component just never
+  appears. **Read the browser console**; nothing else will tell you.
+
+⚠ **A module registering a CORE id WINS, silently.** Module bundles load after the built-ins and the
+registry is a `Map.set`, so a module `kanban` shadows the core `kanban` with no warning anywhere —
+which once meant an operator had been using a strictly worse board for weeks and nothing could reveal
+it from the outside. Never reuse a core id unless shadowing is exactly what you mean.
+
+⚠ **Portalled UI cannot rely on scoped CSS.** Menus, popovers and dialogs are teleported outside the
+component subtree, so a scoped rule looks correct in the source and is simply absent at runtime — the
+failure mode is invisible chrome, not an error. Define those styles globally.
+
+## workflow
+
+1. Write the component in the module's `studio/` tree.
+2. Register it in that module's `app.js` with a stable `id`.
+3. Plain-JS `app.js` needs no build; a module wanting a toolchain builds to `studio/dist/app.js`
+   itself. Declare any Lists in `package.json` `dreamteamer.studio.layouts`, then compile to stage it.
+4. Look at it in the real surface.
+5. **Bind it** — a field's `edit`/`view` meta, or a `ui-view.layout` naming the `id`. Only this step
+   touches records.
+
+## common mistakes
+
+| mistake | reality |
+|---|---|
+| looking for a ui-components collection | there isn't one; this is code |
+| bundling Vue | two copies; reactivity dies silently |
+| assuming a registration error is reported | swallowed by fault isolation — read the console |
+| `types: ['string']` on a bespoke widget | it becomes the default for every plain string field |
+| omitting `id`, or renaming it later | the id is the binding surface |
+| binding before building | the id does not exist yet; the view renders nothing |
+| reusing a core layout id | silently shadows the built-in with no warning |

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

@@ -0,0 +1,59 @@
+# ui-views
+
+`modules/<module>/ui-views/<name>.ui-view.yaml`. **A ui-view is a binding, not code** — a
+route plus the id of an already-registered layout, plus how to shape the data. Nothing to build.
+
+The surface reads compiled ui-view records at boot: `nav` becomes a sidebar entry, `path` becomes a
+live route, `target: list` renders the named `layout` over the collection with `filter`/`options`
+applied (`@me` resolves to the current operator). After authoring: compile, then reload the surface.
+
+```yaml
+path: /inbox
+nav: { label: Inbox, icon: inbox, order: 1 }
+target: list
+collection: collections/tasks
+layout: table
+filter: { assignee: { _eq: "@me" } }        # operator objects, never a bare value
+options: { columns: [name, status, due, run], sort: -due }
+```
+
+| field | required | notes |
+|---|---|---|
+| `path` | yes | the route — `/inbox`, `/views/meetings/recent` |
+| `target` | yes | `list`, `item`, or `page` (freestanding) |
+| `layout` | yes | the id of a **registered** layout (`table`, `cards`, `kanban`, `calendar`, `map`, + module-declared) |
+| `collection` | for `list`/`item` | qualified: `collections/<name>` |
+| `nav` | no | `label`/`icon`/`order`; omit for direct-link-only views |
+| `default` | no | `true` makes this the collection's DEFAULT view at `/content/<collection>` |
+
+## default views vs named views
+
+A collection's default presentation **is an ordinary ui-view record** — `default: true`, path
+`/content/<collection>`. A named view is the same record with its own path plus a `nav.label`. One
+shape, one home, both agent-writable and both diffable in git.
+
+⚠ **A view's `options.columns` REPLACES the descriptor's `list_fields`; it does not merge.** And a
+column naming a field the schema lacks is **dropped, not fallen back from** — which is how a core
+inbox view asking for `title` on a collection whose field is `name` rendered every row nameless with
+no error. Check the descriptor's real field names against every column you write.
+
+⚠ **`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 CLI can write these
+
+`dt ui-views add|set|rm` — `set` takes dotted keys (`options.sort=-date`) and derives the record id
+with the descriptor's own template, so a view saved from the CLI and one saved from the UI land on
+the **same record**. This is the one system-stored kind with full CLI write support, because it goes
+through the same compile gate.
+
+## common mistakes
+
+| mistake | reality |
+|---|---|
+| a `layout` id you assumed exists | compile validates it only for `target: list`; otherwise the view renders nothing |
+| bare `collection: tasks` | qualified refs only |
+| `filter: { assignee: "@me" }` | filters are operator objects: `{ assignee: { _eq: "@me" } }` |
+| a column the schema does not have | dropped silently — the row loses that value with no error |
+| a ui-view that restates the built-in fallback | a record to maintain for zero gain |
+| a module ui-view filtered to a named user | use `@me`; a hard-coded id breaks elsewhere |

package/skills/using-dreamteamer/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: using-dreamteamer
+description: always load first — describes this dreamteamer workspace, its collections, conventions and your pending tasks
+---
+
+# using dreamteamer
+
+this is a **dreamteamer** workspace: collections, skills, agents and commands are records compiled
+from sources into a runtime the harness reads.
+
+**core principle:** read the compiled runtime, write the sources, compile — then `dt commit` to publish.
+
+## when to use
+
+load this **first, every session** in this repo. reload mid-session on any of these symptoms: you're
+about to guess a collection's fields; you can't tell whether the file to edit lives under
+`modules/*/<kind>/` or `.dreamteamer/`; you wrote something and the harness didn't notice; you're
+unsure which skill owns the job in front of you.
+
+**this file is the MAP, not the procedure.** Detail lives in two references beside it, loaded on
+demand:
+
+| load | when |
+|---|---|
+| `references/records.md` | reading, creating, updating, renaming or deleting any record — the CLI verbs, hand-writing rules, the hard rules about ids and renames |
+| `references/git-events.md` | "what changed while I was away" — `dt changes`, and how record events are derived from git history |
+
+## the contract
+
+| concern | where | rule |
+|---|---|---|
+| schemas (read) | `.dreamteamer/collections/*.collection.yaml` | the single source of truth for what exists and its shape. **never edit under `.dreamteamer/`** — generated and gitignored |
+| 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:
+  `data/meetings/2026/07/standup.meeting.md` ⇒ id `2026/07/standup`.
+- **references are `<collection>/<id>`** strings — always qualified, greppable, never a bare name and
+  never a file path.
+
+## the CLI is the front door
+
+`npm run --silent dt -- help` is the command surface — don't learn the generic verbs and flags from
+prose; prose drifts. it does **not** list the purpose-built verbs some collections have
+(`collections add`, `<collection> add-field`, `repos ensure`) — those live in the skill that owns
+them, and a verb absent from `help` still works.
+
+what you need to know *about* the CLI: collection verbs validate hard (invalid writes, **including
+unknown fields**, are rejected before disk) **and commit for you** with the right subject. `npm run
+compile` after every source change, `npm run check` after bulk edits, `npm run --silent dt -- status`
+when you're not sure the runtime is fresh.
+
+## routing
+
+| the request is about | load |
+|---|---|
+| a record — read, create, update, rename, delete | `references/records.md` |
+| authoring anything under a module's source folders — a collection, field, skill, command, agent, ui-view, or component code | `building-dreamteamer` |
+| "what changed while I was away" | `references/git-events.md` |
+| the workspace lacks the capability entirely | `building-dreamteamer` → `references/before-you-build.md` |
+
+Domain work — meetings, contacts, tasks, content, design — is owned by the **module** that ships those
+collections, not by core. Read that module's own skills. Core knows about entity kinds, `users` and
+`repos`, and deliberately nothing else.
+
+## conventions
+
+- **a write puts a record on disk; `dreamteamer commit` publishes it.** committing is POLICY —
+  `"auto-commit"` in the workspace's `package.json`, default off — not a property of the write. so
+  commit when a logical change is complete, and run `dt status` if you are unsure what is pending.
+  subjects still read `dreamteamer: <verb> <detail>` for a single record (`dt commit` composes them
+  from git's own status letters), and a multi-record commit says what it swept.
+- **one commit per REPO.** a module can own its records (`owns-data` in its package.json), and git
+  has no cross-repo commit — so a rename whose inbound refs live in another repo is TWO commits.
+  `dt commit` prints both. `dt commit <collection> …` scopes it; `--dry-run` shows the set first.
+- **never `git add -A`, `git add .`, or `git commit -a`.** stage explicit paths. more than one agent
+  can be working in a tree, and a blanket add silently commits whatever another session has
+  uncommitted right now — under your subject, leaving `git status` clean and the damage invisible.
+  the CLI's own writes are pathspec-scoped for exactly this reason, which is why it is the preferred
+  path for record writes.
+- **validate after bulk edits**: `npm run check` reports violations and never modifies files.
+- workspace-level rules live in `CLAUDE.md`, and a workspace's decision log (where one exists) wins
+  over older documents.
+- **session greeting** — surface the operator's inbox: `npm run --silent dt -- tasks list --assignee
+  users/<user> --status todo`. ⚠ the current user is a record in `data/users/` whose id is
+  `slug(git config user.name)`; when those disagree the inbox comes back **empty with no error**.
+
+## common mistakes
+
+| mistake | why it bites |
+|---|---|
+| editing something under `.dreamteamer/` | generated + gitignored; the change vanishes on the next compile |
+| changing a source and not compiling | the harness and `check` still read the stale runtime |
+| hand-writing a record the CLI could add | skips validation, id generation and defaults |
+| bare refs (`ada`, `data/users/x.user.md`) | refs are `<collection>/<id>`; anything else fails check |
+| assuming a write was committed | it was not, unless `auto-commit` is on — `dt status` says what is pending |
+| `git add -A` in a shared tree | steals another session's uncommitted work, invisibly |

package/skills/using-dreamteamer/references/git-events.md

@@ -0,0 +1,64 @@
+# detecting data changes via git
+
+**Core principle:** record events are never observed live — they are **derived from git history**. A
+closed laptop loses nothing, and every derivation is auditable and replayable forever. History IS the
+queue; there is no events file, and there never should be.
+
+## the verb
+
+```bash
+dt changes                      # since the last commit
+dt changes --since <sha>        # since any commit
+dt changes --json               # for a program
+```
+
+Per record it reports the collection, the id and one of `item-added` / `item-updated` /
+`item-removed`, grouped by collection with counts. **Read-only by construction** — there is no cursor
+to advance and nothing is stored, so running it twice is free and running it wrong costs nothing.
+
+## when to use
+
+The operator asks what changed or what they missed; you are reconciling after a batch of edits or a
+bulk rewrite; you want to know what a range of commits actually did to the data.
+
+**Not for:** ordinary "show me the diff" questions — plain `git log` / `git diff` is better. Not for
+reading or writing individual records (`references/records.md`).
+
+## the mechanism
+
+1. **Diff** — `git diff --name-status <sha>..HEAD -- data/ state/`.
+2. **Map** — each path maps to a collection via the compiled descriptors' `storage.path`
+   (longest-prefix match; the suffix + codec must also match a record file, and folder-shape
+   collections match on their `entry`). The id is the path inside the collection folder minus
+   `.<suffix>.<ext>`. **A changed path that matches no descriptor is not a record** and is skipped —
+   source and runtime churn are not data events.
+3. **Classify** — the git status letter becomes the event: `A` → added, `M` → updated, `D` → removed.
+   **A rename emits removed + added**; there is deliberately no `item-renamed` event, because the id IS
+   the path and a moved record is a different record as far as any consumer is concerned.
+
+## what this used to be, and why the rest went
+
+Until 2026-07-31 this mechanism was the front half of `dt sync`, which also matched
+`workflow-triggers` records, **created `workflow-runs`**, and advanced a per-evaluator cursor. That
+whole layer was removed: measured over three days it had produced 1 workflow record and 9 runs all from
+a single burst, **7 of them abandoned mid-flight**, against a cursor that had not advanced — while the
+work it was meant to automate was being done by a chain of commands a person runs.
+
+The derivation survived because it is the half that was actually used, for catch-up. Worth keeping from
+that design if automation is ever rebuilt:
+
+- **Never store an event queue.** A queue drifts from reality; history cannot.
+- **Any evaluator must be idempotent over a range** — re-running must not act twice. The old design
+  keyed that on `trigger + item + commit`, which is the shape to reuse.
+- **A migration is not a data event.** A bulk rewrite looks like N added records to git, so anything
+  acting on events must be scoped past it rather than run over it.
+
+## common mistakes
+
+| mistake | reality |
+|---|---|
+| hand-rolling the diff + path mapping | `dt changes` is the mechanism; a hand-roll misses folder-shape records and the rename split |
+| treating any changed path as a record | only paths matching a descriptor's `storage.path` + suffix + codec are records |
+| diffing the whole tree | scope to `data/` + `state/`; source and runtime churn are not item events |
+| writing an events file to "remember" what changed | history is the record; anything you write can drift from it |
+| reading `dt changes` output as a to-do list | it says what changed, not what it means — the judgement is yours |

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

@@ -0,0 +1,102 @@
+# working with structured data files
+
+**core principle:** the CLI is the default path — it validates before disk, generates the id,
+materializes defaults and commits with the right subject. direct file edits stay first-class,
+but then *you* owe every rule below.
+
+## when to use
+
+any time a record is read, created, changed, renamed or removed — a task, a contact, a meeting,
+a doc, anything under `data/` or `state/`. load it especially when you catch yourself about to
+`mv` a record file, hand-write frontmatter from memory, or set a field you haven't read in the
+descriptor.
+
+**not for:** schema changes (`building-dreamteamer` → `references/collections.md`), or system-stored records — skills, agents,
+commands, ui-views, collections. those are *sources*: edit the file under the owning
+module (`modules/<module>/<kind>/`) and run `npm run compile`; the CLI refuses them on
+purpose.
+
+## the verbs
+
+`npm run --silent dt -- help` lists the generic record verbs and their flags. read them there.
+but **`help` is not the whole surface** — collections with a purpose-built verb (`collections add`,
+`<collection> add-field`, `repos ensure`) don't appear in it, and a verb missing from `help`
+is not a verb that doesn't exist. when a skill names a verb, use the verb.
+
+what the help text can't tell you either way:
+
+- **validation is hard and it includes unknown fields.** a typo'd key (`--assinee`) is rejected
+  with nothing written, same as a dangling ref, a bad enum value (the error echoes the value it
+  got) or an id that misses `id.pattern`. a rejected write leaves no partial state.
+- **every write verb commits by itself**, with the right subject — never stack another commit
+  on top.
+- `set <id> <field>=` with an empty value **removes** the field; array fields take a
+  comma-separated value (`--attendees contacts/a,contacts/b`).
+- `--json` works on every verb — use it whenever you're going to parse the output.
+- `npm run check` validates the whole workspace after the fact: report-only, never rewrites.
+
+## before writing anything
+
+read the compiled descriptor: `.dreamteamer/collections/<collection>.collection.yaml`.
+it defines `storage` (path/codec/shape/suffix), `id` (`generate` template + `pattern`), and
+`schema` (JSON Schema; the `x-` keywords carry the domain semantics — `x-reference`, `x-body`,
+`x-title-template`). It also carries `title` (what to CALL the collection) and `title_template` (how
+to label one of its records) — both resolved by compile from the id unless authored.
+
+## writing a record by hand
+
+**default to `dt <collection> add`** — id, defaults, validation and commit in one line. hand-write
+only when the CLI can't express the value: a nested map, or a long structured body.
+
+when you do, don't reconstruct the shape from the schema — **`dt <collection> get <existing-id>
+--json` prints the exact shape a valid record has**: which fields, which ref forms, dates as
+strings. copy a sibling, change what differs, and:
+
+- put the file where the id says: the id IS its path inside `storage.path`, minus suffix and
+  extension (folder-shape records are a folder named `<id>` holding the descriptor's `entry`).
+  ids are built from **creation-time** values only, never a mutable field, and must satisfy
+  `id.pattern`.
+- **materialize defaults explicitly** — write `status: todo` even though it's the schema default;
+  a file should be legible without its schema.
+- `npm run check` is the only validation a hand-write gets. run it before you commit, once:
+  `dreamteamer: <collection> add <id>` (or `set <id>`, for an update).
+
+example — `data/tasks/2026-07-25--fix-login-flow.task.md` (`md` codec: frontmatter holds the
+fields, the body is the single `x-body: true` field):
+
+```markdown
+---
+title: Fix login flow
+status: todo
+assignee: users/ada
+due: '2026-07-28'
+---
+Users report the login button does nothing on mobile.
+```
+
+## the hard rules
+
+**never hand-rename or `mv` a record file** — the id IS the path, so a rename silently dangles
+every inbound reference; `rename` moves the file and rewrites all refs in one commit. **never
+delete a referenced record** (`rm` refuses for a reason — retarget first). **a changed title
+never changes the id.** **one mutation, one commit.**
+
+## common mistakes
+
+| mistake | reality |
+|---|---|
+| `mv data/tasks/old.task.md …/new.task.md` | every inbound ref now dangles. use `dt … rename`. |
+| renaming a file because the title changed | the id is not a display name — edit the field. |
+| reaching for `--force` to get past the refuse | it leaves the inbound refs dangling. retarget them first — unless `rm` named a *prose* mention (a skill's example, a doc), which isn't a real reference and `check` won't flag. |
+| hand-writing a record "because it's quicker" | no validation, no defaults, no id check, no commit. `dt … add` is one line. |
+| omitting schema defaults from a hand-written file | the file stops being legible without the schema. |
+| unquoted `due: 2026-07-28` | dreamteamer parses with CORE_SCHEMA so it stays a string *here*, but any default-schema YAML reader turns it into a timestamp. quote dates when hand-writing. |
+| CLI-editing a skill / agent / command / collection | system sources — edit the module file, then `npm run compile`. |
+| committing again after a CLI verb | the verb already committed; you'd sweep unrelated work into it. |
+
+## red flags — stop
+
+- you're about to `mv`, `cp` or `rm` a file under `data/` or `state/` directly
+- you're writing a reference you haven't confirmed resolves
+- you're editing anything under `.dreamteamer/` (generated, gitignored)
+- you finished a bulk edit and haven't run `npm run check`