chore: simplify Nova agent policy

Author: luccahuguet

.agent-protocols.json

@@ -97,6 +97,6 @@
   ],
   "exceptions": [],
   "overlay": {
-    "sha256": "bc9259b39146436878e6a5ad0c0678ff9e79a84dbbb9b73503427821f420a835"
+    "sha256": "81d378f1e1c94abe00de964c34985bd4187a94583985e5ce0fdead8a2251b002"
   }
 }

.agent-protocols.local.md

@@ -5,9 +5,8 @@ fewest practical lines of code and the simplest ownership model.
 
 ### Nova Boundary
 
-Use contract-driven, check-backed development rather than mechanically porting
-main Yazelix. Review the current Yazelix sources of truth and decide explicitly
-what survives.
+Do not mechanically port main Yazelix. Review the current Yazelix sources of
+truth and decide explicitly what survives.
 
 Current runtime chain:
 
@@ -16,10 +15,8 @@ yzx -> Mars -> Yazelix Zellij fork
 ```
 
 The project interface is a Nix/Lix-compatible flake. `yzx` is the installed
-command name. Avoid local compatibility shims and generated fixtures unless a
-chosen contract requires them. Do not broaden Home Manager, layouts, config
-generation, plugins, pane policy, or legacy compatibility unless the user
-chooses that scope.
+command name. Do not broaden Home Manager, layouts, config generation, plugins,
+pane policy, or legacy compatibility unless the user chooses that scope.
 
 ### Git Channels
 
@@ -40,8 +37,6 @@ accepted and verified for `main`, advance `main` to that exact revision with:
 git push origin <sha>:main
 ```
 
-Never promote `stable` directly from `edge`.
-
 `stable` is the promotion-only user channel. Advance it only when the user
 explicitly requests promotion. A candidate must be a fast-forward from the
 current `stable`, belong to `main`, pass the protected Linux and cache checks,
@@ -53,25 +48,12 @@ known P0 or P1 regression. Promote the exact verified revision with:
 git push origin <sha>:stable
 ```
 
-Never force-push or delete `stable`.
-
-Rollbacks use a new revert commit on `edge`, followed by normal verification and
-fast-forward promotion through `main` and then `stable`.
-
-### Runtime Delivery
-
-After changing the flake runtime, keep the user's installed runtime current:
-
-```sh
-nix profile upgrade --refresh yazelix
-```
-
-Do not launch GUI sessions unless the user asks or reports manual dogfooding.
+Never delete `stable`.
 
 ### Beads
 
-Use `br` for all issue work and never edit `.beads/` files directly. Serialize
-`br` writes and finish with `br sync --flush-only`.
+Use `br` for all issue work. Serialize writes and finish with
+`br sync --flush-only`.
 
 Use `bv --robot-triage` as the graph-aware planning entry point. Use only
 `bv --robot-*` commands; bare `bv` opens an interactive TUI. `bv` decides what
@@ -84,19 +66,25 @@ Update the README LOC scorecard whenever project files change. Update
 `CHANGELOG.md` when user-visible runtime behavior, commands, keymaps, packaged
 tools, or runtime contracts change.
 
-Prefer deleting scope, avoiding abstractions, and reusing existing package
-outputs over adding local wrappers. If LOC grows, make the added behavior
-visible in the scorecard and justify it. Formatting rules outrank LOC pressure;
-for Rust, keep `rustfmt` output rather than compressing code manually.
+If LOC grows, make the added behavior visible in the scorecard and justify it.
+Formatting rules outrank LOC pressure; for Rust, keep `rustfmt` output rather
+than compressing code manually.
 
 ### Nova Verification
 
-Run the cheapest exact checks for the changed surface. For runtime flake
-changes, normally verify:
+For runtime flake changes, normally verify:
 
 ```sh
 nix flake check
 nix flake show --all-systems
 nix build .#yazelix --no-link --print-build-logs
 nix profile add --refresh /home/lucca/pjs/yazelix-dir/yazelix --profile <tmp>
 ```
+
+After changing the flake runtime, keep the user's installed runtime current:
+
+```sh
+nix profile upgrade --refresh yazelix
+```
+
+Do not launch GUI sessions unless the user asks or reports manual dogfooding.

.beads/issues.jsonl

@@ -367,9 +367,8 @@ fewest practical lines of code and the simplest ownership model.
 
 ### Nova Boundary
 
-Use contract-driven, check-backed development rather than mechanically porting
-main Yazelix. Review the current Yazelix sources of truth and decide explicitly
-what survives.
+Do not mechanically port main Yazelix. Review the current Yazelix sources of
+truth and decide explicitly what survives.
 
 Current runtime chain:
 
@@ -378,10 +377,8 @@ yzx -> Mars -> Yazelix Zellij fork
 ```
 
 The project interface is a Nix/Lix-compatible flake. `yzx` is the installed
