A1 Slovenija tenant seed (Postgres COPY archive, gzipped)
File: a1-demo-data.sql.gz
Company id: 604f23a8-b66e-4b21-8b45-0d72b68f4790
Legacy MySQL id: 97e1a309-3d23-4aa2-b518-8e8d7afdfec7
Source of truth for a clean local DB (2026-08-08 reseed):
MySQL dump → C:\Users\Green Eclipse\Downloads\descrybe_new (1).sql
Loaded into Laragon MySQL DB `descrybe_new`, then A1-only migrator
(`-company 97e1a309-3d23-4aa2-b518-8e8d7afdfec7`) + seed-demo + user cleanup.
See docs/migrate-from-descrybe-new.md and docs/demo-user.md.
Expected A1 snapshot (dump-faithful, no local QA/Iso pollution):
companies=1 (A1 Slovenija only, plus internal __platform_settings__)
users=3 (demo@descrybe.local, demo@descrybe.test, a1-primary@descrybe.local)
memberships=3
categories=119 (108 with AI prompts via overlay)
attributes=303
category_attributes=307
input_feeds=12 / feed_mappings=11 / export_feeds=2
raw_products=~25355 / processed_products=0 (demo seed clears processed)
processing_jobs=0 / processing_job_products=0
plan=A1 wallet total=2500 used=163 remaining=2337
mapped coverage (typical): description ~98%, feed attrs ~99%, category ~17% (4330 dump-assigned)
Category assignment (dump -> PG):
MySQL processed_products.category holds category unique_id (e.g. 46, 120).
Feed XML / feed_mappings do NOT include a category field - assignment was
historical processing output. Archive restores raw mapped_data (description,
specs/attrs, category when present). seed-a1 then refreshes
mapped_data.category from a MySQL dump when available.
Dump path (first match wins):
1. -mysql-dump flag / admin body mysql_dump
2. SEED_A1_MYSQL_DUMP (API process env on Git-Syncer)
3. Auto-detect: scripts/seed/descrybe_new.sql (deploy root),
~/Downloads/descrybe_new (1).sql or descrybe_new.sql
Git-Syncer / production: copy the dump onto the API host, e.g.
<deploy-root>/scripts/seed/descrybe_new.sql
or set SEED_A1_MYSQL_DUMP=/absolute/path/descrybe_new.sql in the API env.
Then use Admin → Companies → Sync A1 (no CLI DATABASE_URL needed).
One-off without wipe (CLI; loads monorepo-root .env when unset):
go run ./cmd/seed-a1 -mode backfill-categories
Admin Sync A1 = dump category backfill (when dump present) + Fix hygiene
(prompts, weak hashes, bidirectional category backfill, attr sanitize).
It does NOT wipe/reimport the ~25k catalog.
Note: MySQL processed description/attributes are usually NULL; feed-origin
original description + specs live on raw_products.mapped_data in the archive.
A1 demo seed keeps processed=0 / jobs=0.
Who sees what:
demo@descrybe.local � platform admin + membership on Platform Demo only
(switch/impersonate to a1-primary to act on A1; do not use demo API key for A1)
a1-primary@descrybe.local � A1 member only (same A1 catalog; no other tenants)
Category prompts overlay (committed WP dump + JSON fallback):
wp_product_categories.sql — primary Sync A1 / repair source of truth
a1-category-prompts.json — JSON fallback when WP SQL is absent
Applied automatically after every `npm run seed:a1` reimport (match by normalized
category name; rewrites {""OPIS IZDELKA""} -> {{description}},
{""STARO IME IZDELKA""} -> {{name}}). Skip with -skip-category-prompts, or re-apply
without wipe:
go run ./cmd/seed-a1 -mode apply-category-prompts -file ../../scripts/seed/a1-demo-data.sql.gz
go run ./cmd/repair-category-prompts -apply
# uses scripts/seed/wp_product_categories.sql by default (SEED_A1_WP_CATEGORIES overrides)
Normal use (loads DATABASE_URL from repo-root .env if unset):
npm run seed:a1 # wipe A1-only rows, import archive, prompts + mapped category backfill
npm run reimport:a1 # alias of seed:a1
Requires migrations already applied. Does not wipe other companies.
Does not run export — it only imports scripts/seed/a1-demo-data.sql.gz.
A1 demo seed skips processed_products / processing_jobs (processed=0, jobs=0).
Use -mode recover-jobs only when restoring legacy job history from a MySQL dump.
feed_sync_jobs stay ephemeral and are not restored; raw_products.sync_job_id is
exported as NULL for that reason. Archive is Postgres COPY text inside gzip, not
MySQL dump SQL.
Full clean rebuild from MySQL dump (when archive is wrong / polluted):
1. mysql: DROP/CREATE descrybe_new; stream-import the Adminer dump
2. docker: DROP/CREATE postgres descrybe; goose up
3. migrator -company <A1 legacy id> -resume -ensure-demo -skip-post-import
4. migrator -domains jobs -resume
5. go run ./cmd/seed-demo
6. keep only demo + a1-primary memberships; delete orphan users / Iso test cos
7. go run ./cmd/seed-a1 -mode apply-category-prompts
8. npm run seed:a1:export # refresh a1-demo-data.sql.gz then commit
Export copies EVERY A1 processing_jobs / processing_job_products row (no LIMIT).
If the archive only has a couple of jobs, live Postgres was missing history —
recover from the MySQL dump first, then re-export:
set SEED_A1_MYSQL_DUMP=D:\path\descrybe_new.sql
go run ./cmd/seed-a1 -mode recover-jobs
npm run seed:a1:export
Maintainer only — regenerate the snapshot when live A1 data must be re-captured:
npm run seed:a1:export # snapshot live A1 → a1-demo-data.sql.gz (then commit)
Not part of the day-to-day reset workflow.
Support Knowledge articles (platform FAQ /admin/support/knowledge):
support-kb-articles.json � product/user corpus (Agent 6)
support-kb-articles-tech.json � technical/ops/admin corpus (Agent 7; tech-* slugs)
Markdown sources for tech bodies (optional edit then regenerate JSON):
apps/api/cmd/seed-support-kb/content/*.md
Seed (from apps/api, DATABASE_URL set):
go run ./cmd/seed-support-kb
go run ./cmd/seed-support-kb -file ../../scripts/seed/support-kb-articles-tech.json
Idempotent ON CONFLICT (slug). Do not reuse product slugs for tech articles.
