swudeck-session-start

name	swudeck-session-start
description	Use at the START of a SWUDeck (NOT overall TCGEngine) working session to get oriented — recall past gotchas/lessons, confirm the local dev environment + cross-browser verification tooling are ready, and surface in-flight work — before making changes. Invoke when the user signals they're beginning SWUDeck work ("let's work on SWUDeck", "start a SWUDeck session") or runs /swudeck-session-start.

SWUDeck Session Start

A lightweight start-of-session ritual: load the context that keeps us from repeating past mistakes, confirm the local environment and verification tools are ready, and surface where things left off — so the first change lands on solid footing. This is the counterpart to swudeck-session-close.

When to run

• The user signals they're beginning SWUDeck work.
• Explicitly invoked (/swudeck-session-start).
• Before a substantive SWUDeck change when you haven't yet oriented this session.

Skip it for a one-line question you can answer immediately.

Steps

Create a todo per step and work through them in order.

1. Load carried-forward context

These are the traps that already bit us — read them before touching code:

• Project memory — the MEMORY.md index is auto-loaded each session; skim it and read the specific notes that bear on today's task (e.g. the Firefox height:100%/flex-stretch gotcha for a layout change; the SET_NNN-vs-UUID bridge for anything touching format legality; the image-generator regen workflow for crop/art changes).
• Retro log — .claude/skills/swudeck-session-close/references/lessons-learned.md. Skim the newest entries for process lessons and any known follow-ups left open.

Call out anything that directly changes today's approach.

2. Confirm the dev environment is up

SWUDeck runs in Docker, served at http://localhost:3100/TCGEngine. Verify:

• Containers running: docker ps | grep swustats — expect the web server, mysql, and redis (otmtcge-swustats-web-server-1, -mysql-server-1, swustats_app_redis; names may vary).
• App responds: curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3100/TCGEngine/SharedUI/LoginPage.php → 200.
• DB reachable (only if you'll touch data): docker exec otmtcge-swustats-mysql-server-1 mysql -u root -psecret -D swudeck -e "SELECT 1".

If something's down, tell the user and offer to start it (docker compose up -d) — don't guess around a broken environment.

3. Ready the cross-browser verification tooling

Per the CLAUDE.md engineering rule, SWUDeck UI/CSS changes must be checked in Chromium + Firefox + WebKit. Make sure verification is one command away later:

• DevTools/ui-harness/ exists with node_modules installed — if not, cd DevTools/ui-harness && npm install (its postinstall pulls the three browser engines). Usage + flags are in its README.md.
• Test login is Drixx / pass (CLAUDE.md ## Creds); the users table username column is usersUid. Mutating flows (leader swap/remove, import) run on a throwaway deck, never a real one.

Don't run a full render yet — just confirm nothing blocks it.

4. Surface in-flight work

• git status + git log --oneline -5 — uncommitted changes, current branch, recent commits. Standing rule: the user commits, never the assistant.
• Re-state any open follow-ups found in step 1 so they aren't silently dropped.

5. Confirm the task

Briefly restate what the user wants to do this session, flagging anything from the above that changes the approach. Then proceed.

Output

A short orientation summary: the relevant carried-forward gotchas, environment status (up / what's down), tooling readiness, in-flight/uncommitted state + open follow-ups, and the confirmed task.