feat: support reading external files as Code Review rules via use_file_path

[zephyrq-z]

Description

This PR adds support for loading Code Review rules from external .md / .txt files via a top-level use_file_path toggle in rule.json.

In practice, inlining complex review rules directly into rule.json makes the configuration bloated and hard to maintain. This change allows users to extract rule content into separate documents and reference them by path, keeping rule.json concise and readable.

Core Changes

• New top-level field use_file_path (boolean) on ProjectRule:
  • When true, all rule fields within the same rule.json are treated as relative paths to external .md / .txt files. The file content is read and overwrites the rule field at load time.
  • When false or omitted, rule fields continue to work as inline string rules — fully backward compatible.
• New resolveRuleFiles() function implements the file loading logic, called from loadGlobalRule(), loadRuleFile(), and loadProjectRule() after JSON unmarshalling.

Security & Robustness

The resolveRuleFiles function enforces strict safety guards:

1. Directory traversal protection — resolves symlinks on both base dir and file path, then performs an absolute-path prefix check to block ../ escapes.
2. Extension whitelist — only .md and .txt files are accepted; other extensions are rejected with a warning.
3. File size cap — individual rule files are limited to 100 KB to prevent LLM context-window bloat.
4. Graceful degradation — missing files, permission errors, unsupported extensions, or empty paths all produce a [WARN] log and leave the original rule string intact (no panics).

Configuration Example

{
  "use_file_path": true,
  "rules": [
    {
      "path": "**/*mapper*.xml",
      "rule": "docs/sql-rules.md"
    },
    {
      "path": "web/**/*.ts",
      "rule": "docs/frontend-rules.md"
    }
  ]
}

Paths are relative to the directory containing the rule.json file.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring (no functional changes)
• Documentation update
• CI / Build / Tooling

How Has This Been Tested?

Unit tests added in internal/config/rules/system_rules_test.go:

• TestResolveRuleFiles_Basic — verifies that a valid .md file's content correctly replaces the rule field.

• TestResolveRuleFiles_Security — confirms ../outside.md path traversal is blocked and the original rule string is preserved.

• TestResolveRuleFiles_UnsupportedExtension — confirms .json extension is rejected.

• TestResolveRuleFiles_TooLarge — confirms files exceeding 100 KB are rejected.

• TestResolveRuleFiles_MissingFile — confirms missing files produce a warning without panicking.

• make test passes locally

• Manual testing (describe below)

  Tested with use_file_path: true pointing to .md files in .opencodereview/docs/, confirmed rules are loaded correctly. Tested with ../ traversal paths and verified warnings are emitted and rules are not loaded.

Checklist

• My code follows the project's coding style (go fmt, go vet)
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or my feature works
• New and existing unit tests pass locally with my changes
• I have updated the documentation accordingly (if applicable)
• I have signed the CLA

Related Issues

Closes #67

[CLAassistant]

All committers have signed the CLA.

[lizhengfeng101]

感觉需要放在顶层，不然每个子项都需要配置一遍。

[github-actions]

🔍 OpenCodeReview found 2 issue(s) in this PR.

• ✅ 2 posted as inline comment(s)
• 📝 0 posted as summary (missing line info)

[github-actions]

Security: Symlink-based directory traversal bypass. filepath.Abs only performs lexical path cleaning — it does NOT resolve symlinks. An attacker (or a malicious repo) could place a symlink inside .opencodereview/ that points to an arbitrary file outside the base directory. The prefix check on the string path would pass because the symlink itself lives within the base dir, but os.ReadFile follows the symlink and reads the target file.

To fix this, resolve symlinks before performing the prefix check:

resolvedFile, err := filepath.EvalSymlinks(absFile)
if err != nil {
    fmt.Fprintf(os.Stderr, "[WARN] Failed to resolve symlinks for rule file %s: %v\n", filePath, err)
    continue
}

Then use resolvedFile for both the security check and subsequent reads. You should also resolve absBase with EvalSymlinks to handle the case where the base directory itself contains symlinks.

[github-actions]

Silent skip without warning when UseFilePath is true but Rule is empty. A user who sets "use_file_path": true but forgets to specify the "rule" field will get no feedback at all, making configuration debugging difficult. Consider adding a warning here similar to the other error paths.

Suggestion:

Suggested change

	if !entry.UseFilePath || entry.Rule == "" {
	continue
	}
	if !entry.UseFilePath {
	continue
	}
	if entry.Rule == "" {
	fmt.Fprintf(os.Stderr, "[WARN] Rule entry has use_file_path=true but empty rule path, skipping\n")
	continue
	}

[lizhengfeng101]

感觉这个说明会误导用户，同时存在 path 和字符串应该会报错吧，use_file_path开关应该是控制用户使用其中一种。

[lizhengfeng101]

另外其他语言的 readme 也需要补充下