Files

Brendan Chen 455cb53aa8 docs: authorize autonomous commits and pushes for this project

Standing authorization so any Claude Code instance commits work after
each logical change (build+tests green) and pushes to the upstream
branch, without waiting to be asked. Force-push and pushes to main from
a feature branch still require explicit approval.

2026-05-03 02:52:27 -07:00

2.4 KiB

Raw Blame History

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 <user> --password <pass> — 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 <specific files> 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.