codelaw-rules-data 0.2.0__py3-none-any.whl

codelaw_rules_data/rules/md/table-column-count.md

@@ -0,0 +1,43 @@
+---
+id: md/table-column-count
+title: "Table rows have as many cells as the header"
+languages: [markdown]
+fix: manual
+fix_reason: "which cell is missing or extra needs the author"
+stability: preview
+ported_from: [markdownlint/MD056]
+since: 0.1.0
+---
+
+Every row of a pipe table has the same number of cells as its header row.
+
+**Why:** Renderers drop extra cells and leave missing ones empty, so a misplaced pipe silently loses or shifts data.
+
+```codelaw
+native: md/table-column-count
+```
+
+## How to fix
+
+1. Compare the row with the header.
+2. Add the missing cells or remove the extra ones, or add a header column if the data needs it.
+
+## Examples
+
+### Markdown
+
+#### Don't
+
+````md
+| Name | Type |
+| ---- | ---- |
+| id | number | required |
+````
+
+#### Do
+
+````md
+| Name | Type | Note |
+| ---- | ---- | ---- |
+| id | number | required |
+````

codelaw_rules_data/rules/toml/deps-sorted.cases.md

@@ -0,0 +1,28 @@
+# toml/deps-sorted — edge cases
+
+### case: optional dependencies
+
+```toml
+[project.optional-dependencies]
+test = ["pytest", "Coverage[toml]"]
+```
+
+```expect
+2:1 toml/deps-sorted
+```
+
+```fixed
+[project.optional-dependencies]
+test = ["Coverage[toml]", "pytest"]
+```
+
+### case: names normalised
+
+```toml
+[project]
+dependencies = ["typing_extensions", "Typing-Inspect"]
+```
+
+```expect
+(none)
+```

codelaw_rules_data/rules/toml/deps-sorted.md

@@ -0,0 +1,49 @@
+---
+id: toml/deps-sorted
+title: "pyproject.toml dependencies are sorted by name"
+languages: [toml]
+files: ["**/pyproject.toml"]
+fix: auto
+stability: preview
+since: 0.1.0
+---
+
+The requirement lists in `[project].dependencies` and in each `[project.optional-dependencies]` extra are sorted by package name. Names compare the way pip compares them: case, `-`, `_` and `.` don't matter.
+
+**Why:** A sorted list is quicker to scan, shows a duplicate at once and gives smaller diffs; installers don't depend on the order.
+
+```codelaw
+native: toml/deps-sorted
+```
+
+## Examples
+
+### TOML
+
+#### Don't
+
+```toml path=pyproject.toml
+[project]
+name = "app"
+dependencies = [
+    "requests>=2.31",
+    "click>=8",
+    "attrs",
+]
+```
+
+#### Do
+
+```toml path=pyproject.toml
+[project]
+name = "app"
+dependencies = [
+    "attrs",
+    "click>=8",
+    "requests>=2.31",
+]
+```
+
+## Notes
+
+A list with comments in it is reported without a fix, because the comments would stay on their lines while the requirements move.

codelaw_rules_data/rules/toml/no-duplicate-keys.cases.md

@@ -0,0 +1,43 @@
+# toml/no-duplicate-keys — edge cases
+
+### case: array of tables repeats its header
+
+```toml
+[[bin]]
+name = "a"
+
+[[bin]]
+name = "b"
+```
+
+```expect
+(none)
+```
+
+### case: header after dotted keys
+
+```toml
+[tool]
+x.y = 1
+
+[tool.x]
+z = 2
+```
+
+```expect
+4:2 toml/no-duplicate-keys
+```
+
+### case: header defined twice
+
+```toml
+[a]
+x = 1
+
+[a]
+y = 2
+```
+
+```expect
+4:2 toml/no-duplicate-keys
+```

codelaw_rules_data/rules/toml/no-duplicate-keys.md

@@ -0,0 +1,43 @@
+---
+id: toml/no-duplicate-keys
+title: "No key or table defined twice in TOML"
+languages: [toml]
+fix: manual
+fix_reason: "which of the two definitions was meant can't be known from the file"
+stability: preview
+since: 0.1.0
+---
+
+A key is defined once in its table, and a `[table]` header appears once. That covers dotted keys (`a.b = 1` and then `a = 2`), a table defined both by a header and by dotted keys, and keys inside inline tables.
+
+**Why:** TOML forbids defining a key or table twice and conforming parsers refuse the file, so the mistake breaks every tool that reads it.
+
+```codelaw
+native: toml/no-duplicate-keys
+```
+
+## How to fix
+
+1. Decide which definition is right.
+2. Delete the other one, or merge the two tables into one.
+
+## Examples
+
+### TOML
+
+#### Don't
+
+```toml
+[tool.pytest]
+addopts = "-q"
+testpaths = ["tests"]
+addopts = "-ra"
+```
+
+#### Do
+
+```toml
+[tool.pytest]
+addopts = "-ra"
+testpaths = ["tests"]
+```

