diff --git a/.planning/todos/pending/lagoon-readme-after-commit-callback-order.md b/.planning/todos/pending/lagoon-readme-after-commit-callback-order.md
new file mode 100644
index 0000000..d6b01c3
--- /dev/null
+++ b/.planning/todos/pending/lagoon-readme-after-commit-callback-order.md
@@ -0,0 +1,12 @@
+---
+title: lagoon README registers an after-commit GORM callback that can sort after the flush
+date: 2026-09-30
+priority: high
+area: summercms.go lagoon
+---
+
+The `lagoon.OnDatabase` example in `modules/lagoon/README.md` registers its create callback with `After("gorm:after_create")` and calls `lagoon.AfterCommit` from it. GORM sorts that callback after `lagoon:after_commit` (itself `After("gorm:commit_or_rollback_transaction")`), so the work is buffered after the buffer was flushed and never runs, with no error or log. A docs test reproduced it: the same callback registered with `After("gorm:create").Before("gorm:commit_or_rollback_transaction")` runs as expected.
+
+Found while writing `docs/database/transactions.md` (Phase 11.1 plan 04). The page registers the callback before GORM's commit callback and says why.
+
+Suggested fix: change the README example to register before `gorm:commit_or_rollback_transaction`, and consider making `lagoon.AfterCommit` warn when it buffers work on a statement whose `lagoon:after_commit` callback has already run. The README was read-only in plan 11.1-04 (Phase 11 gap plan 11-08 owned it). While there, correct the `lagoon.RegisterJoinTable` comment and README line that say pivot reads use `Preload(field)` plus `.Order(...)` on the pivot's columns: GORM preloads many-to-many targets in a query without the join table, so ordering by a pivot column there fails with "missing FROM-clause entry"; an explicit join does work.
diff --git a/.planning/todos/pending/lagoon-validate-min-message.md b/.planning/todos/pending/lagoon-validate-min-message.md
new file mode 100644
index 0000000..e9b3601
--- /dev/null
+++ b/.planning/todos/pending/lagoon-validate-min-message.md
@@ -0,0 +1,12 @@
+---
+title: lagoon.Validate reports every numeric range failure with the max message
+date: 2026-09-30
+priority: medium
+area: summercms.go lagoon
+---
+
+When a field has `integer` or `numeric` and a `min`, `max` or `between` rule, `lagoon.Validate` checks the range once and always answers a failure with the `max` message. With only `min:0` and a value of `-1`, the message is `The views may not be greater than .`: the wrong rule and an empty parameter. Laravel answers `The views must be at least 0.` for `min` and `The views must be between 0 and 10.` for a numeric `between`.
+
+Found while writing `docs/database/casts-and-validation.md` (Phase 11.1 plan 04). The page does not show a `min` failure; its example uses `max:1000`, whose message is correct.
+
+Suggested fix: in `modules/lagoon/validate.go`, pick the message by which bound failed (`min` below the lower bound, `max` above the upper, `between` when both bounds came from `between`), with a unit test per case. Check the PHP API responses first if a ported endpoint depends on the current text. The change is outside the docs phase boundary, so it is not made in Phase 11.1.