Block 9 endet wie Block 6 mit Kapitel 54, Block 7 mit Kapitel 61 und Block 8 mit Kapitel 70: eine gesammelte Rückschau - diesmal auf den kompletten Weg von der Entscheidungsfrage in Kapitel 71 bis zur einlösbaren, rabattfähigen Bestellung in Kapitel 77.

Alle Dateien dieses Blocks im Überblick

app/code/Mironsoft/Loyalty/
├── Model/
│   └── Product/
│       └── Type/
│           ├── PointsPackage.php                                (Kapitel 73)
│           └── PointsPackage/
│               └── Price.php                                    (Kapitel 73)
├── Observer/
│   └── CreditPurchasedPointsPackageOnOrderPlaced.php             (Kapitel 76)
├── Setup/
│   └── Patch/
│       └── Data/
│           ├── InstallPointsPackageAttributeSet.php              (Kapitel 74)
│           ├── InstallPointsPackageAmountAttribute.php           (Kapitel 74)
│           └── InstallSalesLoyaltyPointsPackageCreditedAttribute.php  (Kapitel 76)
├── etc/
│   ├── product_types.xml                                        (Kapitel 72)
│   └── events.xml                                               (Kapitel 76, erweitert)
└── view/
    ├── adminhtml/
    │   └── ui_component/
    │       └── product_form.xml                                 (Kapitel 74, optional)
    └── frontend/
        ├── layout/
        │   └── catalog_product_view_type_loyalty_points_package.xml  (Kapitel 75)
        └── templates/
            └── product/
                └── view/
                    └── type/
                        └── points-package.phtml                 (Kapitel 75)

Checkliste: eigene Produkttypen einführen

1. Entscheidung begründen (Kapitel 71): Reicht ein Attribut auf einem bestehenden Typ, oder braucht das Konzept eine eigene apply_to-Abgrenzung?
2. Registrieren (Kapitel 72): etc/product_types.xml mit modelInstance, priceModel, indexPriceModel - Cache leeren, in Production setup:di:compile.
3. Type- und Price-Model implementieren (Kapitel 73): passende Elternklasse wählen (hier Virtual), nur das wirklich Abweichende überschreiben.
4. Admin-Formular vorbereiten (Kapitel 74): eigenes Attribut-Set, Pflichtfelder mit apply_to-Scoping, Attribut-Set UND Typ zusammen kommunizieren.
5. Frontend anzeigen und verkaufen (Kapitel 75): automatischen Layout-Handle nutzen, generische additional_options statt neuer Cart-/Order-Templates.
6. Bestellabwicklung verzahnen (Kapitel 76): Observer statt Plugin, eigenes Idempotenz-Attribut, bestehende Repository-Schnittstellen aus Block 1 wiederverwenden statt neu zu erfinden.
7. Kompatibilität testen (Kapitel 77): vollständiger Reindex nach Einführung, Preisregeln und Drittanbieter-Kampagnen gezielt end-to-end durchklicken statt anzunehmen, dass sie funktionieren.

Block 10 wendet sich als Nächstes APIs zu: REST- und GraphQL-Endpunkte, die denselben Punktestand und dieselben Repositories - inklusive der in diesem Block neu verzahnten Punkte-Paket-Logik - für externe Clients zugänglich machen.