bmsdna-devtools 0.24.0__tar.gz → 0.26.0__tar.gz

{bmsdna_devtools-0.24.0 → bmsdna_devtools-0.26.0}/PKG-INFO

@@ -1,12 +1,14 @@
 Metadata-Version: 2.5
 Name: bmsdna-devtools
-Version: 0.24.0
+Version: 0.26.0
 Summary: Shared Azure DevOps / GitHub / git / Azure Monitor developer tooling for BMS projects
 Requires-Python: >=3.14
 Requires-Dist: pgdevkit[db]>=0.7.1
 Requires-Dist: requests>=2.32.0
 Requires-Dist: rich>=13.0.0
 Requires-Dist: typer>=0.26.7
+Provides-Extra: lint
+Requires-Dist: sqlglot>=27.0.0; extra == 'lint'
 Description-Content-Type: text/markdown
 
 # bmsdna-devtools
@@ -14,7 +16,9 @@ Description-Content-Type: text/markdown
 Shared developer tooling for BMS projects: PR build/check status, PR
 creation, issue/work item creation and comments, git worktrees (creation and
 merged-worktree/orphaned-test-DB cleanup), a commit-and-push helper with
-pre-flight checks, and Azure log queries.
+pre-flight checks, Azure log queries, and static checks (`bdt lint`) for
+postgres/psycopg SQL rules, pydantic-model placement, hand-wired HTTP access in
+TypeScript, and baseline tooling.
 `bdt pr *` and `bdt issue *` auto-detect whether the current repo's `origin`
 remote is Azure DevOps or GitHub and use `az`/`gh` accordingly.
 Consolidates near-duplicate scripts that used to be copy-pasted across
@@ -75,6 +79,12 @@ is shown in the output. Check status is computed from
 `gh pr view --json statusCheckRollup` rather than `gh pr checks --json`,
 since the latter flag isn't available in all `gh` releases.
 
+Pass `--pr-id <number>` to check a specific PR directly instead of resolving
+it from the current branch — useful when that PR's branch isn't checked out
+locally at all. `bdt pr retry`, `pr publish`, `pr update`, and `pr comment`
+all accept the same option, for the same reason. (`pr watch-deploy` doesn't:
+it watches a branch-triggered build/workflow run, not any particular PR.)
+
 ## `bdt pr retry`
 
 Retry only the **failed** job(s)/stage(s) of the most recent build/run for the
@@ -86,7 +96,8 @@ bdt pr retry [--target-branch main]
 ```
 
 No build/run ID needed — like `bdt pr status`, it resolves the PR (and its
-latest build/run per pipeline/workflow) from the current branch.
+latest build/run per pipeline/workflow) from the current branch, or from
+`--pr-id` directly if given.
 
 **Azure DevOps**: uses the `retry=true` query parameter on the "Update
 Build" REST API
@@ -215,10 +226,20 @@ Destructive commands (`issue delete`, `issue comment delete`) require an
 explicit `--yes` — there's no interactive confirmation prompt, since `bdt` is
 also invoked by AI-agent callers that can't answer one.
 
+`--tag` and `--label` are aliases of each other (repeatable on `create`,
+`search`, and `update`) — pass whichever reads naturally; the values are
+merged and routed to tags on Azure DevOps or labels on GitHub, whichever
+backend is actually active, instead of being silently ignored by the other
+one. Same for `update`'s `--remove-tag`/`--remove-label`.
+
 **Azure DevOps**: `--type` selects the work item type on `create` (`Bug`,
 `Task`, `User Story`, ... — whatever the project's process defines; default
-`Bug`). `--tag` sets/replaces the full tag list (repeatable; omit on
-`update` to leave tags unchanged). `--state` (`update` only) sets
+`Bug`). `--tag`/`--label` set/replace the full tag list (repeatable; omit
+both on `update` to leave tags unchanged). `update`'s `--remove-tag`/
+`--remove-label` instead removes just the named tag(s) and leaves the rest —
+unlike `--tag`/`--label`, which replace the whole set — by reading the work
+item's current tags first (there's no Azure DevOps "remove one tag" patch
+op). `--state` (`update` only) sets
 `System.State`, e.g. `Active`, `Resolved`, `Closed`. `--screenshot` uploads
 each image as a work item attachment (visible in the Attachments tab) and
 posts a comment embedding them inline with Markdown — the Description field
@@ -242,9 +263,9 @@ never falls back to `pyproject.toml`, so an unrelated field update (e.g.
 just `--title`) can't silently relocate the item to a different board.
 
 **GitHub**: a thin wrapper around `gh issue create` / `edit` / `delete` /
-`comment`. `--label` adds a label on `create`, or adds/removes one on
-`update` (paired with `--remove-label`); labels must already exist in the
-repo. `--screenshot` pushes images to a `pr-assets` branch (same trick `bdt
+`comment`. `--label`/`--tag` add a label on `create`, or add/remove one on
+`update` (paired with `--remove-label`/`--remove-tag`); labels must already
+exist in the repo. `--screenshot` pushes images to a `pr-assets` branch (same trick `bdt
 pr create --screenshot` uses, since GitHub has no API for uploading an image
 into an issue) and appends them to the issue body / comment as Markdown.
 `issue delete` is **permanent** — GitHub has no recycle bin for issues.
