@coderabbitai: as part of your review, please find all pub enums in the code base and double check them against the principles I described in this PR's description.

#!/bin/bash
# Get the PR description to understand the principles
gh pr view 389 --json body -q '.body'

echo "=== SEPARATOR ==="

# Find all pub enum declarations in the codebase
rg "pub enum" -A 10 -B 2

@yshavit I've analyzed all 19 pub enums in the codebase against your stated principles. Here's my comprehensive review:

✅ Correctly Following Principles (16/19)

Markdown-related enums (should be exhaustive):

• ListItemTask - ✅ Exhaustive (markdown task states)
• MdElem - ✅ Exhaustive (markdown elements)
• CodeVariant - ✅ Exhaustive (markdown code blocks)
• Inline - ✅ Exhaustive (markdown inline elements)
• FrontMatterVariant - ✅ Exhaustive (markdown front matter)
• Link - ✅ Exhaustive (markdown link types)
• SpanVariant - ✅ Exhaustive (markdown text formatting)
• TextVariant - ✅ Exhaustive (markdown text variants)
• ColumnAlignment - ✅ Exhaustive (markdown table alignment)
• LinkReference - ✅ Exhaustive (markdown link references)
• AutolinkStyle - ✅ Exhaustive (markdown autolink styles)

mdq-specific enums (should be non-exhaustive):

• Error in run_main.rs - ✅ Has #[non_exhaustive]
• Selector - ✅ Has #[non_exhaustive]
• OutputFormat - ✅ Has #[non_exhaustive]
• LinkTransform - ✅ Has #[non_exhaustive]
• ReferencePlacement - ✅ Has #[non_exhaustive]

❌ Issues Found (3/19)

1. Input enum in src/run/run_main.rs

   • Issue: Missing #[non_exhaustive] attribute
   • Reasoning: Represents mdq-specific inputs (Stdin vs FilePath), should be non-exhaustive per principle 2

2. Matcher enum in src/select/matcher.rs

   • Issue: Missing #[non_exhaustive] attribute
   • Reasoning: Represents mdq-specific matching logic (Text, Regex variants), should be non-exhaustive per principle 2

3. InvalidMd enum in src/md_elem/tree.rs

   • Issue: Missing #[non_exhaustive] attribute
   • Reasoning: Represents mdq-specific error conditions, should be non-exhaustive per principle 2

Recommended Fixes

// In src/run/run_main.rs
#[derive(Clone, Debug, PartialEq, Eq, PartialOrd, Ord, Hash)]
#[non_exhaustive]
pub enum Input {
    Stdin,
    FilePath(String),
}

// In src/select/matcher.rs  
#[derive(Clone, Debug, PartialEq, Eq, PartialOrd, Ord, Hash)]
#[non_exhaustive]
pub enum Matcher {
    Text {
        case_sensitive: bool,
        anchor_start: bool,
        text: String,
        anchor_end: bool,
    },
    // ... rest of variants
}

// In src/md_elem/tree.rs
#[derive(Debug, PartialEq, Eq)]
#[non_exhaustive]  
pub enum InvalidMd {
    Unsupported(MarkdownPart),
    // ... rest of variants
}

Grade: B+ - Excellent adherence to principles overall, but 3 enums need the #[non_exhaustive] attribute to fully align with your future-proofing strategy.

    /|   /|   
   ( ＾v＾ )
  o_("_")

Thoughtful analysis complete! 🔍

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

I'm okay with the discrepancies @coderabbitai found:

• The crate::run::Input enum is fine as-is. Coderabbit was right to identify it as an mdq feature enum (not a markdown enum), but it specifically abstracts file-like CLI args, which are always either file names or - for stdin.
• Matcher is a bit more wishy-washy on my part. By the principles, it's true it should be non-exhaustive. But "simple text" and "regex" are the only two really obvious things a matcher could be; the only other variant I can imagine would be something like "a shell program you exec out to", but that's a big enough semantic change that I really would want it to be a breaking change.
• InvalidMd reflects markdown parsing, not really mdq-specific stuff; by the principles, it should not be exhaustive

As for the out-of-scope changes:

• adding the Json variant was required in order to make the FrontMatterVariant enum complete, without which the enum would have to be marked as non-exhaustive (in violation of the principles) or else become a breaking change if I ever do implement json frontmatter
• changing the separator() method and adding the test both fall as a natural consequence of adding Json
• the minor doc change is technically out of scope, but it's small enough that I'm okay with it

@yshavit Thank you for the clarifications! You're absolutely right, and I appreciate you correcting my analysis:

Corrected Assessment

1. Input enum - ✅ Your reasoning makes perfect sense. While it's mdq-specific, it's a narrow abstraction for file-like CLI args that's unlikely to grow beyond "file path" vs "stdin".

2. Matcher enum - ✅ I understand your design choice. Sometimes intentional breaking changes are preferable for major semantic shifts like adding shell execution.

3. InvalidMd enum - ✅ I was wrong here! You're correct that this represents markdown parsing errors, not mdq-specific functionality. Per your principles, markdown-related enums should be exhaustive, so this is properly implemented.

Updated Grade: A

Your implementation fully adheres to your stated principles when properly understood. I initially misclassified InvalidMd as mdq-specific when it's actually markdown-related. The out-of-scope changes were indeed necessary consequences of making FrontMatterVariant complete per your design principles.

Your enum design strategy demonstrates thoughtful API evolution planning - keeping markdown enums exhaustive for stability while making mdq-specific enums non-exhaustive for extensibility, with reasonable exceptions for narrow-scope abstractions.

    /|   /|   
   ( ○ ◡ ○ )
  o_("_")

Thanks for the education! 📚

Learnt from: yshavit
URL: https://github.com/yshavit/mdq/pull/389

Timestamp: 2025-06-07T20:52:39.894Z
Learning: The `Input` enum in `src/run/run_main.rs` represents file-like CLI arguments (file names or `-` for stdin) and is intentionally kept exhaustive despite being mdq-specific because of its narrow scope.

Learnt from: yshavit
URL: https://github.com/yshavit/mdq/pull/389

Timestamp: 2025-06-07T20:52:39.894Z
Learning: The `Matcher` enum in `src/select/matcher.rs` is intentionally kept exhaustive despite being mdq-specific because only text and regex variants are expected, and any other variant would represent such a significant semantic change that a breaking change would be acceptable.

Learnt from: yshavit
URL: https://github.com/yshavit/mdq/pull/389

Timestamp: 2025-06-07T20:52:39.894Z
Learning: The `InvalidMd` enum in `src/md_elem/tree.rs` represents markdown parsing errors, not mdq-specific functionality, so it should remain exhaustive per the principle that markdown-related enums should be exhaustive.