@opengroundplan/core 0.1.1

package/catalog/sources/cms-ecommerce.yaml

@@ -0,0 +1,558 @@
+# cms-ecommerce.yaml
+#
+# Research date: 2026-07-18
+# Adversarial re-verification: 2026-07-18 (second pass, independent).
+#
+# Verification method for the re-verification pass: the GitHub REST API was fully rate-limited
+# for this IP (core quota 0/60), so every license was re-read from the PRIMARY source — the raw
+# LICENSE file at raw.githubusercontent.com — and cross-checked against the license label GitHub
+# renders on each repo page. Stars and pushedAt were re-read from the ungh.cc mirror; all sixteen
+# repos returned figures identical to those already recorded. Archived status was read from the
+# archive banner on each repo page, validated against a known-archived control
+# (medusajs/nextjs-starter-medusa) and a known-live control (medusajs/medusa).
+#
+# TWO CRITICAL DEFECTS FOUND AND FIXED IN THE RE-VERIFICATION PASS:
+#   * saleor/storefront          — was recorded as BSD-3-Clause / vendorable. The LICENSE file is
+#                                  actually the Functional Source License 1.1 (FSL-1.1-ALv2),
+#                                  copyright 2026 Saleor Commerce, with a "Competing Use"
+#                                  restriction. Source-available, NOT BSD. GitHub renders no
+#                                  license label for it. The root repo saleor/saleor is still
+#                                  genuinely BSD-3-Clause — the org relicensed the storefront only,
+#                                  which is exactly the per-repo divergence that makes an org-level
+#                                  license assumption dangerous. ENTRY DROPPED.
+#   * medusajs/b2b-starter-medusa — MIT is correct, but the repo was ARCHIVED by its owner on
+#                                  2026-07-02 and is read-only; it was recorded `maintained: true`.
+#                                  Archived on the same day as nextjs-starter-medusa, which this
+#                                  file already drops for that reason. ENTRY DROPPED for consistency.
+#
+# Everything else in this file re-verified clean: 14 of 14 remaining licenses matched the recorded
+# spdx exactly, all stars matched to the unit, all pushedAt dates matched, no other repo is
+# archived, and every URL resolves. The concrete structural claims were spot-checked and hold:
+# payloadcms/payload really does contain templates/{blank,website,ecommerce,plugin,with-postgres,
+# with-vercel-postgres,with-vercel-mongodb,with-cloudflare-d1,with-vercel-website}, and
+# Shopify/hydrogen really does contain templates/skeleton/app/lib/context.ts.
+#
+# License classes were verified from PRIMARY sources: license.spdx_id from the GitHub API,
+# and/or the raw LICENSE file fetched from raw.githubusercontent.com. No license was guessed.
+#
+# THREE HEADLINE FINDINGS — projects the brief named as expected picks that do NOT pass the gate:
+#   * directus/directus  — relicensed to the "Monospace Sustainable Core License" (MSCL-1.0-GPL),
+#                          a source-available license with a "Competing Use" restriction and an
+#                          anti-license-key-circumvention clause. EXCLUDED. Not MIT/BSL as older
+#                          write-ups claim.
+#   * vendurehq/vendure  — dual GPLv3 / commercial. EXCLUDED for vendoring. Note the GitHub org
+#                          renamed from `vendure-ecommerce` to `vendurehq`; the old URL 301s.
+#   * strapi/strapi      — repo-level SPDX is NOASSERTION. LICENSE is conditional: MIT Expat only
+#                          for code outside `ee/` AND only if you hold no Strapi Cloud account.
+#                          A conditional MIT is not a clean MIT. REFERENCE-ONLY.
+
+category: cms-ecommerce
+
+sources:
+  # ---------------------------------------------------------------- vendorable: CMS
+  - name: payloadcms/payload
+    url: https://github.com/payloadcms/payload
+    stars: 43666
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    stack: TypeScript, Next.js 15, Drizzle/Mongoose, React admin
+    complexity: professional
+    whatToBorrow: >-
+      The `templates/` directory of the monorepo is the single most directly harvestable asset in
+      this whole category — verified to contain `blank`, `website`, `ecommerce`, `plugin`,
+      `with-postgres`, `with-vercel-postgres`, `with-vercel-mongodb`, `with-cloudflare-d1` and
+      `with-vercel-website`. Each is an installable Next.js app, so the db-adapter swap is already
+      expressed as separate template variants rather than conditional code. Borrow
+      `templates/website` for its collection config (Pages/Posts/Media/Categories), its draft
+      preview + live-preview wiring, and its block-based layout builder; borrow
+      `templates/ecommerce` for cart/checkout collections and the Stripe hooks. `payload.config.ts`
+      is the cleanest example in the category of schema-as-config that generates both an admin UI
+      and a typed local API. Also adapt the generated `payload-types.ts` codegen step.
+    whatToAvoid: >-
+      Payload installs *into* a Next.js app and owns the `/admin` route group and a catch-all API
+      route — it is not a detachable layer, so a Groundplan template must commit to Next.js App Router
+      up front. Version churn is real: 2.x → 3.x was a rewrite onto App Router and migration guides
+      age fast, so pin the major. The Vercel-flavoured templates bake in platform-specific blob
+      storage and Postgres adapters; strip those for a portable base. Cloud/Enterprise features are
+      gated behind a paid plan even though the repo is MIT.
+    proposedLayerIds:
+      - cms-payload
+      - cms-payload-website-template
+      - cms-payload-ecommerce-template
+      - db-postgres-drizzle
+      - db-mongodb-mongoose
+      - media-uploads-s3
+      - admin-payload
+      - preview-draft-mode
+
+  - name: sanity-io/sanity
+    url: https://github.com/sanity-io/sanity
+    stars: 6218
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    stack: TypeScript, React, Sanity Studio v4
+    complexity: professional
+    whatToBorrow: >-
+      Schema-definition ergonomics: `defineType`/`defineField`/`defineArrayMember` give fully typed
+      content models with autocomplete, and are worth copying as a pattern even for a non-Sanity
+      CMS layer. The Studio's `sanity.config.ts` plugin composition model (plugins as objects that
+      contribute schema + structure + tools) is a good template for a pluggable admin. Also borrow
+      Portable Text: the JSON rich-text spec and its React renderer are a far better answer to
+      "rich text in a database" than storing HTML, and the serializer pattern is portable.
+      GROQ query colocation and the `@sanity/client` typed fetch helpers adapt cleanly.
+    whatToAvoid: >-
+      The MIT license covers the Studio (the editing client) — the content lake it talks to is a
+      proprietary hosted API with usage-based pricing. This is the sharpest vendor-lock-in trap in
+      the category: you can vendor the UI but you cannot self-host the backend. Do not sell a
+      Groundplan layer as "open source CMS" on this basis. The repo is a large multi-package monorepo;
+      harvest specific packages, never the tree. Studio v2 → v3 → v4 broke config shape twice.
+    proposedLayerIds:
+      - cms-sanity
+      - cms-sanity-studio-embedded
+      - content-portable-text
+      - content-schema-typed
+      - preview-live-visual-editing
+
+  - name: Thinkmill/keystatic
+    url: https://github.com/Thinkmill/keystatic
+    stars: 2221
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    stack: TypeScript, React, Markdoc/MDX, Git-backed storage
+    complexity: simple
+    whatToBorrow: >-
+      The best `simple` tier entry in this category. `keystatic.config.ts` defines collections and
+      singletons in ~40 lines and the entire content store is Markdown/JSON files in the repo —
+      no database, no migrations, no running service. Borrow the config shape verbatim for a
+      "CMS without infrastructure" layer. The dual storage mode (`kind: 'local'` for filesystem,
+      `kind: 'github'` for a GitHub App that commits edits as PRs) is a genuinely clever pattern
+      worth adapting: content review becomes code review. The Astro, Next.js and Remix adapters
+      show how to mount an admin UI at one route with minimal framework coupling.
+    whatToAvoid: >-
+      Git-backed storage does not scale to high edit volume or many concurrent editors — every save
+      is a commit, and merge conflicts surface to non-technical users. No querying beyond reading
+      files, so it is wrong for anything relational or search-heavy. Smallest community of the
+      vendorable CMSes here, and it shares maintainer bandwidth with Keystone at Thinkmill, so
+      treat bus factor as a real risk for a professional-tier template.
+    proposedLayerIds:
+      - cms-keystatic
+      - content-git-backed
+      - content-markdoc
+      - content-mdx
+      - admin-keystatic-embedded
+
+  - name: keystonejs/keystone
+    url: https://github.com/keystonejs/keystone
+    stars: 9920
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    stack: TypeScript, Node, Prisma, GraphQL, React admin
+    complexity: standard
+    whatToBorrow: >-
+      The `list()`/`field` schema DSL that emits a full CRUD GraphQL API plus an admin UI from one
+      declaration — the tightest schema-to-API mapping among the MIT-licensed options. Borrow the
+      access-control model specifically: `access: { operation, filter, item }` separates
+      "can you call this at all" from "which rows" from "this particular row", which is a cleaner
+      authorization decomposition than most starters ship and is worth lifting even into non-
+      Keystone layers. Its Prisma integration and generated migration workflow are a solid
+      reference for a db-postgres-prisma layer. Session/auth via `@keystone-6/auth` is compact.
+    whatToAvoid: >-
+      Verify current momentum before making this a flagship template — Keystone 5 is explicitly in
+      maintenance mode at `keystonejs/keystone-5` (stated in the README), and Keystone 6 is the
+      live line but ships slowly compared with Payload, which has taken most of the mindshare in
+      this niche. Keystone owns the Prisma schema it generates, so hand-editing Prisma models
+      fights the tool. The admin UI is functional but visually dated and hard to theme deeply.
+    proposedLayerIds:
+      - cms-keystone
+      - db-postgres-prisma
+      - api-graphql-server
+      - authz-field-level-access
+      - auth-session-keystone
+
+  - name: TryGhost/Ghost
+    url: https://github.com/TryGhost/Ghost
+    stars: 54465
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    stack: Node, Express, Knex, MySQL/SQLite, Ember admin, Handlebars themes
+    complexity: professional
+    whatToBorrow: >-
+      Ghost is the most battle-tested MIT publishing platform here and its value for Groundplan is the
+      *subsystems*, not the monolith. Borrow the members/subscriptions implementation — magic-link
+      email auth with no passwords, tiers, and Stripe Connect billing — which is a complete
+      paid-newsletter vertical that few starters have. Borrow the Content API vs Admin API split
+      (read-only key-scoped public API separate from an authenticated JWT admin API), a pattern
+      worth copying into any headless layer. Its Knex migration directory is a good model of
+      long-lived, strictly ordered, reversible migrations.
+    whatToAvoid: >-
+      It is a large mature product, not a scaffold — do not attempt to vendor the tree. MySQL is
+      the only supported production database (SQLite is dev-only, Postgres unsupported), which is
+      a hard constraint against a Postgres-default Groundplan. The admin client is Ember, out of step
+      with everything else in this category. The Handlebars theme layer means the frontend is not
+      React/Vue, so pair it as headless-only. Trademark: "Ghost" branding is not covered by MIT.
+    proposedLayerIds:
+      - cms-ghost-headless
+      - content-api-readonly-keys
+      - members-subscriptions
+      - payments-stripe-subscriptions
+      - auth-magic-link-email
+      - db-mysql-knex
+
+  - name: nuxt/content
+    url: https://github.com/nuxt/content
+    stars: 3652
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    stack: TypeScript, Nuxt 3/4, Vue, SQLite/D1
+    complexity: simple
+    whatToBorrow: >-
+      The file-based-content answer for the Vue half of the ladder, and the natural counterpart to
+      Keystatic in a framework-diverse catalog. Borrow the `content.config.ts` collection schema
+      (Zod-validated frontmatter — invalid frontmatter fails the build rather than rendering
+      broken pages, which is the right default). The v3 architecture is worth adapting on its own
+      merits: Markdown is compiled at build time into a SQLite database that ships with the app,
+      so you get real queryable content with zero runtime service — and it degrades to Cloudflare
+      D1 for edge deploys. `<ContentRenderer>` plus MDC (Markdown with Vue components inline) is a
+      clean alternative to MDX.
+    whatToAvoid: >-
+      Hard-bound to Nuxt; there is nothing to salvage for a React template. The v2 → v3 rewrite
+      changed the storage engine and query API completely, so any code or tutorial predating it is
+      misleading — pin v3+ and ignore older examples. Build-time compilation means content changes
+      require a rebuild, so it is wrong for editor-driven sites that need instant publish.
+    proposedLayerIds:
+      - cms-nuxt-content
+      - content-file-based
+      - content-schema-zod
+      - db-sqlite-embedded
+      - deploy-cloudflare-d1
+
+  # ---------------------------------------------------------------- vendorable: commerce
+  - name: medusajs/medusa
+    url: https://github.com/medusajs/medusa
+    stars: 35221
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    stack: TypeScript, Node, Postgres, MikroORM, React admin
+    complexity: professional
+    whatToBorrow: >-
+      The strongest genuinely-MIT commerce backend available — no dual-license asterisk, which
+      after Vendure's GPL move and Directus's MSCL move makes it the default pick for a vendorable
+      commerce layer. Verified package layout is `packages/core`, `packages/modules`,
+      `packages/medusa`, `packages/admin`, `packages/cli`. Borrow the module architecture: cart,
+      pricing, inventory, fulfillment, payment and tax are independent packages behind defined
+      interfaces, so a Groundplan layer can ship "commerce minus fulfillment" honestly. Borrow the
+      Workflow SDK — long-running multi-step operations with explicit compensation/rollback steps —
+      which is the correct pattern for order placement and is rare in open starters.
+    whatToAvoid: >-
+      v1 → v2 was a near-total rewrite (module system, workflows, data layer all changed); anything
+      written before v2 is actively wrong, so pin and date your source. Postgres is effectively
+      mandatory. The admin is a separate build that must be served or deployed alongside the API,
+      which complicates single-container deploys. Note the official Next.js storefront starter
+      `medusajs/nextjs-starter-medusa` is now ARCHIVED (verified `archived: true` via the GitHub
+      API, last push 2026-04-23) — do not point a template at it.
+    proposedLayerIds:
+      - commerce-medusa
+      - db-postgres-mikroorm
+      - workflows-saga-compensation
+      - payments-stripe
+      - commerce-cart-checkout
+      - commerce-inventory-fulfillment
+      - admin-medusa
+
+  - name: saleor/saleor
+    url: https://github.com/saleor/saleor
+    stars: 23109
+    spdx: BSD-3-Clause
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    stack: Python, Django, GraphQL (Graphene), Postgres, Celery
+    complexity: enterprise
+    whatToBorrow: >-
+      The enterprise rung of the ladder and the only serious non-JavaScript option here, which is
+      worth keeping for stack diversity. BSD-3-Clause is cleanly vendorable provided you carry the
+      copyright notice. Borrow the GraphQL-first API design: a single strongly-typed schema with
+      cursor pagination, node IDs and a consistent mutation-error convention (errors returned in
+      the payload with field + code rather than thrown) — that error contract is worth copying into
+      any API layer. Also borrow multi-channel modelling (per-channel pricing, currency,
+      availability and warehouse assignment), permission groups, and the webhook/app extension
+      system with signed payloads.
+    whatToAvoid: >-
+      Genuinely heavy — Postgres plus Celery plus Redis before you serve a request; wrong for
+      anything below the enterprise tier. Python/Django is stack-isolated from the rest of this
+      category, so a Groundplan plan cannot share layers between it and the TS options. Some newer
+      capabilities land in Saleor Cloud ahead of the OSS core. BSD-3 attribution is a real
+      obligation, not a formality: the notice must travel with any copied file.
+    proposedLayerIds:
+      - commerce-saleor
+      - api-graphql-schema-first
+      - db-postgres-django
+      - queue-celery-redis
+      - commerce-multichannel
+      - authz-permission-groups
+      - webhooks-signed-events
+
+  - name: saleor/saleor-dashboard
+    url: https://github.com/saleor/saleor-dashboard
+    stars: 1014
+    spdx: BSD-3-Clause
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    stack: TypeScript, React, Apollo Client, Vite, MacawUI
+    complexity: enterprise
+    whatToBorrow: >-
+      A production admin console for a complex domain, useful as a reference for any
+      enterprise-tier admin layer regardless of backend. Borrow the saved-views/filter-preset
+      pattern (complex list filters serialised into the URL so views are shareable and
+      bookmarkable), the bulk-action and column-picker implementations on large datasets, and the
+      Apollo cache/optimistic-update conventions. Its i18n pipeline with extracted message
+      catalogues is a clean model for a localisation layer.
+    whatToAvoid: >-
+      Large, mature, and highly coupled to the Saleor GraphQL schema and the MacawUI design system
+      — extract patterns, never files wholesale. Apollo Client is a heavier and less fashionable
+      choice than TanStack Query for new work. Only worthwhile if the generated project actually
+      needs an admin of this weight; for most templates it is over-engineering.
+    proposedLayerIds:
+      - admin-dashboard-react
+      - state-apollo-client
+      - ui-data-table-advanced
+      - i18n-message-catalog
+      - build-vite
+
+  - name: Shopify/hydrogen
+    url: https://github.com/Shopify/hydrogen
+    stars: 2065
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    stack: TypeScript, React Router 7 (ex-Remix), Vite, Oxygen edge runtime
+    complexity: standard
+    whatToBorrow: >-
+      `templates/skeleton/` is a verified, deliberately minimal starter (confirmed present, along
+      with `templates/skeleton/app/lib/context.ts`) and is exactly the shape a scaffolding tool
+      wants — Shopify maintains it as the `npm create @shopify/hydrogen` output. Borrow the
+      request-context factory in `app/lib/context.ts`: it builds a per-request storefront client,
+      session and cart handler and passes them through loader context rather than reaching for
+      module-level singletons, which is the correct pattern for edge/worker runtimes where global
+      state leaks between requests. Also borrow the cart handler abstraction and the deferred-data
+      + `<Await>`/`<Suspense>` streaming pattern for above-the-fold performance.
+    whatToAvoid: >-
+      The clearest vendor lock-in here: MIT code, but it only talks to Shopify's Storefront API, and
+      the Oxygen deploy target is Shopify-hosted. You are adopting a commercial platform, and the
+      storefront cannot be repointed at another backend without a rewrite. The framework base has
+      moved Remix → React Router 7, so older Hydrogen examples no longer apply — pin recent. Star
+      count understates adoption (most users consume it via the CLI, not the repo).
+    proposedLayerIds:
+      - storefront-shopify-hydrogen
+      - framework-react-router-7
+      - runtime-edge-worker
+      - commerce-cart-shopify
+      - rendering-streaming-deferred
+      - deploy-shopify-oxygen
+
+  - name: vercel/commerce
+    url: https://github.com/vercel/commerce
+    stars: 14155
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-06-10"
+    stack: TypeScript, Next.js App Router, Tailwind, Shopify Storefront API
+    complexity: simple
+    whatToBorrow: >-
+      The cleanest small reference storefront in the category and the best `simple` commerce rung.
+      Everything backend-facing is confined to `lib/shopify/` (a typed fetch wrapper, GraphQL
+      fragments and normalising mappers), so the swap surface for a different commerce provider is
+      one directory — copy that boundary even if you drop the Shopify part. Borrow the cart as an
+      optimistic React context over server actions, the `generateMetadata` + OpenGraph conventions,
+      and the tidy `app/product/[handle]` and `app/search` route structure. Small enough to read
+      end to end in an afternoon, which is exactly what a strippable template needs.
+    whatToAvoid: >-
+      Note the repo changed character: it was once a multi-provider commerce framework and is now a
+      single Shopify-only demo, so older documentation describing pluggable providers is obsolete.
+      Development pace has slowed relative to the rest of this list (last push 2026-06-10 — still
+      well inside the freshness window, but the only entry here not touched within the week). It is
+      a showcase, not a product: no tests, no auth, no order history, and the Vercel-flavoured
+      caching assumptions need review for other hosts.
+    proposedLayerIds:
+      - storefront-nextjs-minimal
+      - commerce-provider-adapter
+      - commerce-cart-optimistic
+      - ui-tailwind
+      - seo-metadata-opengraph
+
+  # ---------------------------------------------------------------- gated: do not vendor
+  - name: strapi/strapi
+    url: https://github.com/strapi/strapi
+    stars: 72681
+    spdx: NOASSERTION
+    licenseClass: reference-only
+    maintained: true
+    lastCommit: "2026-07-17"
+    stack: TypeScript, Node, Koa, SQLite/Postgres/MySQL, React admin
+    complexity: professional
+    whatToBorrow: >-
+      READ ONLY — DO NOT COPY FILES. The most-starred CMS in the category and worth studying for
+      its content-type-builder model (schemas as JSON under `src/api/*/content-types/*/schema.json`,
+      editable at runtime through the admin), its draft/publish and i18n locale model, and its
+      plugin architecture with admin-panel injection zones. Its role/permission matrix mapping
+      roles to per-content-type CRUD is a good reference for an RBAC layer. Reimplement these ideas
+      from scratch; do not lift source.
+    whatToAvoid: >-
+      The license is the problem. GitHub reports `license.spdx_id: NOASSERTION`, and the LICENSE
+      file grants MIT Expat only (a) for code outside any `ee/` directory AND (b) if you have no
+      registered account on Strapi's cloud offering — everything under `ee/` is proprietary. A
+      grant conditioned on your commercial relationship with the vendor is not a clean MIT, and it
+      cannot be safely propagated into every repo a scaffolding tool generates. Classified
+      reference-only for that reason. Separately: v3 → v4 → v5 broke plugins each time, and
+      SQLite-to-Postgres migration is a known rough edge.
+    proposedLayerIds:
+      - cms-strapi-reference
+      - content-type-builder-runtime
+      - authz-rbac-matrix
+      - i18n-content-locales
+
+  - name: directus/directus
+    url: https://github.com/directus/directus
+    stars: 36598
+    spdx: NOASSERTION
+    licenseClass: excluded
+    maintained: true
+    lastCommit: "2026-07-18"
+    stack: TypeScript, Node, Vue 3 admin, SQL-database-agnostic
+    complexity: professional
+    whatToBorrow: >-
+      NOTHING MAY BE COPIED. Listed only so the next phase does not rediscover it and assume it is
+      permissive. Conceptually notable for wrapping an existing SQL database rather than owning the
+      schema (point it at a legacy database and get an API and admin immediately) — that
+      database-first inversion is a legitimate idea to implement independently, from documentation
+      only, with no reference to this source tree.
+    whatToAvoid: >-
+      EXCLUDED ON LICENSE. The LICENSE file at the repo root is the "Monospace Sustainable Core
+      License, Version 1.0" (self-abbreviated MSCL-1.0-GPL), fetched and read directly. It grants
+      use only for a "Permitted Purpose", explicitly excluding any "Competing Use", and forbids
+      moving, disabling or circumventing the software's license-key functionality. That is a
+      source-available license, not open source, and it fails the vendorable gate outright. Any
+      catalog entry, blog post or model memory describing Directus as MIT or GPL is out of date.
+    proposedLayerIds: []
+
+  - name: vendurehq/vendure
+    url: https://github.com/vendurehq/vendure
+    stars: 8255
+    spdx: GPL-3.0-or-later
+    licenseClass: excluded
+    maintained: true
+    lastCommit: "2026-07-17"
+    stack: TypeScript, NestJS, TypeORM, GraphQL, Postgres/MySQL
+    complexity: professional
+    whatToBorrow: >-
+      NOTHING MAY BE COPIED into generated repos. Recorded because the brief named it and because
+      the licensing situation is easy to get wrong. Its NestJS + TypeORM + GraphQL layering and its
+      channel/tax-zone modelling are architecturally strong and may be studied, but a GPLv3
+      obligation cannot be attached to arbitrary generated projects.
+    whatToAvoid: >-
+      EXCLUDED ON LICENSE. `LICENSE.md` on the `master` branch states dual licensing: GPLv3 as the
+      Community Edition by default, or a paid Vendure Commercial License. GPLv3 is copyleft and
+      fails the gate. There is a section-7 additional permission allowing *plugins* to be
+      distributed under a different license, but that exception covers extensions built against
+      Vendure — it does not permit vendoring core source. ALSO NOTE the org rename:
+      `vendure-ecommerce/vendure` now 301-redirects to `vendurehq/vendure`; the GitHub API returns
+      no data for the old path, so any stored URL should be updated.
+    proposedLayerIds: []
+
+droppedCandidates:
+  - "saleor/storefront — DROPPED IN RE-VERIFICATION ON THE LICENSE GATE. Was recorded as
+    BSD-3-Clause/vendorable; the LICENSE file at main is in fact the Functional Source License,
+    Version 1.1, ALv2 Future License (self-abbreviated FSL-1.1-ALv2), copyright 2026 Saleor
+    Commerce. It grants use only for a 'Permitted Purpose' and excludes any 'Competing Use',
+    defined to include offering 'the same or substantially similar functionality as the Software'.
+    That is source-available, not open source, and a scaffolding tool cannot attach it to
+    arbitrary generated repos. GitHub renders no license label for the repo, consistent with a
+    non-SPDX license. Note the divergence within one org: saleor/saleor and saleor/saleor-dashboard
+    remain genuinely BSD-3-Clause (raw LICENSE re-read for both), so the storefront was relicensed
+    on its own. The FSL does convert to Apache-2.0 two years after each release, but a
+    date-dependent future grant is not a present permissive grant and cannot gate a build.
+    Storefront coverage is retained via vercel/commerce (MIT) and Shopify/hydrogen (MIT).
+    (1480 stars, pushed 2026-07-17 — both figures as recorded; the numbers were fine, the
+    license was not.)"
+  - "medusajs/b2b-starter-medusa — DROPPED IN RE-VERIFICATION AS ARCHIVED. MIT is correct
+    (raw LICENSE confirms), and stars/date were as recorded (420 stars, pushed 2026-04-09), but
+    the repo page carries the banner 'This repository was archived by the owner on Jul 2, 2026.
+    It is now read-only.' It was recorded `maintained: true`, which is wrong. Verified against a
+    known-live control (medusajs/medusa, no banner) to rule out a false positive. Dropped for the
+    same reason this file already drops medusajs/nextjs-starter-medusa — the two were archived on
+    the same day, suggesting Medusa retired its starter repos together. Consequence: the catalog
+    now has no B2B commerce source. If B2B coverage is wanted, the archived tree may still be read
+    for its company/employee model and quote-approval workflow (MIT permits copying even from an
+    archived repo), but it must not seed a template, and it will not track Medusa core."
+  - "sanity-io/sanity-template-nextjs-clean — repo exists and is active (401 stars, pushed 2026-07-18) but has NO license file: checked LICENSE, LICENSE.md, license, LICENSE.txt and COPYING, all 404. Absence of a license means all rights reserved, so it is excluded rather than permissive."
+  - "Shopify/hydrogen-demo-store — GitHub API returns license: null (235 stars, pushed 2026-07-01). Unlicensed, therefore excluded. Use templates/skeleton inside Shopify/hydrogen instead, which is covered by that repo's MIT license."
+  - "medusajs/nextjs-starter-medusa — verified archived: true via the GitHub API (2789 stars, last push 2026-04-23). MIT, but an archived repo should not seed a template."
+  - "vendure-ecommerce/vendure — not a real current path; 301-redirects to vendurehq/vendure after an org rename. Listed under its canonical name above."
+  - "vendure-ecommerce/storefront-remix-starter — no LICENSE file found at the expected path on the master branch, and the parent org has been renamed; combined with Vendure core being GPLv3, not worth pursuing."
+
+notes: >-
+  Sixteen entries were researched on 2026-07-18 and re-verified adversarially the same day; two
+  were dropped in that second pass, leaving fourteen. Eleven pass the vendorable gate (MIT or
+  BSD-3-Clause), one is reference-only (Strapi), and two are excluded on license (Directus,
+  Vendure).
+
+  The re-verification pass changed the result. saleor/storefront was recorded as BSD-3-Clause but
+  actually ships the Functional Source License 1.1 with a Competing Use restriction — the original
+  pass appears to have inferred the license from the Saleor org rather than reading that repo's own
+  LICENSE file, and the org is genuinely split (core and dashboard are BSD-3-Clause, the storefront
+  is not). medusajs/b2b-starter-medusa was recorded `maintained: true` but was archived read-only
+  on 2026-07-02. Both are now in droppedCandidates with the evidence. The lesson for later
+  categories: license and archived status must be read per repo, never inherited from an org, a
+  sibling repo, or an earlier note.
+
+  The headline result is that the brief's expected list has aged badly. Three of the nine projects
+  named — Directus, Vendure and Strapi — no longer offer a clean permissive grant. Directus now
+  ships the Monospace Sustainable Core License with a Competing Use restriction; Vendure is dual
+  GPLv3/commercial and has also renamed its GitHub org; Strapi's MIT applies only outside `ee/` and
+  only to users without a Strapi Cloud account. All three were read from the raw LICENSE files, not
+  from the API summary, which is what surfaced the problem — the GitHub API reports NOASSERTION for
+  Strapi and Directus and would have been easy to misread as "unknown, probably fine".
+
+  That reshapes the recommended core. For commerce, Medusa (MIT) is the default vendorable backend
+  now that Vendure is out, with Saleor (BSD-3, attribution required) as the enterprise/non-JS
+  option. For CMS, Payload (MIT) is the strongest pick and uniquely ships a verified `templates/`
+  directory containing blank, website, ecommerce and four database-variant starters — closer to
+  ready-to-harvest scaffolds than anything else found.
+
+  Complexity ladder coverage after the drops: simple = Keystatic, nuxt/content, vercel/commerce;
+  standard = Keystone, Hydrogen; professional = Payload, Medusa, Sanity, Ghost; enterprise =
+  Saleor core, saleor-dashboard. Two gaps opened that the build phase should know about. First,
+  the enterprise rung is now Saleor-only and therefore Python/Django-only, so there is no
+  enterprise-tier TypeScript option; Medusa (professional) is the closest substitute. Second,
+  B2B commerce is now uncovered entirely. Neither gap is worth closing by relaxing the gate.
+
+  Two license obligations to carry into the build phase: BSD-3-Clause (saleor/saleor and
+  saleor/saleor-dashboard — note this is now two repos, not three, since saleor/storefront was
+  dropped as FSL) requires the copyright notice to travel with any copied file, and Sanity is MIT
+  only for the Studio client — its content lake is a proprietary hosted service, so that layer must
+  never be described as self-hostable.
+
+  Freshness: every retained entry was pushed within the last ~6 weeks and none is archived
+  (re-checked individually against the repo archive banner, not inferred). The oldest is
+  vercel/commerce (2026-06-10), far inside the 18-month staleness bar. Stars and dates were
+  re-read from the ungh.cc mirror during re-verification and matched the recorded values exactly
+  for all sixteen repos, including the two dropped ones — the numeric research was sound
+  throughout; the failures were both categorical (license class, maintained flag), which is the
+  more dangerous kind because no amount of re-counting surfaces them.