[RAGE][DOTEXP-007] Project + per-language style KB for dotfiles, seeded from authoritative repo conventions #226

New issue

Open

opened 2026-09-20 01:44:30 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-20 01:44:30 +00:00

Owner

Parent: #281. Depends on lost-rob0t/prolog-rlm#493/#504 and language experts as they become available.

Create real project-scoped symbolic style rules under .zara/style/.

Seed provenance-bearing rules from authoritative current repo policy, including:

canonical Org source must be edited before generated/tangled outputs;
generated output parity;
TDD/verification obligations;
small focused diffs;
Nix/Home Manager conventions;
Bash safety/source-of-truth conventions;
Prolog KB/module conventions;
Common Lisp / Emacs Lisp project conventions;
Python/Nim/JS/TS/Java/Kotlin rules only where the repository has actual evidence.

Do not translate every prose sentence mechanically. Each rule needs stable ID, scope, source reference, check semantics, severity/category, optional preferred form/autofix class and revision.

Project rules layer over generic language style experts and remain explainable.

Acceptance: at least four language-specific project rule files plus project-wide rules load in full symbolic mode; conflicting user/project rules resolve deterministically; explanations cite source policy; project rules do not leak outside this repo.

Parent: #281. Depends on lost-rob0t/prolog-rlm#493/#504 and language experts as they become available. Create real project-scoped symbolic style rules under `.zara/style/`. Seed provenance-bearing rules from authoritative current repo policy, including: - canonical Org source must be edited before generated/tangled outputs; - generated output parity; - TDD/verification obligations; - small focused diffs; - Nix/Home Manager conventions; - Bash safety/source-of-truth conventions; - Prolog KB/module conventions; - Common Lisp / Emacs Lisp project conventions; - Python/Nim/JS/TS/Java/Kotlin rules only where the repository has actual evidence. Do not translate every prose sentence mechanically. Each rule needs stable ID, scope, source reference, check semantics, severity/category, optional preferred form/autofix class and revision. Project rules layer over generic language style experts and remain explainable. Acceptance: at least four language-specific project rule files plus project-wide rules load in full symbolic mode; conflicting user/project rules resolve deterministically; explanations cite source policy; project rules do not leak outside this repo.