structured-data-models/.coderabbit.yaml at main · NVIDIA/structured-data-models · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
# yaml-language-server: $schema=https://storage.googleapis.com/coderabbit_public_assets/schema.v2.json

language: en-US

tone_instructions: >-
  Be concise and technical. Prioritize correctness, tensor semantics
  (shape/device/dtype), API design, and leakage-sensitive preprocessing.
  Skip style nitpicks already enforced by ruff and pre-commit.

reviews:
  profile: quiet
  request_changes_workflow: false
  high_level_summary: true
  high_level_summary_in_walkthrough: true
  poem: false
  review_status: false
  collapse_walkthrough: true
  sequence_diagrams: true
  in_progress_fortune: false
  suggested_labels: false
  suggested_reviewers: false

  path_filters:
    - '!uv.lock'
    - '!build/**'
    - '!**/*.egg-info/**'

  path_instructions:
    - path: 'sdm/**/*.py'
      instructions: >-
        Core library code. Enforce the project's PyTorch-centric style:
        typed function and method boundaries; keyword arguments in
        multi-line calls; no `else` after return/raise/break/continue;
        prefer vectorized PyTorch tensor operations over NumPy or Python
        loops; preserve tensor device and dtype, flagging accidental
        transfers via `.cpu()`, `.numpy()`, `.item()`, Python scalars, or
        newly-created CPU tensors; prefer tensor methods over functions
        (e.g. `x.log()` over `torch.log(x)`); expect short shape comments
        on complex tensor operations; avoid formulations that cause
        avoidable `torch.compile` graph breaks. Treat preprocessing as
        leakage-sensitive: transformations that learn state must be
        scoped to the context/training portion unless explicitly designed
        otherwise, and stochastic transformations must expose
        seed/generator control. Keep model-family wrappers thin, avoid
        config-first APIs, and keep core dependencies minimal (heavy
        dependencies optional). In `__init__.py`, imports and `__all__`
        are intentionally ordered by dependency, not alphabetically — do
        not suggest alphabetical sorting there.
    - path: 'sdm/_kernels/**'
      instructions: >-
        For changes introducing or expanding a custom GPU kernel, check
        whether the performance evidence includes a practical
        compiler-generated or existing-library alternative. If absent,
        request a comparison or a concrete explanation of incompatibility.
        Check that comparisons preserve workload and numerical requirements
        and distinguish startup from prediction latency. Treat this as a
        justification question; do not infer performance from source code
        alone.
    - path: 'test/**/*.py'
      instructions: >-
        Pytest-based tests. Check that behavior changes in sdm/ have
        corresponding test coverage, seeds or generators are used only
        when required by the tested behavior, and parametrization covers relevant
        dtype/device variants. Plain pytest functions are preferred over
        unittest-style classes.
    - path: 'examples/**'
      instructions: >-
        Runnable benchmark/usage examples. Prioritize readability and
        end-to-end correctness over micro-optimization, but still flag
        API misuse and data leakage between train/test portions.

  auto_review:
    enabled: true
    drafts: false

  slop_detection:
    enabled: true
    include_all_authors: true
    label: slop

  finishing_touches:
    docstrings:
      enabled: true
    unit_tests:
      enabled: true

  pre_merge_checks:
    title:
      mode: warning
    description:
      mode: warning

  tools:
    ruff:
      enabled: true
    yamllint:
      enabled: false
    markdownlint:
      enabled: false
    languagetool:
      enabled: false
    actionlint:
      enabled: true
    gitleaks:
      enabled: true
    github-checks:
      enabled: true

chat:
  auto_reply: true
  art: false
  allow_non_org_members: false

knowledge_base:
  opt_out: false
  learnings:
    scope: local
  pull_requests:
    scope: local

code_generation:
  docstrings:
    language: en-US
    path_instructions:
      - path: 'sdm/**/*.py'
        instructions: >-
          Follow Google-style docstrings (ruff pydocstyle
          convention=google, line length 79). Start with a one-line
          imperative summary. Document public constructor parameters in
          an Args section. Use bracket shape notation for tensors, e.g.
          `[batch_size, num_cols, dim]`. Cite the paper when the
          implementation follows one. Do not add docstrings to magic
          methods or `__init__` (D105/D107 are ignored).
  unit_tests:
    path_instructions:
      - path: 'sdm/**/*.py'
        instructions: >-
          Place tests under test/ mirroring the sdm/ package layout. Use
          plain pytest functions with `pytest.mark.parametrize` for
          dtype/device variants and `sdm.testing` utilities where applicable.
          Do not set seeds unless the tested behavior requires them; use
          explicit generators when controlled randomness is necessary.