core: RuleContext exposes the entire Config to every static rule, letting any rule read another rule's options or the LLM/plugin settings

[MaximeGaudin]

Summary

RuleContext::config is pub config: &'a Config, the same full Config struct engine::run itself uses (rules, ignore globs, llm settings, plugin refs), so nothing stops a rule implementation from reading context.config.llm.api_key_env or context.config.options_for("some/other-rule"), even though a rule is only supposed to see its own options via context.option().

Scope

• Severity (reporter's assessment): low
• Area: arch
• Code: packages/core/src/rules/mod.rs:89-119
• Reproduced empirically: yes

Minimal reproduction

In any impl Rule for X { fn check(&self, context: &mut RuleContext<'_>) { ... } }, write context.config.options_for("description/min-length") or context.config.llm.provider — both compile and return real data belonging to an unrelated rule/subsystem, because config is a plain public field rather than a narrowed accessor.

Expected

RuleContext should expose only what a static rule needs (its own options via option(), plus perhaps the ignore/ output-facing bits it legitimately requires), not the raw Config, so the type system documents and enforces the boundary between 'my settings' and 'everything the whole run was configured with'.

Sources

• https://rust-lang.github.io/api-guidelines/type-safety.html — API guidelines favor exposing the minimum surface needed rather than a shared mutable/readable god-object

Notes

No rule currently abuses this (verified by reading naming.rs, description.rs, body.rs, bundle.rs, metadata.rs — all use context.option() only), so this is a latent abstraction leak rather than an observed bug today.

---

Filed as part of a systematic pre-release audit. Triage and de-duplication pending.