# MVP roadmap

## M0 — Skeleton

- Implement `internal/config`: load `.env`, require `TELEGRAM_BOT_TOKEN` and
  `DATABASE_URL`.
- Implement `internal/database`: open GORM, set pool limits, ping.
- Wire `cmd/bot/main.go`: config, database, telego client, long polling loop,
  graceful shutdown on `SIGTERM`.
- Fix the `go.mod` module path to the full repository path.

## M1 — Users and lists

- Ensure a user row on every allowed update; store only the Telegram ID.
- Commands: `/start`, `/help`, `/lists`, `/new`, `/cancel`.
- Create, rename, and soft-delete a list. Owner only for rename and delete.
- List index with owned and shared lists.

## M2 — Items

- Add, edit, and delete items. Editor or owner.
- Item fields: title, note, quantity, urgency, status.
- Mark done and reopen.
- Reserve and release with a conditional update.
- List detail view with pagination and role-appropriate buttons.

## M3 — Bot access

- Require `BOT_OWNER_ID`; the bot owner always has access.
- Every other user needs an explicit grant. Deny all updates from users without
  one, including commands and callbacks.
- Owner commands: `/allow <username or id>` and `/kick <username or id>`.
- Username grants stay pending until that user contacts the bot, then bind to
  their Telegram ID.
- Show the owner commands in `/help` for the bot owner only.

## M4 — Sharing

- Grant `reader` or `editor` access by Telegram username or numeric ID to
  users who already have bot access. Unknown targets get a no-access hint.
- Pending shares for allowed usernames that have not contacted the bot yet.
- Resolve pending shares when the target user contacts the bot.
- Share management view for the owner: list shares, change role, revoke.
- Kicking a user removes their shares from other owners' lists but never
  deletes their own lists.

## M5 — Polish

- Versioned callback-data codec with strict validation.
- Confirmation step for destructive actions.
- HTML escaping helper and Telegram length limits.
- Error mapping from domain errors to user messages.
- Structured logging with `log/slog`.

## Before production

- Add versioned SQL migrations; stop relying on GORM automigrate.
- Add PostgreSQL-backed tests for the conditional item transitions (done,
  reopen, reserve, release) in the repository.
- Enable PostgreSQL backups in Dokploy.

## Later

- `events` table and publisher for notifications, reminders, and activity
  feeds.
- Webhook mode plus a shared session store for horizontal scaling.
- Richer list features: events, budgets, recurring lists.
- Metrics and alerting.