Address Jesper Schulz-Wedde's review on PR #157

- release-must-update-app-version.md: reframe around AppSource's actual
  strict full-version-ordering requirement; scope branching-policy
  claims as team convention, not platform rule.
- pictures-must-use-media-not-blob.md: MediaSet is a collection of
  independent media objects, not automatic image variants/thumbnails.
- log-writes-must-survive-rollback.{md,good.al}: StartSession's only
  data channel into the new session is its Record parameter to a
  TableNo-scoped codeunit; a setter called on a local instance before
  starting the session populates nothing in the new session.
- exposed-objects-must-be-in-a-permission-set.md: correct the three
  exposure mechanisms (Web Services config, PageType/QueryType=API,
  ServiceEnabled as a method-only attribute).
- pages-must-not-contain-business-logic.md: scope to persisted
  mutations and cross-entry-point rules; presentation-only
  calculations and table-owned invariants are not violations.
- given-blocks-must-cover-full-precondition-chain.good.al: replace
  invented LibrarySales calls with the real API
  (CreateCustomer/CreateSalesOrderForCustomerNo/PostSalesDocument).
- test-feature-scenario-tags.{md,good.al}: move [SCENARIO] inside the
  test procedure body to match the current BCApps corpus; keep
  [FEATURE] at codeunit level per Microsoft's own documented option.
- ui-test-codeunit-naming.md: scope the _UT suffix and adjacent-ID
  pairing as an explicit team convention, not a BCApps-wide standard.
- page-design-must-match-bc-page-type-conventions.md /
  table-design-must-match-bc-table-type-conventions.md: Card's
  single-key primary-key claim is a contextual heuristic, not a
  mandatory constraint (Ship-to Address, Customer/Vendor Bank Account
  are real composite-key Card pages); a Subsidiary table with its own
  identity commonly gets List+Card, not Worksheet/Tabular.
- api-page-least-privilege-write-access.{md,good.al}: only page-placed
  fields are ever exposed; set InsertAllowed/DeleteAllowed=false in the
  good sample so a narrow field set can't still create/delete records.
- source-organized-by-feature-not-object-type.md,
  test-one-when-per-test.md: scope as team/testing-design conventions,
  not Microsoft platform requirements.
- upgrade-tag-logic-must-not-nest-deeply.md: add the Microsoft Learn
  citation that already backs the two-level nesting limit.
- Wire the new articles into the testing/data-modeling/error-handling/
  security/ui review skills' candidate-selection signals.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

microsoft/knowledge/data-modeling/pictures-must-use-media-not-blob.md

@@ -14,13 +14,15 @@ application-area: [all]
 `BLOB` is still a valid AL field type for arbitrary binary data, but it is
 not the right choice for storing pictures or images. The current
 recommendation is the `Media` field type for a single image, or
-`MediaSet` when a record needs several image variants (e.g. multiple
-sizes). Media/MediaSet integrate with the platform's picture control, the
-media repository, image caching, and thumbnail generation — none of which
-a plain `BLOB` field gets. A `BLOB` field storing a picture works, but it
-is the legacy approach: no caching, no thumbnail support, and no
-integration with the standard picture controls used across Business
-Central pages.
+`MediaSet` when a record needs several independent images (e.g. multiple
+product photos) — `MediaSet` is a collection of separately-imported media
+objects, each with its own identity; it does not generate resized variants
+or thumbnails on its own, and displaying more than one item still requires
+custom page handling. Media/MediaSet integrate with the platform's
+picture control and media repository, which a plain `BLOB` field does not
+— but any derived preview or thumbnail image still has to be generated
+explicitly and stored in its own field, regardless of which type holds the
+source image.
 
 `BLOB` remains the correct choice for genuinely arbitrary binary payloads
 that are not images and don't benefit from the media pipeline (e.g. a raw
@@ -36,9 +38,12 @@ See sample: `pictures-must-use-media-not-blob.good.al`.
 ## Anti Pattern
 
 A `BLOB` field named "Picture" compiles and stores the image bytes, but
-it misses the picture control integration, caching, and thumbnail
-generation that a `Media`/`MediaSet` field provides for free — the anti
-pattern is choosing `BLOB` for image storage out of habit rather than
-recognizing that the field is holding a picture, not generic binary data.
+it misses the picture control integration and media repository that a
+`Media`/`MediaSet` field provides for free — the anti pattern is choosing
+`BLOB` for image storage out of habit rather than recognizing that the
+field is holding a picture, not generic binary data. A related anti
+pattern: assuming `MediaSet` gives automatic image variants or thumbnails
+because it sounds like a collection with derived versions — it is only a
+collection of independently-imported media objects.
 
 See sample: `pictures-must-use-media-not-blob.bad.al`.

microsoft/knowledge/data-modeling/table-design-must-match-bc-table-type-conventions.md

@@ -33,7 +33,12 @@ Match the table's design to its type:
    `LookupPageID`.
 3. **Subsidiary** (Item Vendor) — subsidiary to a Master/Supplemental
    table; primary key is the parent key field(s), optionally + `Line No.`;
-   Worksheet or Tabular page, always filtered by the calling page.
+   page shape depends on whether the table carries its own identity: a
+   pure parent-join table (Item Vendor) typically gets a plain List page
+   filtered by the calling page, while a subsidiary table that supplements
+   a master record with its own identity — parent key + own code, e.g.
+   Ship-to Address, Customer/Vendor Bank Account — commonly gets a
+   List+Card pair instead, for direct editing of that record.
 4. **Ledger** (Cust. Ledger Entry) — transactional record of a functional
    area; primary key `Integer` `Entry No.`, always auto-generated by
    posting, never user-editable, no free add/delete; List page as