By name: run-checks description: Run static checks and high-level validation before a production push in the Inline repo. Use when asked to run checks, verify correctness, or do pre-push/pre-release validation across server/web/admin/apple/cli/proto changes.
Run Checks
Overview
Run the minimal set of static checks and targeted builds/tests based on what changed. Prefer fast, focused checks and confirm with the user before long-running steps.
Workflow Decision Tree
1) Identify Scope
Run git status -sb and git diff --name-only. Group changes by top-level area:
server/web/admin/apple/InlineKitapple/InlineUIapple/InlineIOSapple/InlineMaccli/proto/
If only docs or comments changed, report that checks are optional and ask whether to skip.
2) Run Pre-Checks
If proto/ changed, run bun run generate:proto from repo root and include generated diffs.
If dependencies changed, run the relevant install/build for that stack:
- JS/TS:
bun install - Rust:
cargo fetch(or rely oncargo test/check) - Swift:
swift buildin the affected package directory
3) Run Component Checks
Run only what maps to the touched areas.
Backend (server/):
cd server && bun run typecheckcd server && bun run lintcd server && bun test(prefer targeted tests when possible)
Web (web/):
cd web && bun run typecheck- Run
cd web && bun run buildonly when explicitly requested or required for release validation
Admin (admin/):
cd admin && bun run typecheck
CLI (cli/ or protocol changes):
cd cli && cargo testfor full validation- Use
cd cli && cargo checkif a fast static check is sufficient
Swift packages:
cd apple/InlineKit && swift build(runswift testif tests were modified)cd apple/InlineUI && swift build
Apps:
- If changes are in
apple/InlineIOSorapple/InlineMac, do not run full app builds. Ask the user to runxcodebuildlocally if needed.
4) Report Results
Summarize what ran, what passed/failed, and what was skipped with reasons. For failures, include the first actionable error and the next recommended step.