-command name. Avoid local compatibility shims and generated fixtures unless a
-chosen contract requires them. Do not broaden Home Manager, layouts, config
-generation, plugins, pane policy, or legacy compatibility unless the user
-chooses that scope.
+command name. Do not broaden Home Manager, layouts, config generation, plugins,
+pane policy, or legacy compatibility unless the user chooses that scope.
 
 ### Git Channels
 
@@ -402,8 +399,6 @@ accepted and verified for `main`, advance `main` to that exact revision with:
 git push origin <sha>:main
 ```
 
-Never promote `stable` directly from `edge`.
-
 `stable` is the promotion-only user channel. Advance it only when the user
 explicitly requests promotion. A candidate must be a fast-forward from the
 current `stable`, belong to `main`, pass the protected Linux and cache checks,
@@ -415,25 +410,12 @@ known P0 or P1 regression. Promote the exact verified revision with:
 git push origin <sha>:stable
 ```
 
-Never force-push or delete `stable`.
-
-Rollbacks use a new revert commit on `edge`, followed by normal verification and
-fast-forward promotion through `main` and then `stable`.
-
-### Runtime Delivery
-
-After changing the flake runtime, keep the user's installed runtime current:
-
-```sh
-nix profile upgrade --refresh yazelix
-```
-
-Do not launch GUI sessions unless the user asks or reports manual dogfooding.
+Never delete `stable`.
 
 ### Beads
 
-Use `br` for all issue work and never edit `.beads/` files directly. Serialize
-`br` writes and finish with `br sync --flush-only`.
+Use `br` for all issue work. Serialize writes and finish with
+`br sync --flush-only`.
 
 Use `bv --robot-triage` as the graph-aware planning entry point. Use only
 `bv --robot-*` commands; bare `bv` opens an interactive TUI. `bv` decides what
@@ -446,19 +428,25 @@ Update the README LOC scorecard whenever project files change. Update
 `CHANGELOG.md` when user-visible runtime behavior, commands, keymaps, packaged
 tools, or runtime contracts change.
 
-Prefer deleting scope, avoiding abstractions, and reusing existing package
-outputs over adding local wrappers. If LOC grows, make the added behavior
-visible in the scorecard and justify it. Formatting rules outrank LOC pressure;
-for Rust, keep `rustfmt` output rather than compressing code manually.
+If LOC grows, make the added behavior visible in the scorecard and justify it.
+Formatting rules outrank LOC pressure; for Rust, keep `rustfmt` output rather
+than compressing code manually.
 
 ### Nova Verification
 
-Run the cheapest exact checks for the changed surface. For runtime flake
-changes, normally verify:
+For runtime flake changes, normally verify:
 
 ```sh
 nix flake check
 nix flake show --all-systems
 nix build .#yazelix --no-link --print-build-logs
 nix profile add --refresh /home/lucca/pjs/yazelix-dir/yazelix --profile <tmp>
 ```
+
+After changing the flake runtime, keep the user's installed runtime current:
+
+```sh
+nix profile upgrade --refresh yazelix
+```
+
+Do not launch GUI sessions unless the user asks or reports manual dogfooding.

AGENTS.md

@@ -359,6 +359,6 @@ See [Development](docs/development.md) for CI and local checks,
 
 ## LOC Scorecard
 
-Yazelix owns **26,364 lines** of tracked text project files. The
+Yazelix owns **26,340 lines** of tracked text project files. The
 [reproducible scorecard](docs/development.md#loc-scorecard) excludes Beads,
 lockfiles, and binary assets.

README.md

@@ -17,7 +17,7 @@ contain no Linux desktop entry. The flake advertises the optional Yazelix
 Cachix cache, while source builds remain valid without it. Use Version Gate
 before publishing a release
 
-## Main, stable, and edge
+## Edge, main, and stable
 
 All development commits land on `edge`, including fixes, reverts,
 documentation, and Beads updates. CI runs there, and users who select `edge`
@@ -109,7 +109,7 @@ git ls-files | grep -Ev '^\.beads/|\.lock$|^assets/' | xargs wc -l
 | --- | ---: |
 | Ignore (`.gitignore`) | 19 |
 | License | 201 |
-| Markdown | 3339 |
+| Markdown | 3315 |
 | JSON | 106 |
 | Nix | 1606 |
 | Shell | 84 |
@@ -120,4 +120,4 @@ git ls-files | grep -Ev '^\.beads/|\.lock$|^assets/' | xargs wc -l
 | Lua | 245 |
 | Rust | 19540 |
 | Text | 41 |
-| Total | 26364 |
+| Total | 26340 |