Seed 20 starter templates

## Epic requirement (verbatim) > Create an initial list of templates: > - Do web research for top similar templates at factory, obvious.ai and other similar systems > - Task definitions must be human readable, with no blabbering, nothing overly technical, no repeating obvious things, etc > - A template will have an accompanying image to graphically explain what it does The settled inputs are the PRD (Task 11059) §8–§9 and the architecture (Task 11060) §6. Operator decision I-1: the images are **hand-built SVGs**. ## Scope - `apps/api/app/task_template_starters.py`: the 20 entries of PRD §9 as literals, with fixed UUIDv7 ids and slugs (the `playbook_built_ins.py` pattern). - **The seed migration** (the only migration in this wave): `INSERT … ON CONFLICT (id) DO NOTHING` with `published=true` and `image_key='builtin:<slug>'`. - `tests/test_task_template_seed.py`: migrated rows equal the module, re-running inserts nothing, and an edited row is not overwritten (the `tests/test_playbook_seed.py` pattern). - **20 SVGs** at `apps/web/public/templates/<slug>.svg`: - viewBox `0 0 320 180`; - flat style with one shared 3-colour palette plus a neutral, on a transparent background; - no text; - strokes and fills chosen to read on both light and dark themes; - each draws its template's subject (a bug under a lens, a green check over a pipeline, a shield, and so on). - Carry PRD §9 below verbatim. The copy reviewer may tighten wording only toward AC-18. Each change must keep the meaning and must be recorded in the PR body. ### PRD §9 Starter library (verbatim) Group order: **Build & fix**, **Quality**, **Security**, **Maintenance**, **Docs & release**, **Research & planning**. Persona codes are from `apps/api/app/persona_registry.py`. Depth is task unless noted. Involvement is unattended unless noted. **Build & fix** 1. **Fix a bug** — *Reproduce, fix, add a test.* · coder > Fix the bug described below. Link the issue or paste the error. > - Reproduce it first, then fix the cause, not the symptom. > - Add a test that fails before the fix and passes after. > - Keep the change small. 2. **Build a feature** — *From idea to merged change, with a spec first.* · epic (depth epic, involvement guided) > Build the feature described below. > - Agree on what "done" looks like before writing code. > - Ship it in small, reviewable steps. > - Cover the main path and the obvious failure cases with tests. 3. **Make CI green** — *Find why the build fails and fix it.* · coder > The build or tests are failing. Find out why and fix it. > - Tell a real regression apart from a flaky test or a broken environment. > - Fix real failures; quarantine a flaky test only with a note on why. 4. **Apply review comments** — *Address open feedback on a pull request.* · coder > Address the open review comments on the pull request linked below. > - Make the requested changes, or reply where you disagree and say why. > - Don't change anything the comments don't ask for. 5. **Build a quick prototype** — *A clickable throwaway to test an idea.* · prototyper > Build a quick, clickable prototype of the idea below so we can react to it. > - Favor speed over polish; it will be thrown away. > - Show the main flow end to end. **Quality** 6. **Add tests** — *Cover the riskiest untested code.* · coder > Add tests where they matter most in the area named below (or the whole project). > - Start with code that changes often or breaks often. > - Test behavior, not implementation details. > - No tests that can never fail. 7. **Fix flaky tests** — *Make unreliable tests reliable.* · coder > Find tests that pass and fail without code changes, and make them reliable. > - Fix the cause (timing, shared state, order) rather than adding retries. > - List what you fixed and what you couldn't. 8. **Speed up the test suite** — *Cut test time without losing coverage.* · test_optimizer > Make the test suite faster without weakening it. > - Remove duplicate and dead tests; speed up the slowest ones. > - Report time before and after. 9. **Clean up code** — *Remove dead code and simplify hot spots.* · coder > Tidy the area named below. > - Delete unused code, files and settings. > - Simplify the most tangled parts without changing behavior. > - Keep each change easy to review. **Security** 10. **Security review** — *Find and fix the most serious risks.* · coder (involvement guided) > Review the project for security problems and fix the serious ones. > - Check sign-in, permissions, secrets, input handling and dependencies. > - Rank what you find by real risk; fix the top items. > - Ask before changing anything users would notice. 11. **Patch vulnerable dependencies** — *Upgrade packages with known issues.* · coder > Upgrade dependencies that have published security issues. > - Prefer the smallest version jump that fixes the issue. > - Run the tests; note anything that needed code changes. **Maintenance** 12. **Upgrade a dependency** — *Move a library or framework to a newer version.* · coder > Upgrade the library or framework named below to the version named (or the latest stable). > - Fix everything the upgrade breaks. > - Note any behavior that changed for users. 13. **Migrate a framework** — *Plan and carry out a larger move.* · epic (depth epic, involvement guided) > Move the project from the technology named below to the new one. > - Plan the move in stages that each leave the app working. > - Keep behavior the same unless stated otherwise. 14. **Remove a feature flag** — *Retire a flag that is fully rolled out.* · coder > Remove the feature flag named below and keep the behavior users see today. > - Delete the unused path and its tests. **Docs & release** 15. **Update the docs** — *Bring docs in line with the code.* · coder > Bring the documentation up to date with how the product works today. > - Fix what is wrong, remove what is obsolete, add what is missing. > - Keep it short; link instead of repeating. 16. **Write release notes** — *What changed, in plain words.* · marketer > Write release notes for the changes since the last release. > - Lead with what users will notice. > - Group by new, improved and fixed; skip internal changes. 17. **Translate the app** — *Localize text into another language.* · translate > Translate the product's text into the language named below. > - Match the tone of the original, not word for word. > - Translate only what is new or changed. **Research & planning** 18. **Clarify a request** — *Turn a rough idea into clear requirements.* · business_analysis (involvement guided) > Turn the request below into clear requirements. > - Settle what is in and out of scope. > - Write checkable acceptance criteria. > - Ask about anything that would change the result. 19. **Design a solution** — *Pick an approach before building.* · architecture > Propose how to build the change described below. > - Compare two or three options and recommend one. > - Name the risks and what it would take to undo. 20. **Research a question** — *Sourced answer to a technical or market question.* · researcher > Research the question below and give a clear, sourced answer. > - Lead with the answer, then the evidence. > - Say where sources disagree. The planner verified that all 20 persona codes are in `CREATABLE_PERSONAS`. ## Acceptance criteria (verbatim) - **AC-17 Seeded.** Oracle: on a fresh dev database after migration, open `/templates`. Expected: the 20 templates in §9 are present, published, Official, each with its image, in the stated groups. Re-running the seed does not create duplicates and does not overwrite operator edits. - **AC-18 Readable.** Each starter description reads as a short brief to a capable colleague: a goal sentence, then at most 5 short bullets of "what good looks like". No jargon a product manager would not know, no restating the title, no "please", "you should", "make sure to", no persona or pipeline internals. Oracle: an independent reviewer (`copy-reviewer`) reads all 20 against `docs/standards/ui-copy-standards.md` and this criterion, and returns PASS. Fails if any description is over 90 words. - **AC-19 Images.** Each starter template has its own illustration (not one shared icon) in one consistent style: flat, 2–3 colors, no text in the image. Each reads in both light and dark theme. Oracle: view the gallery in both themes. All 20 images load, the 20 are visually distinct, and a reader can match each image to its template name. - **AC-20 Live on dev.** AC-1 through AC-19 pass on `dev.jaah.ai` after the deploy. Nothing global sits behind a flag that is off in the dev deployment. What this child proves for AC-19: the gallery itself is C4's, so here AC-19 is checked on the SVG files. C4 re-checks it in the live gallery in both themes. Credentials & reach: - UI ACs as the operator (AC-1–5, 17, 19, 20) | `me/jaah/debug/main/operator-login` (operator identity; switches between the operator and tenants), environment `https://app.dev.jaah.ai` | **verified**: the credential is on the roster and `credential_get` succeeded; an HTTPS GET of app.dev.jaah.ai returned 200 from this node. `dev.jaah.ai` (internal ALB) timed out from here, so oracles use `app.dev.jaah.ai` - Copy review (AC-18) | `copy-reviewer` agent, worktree only | **verified**: nothing beyond the worktree - Seed on a fresh DB (AC-17) | The fresh-DB half is a migration test (`tests/test_task_template_seed.py`, the `test_playbook_seed.py` pattern) that runs in the gate's own throwaway Postgres; the presence half is on app.dev.jaah.ai after the deploy, through the operator credential | **deferred** for the literal fresh dev database: dev is shared and isn't reset (a local `./dc` stack is never a control plane). The test and the dev presence check cover it; nothing beyond the worktree and the verified operator credential Out of scope: - N-3 No fill-in inputs, `{{placeholders}}` or variables in template text (D3). - N-6 Templates carry no project, feature, assignee, Jira key, priority or playbook (D7). - N-7 No AI generation of templates or images at runtime. Images are build-time assets (D6) or operator uploads. - N-1 No change to Playbooks. - Do NOT touch: the schema (C1); the asset routes (C1b); any web UI component (C3, C4). This child adds static files under `apps/web/public/templates/` only. Done means: - AC-17: `tests/test_task_template_seed.py` passes on a fresh DB, proving 20 rows, published, the right purposes, re-run idempotent and edits preserved. After the deploy, an authenticated `GET /api/templates` on app.dev.jaah.ai returns all 20, with `origin=global` and each `image_url` set. - AC-18: `copy-reviewer` returns PASS on all 20 descriptions; paste its verdict in the PR body. A test asserts every description is at most 90 words and contains none of "please", "you should" or "make sure to". - AC-19 (files): - all 20 SVGs exist, parse as XML, have viewBox `0 0 320 180` and contain no `<text>`, `<script>`, `on*` handler or external href (a test checks this); - render a contact sheet of all 20 on a white and on a near-black background, look at it, and attach it to the PR; - the 20 are visually distinct, each is recognisably its subject, and each reads on both backgrounds. - Fails if two images are near-duplicates or any image vanishes on one theme. - AC-20: after the deploy, `https://app.dev.jaah.ai/templates/<slug>.svg` returns 200 for all 20 slugs.