@opengroundplan/core 0.1.1

package/catalog/sources/mobile-desktop.yaml

@@ -0,0 +1,638 @@
+# Groundplan source catalog - category: mobile-desktop
+#
+# Research date: 2026-07-18
+# All stars / pushed_at / archived / license values were read from the GitHub API on that
+# date (search/repositories endpoint, which returns the same repo objects as /repos/{o}/{r}).
+# Where the API reported NOASSERTION or null, the LICENSE file was fetched from
+# raw.githubusercontent.com and classified from its text - those cases are flagged inline.
+# licenseClass gate: vendorable = MIT/Apache-2.0/BSD/ISC/CC0 (copy with required notice);
+# reference-only = MPL/LGPL/EPL; excluded = GPL/AGPL/SSPL/BUSL/source-available/unlicensed.
+
+category: mobile-desktop
+
+sources:
+  # ---------------------------------------------------------------- React Native / Expo
+  - name: infinitered/ignite
+    url: https://github.com/infinitered/ignite
+    stars: 19890
+    spdx: MIT
+    licenseClass: vendorable
+    # API reported NOASSERTION; boilerplate/../LICENSE on master reads
+    # "The MIT License (MIT) - Copyright (c) 2016-present Infinite Red, Inc."
+    licenseNote: >-
+      GitHub API returns NOASSERTION (license file has a non-standard preamble). Verified
+      MIT from the LICENSE file text at master.
+    maintained: true
+    lastCommit: "2026-06-07"
+    stack: react-native, expo, typescript, react-navigation, mmkv, i18next, reactotron
+    complexity: professional
+    whatToBorrow: >-
+      The whole `boilerplate/` tree is the payload. Highest-value pieces: `boilerplate/app/config/`
+      split into config.base.ts / config.dev.ts / config.prod.ts with an index.ts that picks by
+      __DEV__ - a clean environment-layer contract to copy verbatim. `boilerplate/app/components/`
+      is a genuinely reusable primitive set (Text, Button, Screen, TextField, ListItem, Card,
+      EmptyState, Header, Toggle/{Checkbox,Radio,Switch}) built on a themed style contract in
+      `boilerplate/app/theme/colors.ts`. `boilerplate/app/i18n/` shows the per-locale module
+      pattern (en/es/fr/ja/ko/hi/ar plus demo-* files) including RTL. `boilerplate/app/devtools/
+      ReactotronClient.ts` + `.web.ts` is a good platform-suffix example. `boilerplate/.maestro/`
+      has real E2E flows (flows/Login.yaml, flows/FavoritePodcast.yaml) plus reusable
+      `shared/_Login.yaml` and `shared/_OnFlowStart.yaml` subflows - copy this as the e2e layer.
+      `boilerplate/app/navigators/AppNavigator.tsx` and `app/context/AuthContext.tsx` give the
+      auth-gated navigation split.
+    whatToAvoid: >-
+      Ignite carries a large opinionated demo app (podcast/episode screens, demo-* i18n files)
+      that must be stripped or it ships to users as dead weight. Reactotron is Infinite Red's own
+      tool and is wired through the app - treat it as an optional layer, not a default. The repo
+      also ships a CLI and generator templates that assume Ignite's own directory conventions;
+      do not import the CLI, only the boilerplate tree. Historically MST-based, so older blog
+      guidance and community snippets may not match the current context-based state approach.
+    proposedLayerIds:
+      - mobile-expo-router
+      - mobile-rn-components-kit
+      - config-env-tiered
+      - i18n-i18next-rtl
+      - storage-mmkv
+      - e2e-maestro
+      - devtools-reactotron
+      - theme-tokens-rn
+
+  - name: obytes/react-native-template-obytes
+    url: https://github.com/obytes/react-native-template-obytes
+    stars: 4281
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-06-02"
+    stack: expo, expo-router, typescript, nativewind/uniwind, react-query, zustand, jest, maestro, eas
+    complexity: professional
+    whatToBorrow: >-
+      The best-in-class CI and env story in this category. `.github/workflows/` is the single
+      biggest borrow - 14 real workflows including type-check.yml, lint-ts.yml, test.yml,
+      expo-doctor.yml, eas-build-preview.yml, eas-build-prod.yml, e2e-android-eas-build.yml,
+      e2e-android-maestro.yml, new-app-version.yml and new-github-release.yml. `env.ts` plus
+      `app.config.ts` implement typed, zod-validated, per-variant environment resolution feeding
+      Expo config - this is exactly the "no static values in code" contract a scaffolder should
+      emit. `src/app/` is a clean expo-router layout (_layout.tsx, login.tsx, onboarding.tsx,
+      +html.tsx, [...messing].tsx catch-all). `src/components/ui/index.tsx` is a barrel-exported
+      primitive set and `src/components/ui/use-theme-config.tsx` + `src/lib/hooks/
+      use-selected-theme.tsx` are a tidy dark-mode layer. `__mocks__/` (bottom-sheet, moti,
+      gesture-handler, keyboard-controller, expo-localization) plus `jest-setup.ts`,
+      `jest.config.js` and `src/lib/test-utils.tsx` are a drop-in RN testing layer. `cli/`
+      (index.js, clone-repo.js, setup-project.js, utils.js) is a working reference for
+      post-clone project renaming/setup. `.maestro/config.yaml` for E2E.
+    whatToAvoid: >-
+      Heavily coupled to Expo EAS and the Obytes house style - the workflows assume EAS
+      credentials and an Expo account, so they are a vendor-lock layer, not a default. Styling
+      recently migrated from classic tailwind.config.js to uniwind (`uniwind-types.d.ts`,
+      `nativewind-env.d.ts` both present), so copied styling code can straddle two systems -
+      pick one. Ships an Astro docs site under `docs/` that is irrelevant to a generated app.
+      Opinionated commit tooling (commitlint.config.js, lint-staged.config.js, husky) should be
+      optional layers rather than baked in.
+    proposedLayerIds:
+      - mobile-expo-router
+      - ui-nativewind
+      - config-env-zod-typed
+      - ci-github-actions-eas
+      - ci-eas-build
+      - test-jest-rn
+      - e2e-maestro
+      - lint-eslint-flat
+      - hooks-husky-commitlint
+
+  - name: expo/examples
+    url: https://github.com/expo/examples
+    stars: 3677
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-02"
+    stack: expo, react-native, typescript, various integrations
+    complexity: simple
+    whatToBorrow: >-
+      First-party, per-concern minimal projects - each top-level directory is one runnable Expo
+      app demonstrating exactly one integration, which is the ideal shape for atomic scaffold
+      layers. Use it as the canonical reference for the current, non-deprecated way to wire a
+      given Expo API (router, auth sessions, notifications, sqlite, camera, styling variants).
+      Because Expo maintains it against each SDK release, it is the best source for the *current*
+      app.json / app.config.js keys and plugin arrays rather than stale blog snippets.
+    whatToAvoid: >-
+      These are demos, not production starters - no auth hardening, no CI, no test setup, no
+      error boundaries, minimal typing. Examples pin specific Expo SDK versions and older
+      directories can lag behind the newest SDK, so verify the SDK version in each app.json
+      before adapting. There is no shared architecture across examples, so composing several of
+      them yields inconsistent conventions unless normalized.
+    proposedLayerIds:
+      - mobile-expo-minimal
+      - mobile-expo-router
+      - mobile-expo-sqlite
+      - mobile-push-notifications
+      - mobile-auth-expo-session
+
+  - name: flemingvincent/expo-clerk-convex
+    url: https://github.com/flemingvincent/expo-clerk-convex
+    stars: 781
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-02"
+    stack: expo, expo-router, typescript, clerk, convex, nativewind
+    complexity: standard
+    # NOTE: this repo was previously FlemingVincent/expo-supabase-starter; github.com/
+    # FlemingVincent/expo-supabase-starter now 301-redirects here and the stack pivoted to
+    # Clerk + Convex. The old Supabase-named URL should not be used.
+    whatToBorrow: >-
+      A complete, small email/password auth flow wired end to end - Clerk for identity plus
+      Convex as the reactive backend, which gives optimistic local writes and automatic
+      resubscription on reconnect (a practical offline-tolerant path without hand-rolling a
+      sync engine). Worth adapting: the auth-gated expo-router group layout (protected vs public
+      route groups), the Clerk token-cache wiring into secure storage, and the Convex client
+      provider composition at the router root. Small enough to read in one sitting, which makes
+      it a good template for an "auth + backend" layer pair.
+    whatToAvoid: >-
+      Two hosted-vendor dependencies (Clerk and Convex) that are both paid at scale - this must
+      be an opt-in layer, never a default, and it is a poor base if the target is self-hosted.
+      Convex's sync is not true offline-first: it is optimistic-plus-reconnect, so it will not
+      survive long offline sessions the way WatermelonDB or PowerSync will. Repo history
+      includes an entirely different Supabase stack, so older stars/reviews describe software
+      that is no longer here.
+    proposedLayerIds:
+      - auth-clerk
+      - backend-convex
+      - mobile-expo-router
+      - mobile-auth-gated-routes
+      - storage-secure-store
+
+  # ---------------------------------------------------------------- Flutter
+  - name: VeryGoodOpenSource/very_good_cli
+    url: https://github.com/VeryGoodOpenSource/very_good_cli
+    stars: 2398
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-15"
+    stack: dart, flutter, mason, bloc, very_good_analysis
+    complexity: enterprise
+    whatToBorrow: >-
+      The most directly transferable repo in this catalog, because it *is* a scaffolder. Copy the
+      architecture, not just the output: `lib/src/commands/create/templates/template.dart` defines
+      an abstract Template with an onGenerateComplete hook, `templates.dart` is the registry, and
+      each template gets a triple (very_good_core.dart / _template.dart / _bundle.dart). That
+      registry + post-generate-hook shape maps almost one-to-one onto a Groundplan layer system.
+      `lib/src/commands/create/templates/post_generate_actions.dart` centralizes
+      "run after files are written" steps (pub get, formatting) - a pattern worth stealing.
+      `tool/generate_bundles.sh` compiles Mason bricks into checked-in Dart bundles so the CLI
+      ships templates with zero network fetch - a strong answer to template distribution.
+      `bricks/test_optimizer/` shows a full brick with pre-gen hooks (hooks/pre_gen.dart) and,
+      notably, tests for the hooks themselves (hooks/test/pre_gen_test.dart).
+    whatToAvoid: >-
+      Enterprise weight: multi-flavor (dev/stg/prod) entrypoints, 100%-coverage enforcement and
+      very_good_analysis lint strictness are correct for an agency but hostile to a simple
+      starter - do not make them the default tier. The generated app is firmly BLoC-opinionated;
+      teams on Riverpod get nothing reusable from the state layer. The actual app templates are
+      Mason bricks maintained in separate repos and only appear here as generated `*_bundle.dart`
+      blobs, so reading this repo alone will not show you the template source - fetch the brick
+      repos for that. Dart/Mason tooling means the generator code itself is not reusable in a
+      TypeScript scaffolder, only its design.
+    proposedLayerIds:
+      - flutter-app-core
+      - flutter-bloc
+      - flutter-flavors-dev-stg-prod
+      - lint-very-good-analysis
+      - test-coverage-enforced
+      - generator-template-registry
+      - generator-post-gen-hooks
+
+  - name: Stacked-Org/stacked
+    url: https://github.com/Stacked-Org/stacked
+    stars: 1039
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-06-22"
+    stack: dart, flutter, mvvm, get_it, code-generation
+    complexity: standard
+    # Canonical location: github.com/FilledStacks/stacked now 301-redirects here.
+    whatToBorrow: >-
+      A coherent MVVM answer for Flutter: ViewModel base classes (BaseViewModel, and the
+      Future/Stream/Reactive variants) that standardize busy/error state, plus a service-locator
+      registration convention via get_it and a StackedApp annotation that generates routes,
+      dependency registration and dialog/bottomsheet setup from one declaration. The annotation
+      -> generated-locator flow is the piece to adapt: it gives a single, declarative place where
+      a scaffolder can inject new services and routes without hand-editing wiring code.
+      The accompanying CLI's view/service generators show a sensible per-feature file trio.
+    whatToAvoid: >-
+      Strong framework lock-in - Stacked's ViewModel and locator conventions leak into every
+      widget, so migrating off it later is a rewrite, and it competes directly with the more
+      mainstream Riverpod/BLoC ecosystems. Depends on build_runner code generation, which adds
+      build latency and a class of confusing generated-file merge conflicts. Community is much
+      smaller than Riverpod/BLoC, so expect thinner third-party integration coverage. Ecosystem
+      is spread across several packages in this monorepo; pin versions together.
+    proposedLayerIds:
+      - flutter-stacked-mvvm
+      - flutter-di-get-it
+      - flutter-codegen-build-runner
+      - flutter-routing-generated
+
+  - name: bizz84/starter_architecture_flutter_firebase
+    url: https://github.com/bizz84/starter_architecture_flutter_firebase
+    stars: 1809
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2025-09-09"
+    stack: flutter, riverpod, firebase, go_router, firebase_ui_auth
+    complexity: professional
+    whatToBorrow: >-
+      The clearest reference implementation of feature-first Flutter layering. Every feature under
+      `lib/src/features/<feature>/` is split into data/ domain/ application/ presentation/ -
+      e.g. `features/authentication/data/firebase_auth_repository.dart`,
+      `features/authentication/domain/app_user.dart`,
+      `features/authentication/presentation/auth_providers.dart`, and on the entries feature
+      `entries/application/entries_service.dart` sitting between repository and UI. That folder
+      contract is directly encodable as a scaffold layer. Also borrow
+      `lib/src/common_widgets/async_value_widget.dart` (the canonical AsyncValue -> UI adapter),
+      `list_items_builder.dart`, `error_message_widget.dart`, `empty_placeholder_widget.dart`,
+      `responsive_center.dart` / `responsive_scrollable_card.dart`, and the design-token files
+      `lib/src/constants/app_sizes.dart` + `breakpoints.dart`. The `.g.dart` files alongside show
+      the riverpod_generator convention.
+    whatToAvoid: >-
+      Last pushed 2025-09-09 - still inside the 18-month window but roughly ten months stale, so
+      Flutter/Firebase/Riverpod package pins need refreshing before use. Deeply Firebase-coupled
+      (firebase_auth, firestore, firebase_ui_auth), so the data layer is not portable to a
+      Postgres/REST backend without rewriting every repository. The app is a time-tracking demo -
+      the entries/jobs domain must be stripped. Uses build_runner codegen, so generated `.g.dart`
+      files must be regenerated, not copied blindly.
+    proposedLayerIds:
+      - flutter-riverpod
+      - flutter-feature-first-layers
+      - auth-firebase
+      - db-firestore
+      - flutter-routing-go-router
+      - flutter-design-tokens
+      - flutter-codegen-build-runner
+
+  - name: flutter/samples
+    url: https://github.com/flutter/samples
+    stars: 19210
+    spdx: BSD-3-Clause
+    licenseClass: vendorable
+    # API reported NOASSERTION; LICENSE at main is the Chromium Authors BSD-3-Clause text.
+    licenseNote: >-
+      GitHub API returns NOASSERTION because the LICENSE file is the comment-prefixed Chromium
+      Authors header. Text verified as BSD-3-Clause - vendorable, retain the copyright notice.
+    maintained: true
+    lastCommit: "2026-07-17"
+    stack: flutter, dart, material 3, various state solutions
+    complexity: simple
+    whatToBorrow: >-
+      First-party and continuously updated against current Flutter stable, which makes it the
+      safest source for baseline files a scaffolder emits: current pubspec.yaml shape,
+      analysis_options.yaml, platform runner directories (android/ ios/ macos/ windows/ linux/
+      web/) and Material 3 theming setup. The `compass_app` sample is Flutter team's own
+      architecture reference (MVVM + repositories + command pattern) and pairs well as the
+      "official" counterweight to community architectures. Individual samples are single-concern
+      and strip down cleanly.
+    whatToAvoid: >-
+      A grab-bag rather than a template - samples disagree with each other on state management
+      and folder layout, so do not mix them into one generated app. Most have no tests, no CI and
+      no environment configuration. BSD-3-Clause requires reproducing the copyright notice and
+      forbids using the Flutter/Google names to endorse derived work - keep the notice in any
+      vendored file and do not brand output as Flutter-endorsed.
+    proposedLayerIds:
+      - flutter-app-minimal
+      - flutter-material3-theme
+      - flutter-platform-runners
+      - flutter-mvvm-compass
+
+  # ---------------------------------------------------------------- Tauri
+  - name: tauri-apps/create-tauri-app
+    url: https://github.com/tauri-apps/create-tauri-app
+    stars: 1604
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    stack: tauri v2, rust, vite, react/vue/svelte/solid/angular/preact, typescript
+    complexity: simple
+    whatToBorrow: >-
+      The template composition mechanism is the prize. `templates/_base_/` holds everything
+      shared (src-tauri/Cargo.toml.lte, src-tauri/build.rs, the full icons/ set including
+      icon.icns / icon.ico / Square*Logo.png, and _gitignore) and each `templates/template-<fw>/`
+      overlays framework-specific files, with a per-template `.manifest` declaring how they merge.
+      Two techniques are worth copying outright: `.lte` template files for value interpolation,
+      and version-gated filenames like `%(v1)%tauri.conf.json.lte` / `%(v2)%tauri.conf.json.lte`
+      and `%(v2)%lib.rs.lte`, which let one tree serve multiple major versions without branching.
+      `templates/_base_/src-tauri/capabilities/%(v2)%default.json.lte` is the current Tauri v2
+      permissions/capabilities model - the correct security default to emit. The complete
+      multi-resolution icon set is itself a reusable asset layer.
+    whatToAvoid: >-
+      Deliberately minimal - no auth, no persistence, no updater, no CI, no state management, so
+      it is a floor rather than a product starter. Still carries v1 conditional paths, so copying
+      indiscriminately can drag deprecated Tauri v1 config into a new project; take only the
+      `%(v2)%` variants. Apache-2.0 requires preserving the NOTICE/license header on vendored
+      files. Rust toolchain plus platform-specific system dependencies (WebKitGTK on Linux) make
+      the CI story more involved than an Electron equivalent.
+    proposedLayerIds:
+      - desktop-tauri-v2
+      - tauri-capabilities-security
+      - tauri-icon-assets
+      - build-vite
+      - generator-base-overlay-templates
+
+  - name: agmmnn/tauri-ui
+    url: https://github.com/agmmnn/tauri-ui
+    stars: 2102
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-04-20"
+    stack: tauri v2, react, shadcn/ui, tailwind, vite/next/react-router/tanstack-start/astro
+    complexity: standard
+    whatToBorrow: >-
+      This has evolved from a static starter into a generator whose internal model is close to
+      what Groundplan needs. `packages/create-tauri-ui/src/adapters/` has one adapter per frontend
+      (vite.ts, next.ts, react-router.ts, start.ts, astro.ts) - the frontend-framework axis
+      factored out cleanly. `packages/create-tauri-ui/src/batteries/` is the feature axis, each
+      an independently injectable concern: debug-panel.ts, external-link-guard.ts,
+      flash-prevention.ts, icon.ts, invoke-example.ts, scroll-container.ts,
+      selection-behavior.ts, size-optimization.ts, workflow.ts. `src/commands/battery-registry.ts`
+      plus `commands/detect.ts` and `commands/manage.ts` implement registry, detection of what is
+      already installed, and add/remove - i.e. idempotent layer application on an existing
+      project. Individual batteries are also good content: external-link-guard is a real Tauri
+      security hardening step, size-optimization is the Cargo release-profile tuning, and
+      flash-prevention fixes the white-flash-on-launch issue every Tauri app hits.
+    whatToAvoid: >-
+      Single-maintainer project - bus factor of one, and the API has churned (it was a plain
+      template repo before becoming a CLI), so pin to a release rather than tracking main.
+      shadcn/ui is copy-in source, so vendored components drift from upstream and you inherit
+      maintenance. Supporting five frontend adapters means any given adapter gets less testing
+      than the Vite default. The repo's own `apps/docs` Next.js site is noise for template
+      extraction.
+    proposedLayerIds:
+      - desktop-tauri-v2
+      - ui-shadcn
+      - ui-tailwind
+      - tauri-security-link-guard
+      - tauri-window-flash-prevention
+      - tauri-release-size-optimization
+      - generator-adapter-per-framework
+      - generator-idempotent-feature-batteries
+
+  # ---------------------------------------------------------------- Electron
+  - name: alex8088/electron-vite
+    url: https://github.com/alex8088/electron-vite
+    stars: 5539
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-04-17"
+    stack: electron, vite, typescript, rollup
+    complexity: standard
+    whatToBorrow: >-
+      The canonical answer to "how do I configure an Electron build in 2026". Borrow the
+      three-target electron.vite.config.ts shape (separate main / preload / renderer sections,
+      each a full Vite config) and the externalizeDepsPlugin convention that keeps node
+      dependencies out of the bundle - getting this wrong is the single most common Electron
+      build failure. Also worth adapting: the HMR strategy for the main process, the
+      `ELECTRON_RENDERER_URL` dev-vs-file-protocol loading split, the bytecode/source-protection
+      option for shipping closed code, and the tsconfig split (node vs web) that gives correct
+      types on both sides of the preload boundary.
+    whatToAvoid: >-
+      This is build tooling, not an application template - it gives you no UI, routing, IPC
+      architecture, state or packaging. Effectively a single-maintainer project. Some
+      documentation is Chinese-first. The source-protection/bytecode feature is not real security
+      and should not be presented as such. You still need electron-builder or Electron Groundplan on
+      top for distribution, so it is always a partial layer.
+    proposedLayerIds:
+      - desktop-electron
+      - build-electron-vite
+      - electron-preload-contextbridge
+      - tsconfig-node-web-split
+
+  - name: daltonmenezes/electron-app
+    url: https://github.com/daltonmenezes/electron-app
+    stars: 806
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2025-12-07"
+    stack: electron, electron-vite, react 19, typescript 5, tailwind 4, shadcn/ui, electron-router-dom
+    complexity: professional
+    whatToBorrow: >-
+      A well-factored Electron application skeleton living under `template/`. The standout is
+      `template/src/lib/electron-app/factories/` - factories/app/instance.ts and app/setup.ts wrap
+      app lifecycle, factories/windows/create.ts is a reusable window factory, and
+      factories/ipcs/register-window-creation.ts shows typed IPC registration instead of ad-hoc
+      ipcMain.on calls scattered through main. The four-way source split
+      (`src/main/`, `src/preload/`, `src/renderer/`, `src/shared/`) with `src/shared/types.ts` and
+      `src/shared/constants.ts` shared across the process boundary is the layout to standardize
+      on. `template/src/lib/electron-router-dom.ts` plus `src/renderer/routes.tsx` solve
+      multi-window routing. `template/src/lib/electron-app/release/` is a complete release
+      pipeline in TypeScript (modules/prebuild.ts, modules/release.ts, utils/exec.ts,
+      utils/extractors.ts, utils/validations.ts), paired with `template/electron-builder.ts` and
+      `template/.github/workflows/release.yml` for signed multi-platform publishing.
+    whatToAvoid: >-
+      It vendors an entire prebuilt React DevTools extension into the repo
+      (`template/src/lib/electron-app/extensions/react-developer-tools/` - dozens of built .js
+      bundles, icons and popups). That is committed third-party build output with its own
+      licensing and staleness problems; strip it and install devtools at runtime instead. Last
+      push 2025-12-07 (~7 months), so React/Electron/Tailwind pins need bumping. The bespoke
+      `electron-router-dom` abstraction is another single-maintainer dependency. Sole maintainer
+      overall, and the factory layer adds indirection that is overkill for a single-window app.
+    proposedLayerIds:
+      - desktop-electron
+      - build-electron-vite
+      - electron-window-factory
+      - electron-typed-ipc
+      - electron-multi-window-router
+      - ui-shadcn
+      - ui-tailwind
+      - packaging-electron-builder
+      - ci-release-multiplatform
+
+  - name: electron-react-boilerplate/electron-react-boilerplate
+    url: https://github.com/electron-react-boilerplate/electron-react-boilerplate
+    stars: 24254
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-04-29"
+    stack: electron, react, typescript, webpack, electron-builder, jest
+    complexity: enterprise
+    whatToBorrow: >-
+      The most battle-tested packaging and release configuration in the Electron ecosystem - a
+      decade of accumulated fixes for code signing, notarization, auto-update and native-module
+      rebuilds that are genuinely hard to reproduce. Borrow the electron-builder configuration
+      (per-platform targets, publish/update channel setup, afterSign notarization hook), the
+      two-package.json structure that keeps native deps out of the app bundle, the multi-config
+      webpack setup (separate main/renderer, dev vs prod), and the CI matrix that builds on
+      macOS/Windows/Linux runners. Its documented security posture (contextIsolation on,
+      nodeIntegration off, explicit preload bridge) is a good checklist to encode as a lint layer.
+    whatToAvoid: >-
+      Webpack-based while the ecosystem has largely moved to Vite, so its build config is the
+      slowest and most complex option available and is the main reason not to use it as a default
+      tier - take the packaging config, leave the bundler. The two-package.json layout confuses
+      newcomers and interacts badly with modern workspaces/pnpm. Long history means accumulated
+      config cruft and a large dependency surface. Development pace has slowed relative to its
+      star count; verify each dependency's currency rather than trusting the aggregate.
+    proposedLayerIds:
+      - desktop-electron
+      - build-electron-webpack
+      - packaging-electron-builder
+      - electron-code-signing-notarization
+      - electron-auto-update
+      - electron-security-baseline
+      - ci-release-multiplatform
+
+  # ---------------------------------------------------------------- .NET MAUI
+  - name: dotnet/maui-samples
+    url: https://github.com/dotnet/maui-samples
+    stars: 3651
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-05-22"
+    stack: dotnet, maui, csharp, xaml, mvvm
+    complexity: standard
+    whatToBorrow: >-
+      First-party MIT-licensed MAUI code, which matters because most MAUI sample material is
+      either unlicensed blog code or Microsoft-docs snippets. Use it for the baseline a
+      scaffolder must emit correctly: the .csproj multi-targeting block
+      (net-android/ios/maccatalyst/windows) with per-platform SupportedOSPlatformVersion, the
+      MauiProgram.cs builder pattern with DI service registration and font/handler configuration,
+      Platforms/{Android,iOS,MacCatalyst,Windows}/ entry points, Resources/ (AppIcon, Splash,
+      Fonts, Styles/Colors.xaml + Styles.xaml) and the AppShell.xaml routing/navigation model.
+      Individual samples are single-feature and map neatly to per-capability layers.
+    whatToAvoid: >-
+      Samples, not a production starter - no CI, no tests, no configuration/secrets layer, minimal
+      error handling. Content is organized by docs article and by .NET version folder, so you must
+      pick the folder matching your target TFM or you will copy outdated APIs. MVVM here is often
+      hand-rolled; pair with CommunityToolkit.Mvvm for source-generated observables rather than
+      copying the boilerplate INotifyPropertyChanged. Windows-centric tooling expectations, and
+      iOS/macOS targets still require a Mac build host - a real constraint for generated CI.
+    proposedLayerIds:
+      - desktop-mobile-maui
+      - maui-multitarget-csproj
+      - maui-di-mauiprogram
+      - maui-shell-navigation
+      - maui-resources-theming
+      - maui-mvvm-toolkit
+
+  # ---------------------------------------------------------------- Offline-first data
+  - name: Nozbe/WatermelonDB
+    url: https://github.com/Nozbe/WatermelonDB
+    stars: 11751
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2025-08-11"
+    stack: react-native, sqlite, typescript, lokijs (web)
+    complexity: professional
+    whatToBorrow: >-
+      The reference implementation of offline-first sync for React Native, and the sync protocol
+      is the real asset. Borrow its pull/push contract - the server returns changes since
+      `last_pulled_at` as created/updated/deleted collections, the client pushes local changes and
+      the engine reconciles - because it is a backend-agnostic design you can implement against
+      any API. Also adapt: the schema + numbered migrations model (schema.js with versioned
+      migrations rather than destructive resets), the Model/decorator definitions with
+      @field/@relation/@children, lazy observable queries that keep large datasets off the JS
+      thread, and the `_status` / `_changed` per-record bookkeeping columns that make conflict
+      resolution tractable. This bookkeeping-column pattern is worth copying even if you use a
+      different database.
+    whatToAvoid: >-
+      Last pushed 2025-08-11 (~11 months) - inside the staleness window but clearly slowing, and
+      issue response has lagged; treat as maturing rather than actively evolving. You must build
+      and operate the server side of the sync protocol yourself - there is no backend included,
+      which is a large hidden cost. Historically Flow-typed with TypeScript definitions layered
+      on, so type ergonomics are weaker than a TS-native library. The decorator-based model API
+      requires legacy decorator support in Babel/TS config. Reactive-query mental model differs
+      enough from ORMs that developer onboarding is non-trivial.
+    proposedLayerIds:
+      - offline-first-sync
+      - db-watermelondb
+      - db-sqlite-mobile
+      - sync-pull-push-protocol
+      - db-migrations-versioned
+
+  - name: powersync-ja/powersync-js
+    url: https://github.com/powersync-ja/powersync-js
+    stars: 691
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-16"
+    stack: typescript, sqlite, react-native, web, node, postgres/mongodb/mysql backends
+    complexity: professional
+    whatToBorrow: >-
+      The most actively developed offline-first option here and the cleanest architectural split
+      to copy: a local SQLite database is the only thing the UI reads/writes, and a separate
+      replication process streams changes to and from the backend, so application code never
+      branches on connectivity. Specific pieces to adapt - the sync-rules declaration that defines
+      which subset of server data each user syncs (a partial-replication model most hand-rolled
+      systems get wrong), the upload-queue/backend-connector interface where you implement how
+      local writes are applied server-side, and the watched-query API that re-emits on local
+      change. The monorepo also demonstrates sharing one sync core across React Native, web and
+      Node packages - useful if a template targets multiple runtimes.
+    whatToAvoid: >-
+      The client SDK is Apache-2.0 but the sync *service* is the company's commercial product -
+      the open-source client is only half a system, and self-hosting has real operational cost, so
+      classify this as a hosted-vendor layer. Newer and smaller (691 stars) than WatermelonDB with
+      a correspondingly thinner body of community troubleshooting. Sync rules are a new DSL to
+      learn and misconfiguration silently under- or over-syncs data. Apache-2.0 requires
+      preserving the NOTICE file and license headers on anything vendored.
+    proposedLayerIds:
+      - offline-first-sync
+      - sync-powersync
+      - db-sqlite-mobile
+      - sync-partial-replication-rules
+      - sync-upload-queue
+      - db-postgres-backend
+
+droppedCandidates:
+  - name: guilherme-v/flutter-clean-architecture-example
+    reason: >-
+      No LICENSE file present (GitHub API license is null; no LICENSE/COPYING at any ref).
+      Unlicensed means all rights reserved - excluded, cannot be copied from. 875 stars, last
+      push 2024-11-12 (stale, >18 months).
+  - name: aspen-cloud/triplit
+    reason: >-
+      AGPL-3.0 verified from the LICENSE file. Excluded - copying would impose AGPL terms on every
+      generated repo. (3099 stars, last push 2026-01-19.)
+  - name: expo/router
+    reason: >-
+      Archived 2024-06-27 and explicitly moved into expo/expo; license is null. Excluded and dead.
+      Use expo/expo or expo/examples for Expo Router material.
+  - name: betomoedano/expo-starter
+    reason: HTTP 404 - repository does not exist at that path. Dropped rather than guessed.
+  - name: electron/electron-quick-start
+    reason: >-
+      Renamed - now 301-redirects to electron/minimal-repro (11445 stars, CC0-1.0, pushed
+      2026-07-15, not archived). It is now positioned as a bug-reproduction harness rather than a
+      starter, so it is a valid but very thin "simple" Electron source; kept out of the main list
+      in favour of electron-vite.
+  - name: isar/isar
+    reason: >-
+      Apache-2.0 and 4020 stars, but last push 2025-06-14 (~13 months) with the v4 rewrite
+      effectively stalled. Not formally stale under the 18-month rule, but too uncertain to
+      recommend as a Flutter persistence layer; drift (MIT, pushed 2026-07-15) is the safer pick.
+  - name: expo/expo-template-default
+    reason: >-
+      Exists (33 stars, pushed 2026-07-17) but has no license (null) and is described as a mirror
+      of the Expo default template. Excluded on license grounds.
+  - name: FilledStacks/stacked
+    reason: Renamed - 301-redirects to Stacked-Org/stacked, which is included above.
+  - name: FlemingVincent/expo-supabase-starter
+    reason: >-
+      Renamed - 301-redirects to flemingvincent/expo-clerk-convex, included above. The Supabase
+      stack it was known for has been replaced by Clerk + Convex, so the old name is misleading.
+  - name: tamagui/tamagui
+    reason: >-
+      MIT, 14090 stars, pushed 2026-07-18 - healthy and a strong universal RN+web option via its
+      create-tamagui monorepo template. Held back because it is primarily a styling library with
+      an optimizing compiler (build-time lock-in) rather than a starter, and the RN/Expo tier is
+      already well covered by ignite and obytes. Reconsider if a universal-app layer is needed.
+  - name: LegendApp/legend-state
+    reason: >-
+      MIT, 4167 stars, pushed 2026-07-12 - a good lightweight local-first state+persistence layer,
+      dropped only to avoid a third overlapping offline-first entry alongside WatermelonDB and
+      PowerSync.