From a0d08b81436bec473caaf0525713bac5cd1e7682 Mon Sep 17 00:00:00 2001
From: Mateo Wang <277851410+mateo-berri@users.noreply.github.com>
Date: Tue, 4 Aug 2026 19:35:22 -0700
Subject: [PATCH] chore: remove pre-commit and bootstrap advisories

They were taking too long
---
 CLAUDE.md | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/CLAUDE.md b/CLAUDE.md
index 5a30d7bb4cf..209d9aaf326 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -39,10 +39,6 @@ Don't hesitate to use values in .env to get needed API keys and other secrets, a
 
 Python max line length is 120, not 88
 
-On a fresh worktree or clone, run `make bootstrap` before anything else. It provisions everything tests, `make pre-commit`, and a local proxy need
-
-Run tests before you commit. Also, run `make pre-commit` right before each commit, which generates types (as needed) and formats/lints your code. Any errors found must be fixed. It only runs when there are staged frontend and/or backend changes and calculates violations, generates types, etc. based on the worktree, so stage what you need or stash/delete unwanted files in litellm/ or ui/ (where backend and frontend lint run, respectively) before running it. If it fails because dashboard api types are stale, it already regenerated them for you. You just need to stage the schema.d.ts and commit; the regenerated file itself can't fail anything (it's prettier/eslint-ignored and regeneration is deterministic), so re-run only if other checks failed too, or if no ui/ files were staged before: staging schema.d.ts newly triggers the folder-wide dashboard lint budgets locally and CI's frontend-lint job (budgets plus knip), which can only fail if the dashboard tree was already broken independently of your change
-
 When you fix violations gated by `ruff-strict-budget.json`, `type-discipline-budget.json`, or `basedpyright-code-budget.json`, run `make lint-budget-update` and commit the lowered limits so the ceilings ratchet down instead of leaving stale headroom. It measures the working tree, so it must contain exactly the fixes you're committing
 
 If you're trying to create a new function that relies on untyped stuff, instead of adding more Any's and pushing `reportAny` / `reportExplicitAny` closer to their basedpyright ceilings, just validate it in the caller with Pydantic (a model or `TypeAdapter` that returns the typed thing or raises will do) and then pass the now typed variable in