# Nanodrop Simple file-sharing platform. TypeScript + Fastify + SQLite. ## Commands - `npm test` — Run all tests (vitest) - `npm run dev` — Start dev server (tsx) - `npm run build` — Compile TypeScript - `npm run register-user -- --username --password ` — Create user ## Architecture - ESM throughout (`"type": "module"`) - Fastify with server-rendered HTML pages - SQLite via better-sqlite3 for persistence - JWT in httpOnly cookies for auth - PRG pattern for HTML forms (no client-side JS except copy-to-clipboard) - Dependency injection — DB/service functions take deps as params for testability ## Code Quality - Review code after every change. Refactor for readability. - Use strict red/green TDD: write the test first, confirm it FAILS (red), then implement until it passes (green). - Build and test after every change. - Break large functions into smaller ones, extract duplicate code. - Search for duplicated code in tests and extract into reusable helpers. - Commit after every logical set of changes. Keep commits small and focused. ## Autonomous Commits (Standing Authorization) Any Claude Code instance working on this project has standing authorization to commit work without asking. Apply this proactively, not when reminded. - After every logical set of changes that builds and tests cleanly (`npm run build && npm test`), create a commit immediately. Do not wait for the user to ask. - Use Conventional Commits (`feat:`, `fix:`, `refactor:`, `docs:`, `test:`, `chore:`, `perf:`, `ci:`) with a concise subject. Add a body only when the *why* isn't obvious from the diff. - One logical change per commit. If you touched multiple unrelated things, split into separate commits. - After committing, also push to the tracked remote (`git push`) — standard `git push` to the current branch's upstream is authorized. **Never** force-push (`--force`, `--force-with-lease`) and **never** push to `main` from a feature branch directly without an explicit request. - **Never** stage `.env`, `data/`, secrets, or anything matching a credential pattern. Prefer `git add ` over `git add -A`/`git add .`. - If the build or tests fail, do **not** commit. Fix or revert, then either commit a working state or report the failure. - Skip the commit if there are no changes (don't create empty commits). - If you find yourself amending or rewriting prior commits, stop and ask first — autonomy covers new commits, not history rewrites.