pi-aia-asf 0.13.2 → 0.13.3

package/CHANGELOG.md

@@ -7,6 +7,23 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.13.3] - 2026-10-16
+
+### Fixed
+
+- **06j §5 had drifted back into enumerating products.** The section now carries
+  the store-agnostic *rule* — the defect is not SQL-shaped, and the distinction
+  that makes a hand-written cascade decidable is the **reference** (a row removing
+  itself vs one entity deciding the fate of another) — instead of a table of
+  store families and a list of ORM dialects. Which dialects the scanner
+  recognises is an implementation detail in `lib/code-health/model.mjs`, reported
+  per finding so you can see what it looked at; the standard states categories and
+  leaves the rest to `model.extraCascadePatterns` /
+  `model.extraHandWrittenPatterns`. A recognised dialect is not a coverage
+  promise: an unknown persistence shape is a `scanned: 0` you say out loud, not a
+  clean bill of health. The fixtures keep naming the concrete dialects — that is
+  where a pattern set belongs.
+
 ## [0.13.2] - 2026-10-16
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-aia-asf",
-  "version": "0.13.2",
+  "version": "0.13.3",
   "description": "Ai Applied Agentic Software Factory — codifies the full software development flow: intake, research, spec capture, adversarial analysis, planning with approval gates, test-first implementation, and release. Requires pi-vigilant, pi-smart-web-search, pi-smart-fetch, and pi-aia-browser.",
   "keywords": [
     "pi-package",

package/skills/aia-asf/references/06j-data-model.md

@@ -179,36 +179,33 @@ requirement: "is this ownership correct?" is judgment and stays in review, while
 "does this file declare a cascade with no `asf-model:` tag?" is measurable.
 
 **It is a tripwire, not an authority — and it is store-agnostic by design.** The
-defect is not SQL-shaped: an instance inheriting its parent's lifecycle happens
+defect is not SQL-shaped. An instance inheriting its parent's lifecycle happens
 in a relational FK action, in an ORM mapping attribute, in a document store's
 delete dependency, in a key-value prefix wipe, or in a loop someone wrote to
 delete children by hand. Three rules run:
 `undeclared-cascade` (a cascade declaration with no ownership declaration),
 `delete-then-reinsert` (rebuild-by-delete over one table or collection), and
-`handwritten-cascade` — the store-agnostic half, for stores that have **no
-constraint to declare the cascade in the first place**:
-
-| Store family | What the cascade looks like when nobody wrote it down |
-|---|---|
-| **MongoDB / Mongoose** | `deleteMany({ userId })` over a child collection — no FK action exists, so this code *is* the cascade |
-| **Firestore** | a recursive `collectionGroup` / subcollection delete; missing a nested subcollection is the standard failure |
-| **DynamoDB** | `DeleteItem` / `BatchWriteItem` driven by a parent key across tables; GSI/LSI are wiped with the table, items are not |
-| **CouchDB** | documents selected and marked `_deleted: true` in one `bulkDocs` |
-| **Redis** | a key-pattern wipe — `keys('session:<id>:*')` then `del`/`unlink`; the prefix *is* the parent |
-| **Elasticsearch** | `deleteByQuery` on a parent field; no referential integrity exists to fall back on |
-
-ORM-level declarations are matched too — `CascadeType.REMOVE`/`ALL`,
-`orphanRemoval = true`, `DeleteBehavior.Cascade`, `onDelete: Cascade`
-(Prisma/Sequelize), `on_delete=models.CASCADE` (Django),
-`dependent: :destroy` / `:delete_all` (Rails), `cascade = "…delete…"`
-(SQLAlchemy) — so the gate is not SQL DDL only.
-
-A fire here asks for a **declaration**; it does not claim the ownership is
-wrong, which stays a judgement in review. A delete of a row by its own identity
-(`deleteOne({ _id: id })`) is not a cascade and does not fire — a rule that
-fires on ordinary deletes gets switched off, and the coverage goes with it.
-Projects add dialects with `model.extraCascadePatterns` and
-`model.extraHandWrittenPatterns` rather than waiting for a release.
+`handwritten-cascade` — the shape a cascade takes in a store that has **no
+constraint to declare it in**, where the decision exists only as code someone
+wrote: a multi-delete driven by a reference to *another* entity.
+
+The distinction that makes `handwritten-cascade` decidable rather than
+judgemental is the **reference**. `deleteOne({ _id: id })` is a row removing
+itself; `deleteMany({ userId })` is one entity deciding the fate of another. The
+first does not fire — a rule that fires on ordinary deletes gets switched off and
+the coverage goes with it, which is why the near-miss fixtures matter more than
+the fire fixtures. A fire asks for a **declaration**; it does not claim the
+ownership is wrong, and that judgement stays in review.
+
+**The pattern set is illustrative and the standard does not enumerate products.**
+The categories above are the standard; the dialects the scanner happens to
+recognise are an implementation detail in `lib/code-health/model.mjs`, reported
+per finding so you can see what it looked at. A project whose store is not in
+that set adds its own spelling with `model.extraCascadePatterns` /
+`model.extraHandWrittenPatterns` rather than waiting for a release — and a
+recognised dialect is not a coverage promise. If your persistence layer speaks a
+shape the scanner does not know, that is a `scanned: 0` you must say out loud,
+not a clean bill of health.
 
 **Where the store has no constraint to inspect, the scan has nothing to attach
 to and the invariant tests below are the only hard gate** — say which of the two