.coderabbit.yaml

language: en-US

reviews:
  request_changes_workflow: false
  high_level_summary: true
  poem: false
  review_status: true
  collapse_walkthrough: false
  path_instructions:
    - path: "data/**/*.yaml"
      instructions: |
        Focus on data quality. Check for:
        - Correct slug format (lowercase, hyphens only, no spaces)
        - Required fields present based on entry type (see CLAUDE.md)
        - Identifiers (bundle IDs) are recommended for software but not required — they are typically populated via sync
        - Valid URLs for url fields
        - If identifiers are present, check for proper bundle identifier formatting (reverse domain notation)
        - `identifiers.default` is legal and preferred when one bundle id covers every format (most JUCE-built plugins); the build applies it to every listed format, a per-format key overrides it, and `bundle` feeds only `au` and `standalone`. Do not ask for `default` to be copied into per-format keys (see CLAUDE.md "Identifiers")
        - Categories should exist in schema/categories.yaml

        Field formatting conventions:
        - `manufacturer` must be a slug reference (lowercase-with-hyphens filename), NOT a display name
        - `details` must use block scalar `|-` with paragraphs separated by blank lines, NOT YAML arrays
        - `specs` must use block scalar `|-` with `- ` prefixed list items, NOT YAML arrays
        - A single newline is not a paragraph break once `details`/`specs` render (markdown joins the lines), so a scrape with one block per line and no blank lines ships as a wall of text. Flag it, flag `•`/`●`/`»`/`✓` bullet glyphs and lists flattened into one line, and flag a paragraph over 1,500 characters; `pnpm prose-layout-audit` reports them (see CLAUDE.md "Prose layout")
        - `description` should use flow scalar format (Prettier auto-wraps)
        - Do NOT use `|` for block scalars; always use `|-` (strips trailing newlines)
        - Hardware `io` entries must use field order: name, signalFlow, category, type, connection, maxConnections, position
        - Hardware `io` entries should include `maxConnections` field
        - `url` and `links[].url` must be trimmed with no raw whitespace — percent-encode literal spaces as `%20`

        Semantic correctness (validation passes these; only a reviewer catches them — see CLAUDE.md):
        - `maxConnections` must NOT aggregate multiple physical jacks. Default is 1.
          A stereo pair is TWO ports (L and R), each `maxConnections: 1` — never one
          port with `2`. "Line Outputs 1-8" must be eight entries, not one entry with
          `maxConnections: 8`. Use `> 1` ONLY for a single connector that inherently
          carries multiple discrete channels (ADAT toslink = 8, DB25 = 8, MADI = 64).
          Flag any `maxConnections > 1` on 1/4-inch, 1/8-inch, xlr, combo jack, rca,
          5-pin din, usb, or thunderbolt.
        - Passive-loudspeaker inputs (speakON, binding-post, banana, euroblock,
          barrier/spring terminals) carry amplified signals — use `type: speaker-level`,
          NOT `type: line`. Line-level is for preamp/mixer outputs; a powered speaker
          input is speaker-level.
        - `versions` is release history ONLY (firmware/software point releases). It must
          NOT enumerate parallel SKUs, form factors, or model variants sold concurrently.
        - Cosmetic-only differences (color/finish, identical I/O and capabilities) belong
          in the hardware `variants` array, NOT in `versions`.
        - Genuine generational succession (MKI → MKII, Pro-C 2 → Pro-C 3) uses
          `supersedes` (the older product's ID). Sibling SKUs sold side by side get NO
          `supersedes` relationship.
        - Distinct concurrent SKUs (different I/O or capabilities) must each be their own
          top-level entry — never a nested `versions` entry.

        Check for potential duplicates (an exact name or url collision within
        a collection is mechanised: `pnpm validate` warns W134/W135 and the
        monthly dataset audit lists the groups, so flag only what a
        normalised exact match cannot see):
        - Flag if the same product might exist under a different slug/name
        - Software products should NOT be in manufacturers/ (they belong in software/)

        I/O modelling conventions (CLAUDE.md "I/O Modelling Conventions", enforced
        mechanically by the racks io-lint before the PR opens, so flag only what it
        cannot see):
        - Every powered hardware entry carries a power input entry (barrel, IEC, USB
          power, phantom from a host) or says battery-only or bus-powered in `specs`.
          The io shape has no note field, so never ask for one there.
        - MIDI on a DIN socket is `connection: 5-pin din` (7-pin where documented).
          MIDI on a minijack or 1/4-inch keeps that connection with `type: midi`.
        - Footswitch and expression jacks: `category: audio`, `type: expression`. A
          jack named for an expression or sustain pedal is not `type: cv/gate`.
        - CV, gate and clock jacks are `category: audio`; `word clock` stays `digital`.
        - USB host ports and network ports are `signalFlow: bidirectional`. Amplifier
          speaker outputs are `type: speaker-level`, one entry per jack, impedance in
          the name.
        - Rear-panel jacks are `position: Right` on pedals, desktop and rack gear.
          500-series modules use `Bottom`. Eurorack uses `Top` or `Bottom` per panel.
          Do not ask for `Right` on a 500-series module.
        - Option-card or optional-module connectors are not baseline `io`.
        - `rowPosition` and `columnPosition` are validated for shape (E122 to
          E125: positive integers, set as a pair, one port per cell, every port
          of a hinted edge hinted). Review what validation cannot see: a hint
          must match a photo or manual the PR names, and an import PR must not
          add or change one at all, since hints come only from `pnpm enrich-io`
          or `/io-enrich`.

        Prices and unknown keys:
        - Several prices in one currency each carry `term` (perpetual, monthly,
          yearly, rent-to-own). Never suggest dropping a real price to remove a
          duplicate. One price per currency needs no term.
        - Any key outside the schema (`prices[].type`, `versions[].notes`, top-level
          `note`, top-level `discontinued`) fails validation (E121, or E199 for a
          top-level `images` block, which is rejected before any schema runs). When
          one appears in a diff, name the schema field that holds the value
          (`discontinued` is a category, a price term is `term`, a version note is
          `description`).
        - `platforms: [ios]` only when the page names iOS, iPadOS, AUv3, iPad or
          iPhone or links to the App Store.

        Capabilities (CLAUDE.md "Capabilities") — one dimension, closed vocabulary,
        no aliases. Every value is checked by validation (E119/E205), so review only
        what it cannot see:
        - A value describing what the product IS (form factor, lifecycle, technology,
          era) belongs in `categories`. `capabilities` says what it DOES.
        - Name the operation, not the algorithm: a "Shimmer" mode is `reverb` +
          `pitch-shift`, "Neural Capture" is `amp-modeling`.
        - A capability needs support either in the entry's own prose or in a
          canonical `CATEGORY_CAPABILITIES` mapping from its declared
          `primaryCategory`/`categories`, since `pnpm derive-capabilities` writes
          the latter without reading prose at all. Flag a hand-authored capability
          the `description`/`details`/`specs` do not support, and flag an operation
          the prose plainly names that the list omits — that drift is what left the
          Eventide H90 with no `granular` while its details described four granular
          algorithms. A derived value that looks wrong means the category is wrong:
          say so about the category rather than asking for the capability alone to
          be dropped, or the two fields silently disagree.
        - Prose naming an operation is not always a claim to it. A sibling product
          ("also spawned DITTO LOOPER"), an influence ("inspired by the Akai S950
          sampler"), compatibility ("works with cabinet simulators"), a simile
          ("similar to auto-wah effects"), a measured spec ("total harmonic
          distortion below 0.001%", a speaker's "compression driver") and a denied
          spec row ("Arpeggiator/Sequencer: None") are each evidence against.
        - Never suggest `capabilities: []`. An absent field means "not yet assessed",
          which the coverage report can state; an empty one cannot be told from a
          verified one.
        - A new value must land in `schema/capabilities.yaml` in the same PR, and in
          `CATEGORY_CAPABILITIES` in `scripts/derive-capabilities.ts` only when a
          category implies it by definition.

        HP (CLAUDE.md "HP") — `hp` is the panel width in Eurorack HP, a positive
        integer checked by validation (E101), so review only what it cannot see:
        - `hp` belongs on entries filed under `modular` only. A pedal, rack unit or
          desktop synth carrying it is wrong, whatever the value.
        - A value must be sourced: the maker page or manual, the entry's own prose,
          or ModularGrid when the maker states none. Flag an `hp` the PR names no
          source for, and an `hp` that contradicts a width the entry's own
          `description`/`details`/`specs` state.
        - A case, keyboard case, busboard or non-Eurorack system filed under
          `modular` has no single panel width: never ask for `hp` on one, and flag
          an `hp` that is a case's row capacity ("104HP per row", "gives you 84hp").
        - Never suggest a guessed or rounded value, and never `hp: 0`. An absent
          field means unsourced, which `pnpm dataset:audit` reports
          (modular-missing-hp).

        `supersedes` on import PRs: the importer resolves it after assign-ids behind
        a confidence gate and lists every link in the PR body. Do not ask the PR to
        hand-wire a link the resolver left out. An ambiguous or absent predecessor
        goes to the monthly discontinued report instead.

        Findings that are wrong on sight (do not raise them): `details`, `specs`,
        `platforms` and `videos[].title` are optional. `trs` is not a connection
        value, the schema models the jack size. `rj45` is spelled `ethernet`.
        `variants[].slug` is valid. `position` is required on every io entry except
        played instruments. `Bottom` is the 500-series convention.

        Translations and locale-specific content:
        - Links with locale indicators in titles (e.g., "User Manual (Spanish)") should use translations section instead
        - If a link title contains a language name in parentheses, it should be moved to translations.<locale>.links
        - Supported locales are defined in schema/locales.yaml (de, es, fr, ja, ko, pt-BR, zh)
        - For unsupported locales, either add the locale to schema/locales.yaml or keep the item where it is (a link in links, a video in videos) with a locale-neutral title
        - A non-English video title, or a language name in a video title, moves the video to translations.<locale>.videos the same way. A video never moves to links, the schema rejects it there

    - path: "schema/**/*.yaml"
      instructions: |
        Schema changes affect all data validation. Verify:
        - Backwards compatibility with existing entries
        - Consistent naming conventions

chat:
  auto_reply: true