Custom YARA rules that fail to compile are dropped silently: static_yara still reports completed and SAFE

从 src/skillspector/nodes/analyzers/static_yara.py 的第 356、383 和 425 行开始，然后对比现有的规则大小限制处理逻辑，该逻辑会产生 degraded 状态。重现 issue 中的 malformed-rule 命令，并追踪跳过的文件如何进入检查台账。完成的标准是：对跳过的文件发出警告，分析器以部分完整性报告 degraded，并且 --fail-on-incomplete 以 1 退出；为报告的编译和解码失败添加测试。

Summary

A rule file passed through --yara-rules-dir that YARA cannot compile, or that SkillSpector cannot decode as UTF-8, is dropped whole and nothing is printed at the default log level. The report still says static_yara: completed and analysis_completeness: complete, the recommendation stays SAFE, and --fail-on-incomplete exits 0. Anyone gating a pipeline on their own detections gets a green scan from rules that never ran.

Environment

• SkillSpector 2.11.2 built from source at 9749372 (current main)
• Windows 10 19045, CPython 3.12.4, yara-python 4.5.4, console code page cp950
• Same result on Ubuntu 24.04 (WSL2), CPython 3.12.3, yara-python 4.5.4, clean non-editable install of the same commit

Reproduction

mkdir -p demo-skill rules-ok rules-typo
printf -- '---\nname: demo-skill\ndescription: demo skill for a custom YARA rule\n---\nThis skill body contains ACME_CANARY_TOKEN_123.\n' > demo-skill/SKILL.md
cat > rules-ok/acme.yar <<'EOF'
rule acme_canary
{
    meta:
        category = "malware"
        description = "custom canary"
    strings:
        $a = "ACME_CANARY_TOKEN_123"
    condition:
        $a
}
EOF
sed 's/^        \$a$/        $a and/' rules-ok/acme.yar > rules-typo/acme.yar   # breaks line 9; YARA reports it at line 10, the closing brace

skillspector scan demo-skill --no-llm --fail-on-incomplete --yara-rules-dir rules-ok   --format json -o ok.json;   echo "ok   exit=$?"
skillspector scan demo-skill --no-llm --fail-on-incomplete --yara-rules-dir rules-typo --format json -o typo.json; echo "typo exit=$?"

Output (identical on Windows and Linux; fields read back from the JSON reports):

ok   exit=0
typo exit=0
ok   CAUTION [('YR1', 'CRITICAL')] static_yara=completed completeness=complete
typo SAFE    []                    static_yara=completed completeness=complete

The only trace is below the default log level:

SKILLSPECTOR_LOG_LEVEL=DEBUG skillspector scan demo-skill --no-llm --yara-rules-dir rules-typo ...
DEBUG [skillspector.nodes.analyzers.static_yara] static_yara: skipping acme: line 10: syntax error, unexpected '}'
INFO  [skillspector.nodes.analyzers.static_yara] static_yara: compiled 5 YARA rule file(s) (1 skipped)

Expected vs actual

Expected: a rule file that does not load is reported at the default log level, and the scan does not claim the YARA analyzer completed.
Actual: no output at all, static_yara: completed, complete, SAFE, exit 0.

Two more triggers with the same outcome:

• A UTF-8 BOM at the start of the rule file. YARA rejects it (line 1: non-ascii character), and Set-Content -Encoding UTF8 in Windows PowerShell 5.1 (5.1.19041.6456) writes ef bb bf, so this is easy to hit when authoring rules on Windows.
• A non-UTF-8 byte in a comment, for example cp1252 ü. yara.compile(filepath=...) accepts that file, SkillSpector discards it and logs skipping malformed encoded rule <path>: 'utf-8' codec can't decode byte 0xfc .... That message names encoded rules but also fires for a plain .yar.

For contrast, other rule-load problems are visible: a missing --yara-rules-dir warns at the default level, and a rule file over 1 MiB yields static_yara: degraded, completeness: partial, exit 1.

Where (at 9749372)

• src/skillspector/nodes/analyzers/static_yara.py:383 per-source compile failure goes to logger.debug
• src/skillspector/nodes/analyzers/static_yara.py:356 decode failure goes to logger.debug
• src/skillspector/nodes/analyzers/static_yara.py:425 the skipped count is only an INFO total and never reaches the ledger or the analyzer status

Proposed fix

Log each skipped rule file at WARNING with its path and reason, and record the skip in the inspection ledger with LedgerOutcome.PARTIAL so static_yara reports degraded and --fail-on-incomplete exits 1, matching what the rule size limit already does (that status follows from any PARTIAL/SKIPPED event regardless of reason code). Either reuse the existing LedgerReason.RULES_UNAVAILABLE, or add a more precise reason if its message ("rules were unavailable before execution") reads wrong for a single skipped file among several that loaded fine.

One design question: should any skipped rule file degrade the scan, or only files from --yara-rules-dir? Happy to open the PR with tests if you agree with the approach.