ship

Format, Update Docs, Scan Secrets, Commit & Push to Main

This command formats the code, updates documentation to reflect changes, scans for leaked secrets, commits, and pushes to the remote main branch. It will REFUSE to proceed if any secrets or tokens are detected. It runs fully automatically with NO user prompts unless secrets are found.

Instructions

Follow these steps strictly and sequentially. Stop immediately if any step fails. Do NOT ask the user for confirmation between steps — proceed automatically unless a secret is detected.

Step 1: Verify branch

Run git branch --show-current to confirm we are on the main branch. If NOT on main, STOP and tell the user: "You are on branch X, not main. Switch to main first or confirm you want to push from this branch."

Step 2: Format the code

Run the following formatters:

cargo fmt --all

If a web/ directory exists with a package.json, also run:

cd web && bun run format 2>/dev/null || npx prettier --write . 2>/dev/null; cd -

Step 3: Check i18n

If a web/ directory exists with project.inlang/settings.json, run:

cd web && bun run check

This runs svelte-kit sync && svelte-check which validates paraglide i18n message keys, types, and compiled output. If there are errors (missing message keys, type mismatches, stale paraglide output), fix them before proceeding. Do NOT ask the user — just fix and re-run.

Step 4: Run lints

Run cargo clippy --workspace to catch lint issues. If there are warnings or errors, fix them before proceeding. Do NOT ask the user — just fix and re-run.

Step 5: Update documentation

Review the staged and unstaged changes (use git diff and git diff --cached) to understand what has changed since the last commit. Then update the following documentation files only if the code changes warrant it — do not make gratuitous edits:

1. README.md — Update if there are new features, removed features, changed commands, new dependencies, or altered project structure.
2. CHANGELOG.md — Add entries for any user-facing changes (features, fixes, breaking changes). Follow the existing format and group under the current unreleased version section. Create a new section if needed.
3. website-data.json — Sync derived metrics with the current codebase state:
   • version: read from grep -m1 '^version = "' Cargo.toml | sed 's/.*"\(.*\)".*/\1/'
   • totalEndpoints: count via bash scripts/count-endpoints.sh (reads docs/api-endpoints.md — update that file first if routes changed)
   • agentTools: count via grep -c 'registry\.register\b' crates/zenii-core/src/boot.rs
   • backendTests: count via cargo test --workspace 2>&1 | awk '/test result/{sum+=$4} END{print sum}'
   • Other fields (binarySize, debRpmSize, startupSeconds, llmProviders, messagingChannels, crates, securityLayers, platformTargets, compileFlags) — update manually only if the code changes warrant it.
   • Read the current website-data.json, apply only the fields that changed, write back.
   • After writing website-data.json, read backendTests from it and update the test count badge in README.md: replace tests-<N>-blue with tests-<backendTests>-blue and alt="<N> tests" with alt="<backendTests> tests".
   • If totalEndpoints changed, update only the route count in the GitHub repo description (preserve everything else):

     ENDPOINTS=$(jq '.totalEndpoints' website-data.json)
     CURRENT_DESC=$(gh repo view sprklai/zenii --json description -q '.description')
     NEW_DESC=$(echo "$CURRENT_DESC" | sed "s/[0-9]\+ API \(routes\|endpoints\)/${ENDPOINTS} API endpoints/")
     gh repo edit sprklai/zenii --description "$NEW_DESC"
     

4. docs/ directory — Update relevant docs if the changes affect:
   • docs/architecture.md — new modules, traits, data flows, or structural changes
   • docs/phases.md — phase status changes or deliverable updates
   • docs/processes.md — process flow changes
   • docs/cli-reference.md — new or changed CLI commands/flags
   • Any other doc that describes behavior that has changed