codelaw_rules_data/rules/toml/pyproject-requires-python.cases.md

@@ -0,0 +1,24 @@
+# toml/pyproject-requires-python — edge cases
+
+### case: no [project] table
+
+```toml
+[tool.poetry]
+name = "app"
+```
+
+```expect
+(none)
+```
+
+### case: declared dynamic
+
+```toml
+[project]
+name = "app"
+dynamic = ["requires-python", "version"]
+```
+
+```expect
+(none)
+```

codelaw_rules_data/rules/toml/pyproject-requires-python.md

@@ -0,0 +1,41 @@
+---
+id: toml/pyproject-requires-python
+title: "pyproject.toml declares requires-python"
+languages: [toml]
+files: ["**/pyproject.toml"]
+fix: suggest
+fix_reason: "the supported Python range is a project decision; the fix inserts the `python` option, which may not be the right range"
+stability: preview
+options:
+  python: { type: "string", default: ">=3.11", description: "the range the fix writes into `requires-python`" }
+since: 0.1.0
+---
+
+A `pyproject.toml` with a `[project]` table says which Python versions the package supports, in `requires-python`, unless it lists the field in `dynamic`.
+
+**Why:** pip uses `requires-python` to pick a release that works on the running interpreter; without it, users on an old Python install a version that then fails at import.
+
+```codelaw
+native: toml/pyproject-requires-python
+```
+
+## Examples
+
+### TOML
+
+#### Don't
+
+```toml path=pyproject.toml
+[project]
+name = "app"
+version = "1.0.0"
+```
+
+#### Do
+
+```toml path=pyproject.toml
+[project]
+name = "app"
+version = "1.0.0"
+requires-python = ">=3.11"
+```

codelaw_rules_data/rules/toml/pyproject-schema.md

@@ -0,0 +1,55 @@
+---
+id: toml/pyproject-schema
+title: "pyproject.toml matches its schema"
+languages: [toml]
+files: ["**/pyproject.toml"]
+fix: manual
+fix_reason: "a value the schema rejects is wrong in a way only its author knows how to correct"
+stability: preview
+ported_from: [schemastore/pyproject.json]
+since: 0.1.0
+---
+
+A `pyproject.toml` matches SchemaStore's schema for it: `[build-system]` and `[project]` hold the keys PEP 517, PEP 518 and PEP 621 define, each in the form they define.
+
+**Why:** Build backends reject or ignore a `[project]` key of the wrong shape — `authors` as a string, `dependencies` as a table — and the error appears only when someone builds the package.
+
+```codelaw
+target: $
+assert: { schema: schemas/pyproject }
+message: "$ERROR"
+```
+
+## How to fix
+
+1. Read the message: it names the key and the form the schema expects.
+2. Rewrite the value in that form, or move a tool's setting under `[tool.<name>]`.
+3. Run `codelaw check` on the file again until it is clean.
+
+## Examples
+
+### TOML
+
+#### Don't
+
+```toml path=pyproject.toml
+[project]
+name = "app"
+version = "1.0"
+authors = "Ada Lovelace"
+dependencies = { requests = ">=2" }
+```
+
+#### Do
+
+```toml path=pyproject.toml
+[project]
+name = "app"
+version = "1.0"
+authors = [{ name = "Ada Lovelace" }]
+dependencies = ["requests>=2"]
+```
+
+## Notes
+
+The schema is SchemaStore's `pyproject.json` schema, shipped with the pack in `data/schemas/pyproject.json` with its descriptions removed; nothing is fetched. The `[tool.*]` tables whose schemas live in other SchemaStore files (ruff, black, mypy, poetry, setuptools, uv, …) accept any value. TOML dates and times are read as strings.

codelaw_rules_data/rules/yaml/document-start.cases.md

@@ -0,0 +1,31 @@
+# yaml/document-start — edge cases
+
+### case: comment and directive before the marker
+
+```yaml
+# CI settings
+%YAML 1.2
+---
+a: 1
+```
+
+```expect
+(none)
+```
+
+### case: comment before content
+
+```yaml
+# settings
+a: 1
+```
+
+```expect
+2:1 yaml/document-start
+```
+
+```fixed
+# settings
+---
+a: 1
+```

codelaw_rules_data/rules/yaml/document-start.md

