enola-guides 0.2.1 → 0.3.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8b0ff999485e94088e964c4dd465bb5c1a26fea1a6dece3ed79b301e644786a8
-  data.tar.gz: 2c015c5cb721592b33c66e274108ead2f537a50e706d0a18d7a97880e9f78664
+  metadata.gz: f8f7f20100ffdeea1ae928ad9e76186848aeba81caed9491993e09cfc5bc7461
+  data.tar.gz: dcbacd0bba3cf8ee9883b1590a8cd969d1c01150d4549789c1869920dad8de9e
 SHA512:
-  metadata.gz: 581a958308b2e03bd6014a30f73007e7b9e6f70cfc5d97dad82d5e733f520c87b557983d3da041ee4234c7d392d510c67ddcf31a145d166909ad791e95ca187c
-  data.tar.gz: b2b684408b5ec182a1edb87f36483f5159af9520e60c144062b1d9e28f550c4a4176f2c3b256e73a8681b1c776a89aab5999b9816c310692331685e44b14e604
+  metadata.gz: f3de1b04dfb1ec8c76f2686d4730052a0f38175721ea288294a09e1f4c2be4fa154d9622748405204b086857bdc5de3969675b49f729b0a5f229f5b8dc5ebebb
+  data.tar.gz: 49e2f753fa478c657683dbe69b729774dc94129a8ba8bf3c6614469b7576e0752857daa266f993006098e8a3e36eeeada89377412548d122c83f9d4fa41d1a01

data/CHANGELOG.md

@@ -1,5 +1,19 @@
 # Changelog
 
+## 0.3.1 (2026-08-23)
+
+The recipes README says where the catalogue ships: built into munola,
+written by `munola init`; the upstream channels carry upstream's built-ins
+only.
+
+## 0.3.0 (2026-08-23)
+
+The recipe catalogue munola binds: `data-ownership`, `api-boundaries`,
+`background-work` and the `tenant-foreign-key` template beside
+`ember-conventions`, each law an existing enola form with the number it held
+at on a real monolith in the catalogue table; every file lints clean bound
+to a Rails tree.
+
 ## 0.2.1 (2026-08-23)
 
 enola v0.4.4 released the constraints program the guides describe

data/README.md

@@ -74,7 +74,7 @@ your agent's skills folder; the hooks they pair with are under
 ## Templates and recipes
 
 [`templates/`](templates): the CI check script and its comment renderer,
-a cluster configuration, a constraints starter. [`recipes/`](recipes/README.md):
+a cluster configuration, a constraints starter. [`recipes/`](recipes/README.md) (the catalogue munola binds, each recipe with the number its laws held at):
 recipes a repository copies into its own `enola/recipes/` and binds in one
 line, starting with the Ember conventions and a house-recipe template;
 starting points the team reviews, never defaults the tool applies.

data/lib/enola-guides.rb

@@ -2,6 +2,6 @@
 
 module Enola
   module Guides
-    VERSION = "0.2.1"
+    VERSION = "0.3.1"
   end
 end

data/recipes/README.md

@@ -40,6 +40,33 @@ breach. Start with ratchet.
 
 ## The recipes
 
+The catalogue munola ships built in: `munola init` writes these recipes
+into a project's `enola/recipes/` and binds those whose roles resolve,
+and the munola binary embeds the parameter-free ones, generated from
+these files at release. The `enola` and `enola-rb` gems carry upstream's
+own built-ins only (`rails-conventions`, `rails-strict`, `vanilla-rails`
+and the six arrangements); a team on those channels copies a file from
+here by hand. Each law is
+an existing enola form; each recipe is here because its laws held on a real
+Rails monolith at a number a team can act on, given beside it.
+
+| Recipe | States | Held at |
+|---|---|---|
+| `rails-conventions` (upstream) | jobs, models, serializers and components never render; policies and mailers never enqueue; request API stays in controllers | five of seven laws with zero exceptions, three advisory at 134 crossings |
+| `rails-strict` (upstream) | the above plus no cycles among the Rails roles and independent concerns | 0 of 127 concerns breach |
+| `vanilla-rails` (upstream) | the directories the vanilla arrangement leaves empty stay empty | an arrangement a team chooses |
+| `ember-conventions.yaml` | nine Ember conventions selected by what the code carries | the neutral eight hold; the house ones stay out |
+| `data-ownership.yaml` | readers read the store only | advisory; bind your query objects |
+| `api-boundaries.yaml` | the public API is reached only by controllers; a mutating action reaches a policy | 736 unauthorized mutations reported, advisory |
+| `background-work.yaml` | maintenance tasks live in their namespace and never reach controllers | 0 of 3,250 task call edges reach a controller |
+| `tenant-foreign-key.yaml` | a table carrying the tenant column carries the foreign key | 3,720 declared, 0 new |
+
+Two data-ownership laws, one owner per table and storage stays home, are
+declarations rather than recipe rules for now: they live as worked examples
+under [`examples/laws/`](../examples/laws/README.md) because recipe expansion
+in the current release does not rebind the part a graph law names. They join
+`data-ownership.yaml` when it does.
+
 - `ember-conventions.yaml`: nine Ember conventions a team can adopt as laws,
   selected by what the code carries (a decorator, a written field, a base
   class's module) rather than by where it sits. Two optional roles are
@@ -47,6 +74,17 @@ breach. Start with ratchet.
   tracked functions in your app) and `fixture-setup` (the entry points of
   your fixture library in tests).
 
