Context
Today there is exactly one .bec/rules.yaml, at the repo root. In a monorepo, teams own packages and will want to own their rules (packages/api/.bec/rules.yaml), with different severities per package.
The current workaround — scope rules with paths: ["packages/api/**"] globs — works and is now documented in usage.md's Performance and limits (#77), but it centralizes ownership at the root.
Options to evaluate
- Discover nested
.bec/rules.yaml files and merge, with the nearest file winning for its subtree (mirrors .gitignore layering). Portability question: what does export mean for a nested rule?
- A root-level
include: listing package rule files — explicit, no discovery cost.
- Do nothing and bless the glob-scoping pattern as the monorepo answer in the docs.
Option 3 is free; 1 is the most ergonomic but touches the frozen file discovery contract, so it needs the deprecation lens even though it is additive.
Acceptance
Context
Today there is exactly one
.bec/rules.yaml, at the repo root. In a monorepo, teams own packages and will want to own their rules (packages/api/.bec/rules.yaml), with different severities per package.The current workaround — scope rules with
paths: ["packages/api/**"]globs — works and is now documented in usage.md's Performance and limits (#77), but it centralizes ownership at the root.Options to evaluate
.bec/rules.yamlfiles and merge, with the nearest file winning for its subtree (mirrors.gitignorelayering). Portability question: what doesexportmean for a nested rule?include:listing package rule files — explicit, no discovery cost.Option 3 is free; 1 is the most ergonomic but touches the frozen file discovery contract, so it needs the deprecation lens even though it is additive.
Acceptance
why,export/importand the hook path