@@ -0,0 +1,36 @@
+---
+id: yaml/document-start
+title: "A YAML document starts with ---"
+languages: [yaml]
+exclude: ["**/*.md", "**/*.mdx"]
+fix: auto
+stability: preview
+since: 0.1.0
+---
+
+Every YAML document begins with an explicit `---` line. Comments and directives may come before it. Markdown front matter is not checked: its `---` belongs to the Markdown file.
+
+**Why:** An explicit start marks where a document begins, so a file can grow to hold several documents, and tools that concatenate YAML files keep the boundaries.
+
+```codelaw
+native: yaml/document-start
+```
+
+## Examples
+
+### YAML
+
+#### Don't
+
+```yaml
+name: build
+on: push
+```
+
+#### Do
+
+```yaml
+---
+name: build
+on: push
+```

codelaw_rules_data/rules/yaml/gha-action-schema.md

@@ -0,0 +1,59 @@
+---
+id: yaml/gha-action-schema
+title: "GitHub Actions action metadata matches its schema"
+languages: [yaml]
+files: ["**/action.yml", "**/action.yaml"]
+fix: manual
+fix_reason: "a misshapen input or run step has several possible meanings; the author picks the one they intended"
+stability: preview
+ported_from: [schemastore/github-action.json]
+since: 0.1.0
+---
+
+An `action.yml` matches SchemaStore's schema for action metadata: `name`, `description` and `runs` are present, and the inputs, outputs and steps have the keys and forms GitHub reads.
+
+**Why:** GitHub reads an action's metadata only when a workflow uses it, so a misspelt `steps:` or `using:` breaks every workflow that calls the action, not the action's own repository.
+
+```codelaw
+target: $
+assert: { schema: schemas/github-action }
+message: "$ERROR"
+```
+
+## How to fix
+
+1. Read the message: it names the key and what the schema expects.
+2. Add the missing key, or correct the key or the value.
+3. Run `codelaw check` on the file again until it is clean.
+
+## Examples
+
+### YAML
+
+#### Don't
+
+```yaml path=action.yml
+name: Setup
+description: Set the toolchain up
+runs:
+  using: composite
+  step:
+    - run: ./setup.sh
+      shell: bash
+```
+
+#### Do
+
+```yaml path=action.yml
+name: Setup
+description: Set the toolchain up
+runs:
+  using: composite
+  steps:
+    - run: ./setup.sh
+      shell: bash
+```
+
+## Notes
+
+The schema is SchemaStore's `github-action.json` schema, shipped with the pack in `data/schemas/github-action.json` with its descriptions removed; nothing is fetched. `oneOf` is read as `anyOf`.

codelaw_rules_data/rules/yaml/gha-pin-sha.cases.md

@@ -0,0 +1,25 @@
+# yaml/gha-pin-sha — edge cases
+
+### case: local action and docker image
+
+```yaml
+steps:
+  - uses: ./.github/actions/setup
+  - uses: docker://alpine:3.20
+```
+
+```expect
+(none)
+```
+
+### case: reusable workflow on a branch
+
+```yaml
+jobs:
+  call:
+    uses: octo/repo/.github/workflows/ci.yml@main
+```
+
+```expect
+3:11 yaml/gha-pin-sha
+```

codelaw_rules_data/rules/yaml/gha-pin-sha.md

@@ -0,0 +1,57 @@
+---
+id: yaml/gha-pin-sha
+title: "GitHub Actions are pinned to a commit SHA"
+languages: [yaml]
+files: ["**/.github/workflows/*.yml", "**/.github/workflows/*.yaml", "**/action.yml", "**/action.yaml"]
+fix: manual
+fix_reason: "finding the commit a tag points to needs the network, and the engine never uses it (L5)"
+stability: preview
+since: 0.1.0
+---
+
+A `uses:` in a GitHub Actions workflow or composite action names a full 40-character commit SHA, not a tag or branch. Local actions (`./…`) and `docker://` images are not checked.
+
+**Why:** A tag or branch can be moved to different code at any time, so a compromised or careless upstream changes what your workflow runs; a commit SHA can't change.
+
+```codelaw
+match:
+  kind: flow_node
+  regex: "@"
+  inside:
+    kind: block_mapping_pair
+    has: { field: key, regex: '^uses$' }
+  all:
+    - not: { regex: '@[0-9a-fA-F]{40}' }
+    - not: { regex: '^[''"]?(\./|docker://)' }
+message: "Pin `$$MATCH` to a full commit SHA; a tag or branch can be moved to other code"
+```
+
+## How to fix
+
+1. Look up the commit the tag points to, for example with `git ls-remote https://github.com/<owner>/<repo> <tag>`.
+2. Replace the tag with the 40-character SHA and keep the tag as a comment: `uses: actions/checkout@<sha> # v4.2.2`.
+3. Let Dependabot or Renovate update the pinned SHAs.
+
+## Examples
+
+### YAML
+
+#### Don't
+
+```yaml path=.github/workflows/ci.yml
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+```
+
+#### Do
+
+```yaml path=.github/workflows/ci.yml
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+```