+- `data-ownership.yaml`: readers (your query objects, bound by you) reach
+  the store and nothing else.
+- `api-boundaries.yaml`: the API layer is entered through controllers, and a
+  mutating action reaches a policy; bind `mutating-actions` to the part your
+  routes reach with POST, PUT, PATCH or DELETE.
+- `background-work.yaml`: maintenance tasks live in the `Maintenance`
+  namespace the runner resolves, and never reach controllers.
+- `tenant-foreign-key.yaml`: a template; replace `TENANT_COLUMN` and
+  `TENANT_TABLE` (munola's generator does) and every table carrying the
+  column must carry the key.
+
 Laws whose far end is a helper of your own (a promise-unwrapping getter
 helper, an async-relationship reader) belong in your repository's recipe
 beside these, with your names in them.

data/recipes/api-boundaries.yaml

@@ -0,0 +1,25 @@
+recipe: api-boundaries
+roles:
+  - name: controllers
+    match: ["app/controllers/**"]
+  - name: policies
+    match: ["app/policies/**"]
+  - name: public-api
+    match: ["app/controllers/api/**"]
+  - name: mutating-actions
+    optional: true
+rules:
+  - id: public-api-reached-only-by-controllers
+    protect: public-api
+    owners: [controllers]
+    via: calls
+    mode: advisory
+    because: "The API layer is entered through a request so that authentication, rate limits and serialization run once, at the edge; an internal caller that reaches an API class directly skips all three and nobody reading the API can see it."
+
+  - id: mutations-are-authorized
+    require_edge: mutating-actions
+    to: policies
+    direction: outbound
+    via: calls
+    mode: advisory
+    because: "Every write passes a policy before it touches a record. Bind the actions that routes reach with POST, PUT, PATCH or DELETE (a part declared with handles: on those methods) and the law names each mutating action that reaches no policy."

data/recipes/background-work.yaml

@@ -0,0 +1,21 @@
+recipe: background-work
+roles:
+  - name: tasks
+    match: ["app/tasks/**"]
+  - name: task-classes
+    match: ["app/tasks/**"]
+    kind: symbol
+    where: { symbol_kind: "class" }
+  - name: controllers
+    match: ["app/controllers/**"]
+rules:
+  - id: maintenance-tasks-live-in-their-namespace
+    require_name: task-classes
+    pattern: "Maintenance::*"
+    because: "The task runner resolves task constants from that namespace, which is the one its generator creates, so a task declared outside it never appears in the runner and cannot be run by anyone."
+
+  - id: maintenance-tasks-never-reach-controllers
+    forbid: tasks
+    to: controllers
+    via: calls
+    because: "A task runs from the runner or the console with no request around it, so controller code reached from one has nothing to read."

data/recipes/data-ownership.yaml

@@ -0,0 +1,13 @@
+recipe: data-ownership
+roles:
+  - name: store
+    match: ["app/models/**"]
+  - name: readers
+    optional: true
+rules:
+  - id: readers-read-the-store-only
+    allow: readers
+    only: [store]
+    via: calls
+    mode: advisory
+    because: "A reader derives its answer from the store alone, which is what keeps it replayable against a snapshot; a reader that reaches a service or a client answers differently on a different machine. Bind your query objects or report classes as the readers."

data/recipes/tenant-foreign-key.yaml

@@ -0,0 +1,12 @@
+recipe: tenant-foreign-key
+roles:
+  - name: tables
+    match: ["db/schema.rb", "db/structure.sql", "app/models/**"]
+    kind: storage
+rules:
+  - id: tenant-foreign-key
+    require: tables
+    when_prop_contains: { prop: columns, value: TENANT_COLUMN }
+    must_prop_contain: { prop: fk_constraints, value: "TENANT_COLUMN->TENANT_TABLE" }
+    mode: advisory
+    because: "A table carrying the tenant column references the tenant, so the database should say so with a foreign key; a row that outlives its tenant is the leak nobody notices until an export. Advisory while a backfill path that ships the column before the constraint is reconciled with the rule; the verdict names every table that carries the column without the key."

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: enola-guides
 version: !ruby/object:Gem::Version
-  version: 0.2.1
+  version: 0.3.1
 platform: ruby
 authors:
 - Muhamed Isabegovic
@@ -115,8 +115,12 @@ files:
 - guides/12-the-wrapper.md
 - lib/enola-guides.rb
 - recipes/README.md
+- recipes/api-boundaries.yaml
+- recipes/background-work.yaml
+- recipes/data-ownership.yaml
 - recipes/ember-conventions.yaml
 - recipes/house-recipe-template.yaml
+- recipes/tenant-foreign-key.yaml
 - templates/constraints-starter/background-jobs-never-invoke-controller-code.rb
 - templates/constraints-starter/models-do-not-reach-controllers.rb
 - templates/constraints-starter/policies-only-answer.rb