fix: handle empty search results
feat(auth): add passkey enrollment
docs(readme): document local setup

Use ! and/or a BREAKING CHANGE: footer for breaking changes:

feat(api)!: remove legacy upload endpoint

BREAKING CHANGE: /v1/upload is no longer available.

Commit Types

Type	Purpose
`feat`	New feature
`fix`	Bug fix
`docs`	Documentation only
`style`	Formatting/style only
`refactor`	Code refactor, no feature/fix
`perf`	Performance improvement
`test`	Add/update tests
`build`	Build system/dependencies
`ci`	CI/config changes
`chore`	Maintenance/misc
`revert`	Revert a prior commit

Workflow

1. Inspect Repository State

Always inspect both staged and unstaged work before deciding what to commit:

git status --porcelain --branch
git diff --staged
git diff

If staged changes already exist, treat them as intentional but still compare them with unstaged and untracked work. Do not accidentally commit a stale or incomplete staged state. If the intended commit boundary is unclear, ask the user before staging or committing.

2. Choose the Commit Boundary

Stage only files that belong to the same logical change:

git add path/to/file1 path/to/file2

Use broad patterns only after reviewing git status --porcelain and confirming every matched path belongs in the commit. Avoid mixing unrelated fixes, formatting, generated files, or follow-up cleanup into the same commit unless the user explicitly wants that. Use interactive staging commands such as git add -p only when the environment supports interactive terminal prompts; avoid them in headless agent runs.

3. Check for Secrets and Accidental Files

Before committing, review newly added files and suspicious paths. Never commit .env files, credentials, private keys, tokens, production dumps, or local machine config.

Use available project tooling when present, and at minimum inspect staged names and content:

git diff --staged --name-status
git diff --staged

If a secret may have been staged, stop and ask the user how to proceed. Do not remove, rewrite, or rotate secrets unless explicitly requested.

4. Generate the Message

Derive the message from the staged diff:

Type: the kind of change, using the table above.
Scope: affected package, module, feature, or file family; omit when unclear.
Description: imperative, present tense, concise, and ideally under 50 chars (72 max).

Good subjects:

fix(auth): reject expired refresh tokens
test(api): cover paginated search errors
chore(deps): update eslint packages

Avoid subjects that describe the past:

fixed auth bug
updates tests
changed config

5. Add a Body When It Helps

Use a commit body when the subject alone does not explain the change well. Add one for non-obvious motivation, multi-file changes, behavioral changes, bug fixes where the root cause matters, migrations, compatibility constraints, breaking changes, or issue context.

Skip the body for small, self-explanatory commits.

Body style:

Separate subject and body with a blank line.
Explain why the change is needed and any important consequences.
Wrap lines around 72 characters when practical.
Do not mechanically restate the diff.

6. Commit

Use only the staged changes:

git diff --staged
git commit -m "fix(auth): reject expired refresh tokens"

For commits with a body or footer, pass additional -m paragraphs:

git commit \
  -m "fix(auth): reject expired refresh tokens" \
  -m "The previous check validated token shape but not expiry, so old refresh tokens could start a new session." \
  -m "Closes #123"

Safety Protocol

Never update git config.
Never run destructive commands without explicit user approval.
Never skip hooks with --no-verify unless the user asks.
Never force push to main or master.
Never amend an existing commit unless the user asks.
If a commit hook fails, fix the failure, re-run relevant validation, and retry the commit. Do not bypass the hook.

git-commit

Git Commit

Overview

Conventional Commit Format