Energy Label Generator (EU)

Paid pluginsize Midea, not a commitment

Indicative price, not an offer: €24/mo; per-country obligation: EU energy-label data + PDF generation

Generated from docs/plan/paid/energy-label-generator/PLAN.md in the project's planning notes, which are not part of the public repository. Nothing described below is implemented — it is the written plan for it.

An idea, not a commitment. It has a written plan but no place in the build order and no date. What is committed.

Build note (2026-10-13, branch feat/energy-label in astrobaas-commercial, not merged): built as @astrobaas/energy-label — the DEALER’s side of Regulation (EU) 2017/1369 (a Regulation, not a Directive). Built: per-product energy fields (group, class, model, kWh, EPREL number/link, supplier label and product-information-sheet links); class validated against the group’s scale (A–G or A+++–D); the nested-display arrow as SVG; missing-label warnings on an admin catalogue check; an optional checkout block (env ENERGY_LABEL_BLOCK_CHECKOUT, off by default). Declined: label PDF generation and “compliant label” claims — the supplier makes the label per product group’s delegated regulation and registers it in EPREL. Routes are /api/plugin/energy-label/…, not /api/products/:id/…. Full list of departures: packages/energy-label/README.md, “Where this departs from the plan”.

An EU energy label system that generates compliant energy labels for electronics and appliances, validating product data against EU Directive 2017/1369.

The problem

EU: electronics and appliances need energy labels; non-compliance results in fines.

What it does

• Attach energy label metadata to product (EU energy class A-G, kWh per year, etc.)
• Generate energy label PDF per EU Directive 2017/1369
• Display label image on product page and in order
• Validation: reject products without energy label in EU region
• Multi-country support (EU only initially)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Energy data import — merchant manually enters; we don’t scrape manufacturer sites. Reason: data accuracy liability.
• Label translation — labels are in English; merchant translates if needed. Reason: language customization is merchant’s responsibility.

Data model

New tables: EnergyLabel {id, productId, energyClass (‘A’|‘B’|…|‘G’), kwhPerYear, fuelType, model, imageUrl, createdAt}. No migration.

API

• POST /api/products/:id/energy-label
• GET /api/products/:id/energy-label
• GET /api/products/:id/energy-label/pdf

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Product edit page: energy label section (class, kWh, model). Generate and preview label PDF. Bulk import from CSV.

The seam — why this is paid

Core owns: label storage, PDF generation interface. Paid owns: EU compliance validation, per-country rules, fines mitigation.

Per-country obligation: EU energy-label rules, we generate compliant labels

Dependencies

• Product database

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Product with energyClass=‘A’ generates valid EU energy label PDF
• Products sold in EU region without label trigger admin warning
• Label PDF is correct format and contains required fields per Directive 2017/1369

Risks

Non-compliance fines: if label is missing or incorrect, merchant faces EU fines; mitigation: admin warning + validation, but ultimate responsibility is merchant’s.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and CONTRIBUTING.md for how to work on this repository.