repopilot 0.11.0

Local-first CLI for repository audit, architecture risk detection, baseline tracking, and CI-friendly code review.
Documentation 
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

use crate::findings::types::{FindingCategory, Severity};
use crate::rules::metadata::RuleMetadata;

pub(super) static RULES: &[RuleMetadata] = &[
    RuleMetadata {
        rule_id: "language.rust.panic-risk",
        title: "Risky Rust panic or unwrap usage",
        category: FindingCategory::CodeQuality,
        default_severity: Severity::Medium,
        docs_url: None,
        description: "Rust panic-style operations such as unwrap(), expect(), panic!, todo!, and unimplemented! can be risky in reusable production code. Their severity depends on whether the code is test code, CLI boundary code, library code, or domain code.",
        recommendation: Some(
            "Use context-aware error handling. Prefer Result, ?, typed errors, validation, or explicit fallback behavior in production and library code.",
        ),
    },
    RuleMetadata {
        rule_id: "language.go.panic-exit-risk",
        title: "Risky Go panic or process exit usage",
        category: FindingCategory::CodeQuality,
        default_severity: Severity::Medium,
        docs_url: None,
        description: "Go panic and process-exit operations can terminate the program abruptly. Their risk depends on whether the file is test code, CLI boundary code, library code, or domain code.",
        recommendation: Some(
            "Return errors from reusable code and reserve panic/log.Fatal/os.Exit for narrow process boundaries where callers cannot recover.",
        ),
    },
    RuleMetadata {
        rule_id: "language.python.exception-risk",
        title: "Risky Python exception or assertion pattern",
        category: FindingCategory::CodeQuality,
        default_severity: Severity::Medium,
        docs_url: None,
        description: "Broad exception handlers, production asserts, and NotImplementedError placeholders can hide failures or ship incomplete behaviour. Their severity depends on test, script, and domain context.",
        recommendation: Some(
            "Catch specific exceptions, use explicit runtime validation, and replace placeholders before production release.",
        ),
    },
    RuleMetadata {
        rule_id: "language.javascript.runtime-exit-risk",
        title: "Risky JavaScript runtime exit or library throw",
        category: FindingCategory::CodeQuality,
        default_severity: Severity::Medium,
        docs_url: None,
        description: "Process exits and generic thrown errors have different risk at a CLI boundary than in reusable browser, Node, or package code.",
        recommendation: Some(
            "Prefer returning typed errors, rejecting promises with actionable context, or centralising CLI exit handling at the entrypoint.",
        ),
    },
    RuleMetadata {
        rule_id: "language.managed.fatal-exception-risk",
        title: "Risky JVM or .NET fatal exception placeholder",
        category: FindingCategory::CodeQuality,
        default_severity: Severity::Medium,
        docs_url: None,
        description: "Generic fatal exceptions and not-implemented placeholders in Java, Kotlin, or C# domain/library code can become runtime failures that callers cannot handle precisely.",
        recommendation: Some(
            "Replace placeholders with implemented behaviour and use domain-specific exception or result types where callers need to recover.",
        ),
    },
];