Improve seed/dev scripts: human-friendly logging and safety checks (foolproof mode)

[diyor28]

Problem

Our local dev/seed workflows can fail silently or be confusing. Example: a developer may run make db seed against a restored backup or a non-empty DB, then try default creds and assume “seed is broken”. The scripts/logs don’t clearly explain what happened, what DB they targeted, or why credentials didn’t apply.

Goal

Make seed/dev scripts human-friendly and hard to misuse.

Requirements

1) Human-friendly logging

• Print a clear banner at start:
  • target environment (dev/stage/prod if applicable)
  • DB host/port/name/user (redact passwords)
  • whether DB is empty / contains data (row count heuristics)
  • what actions will be executed (migrations, seed steps)
• Use structured logging where reasonable (zap/slog), but output must be readable in console.
• Print a summary at the end (created users, companies/tenants, etc.).

2) Safety checks (“foolproof mode”)

• Refuse to run destructive steps (drop/truncate) unless an explicit flag is provided:
  • e.g. --force, --i-know-what-im-doing, or SEED_FORCE=1
• Detect and warn if:
  • DB is not local (host not localhost/127.0.0.1/docker service)
  • DB already has data (non-empty) and seed would conflict/duplicate
  • running against a restored backup (heuristic: presence of known prod/stage markers)
• Provide an interactive confirmation (TTY) when risk is detected, unless --yes is supplied.
• Exit with non-zero status on unsafe conditions.

3) Credential clarity

• Always print (or write to .env.local / output file) the default login credentials that were seeded.
• If credentials already exist, log that seed skipped them and what to do next.

4) Developer UX

• Add --dry-run to show what would happen.
• Update README/docs: how to seed from scratch vs. how to work with backups.

Acceptance Criteria

• Running seed on a non-empty DB clearly explains what was detected and what was skipped/refused.
• Risky operations require explicit confirmation/flag.
• Default credentials are always discoverable from the output.
• Logs are understandable without reading the code.

Notes

This should cover both Go-based seed commands and any Makefile/dev scripts in the repo.

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[diyor28]

Additional requirement: disable background sync tasks in dev commands/scripts. Periodic/background sync jobs should not start when running seed/dev helper commands; they must start only together with the dev/production server process (i.e., when the app server is running), not during one-off CLI commands.

[diyor28]

Добавлю уточнение к задаче: отключить background sync tasks в dev командах (seed/dev scripts). Они не должны автоматически стартовать при запуске dev-утилит, а должны запускаться только вместе с dev/prod сервером (явно, через запуск сервера/воркера).