codelaw_rules_data/rules/yaml/gha-workflow-schema.md

@@ -0,0 +1,57 @@
+---
+id: yaml/gha-workflow-schema
+title: "GitHub Actions workflows match their schema"
+languages: [yaml]
+files: ["**/.github/workflows/*.yml", "**/.github/workflows/*.yaml"]
+fix: manual
+fix_reason: "a misshapen job or step has several possible meanings; the author picks the one they intended"
+stability: preview
+ported_from: [schemastore/github-workflow.json]
+since: 0.1.0
+---
+
+A GitHub Actions workflow matches SchemaStore's schema for workflows: every key of a trigger, a job and a step is one GitHub reads, with a value of the form it takes.
+
+**Why:** GitHub rejects a malformed workflow only when it is pushed, and a misspelt key such as `runs_on` or `timeout-minute` fails the whole workflow file, so the mistake shows up as a red run instead of in review.
+
+```codelaw
+target: $
+assert: { schema: schemas/github-workflow }
+message: "$ERROR"
+```
+
+## How to fix
+
+1. Read the message: it names the key and what the schema expects, and suggests the key meant when the name is misspelt.
+2. Correct the key or the value.
+3. Run `codelaw check` on the file again until it is clean.
+
+## Examples
+
+### YAML
+
+#### Don't
+
+```yaml path=.github/workflows/ci.yml
+on: push
+jobs:
+  test:
+    runs_on: ubuntu-latest
+    steps:
+      - run: npm test
+```
+
+#### Do
+
+```yaml path=.github/workflows/ci.yml
+on: push
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - run: npm test
+```
+
+## Notes
+
+The schema is SchemaStore's `github-workflow.json` schema, shipped with the pack in `data/schemas/github-workflow.json` with its descriptions removed; nothing is fetched. YAML is read as YAML 1.2, as GitHub reads it, so `on:` is a key. `oneOf` is read as `anyOf`.

codelaw_rules_data/rules/yaml/no-ambiguous-booleans.cases.md

@@ -0,0 +1,29 @@
+# yaml/no-ambiguous-booleans — edge cases
+
+### case: GitHub Actions trigger key
+
+```yaml
+on:
+  push:
+    branches: [main]
+```
+
+```expect
+(none)
+```
+
+### case: quoted and sequence values
+
+```yaml
+a: "yes"
+b: [on, 'off']
+```
+
+```expect
+2:5 yaml/no-ambiguous-booleans
+```
+
+```fixed
+a: "yes"
+b: ["on", 'off']
+```

codelaw_rules_data/rules/yaml/no-ambiguous-booleans.md

@@ -0,0 +1,43 @@
+---
+id: yaml/no-ambiguous-booleans
+title: "No yes/no/on/off as unquoted values"
+languages: [yaml]
+fix: suggest
+fix_reason: "quoting keeps the YAML 1.2 meaning (a string); if a boolean was meant, write `true` or `false` instead"
+stability: preview
+since: 0.1.0
+---
+
+A value is not a bare `yes`, `no`, `on` or `off` (in any of their capitalisations). Quote it if it is text, or write `true` or `false` if it is a boolean. Keys are not checked, so a GitHub Actions `on:` is fine.
+
+**Why:** YAML 1.2 reads these words as strings, but YAML 1.1 loaders, still common (PyYAML, Ruby's Psych, many tools built on them), read them as booleans: `country: no` becomes `false`.
+
+```codelaw
+native: yaml/no-ambiguous-booleans
+```
+
+## Examples
+
+### YAML
+
+#### Don't
+
+```yaml
+country: no
+```
+
+#### Do
+
+```yaml
+country: "no"
+```
+
+#### Do
+
+```yaml
+enabled: true
+```
+
+## Differences from the source
+
+The idea comes from the YAML 1.1 and 1.2 specifications. `y` and `n` are not reported: the YAML 1.1 type repository lists them, but the common 1.1 loaders don't treat them as booleans.

codelaw_rules_data/rules/yaml/no-ambiguous-numbers.cases.md

@@ -0,0 +1,24 @@
+# yaml/no-ambiguous-numbers — edge cases
+
+### case: plain numbers and times that are not base 60
+
+```yaml
+a: 0
+b: 10:75
+c: 0:30
+d: 1.5
+```
+
+```expect
+(none)
+```
+
+### case: negative leading zero
+
+```yaml
+offset: -010
+```
+
+```expect
+1:9 yaml/no-ambiguous-numbers
+```