# FamilyDashboard admin Benefits/Tasks + persistence workflow

Use when working on `/home/agent/projects/FamilyDashboard` admin CRUD for Benefits, TaskTemplates, dashboard data persistence, or iPad-facing public/admin separation.

## Durable workflow lessons

1. **Git first, do not pull blindly**
   - Start with `git status --short`, current branch, remotes, authenticated fetch if needed, and compare `HEAD` with `origin/main`.
   - Treat untracked backup files as artifacts unless explicitly requested; do not overwrite or delete them casually.
   - If GitHub auth fails non-interactively, use the configured project token via an extra HTTP authorization header rather than printing or embedding credentials.

2. **Public Benefits page is child-facing only**
   - `/benefits` must not contain Admin PIN/login UI or Benefit management controls.
   - It should show only active Benefit cards, price, target child/both, child-specific redeem buttons, and a clear “not enough Coins” state.
   - Admin redemptions/fulfill/cancel controls belong in admin-only flows, not the child-facing page.

3. **Admin Benefits management pattern**
   - Put Benefit CRUD in the Admin portal as a clear “Benefits verwalten” panel.
   - Use existing endpoints: `GET/POST/PATCH/DELETE /api/admin/benefits`.
   - DELETE is expected to be soft delete (`active=false`); preserve historical data.
   - Inline-edit title, description, price, target child (`null` = both), active flag, and sort order.
   - Invalidate admin benefits, public benefits, and dashboard-related queries after writes.

4. **Admin TaskTemplate management pattern**
   - Put TaskTemplate CRUD in Admin as “Aufgaben verwalten”.
   - Use existing endpoints: `GET/POST/PATCH/DELETE /api/admin/task-templates`.
   - DELETE is soft delete (`active=false`).
   - Inline-edit title, kind, active flag, weekdays, and values.
   - For `required`: show the penalty as a positive input if friendlier, but save `coin_value=0` and negative `penalty_value`.
   - For `bonus`/`study`: save positive `coin_value` and `penalty_value=0`.
   - Existing/past TaskInstances need not be retroactively changed; new generated daily tasks should pick up changed templates.

5. **Persistence guardrails**
   - Verify `/data/familydashboard.db` before and after Docker rebuilds with table counts for `benefit`, `tasktemplate`, `scheduleblock`, and `child`.
   - Productive SQLite should be bind-mounted from project `./data:/data`; `data/*.db`, `data/*.db-*`, and `data/backups/` must remain ignored.
   - Never use `docker compose down -v` during normal work; `docker compose down` without `-v` is acceptable when needed.
   - Seed routines must add missing defaults only. They must not overwrite/deactivate admin-edited TaskTemplates or ScheduleBlocks except through an explicit confirmed reset path.

6. **Tests/smoke to add or keep green**
   - Backend: add/maintain tests that Benefit edits/deactivation and TaskTemplate value changes/deactivation persist after `init_db()`/DB reopen simulation.
   - E2E: assert `/benefits` has no PIN/login/admin management and that `/admin` contains “Benefits verwalten” and “Aufgaben verwalten”.
   - Run: Docker rebuild, `/api/health`, frontend HTTP check, frontend build, Playwright, and full backend pytest before commit/push.

## Common acceptance checks

- `/benefits`: no PIN input, no “Reservierungen” admin panel, child-friendly redeem cards visible.
- `/admin`: Benefit list editable; Benefit price/name/active state can change; delete/deactivate needs confirmation.
- `/admin`: Task list editable; bonus value and required penalty are directly editable; delete/deactivate needs confirmation.
- Docker rebuild does not change productive counts unexpectedly.