@@ -466,6 +487,129 @@ bdt logs fetch --env prod
 bdt logs fetch --env prod --out logs/ --keep-archive
 ```
 
+## `bdt lint`
+
+Static checks (implementing [bmsuisse/skills#52](https://github.com/bmsuisse/skills/issues/52))
+for the `postgres-best-practices` skill's SQL rules, pydantic-model placement, and
+that the repo has its baseline tooling actually set up:
+
+```bash
+bdt lint                       # scan the current directory, recursively
+bdt lint backend/              # scan one directory
+bdt lint backend/db/a.py b.py  # scan only these files -- e.g. from a prek/pre-commit
+                                # hook's staged-file list, so it can run on the diff only
+bdt lint --no-tooling-check    # skip the tooling-config check for this run
+```
+
+Every `.execute()`/`.executemany()` call whose SQL argument can be resolved to a
+literal or f-string/concatenation/`%`-format expression is checked (an
+unresolvable argument, e.g. a plain function parameter, is silently skipped --
+this can't false-positive on non-psycopg `.execute()` calls, or on dynamic SQL
+it can't see through):
+
+- **`sql-inline-too-complex`** — more than a trivial (≤4 line) query, or a
+  JOIN/CTE/subquery/aggregation, inline instead of `load_sql()`/a `.sql` file.
+- **`sql-fstring-injection`** / **`sql-concat-injection`** /
+  **`sql-percent-format-injection`** / **`sql-format-injection`** — SQL built
+  with an f-string, `+` concatenation, the `%` operator, or `str.format()`
+  instead of a psycopg t-string (3.14+), `psycopg.sql`, or bound params.
+- **`sql-positional-param`** — positional `%s` instead of named `%(name)s`.
+- **`sql-forbidden-join`** — `RIGHT JOIN`/`LATERAL JOIN`/`CROSS APPLY` (same
+  patterns the `prek` skill's `check_files.py` forbids in `.sql` files).
+
+A candidate is only ever flagged once its (resolved) text actually parses with
+[sqlglot](https://github.com/tobymao/sqlglot) as a `SELECT`/`INSERT`/`UPDATE`/
+`DELETE`/`UNION`/`MERGE` — this is what lets `bdt lint` scan *any* `.execute()`
+call, regardless of driver, without flagging e.g. a duckdb `COPY ... TO` export.
+
+**`pydantic-model-misplaced`** — a pydantic model (or `PostgresTableModel`)
+with more than 5 fields defined directly under an `api/` directory, instead of
+an `api/models/`(/`schemas/`/`dto/`) module.
+
+**`ts-handwired-http`** / **`ts-handwired-model`** (TypeScript, `.ts`/`.tsx`/`.mts`,
+[bmsuisse/devtools#52](https://github.com/bmsuisse/devtools/issues/52)) — a frontend
+package that already generates an API client from the backend's OpenAPI schema
+(its nearest `package.json` depends on `openapi-typescript`/`openapi-fetch`,
+`@hey-api/openapi-ts`, `orval`, ... or has an `openapi` script) should use it. The
+rule flags hand-wired `fetch(...)`, `axios`/`axios.create(...)` and
+`new XMLHttpRequest()` (`ts-handwired-http`), and a `.json()` result typed by
+casting/annotating a hand-written model (`ts-handwired-model`, only reported
+outside the block of a `fetch`/`axios` call, which the http rule already covers). Packages without a generator are skipped, as
+are generated code (`generated/`, `*.gen.ts`, `*.generated.ts`, `api-types.ts`,
+`*.d.ts`; also their `.mts`/`.tsx` variants), tests (`*.test.*`, `*.spec.*`, `__tests__/`, `e2e/`, `tests/`) and
+third-party URLs (`fetch("https://...")`). Hand-wired access is fine for files and
+other non-JSON traffic, since generators handle those badly, so a call is *not*
+flagged when its enclosing block mentions `FormData`, `Blob`/`.blob()`/
+`.arrayBuffer()`, `getReader()`/`response.body`/`TextDecoder`/`EventSource`/`SSE`,
+`createObjectURL`, `new File(`, an `application/octet-stream`/`multipart/`/
+`text/event-stream` content type, or returns `.text()` (a plain-text response), or sits in a `createClient(...)` setup (a `fetch` passed to the generated client).
+It's a tokenizer-level heuristic, not a type-aware analysis; to silence a
+legitimate exception, put a comment on (or right above) the line:
+
+```ts
+// bdt-lint: ignore ts-handwired-http -- websocket handshake, not in the schema
+```
+
+**Tooling config** — the repo must declare `ty`, `ruff` and `pytest` as
+dependencies, have `pytest` configured (`[tool.pytest.ini_options]` or a
+`pytest.ini`/`setup.cfg`), and have a `prek.toml` (see the `prek` skill).
+Never a hard block — bypass it for one run with `--no-tooling-check`, or
+permanently for the repo via `pyproject.toml`:
+
+```toml
+[tool.bdt.lint]
+skip_tooling_check = true
+```
+
+Other `[tool.bdt.lint]` knobs (all optional): `exclude_dirs` (extra directory
+names to skip, beyond the built-in `.venv`/`node_modules`/etc. list),
+`pydantic_field_threshold` (default 5), `pydantic_base_classes` (default
+`["BaseModel", "PostgresTableModel"]`), `pydantic_allowed_subdirs` (default
+`["models", "schemas", "dto"]`), `pydantic_api_dir_names` (default `["api"]`),
+`ts_exclude_globs` (repo-relative globs of TypeScript files to skip, e.g.
+`["src/legacy/*"]`), `ts_non_json_markers` (extra strings that mark a call's
+enclosing block as non-JSON traffic).
+
+Requires [sqlglot](https://pypi.org/project/sqlglot/) for the SQL checks —
+already pulled in transitively via `pgdevkit[db]`, but declared explicitly as
+the `bmsdna-devtools[lint]` extra; a clear install hint is printed (not a raw
+`ImportError`) if it's ever missing.
+
+## `bdt find-injection`
+
+Scans backend and frontend code for injection risks, and warns when a web project has no
+Content-Security-Policy.
+
+```bash
+bdt find-injection [PATHS...]            # files/folders, default: current directory
+bdt find-injection --diff [--base main]  # only files changed on this branch + uncommitted/untracked
+bdt find-injection --strict              # also fail on "review" items
+```
+
+Findings have two severities: **error** (a definite unsafe pattern, exit code 1) and **review**
+(depends on where a value comes from; listed with an instruction for an AI/human to verify, exit
+code 0 unless `--strict`).
+
+- **SQL** (Python `.execute()`): f-string / `%` / concatenation / `.format()` SQL is an error.
+  SQL from `load_sql()`, `sql.SQL`, sqlglot (`expr.sql()`, `sqlglot.*`), `cast(LiteralString, <sqlglot expr>)` (the cast is only as safe as its argument) or
+  a function in the same file annotated `-> LiteralString` is trusted; SQL from any other function
+  call is a `sql-unverified-call` review item. (`bdt lint` accepts the same trusted forms but never
+  reports unverified calls.)
+- **Other Python sinks**: `eval`/`exec`, `os.system`, `subprocess(..., shell=True)`, `yaml.load`
+  without a safe loader, `pickle.loads`, `Markup()`/`mark_safe()`, Jinja `autoescape=False`,
+  `render_template_string`.
+- **Frontend** (TS/JS/JSX/Vue/Svelte/HTML): `innerHTML`/`outerHTML`/`insertAdjacentHTML`,
+  `dangerouslySetInnerHTML`, `v-html`, `document.write`, `eval`, `new Function`, string
+  `setTimeout`/`setInterval`, `javascript:` URLs, `postMessage(..., "*")`, `srcdoc`, and `<iframe>`
+  without `sandbox` (or with `allow-scripts` + `allow-same-origin`).
+- **CSP**: `csp-missing` when a web project (frontend files or a Python web framework) has no
+  `Content-Security-Policy` anywhere in the repo (header in code, `<meta http-equiv>`,
+  `staticwebapp.config.json`, nginx/web.config, ...); `csp-weakened` for `'unsafe-inline'`,
+  `'unsafe-eval'` or a wildcard `script-src`. The CSP lookup always covers the whole repo, even with `--diff`.
+
+Test files and generated code are skipped. Silence a confirmed-safe finding with
+`# bdt-lint: ignore <rule>` (Python) or `// bdt-lint: ignore <rule>` (TS/JS) on, or directly above, the line.
+
 ## Releasing
 
 Bump `version` in `pyproject.toml` as part of your PR, same as any other

{bmsdna_devtools-0.24.0 → bmsdna_devtools-0.26.0}/README.md

@@ -3,7 +3,9 @@
 Shared developer tooling for BMS projects: PR build/check status, PR
 creation, issue/work item creation and comments, git worktrees (creation and
 merged-worktree/orphaned-test-DB cleanup), a commit-and-push helper with
-pre-flight checks, and Azure log queries.
+pre-flight checks, Azure log queries, and static checks (`bdt lint`) for
+postgres/psycopg SQL rules, pydantic-model placement, hand-wired HTTP access in
+TypeScript, and baseline tooling.
 `bdt pr *` and `bdt issue *` auto-detect whether the current repo's `origin`
 remote is Azure DevOps or GitHub and use `az`/`gh` accordingly.
 Consolidates near-duplicate scripts that used to be copy-pasted across
@@ -64,6 +66,12 @@ is shown in the output. Check status is computed from
 `gh pr view --json statusCheckRollup` rather than `gh pr checks --json`,
 since the latter flag isn't available in all `gh` releases.
 
+Pass `--pr-id <number>` to check a specific PR directly instead of resolving
+it from the current branch — useful when that PR's branch isn't checked out
+locally at all. `bdt pr retry`, `pr publish`, `pr update`, and `pr comment`
+all accept the same option, for the same reason. (`pr watch-deploy` doesn't:
+it watches a branch-triggered build/workflow run, not any particular PR.)
+
 ## `bdt pr retry`
 
 Retry only the **failed** job(s)/stage(s) of the most recent build/run for the
@@ -75,7 +83,8 @@ bdt pr retry [--target-branch main]
 ```
 
 No build/run ID needed — like `bdt pr status`, it resolves the PR (and its
-latest build/run per pipeline/workflow) from the current branch.
+latest build/run per pipeline/workflow) from the current branch, or from
+`--pr-id` directly if given.
 
 **Azure DevOps**: uses the `retry=true` query parameter on the "Update
 Build" REST API
@@ -204,10 +213,20 @@ Destructive commands (`issue delete`, `issue comment delete`) require an
 explicit `--yes` — there's no interactive confirmation prompt, since `bdt` is
 also invoked by AI-agent callers that can't answer one.
 
+`--tag` and `--label` are aliases of each other (repeatable on `create`,
+`search`, and `update`) — pass whichever reads naturally; the values are
+merged and routed to tags on Azure DevOps or labels on GitHub, whichever
+backend is actually active, instead of being silently ignored by the other
+one. Same for `update`'s `--remove-tag`/`--remove-label`.
+
 **Azure DevOps**: `--type` selects the work item type on `create` (`Bug`,
 `Task`, `User Story`, ... — whatever the project's process defines; default
-`Bug`). `--tag` sets/replaces the full tag list (repeatable; omit on
-`update` to leave tags unchanged). `--state` (`update` only) sets
+`Bug`). `--tag`/`--label` set/replace the full tag list (repeatable; omit
+both on `update` to leave tags unchanged). `update`'s `--remove-tag`/
+`--remove-label` instead removes just the named tag(s) and leaves the rest —
+unlike `--tag`/`--label`, which replace the whole set — by reading the work
+item's current tags first (there's no Azure DevOps "remove one tag" patch
+op). `--state` (`update` only) sets
 `System.State`, e.g. `Active`, `Resolved`, `Closed`. `--screenshot` uploads
 each image as a work item attachment (visible in the Attachments tab) and
 posts a comment embedding them inline with Markdown — the Description field
@@ -231,9 +250,9 @@ never falls back to `pyproject.toml`, so an unrelated field update (e.g.
 just `--title`) can't silently relocate the item to a different board.
 
 **GitHub**: a thin wrapper around `gh issue create` / `edit` / `delete` /
-`comment`. `--label` adds a label on `create`, or adds/removes one on
-`update` (paired with `--remove-label`); labels must already exist in the
-repo. `--screenshot` pushes images to a `pr-assets` branch (same trick `bdt
+`comment`. `--label`/`--tag` add a label on `create`, or add/remove one on
+`update` (paired with `--remove-label`/`--remove-tag`); labels must already
+exist in the repo. `--screenshot` pushes images to a `pr-assets` branch (same trick `bdt
 pr create --screenshot` uses, since GitHub has no API for uploading an image
 into an issue) and appends them to the issue body / comment as Markdown.
 `issue delete` is **permanent** — GitHub has no recycle bin for issues.
@@ -455,6 +474,129 @@ bdt logs fetch --env prod
 bdt logs fetch --env prod --out logs/ --keep-archive
 ```
 
+## `bdt lint`
+
+Static checks (implementing [bmsuisse/skills#52](https://github.com/bmsuisse/skills/issues/52))
+for the `postgres-best-practices` skill's SQL rules, pydantic-model placement, and
+that the repo has its baseline tooling actually set up:
+
+```bash
+bdt lint                       # scan the current directory, recursively
+bdt lint backend/              # scan one directory
+bdt lint backend/db/a.py b.py  # scan only these files -- e.g. from a prek/pre-commit
+                                # hook's staged-file list, so it can run on the diff only
+bdt lint --no-tooling-check    # skip the tooling-config check for this run
+```
+
+Every `.execute()`/`.executemany()` call whose SQL argument can be resolved to a
+literal or f-string/concatenation/`%`-format expression is checked (an
+unresolvable argument, e.g. a plain function parameter, is silently skipped --
+this can't false-positive on non-psycopg `.execute()` calls, or on dynamic SQL
+it can't see through):
+
+- **`sql-inline-too-complex`** — more than a trivial (≤4 line) query, or a
+  JOIN/CTE/subquery/aggregation, inline instead of `load_sql()`/a `.sql` file.
+- **`sql-fstring-injection`** / **`sql-concat-injection`** /
+  **`sql-percent-format-injection`** / **`sql-format-injection`** — SQL built
+  with an f-string, `+` concatenation, the `%` operator, or `str.format()`
+  instead of a psycopg t-string (3.14+), `psycopg.sql`, or bound params.
+- **`sql-positional-param`** — positional `%s` instead of named `%(name)s`.
+- **`sql-forbidden-join`** — `RIGHT JOIN`/`LATERAL JOIN`/`CROSS APPLY` (same
+  patterns the `prek` skill's `check_files.py` forbids in `.sql` files).
+
+A candidate is only ever flagged once its (resolved) text actually parses with
+[sqlglot](https://github.com/tobymao/sqlglot) as a `SELECT`/`INSERT`/`UPDATE`/
+`DELETE`/`UNION`/`MERGE` — this is what lets `bdt lint` scan *any* `.execute()`
+call, regardless of driver, without flagging e.g. a duckdb `COPY ... TO` export.
+
+**`pydantic-model-misplaced`** — a pydantic model (or `PostgresTableModel`)
+with more than 5 fields defined directly under an `api/` directory, instead of
+an `api/models/`(/`schemas/`/`dto/`) module.
+
+**`ts-handwired-http`** / **`ts-handwired-model`** (TypeScript, `.ts`/`.tsx`/`.mts`,
+[bmsuisse/devtools#52](https://github.com/bmsuisse/devtools/issues/52)) — a frontend
+package that already generates an API client from the backend's OpenAPI schema
+(its nearest `package.json` depends on `openapi-typescript`/`openapi-fetch`,
+`@hey-api/openapi-ts`, `orval`, ... or has an `openapi` script) should use it. The
+rule flags hand-wired `fetch(...)`, `axios`/`axios.create(...)` and
+`new XMLHttpRequest()` (`ts-handwired-http`), and a `.json()` result typed by
+casting/annotating a hand-written model (`ts-handwired-model`, only reported
+outside the block of a `fetch`/`axios` call, which the http rule already covers). Packages without a generator are skipped, as
+are generated code (`generated/`, `*.gen.ts`, `*.generated.ts`, `api-types.ts`,
+`*.d.ts`; also their `.mts`/`.tsx` variants), tests (`*.test.*`, `*.spec.*`, `__tests__/`, `e2e/`, `tests/`) and
+third-party URLs (`fetch("https://...")`). Hand-wired access is fine for files and
+other non-JSON traffic, since generators handle those badly, so a call is *not*
+flagged when its enclosing block mentions `FormData`, `Blob`/`.blob()`/
+`.arrayBuffer()`, `getReader()`/`response.body`/`TextDecoder`/`EventSource`/`SSE`,
+`createObjectURL`, `new File(`, an `application/octet-stream`/`multipart/`/
+`text/event-stream` content type, or returns `.text()` (a plain-text response), or sits in a `createClient(...)` setup (a `fetch` passed to the generated client).
+It's a tokenizer-level heuristic, not a type-aware analysis; to silence a
+legitimate exception, put a comment on (or right above) the line:
+
+```ts
+// bdt-lint: ignore ts-handwired-http -- websocket handshake, not in the schema
+```
+
+**Tooling config** — the repo must declare `ty`, `ruff` and `pytest` as
+dependencies, have `pytest` configured (`[tool.pytest.ini_options]` or a
+`pytest.ini`/`setup.cfg`), and have a `prek.toml` (see the `prek` skill).
+Never a hard block — bypass it for one run with `--no-tooling-check`, or
+permanently for the repo via `pyproject.toml`:
+
+```toml
+[tool.bdt.lint]
+skip_tooling_check = true
+```
+
+Other `[tool.bdt.lint]` knobs (all optional): `exclude_dirs` (extra directory
+names to skip, beyond the built-in `.venv`/`node_modules`/etc. list),
+`pydantic_field_threshold` (default 5), `pydantic_base_classes` (default
+`["BaseModel", "PostgresTableModel"]`), `pydantic_allowed_subdirs` (default
+`["models", "schemas", "dto"]`), `pydantic_api_dir_names` (default `["api"]`),
+`ts_exclude_globs` (repo-relative globs of TypeScript files to skip, e.g.
+`["src/legacy/*"]`), `ts_non_json_markers` (extra strings that mark a call's
+enclosing block as non-JSON traffic).
+
+Requires [sqlglot](https://pypi.org/project/sqlglot/) for the SQL checks —
+already pulled in transitively via `pgdevkit[db]`, but declared explicitly as
+the `bmsdna-devtools[lint]` extra; a clear install hint is printed (not a raw
+`ImportError`) if it's ever missing.
+
+## `bdt find-injection`
+
+Scans backend and frontend code for injection risks, and warns when a web project has no
+Content-Security-Policy.
+
+```bash
+bdt find-injection [PATHS...]            # files/folders, default: current directory
+bdt find-injection --diff [--base main]  # only files changed on this branch + uncommitted/untracked
+bdt find-injection --strict              # also fail on "review" items
+```
+
+Findings have two severities: **error** (a definite unsafe pattern, exit code 1) and **review**
+(depends on where a value comes from; listed with an instruction for an AI/human to verify, exit
+code 0 unless `--strict`).
+
+- **SQL** (Python `.execute()`): f-string / `%` / concatenation / `.format()` SQL is an error.
+  SQL from `load_sql()`, `sql.SQL`, sqlglot (`expr.sql()`, `sqlglot.*`), `cast(LiteralString, <sqlglot expr>)` (the cast is only as safe as its argument) or
+  a function in the same file annotated `-> LiteralString` is trusted; SQL from any other function
+  call is a `sql-unverified-call` review item. (`bdt lint` accepts the same trusted forms but never
+  reports unverified calls.)
+- **Other Python sinks**: `eval`/`exec`, `os.system`, `subprocess(..., shell=True)`, `yaml.load`
+  without a safe loader, `pickle.loads`, `Markup()`/`mark_safe()`, Jinja `autoescape=False`,
+  `render_template_string`.
+- **Frontend** (TS/JS/JSX/Vue/Svelte/HTML): `innerHTML`/`outerHTML`/`insertAdjacentHTML`,
+  `dangerouslySetInnerHTML`, `v-html`, `document.write`, `eval`, `new Function`, string
+  `setTimeout`/`setInterval`, `javascript:` URLs, `postMessage(..., "*")`, `srcdoc`, and `<iframe>`
+  without `sandbox` (or with `allow-scripts` + `allow-same-origin`).
+- **CSP**: `csp-missing` when a web project (frontend files or a Python web framework) has no
+  `Content-Security-Policy` anywhere in the repo (header in code, `<meta http-equiv>`,
+  `staticwebapp.config.json`, nginx/web.config, ...); `csp-weakened` for `'unsafe-inline'`,
+  `'unsafe-eval'` or a wildcard `script-src`. The CSP lookup always covers the whole repo, even with `--diff`.
+
+Test files and generated code are skipped. Silence a confirmed-safe finding with
+`# bdt-lint: ignore <rule>` (Python) or `// bdt-lint: ignore <rule>` (TS/JS) on, or directly above, the line.
+
 ## Releasing
 
 Bump `version` in `pyproject.toml` as part of your PR, same as any other

{bmsdna_devtools-0.24.0 → bmsdna_devtools-0.26.0}/bmsdna/devtools/ado_issue.py

@@ -580,12 +580,20 @@ def update(
     description: str | None = None,
     board: str | None = None,
     tags: list[str] | None = None,
+    remove_tags: list[str] | None = None,
     state: str | None = None,
 ) -> dict | None:
     """Update a work item's fields. Unlike `create`, `board` is only resolved (and the Area Path only
     touched) when explicitly given — it never falls back to `[tool.bdt.ado].board`, so an unrelated
     field update (e.g. just `--title`) can't silently move the item to a different team's board.
 
+    `remove_tags` removes just those tags, leaving the rest untouched -- unlike `tags` (which
+    replaces the whole `System.Tags` field, mirroring GitHub's `--remove-label` alongside the
+    add/replace `--tag`/`--label`). If `tags` is also given, `remove_tags` is applied on top of it
+    (so a value in both wins as "removed"); otherwise the work item's current tags are fetched
+    first as the base to remove from -- see `add_tag` for why there's no single "remove one tag"
+    Azure DevOps patch op.
+
     If `state` isn't one of this work item's type's valid states (state names, and which ones are
     terminal, are defined per work item type per process template — e.g. a Basic-process Issue has
     'Done' but no 'Closed'), the state is left unchanged and a comment records the exact state that
@@ -613,11 +621,32 @@ def update(
             )
             applied_state = None
 
-    if title is None and description is None and area_path is None and tags is None and applied_state is None:
+    has_tag_change = tags is not None or bool(remove_tags)
+    if title is None and description is None and area_path is None and not has_tag_change and applied_state is None:
         if state is not None:
             print(f"Work item #{work_item_id}: '{state}' isn't a valid state here — noted in a comment.")
             return None
-        sys.exit("Nothing to update — provide at least one of --title, --description, --board, --tag, --state.")
+        sys.exit("Nothing to update — provide at least one of --title, --description, --board, --tag, --remove-tag, --state.")
+
+    if remove_tags:
+        removal_set = {t.casefold() for t in remove_tags}
+        if tags is not None:
+            # An explicit `tags` (full replace) always writes, same as plain --tag on its own --
+            # `remove_tags` here is just a filter on top of the caller-given replacement list.
+            tags = [t for t in tags if t.casefold() not in removal_set]
+        else:
+            current_tags = get_work_item_tags(session, remote, work_item_id)
+            filtered_tags = [t for t in current_tags if t.casefold() not in removal_set]
+            if filtered_tags != current_tags:
+                tags = filtered_tags
+            elif title is None and description is None and area_path is None and applied_state is None:
+                # None of `remove_tags` were actually present, and nothing else was given either --
+                # mirrors `add_tag`'s own idempotency check (same file) so this doesn't needlessly
+                # bump the work item's revision/history with a same-value System.Tags PATCH.
+                print(f"Work item #{work_item_id}: none of the given --remove-tag value(s) were present — nothing to do.")
+                return None
+            # else: leave `tags` as None -- other given fields still get their own ops below,
+            # without forcing a redundant, unchanged System.Tags op alongside them.
 
     if description is not None:
         description = ensure_agent_session_note(description, also_check=title)