Migracje w SurrealQL, wersjonowane w git. Backend (plik/RocksDB) jest źródłem prawdy; frontend (WASM) stosuje ten sam podzbiór definicji przy starcie.

Pliki

Plik	Zawartość
`0001_schema.surql`	tabele, pola, indeksy (w tym HNSW + pełnotekstowy), `ACCESS`, `PERMISSIONS`, `ASSERT`
`0002_taxonomy_seed.surql`	8 obszarów (`social_challenge`), tagi, próbka lokalizacji
`0003_demo_schema.surql`	dodatki schematu pod demo: `user.display_name`, `innovation.tags`, pola `FLEXIBLE`
`0004_demo_seed.surql`	dane syntetyczne (persony, problemy, innowacje, wiedza, nabory)

Zasady

Numeracja NNNN_nazwa.surql, stosowana w kolejności rosnącej.
Migracje idempotentne (DEFINE ... OVERWRITE, INSERT IGNORE), addytywne.
Zmiany schematu wyłącznie przez nowy plik migracji — bez ręcznych zmian na środowisku.
Brak danych osobowych/wrażliwych w seedach (krok 09).

Aplikowanie

SurrealDB CLI 3.x. surreal sql nie ma już flagi --file — przekaż plik przez stdin z --multi (średniki rozdzielają instrukcje):

Get-Content -Raw backend/migrations/0001_schema.surql | `
  surreal sql -e http://127.0.0.1:18010 -u root -p root --ns hubmi --db hubmi --hide-welcome --multi
Get-Content -Raw backend/migrations/0002_taxonomy_seed.surql | `
  surreal sql -e http://127.0.0.1:18010 -u root -p root --ns hubmi --db hubmi --hide-welcome --multi

Alternatywnie surreal import — wymaga OPTION IMPORT; jako pierwszej instrukcji pliku (wyłącza przetwarzanie pól).

Embedded RocksDB: uruchom pwsh ./scripts/surrealdb-start.ps1 (tryb zdalny) albo zastosuj migracje przez backend przy starcie (krok 10).

Weryfikacja

Zwalidowano na SurrealDB 3.2.4 (instancja in-memory): schemat i seed aplikują się bez błędów, ponowne uruchomienie jest idempotentne (22 tabele, 8 obszarów, 18 tagów, 4 lokalizacje), a CRUD na encjach (create/update/select/delete) działa.

Frontend (WASM)

Frontend stosuje podzbiór 0001_schema.surql do indxdb://tarninahub (bez serwerowych PERMISSIONS i ACCESS). Reguły synchronizacji: patrz 10_ZalozeniaProjektowe/todo08/BAZA_DANYCH.md §6.