@symbiote-native/cli 0.0.1

package/templates/js/vue-tsx/README.md

@@ -0,0 +1,110 @@
+# templates/js/vue-tsx
+
+Per-framework JS-level overlay for a Vue-**TSX**-flavored generated app (`.tsx` + JSX,
+`@vue/babel-plugin-jsx` — as opposed to `templates/js/vue-sfc`'s `.vue` single-file-component
+flavor). Combined at generation time with the shared `templates/native/{ios,android}` shell.
+Source: `examples/vue-tsx/` (root-level files only — its `ios/`/`android/` are already covered
+by the shared native template).
+
+## Copied files
+
+Every file below is bootstrap/tooling/config: identical (or safe-to-reuse-verbatim) in any new
+SymbioteNative Vue-TSX app, regardless of what screens the app author writes on top.
+
+| File | Why it belongs in the seam |
+|---|---|
+| `index.js` | Entry point — `createApp(App).mount(appName)` via `@symbiote-native/vue/bootstrap`. Wires the native-host seam + RN's `AppRegistry`; every generated app needs this exact boilerplate (only `App` and `app.json`'s `name` vary, and both are supplied separately). |
+| `metro.config.js` | Metro config. **Vue-TSX-specific**, not a copy of React's: sets `babelTransformerPath` to `@symbiote-native/vue/metro-css-parser` (not React's `@symbiote-native/react/metro-css-parser`), and adds a `resolver.extraNodeModules` alias mapping the bare `vue` specifier to this app's installed `@vue/runtime-core` — needed because `@vue/babel-plugin-jsx`'s generated helper imports say `from 'vue'`, but the app never installs the `vue` runtime package itself (see the dependency fragment below). |
+| `babel.config.js` | **The file with the real TSX-vs-SFC-specific wiring** — see the dedicated section below. |
+| `tsconfig.json` | Extends `@react-native/typescript-config`, adds the `@symbiote-native/css-parser/typescript-plugin` TS-server plugin (per-file `.module.css` literal-key typing in the editor). Same shape React/Angular use, just with the plugin swapped in. |
+| `tsconfig.typecheck.json` | **Vue-TSX-specific.** A separate `vue-tsc` typecheck config with `jsx: "preserve"` and a `jsxFactory` pointed at a namespace (`VueJsx.createElement`) neither Vue nor React ever populate, purely to make TS's JSX-type-resolution algorithm fall through to the global `JSX` namespace declared in `vue-jsx.d.ts` (see that file's own comment for the exact TS-internal reason `declare global { namespace JSX {...} }` alone doesn't work). A `.vue`-SFC app has no equivalent file — the SFC compiler doesn't do JSX attribute excess-property checking the way TSX does. |
+| `app.json` | RN app metadata (`name`, `displayName`). **Not parameterized** — see the explicit note below. |
+| `css.d.ts` | Ambient module declarations for `*.css` (side-effect import) and the generic `*.module.css` fallback (before a real per-file generated `.d.ts` exists). Identical shape to `examples/react/css.d.ts` / `examples/angular/css.d.ts`. |
+| `vue-jsx.d.ts` | **Vue-TSX-specific.** Declares the `VueJsx.JSX` namespace `tsconfig.typecheck.json`'s `jsxFactory` points at — `Element`, `ElementClass`, `ElementAttributesProperty`, and (load-bearing) an `IntrinsicAttributes` index signature, because several adapter components (`SafeAreaView`, `StatusBar`, `ActivityIndicator`, `Animated.*`) declare no `props` schema and forward everything through Vue's untyped `$attrs` fallthrough — without the index signature, TSX's excess-property check on those components would false-positive on every extra prop, whereas `.vue` SFCs never hit this at all (their template compiler doesn't excess-property-check against JSX's `IntrinsicAttributes`). |
+| `vue-runtime-core.d.ts` | `declare module 'vue' { export * from '@vue/runtime-core' }` — makes the bare `'vue'` import specifier type-check even though the app only installs `@vue/runtime-core`, mirroring `metro.config.js`'s resolver alias at the type level. |
+| `.eslintrc.js` | `extends: '@react-native'` — same base RN lint config every framework's overlay needs. |
+| `.prettierrc.js` | Standard formatting (`arrowParens: 'avoid'`, `singleQuote: true`, `trailingComma: 'all'`) — framework-independent. |
+| `.watchmanconfig` | Empty `{}` — Metro/Watchman boilerplate every RN app needs, framework-independent. |
+| `.gitignore` | Standard RN `.gitignore` (Xcode/Gradle/CocoaPods/node_modules/Metro health-check files) — framework-independent. |
+
+## The Vue-TSX-specific Babel/Metro wiring (read this before touching either file)
+
+Compared against `examples/react/babel.config.js`, Vue TSX needs real JSX-pragma rewiring, not
+just RN's stock preset:
+
+- **Plugin order is load-bearing.** `babel.config.js`'s `plugins` array lists
+  `'@vue/babel-plugin-jsx'` FIRST. Babel runs `plugins` before `presets`, so the Vue plugin
+  rewrites every `JSXElement` into a `@vue/runtime-core` `createVNode()` call *before* the RN
+  preset's own React-JSX transform (pulled in via `presets: ['module:@react-native/babel-preset']`)
+  ever sees the file — by the time the React transform runs, there is no JSX left for it to
+  touch, so it silently no-ops. Reordering these would leave Vue JSX compiled as React
+  `createElement()` calls, which the Vue runtime cannot mount.
+- **`stripReactJsxDevAttrs` is a real correctness fix, not cleanup.** The RN preset's dev
+  React-JSX transform injects `__self={this}` / `__source={...}` dev annotations on every
+  `JSXElement`; under React those are inert, but `@vue/babel-plugin-jsx` copies them verbatim
+  into the Vue vnode's `props`. At module scope `this` is the Hermes global `HostObject`, so any
+  Vue dev warning that tries to format that prop reads `Symbol.toStringTag` off the
+  `HostObject`, throws, and unwinds the whole mount into a blank screen. This plugin strips both
+  attributes on `JSXOpeningElement` exit (after the self/source plugins add them on enter, before
+  the Vue plugin reads attributes on the parent `JSXElement`'s exit).
+- **`inlineDebugFlag`** is the same `DEBUG` env-var inlining every framework's `babel.config.js`
+  carries (see `<keep_logs_gate_behind_DEBUG>` in the root `CLAUDE.md`) — not TSX-specific, just
+  present here too.
+- **`metro.config.js`'s `vue` → `@vue/runtime-core` alias is the resolver-level twin of the
+  Babel plugin order above**: the Vue plugin's generated helper imports say `from 'vue'`, but
+  this app never installs the `vue` runtime package as a dependency (only `@vue/runtime-core` —
+  see the dependency fragment). Without the alias, Metro would fail to resolve those bare `vue`
+  imports at bundle time.
+
+## Deliberately excluded
+
+- `App.tsx`, `App.css`, `components/`, `screens/`, `navigation-lines.ts`,
+  `navigation-linking.ts`, `routes.ts`, `assets/`, `e2e/`, `package-lock.json` — the example
+  app's own demo content, per the task scope. Not part of the scaffold seam.
+- `package.json` (the full file) — not copied; only the dependency fragment below is.
+- **`Gemfile`** — byte-identical to `examples/react/Gemfile` (verified via `diff`). It's Ruby/
+  CocoaPods toolchain config for the iOS build, framework-independent — conceptually it belongs
+  with the *shared* native shell (`templates/native/ios/`, which already has `Podfile`/
+  `Podfile.lock` but no `Gemfile`), not duplicated verbatim into every per-framework JS overlay.
+  Since this pass is scoped to `templates/js/vue-tsx/` only and must not touch `templates/
+  native/`, it's left out here — flagging it as a real gap for whoever wires the native+overlay
+  merge in `generate.ts` to close (add `Gemfile` to the shared native template once, not to
+  four JS overlays).
+- **`detox.config.js`** — its `testRunner` points at `e2e/jest.config.js`, and its `binaryPath`/
+  `build` fields hardcode the app scheme (`Canary.xcworkspace`, `Canary.app`). Since `e2e/` is
+  excluded as app-authored test content, copying this file alone would ship a dead config with
+  no tests to run and no generic way to point it at a not-yet-generated app's real scheme name.
+  E2E scaffolding is a separate concern from this pass.
+- **`vue-fragment.test.ts`** — a regression test for SymbioteNative's own Vue-adapter engine
+  internals (Fragment start/end anchor handling under the fake-Fabric test harness), ported from
+  a headless smoke test elsewhere in the monorepo. It verifies the *framework*, not something a
+  newly generated app needs; it isn't app code.
+- **`tunnel-demo.ts`** — a `createTunnel()` demo singleton consumed only by the excluded
+  `screens/CanaryScreen.tsx`'s "Show toast" demo button. App-authored demo content, same
+  category as `App.tsx`.
+
+## `package.json.fragment.json`
+
+A dependency **fragment**, not a full `package.json` (this folder isn't an npm package itself).
+Lists only the SymbioteNative-relevant `dependencies`/`devDependencies` a generated app's real
+`package.json` needs, derived from what `index.js`, `metro.config.js`, `babel.config.js`,
+`tsconfig.json`, and `tsconfig.typecheck.json` actually import/require/extend — not guessed.
+Versions are pulled verbatim from `examples/vue-tsx/package.json`. Notably: the runtime
+dependency is `@vue/runtime-core` (not the `vue` meta-package — see the Babel/Metro section
+above for why), and `react-reconciler` is intentionally absent since it's the React adapter's
+own driving mechanism, unused by Vue.
+
+## Not yet parameterized
+
+`app.json`'s `name`/`displayName` fields (`"Canary"`) are copied **literally**, as-is, from the
+example app — no placeholder or templating scheme has been introduced. That's real follow-up
+work for `@symbiote-native/cli new`'s actual generation logic, which still throws
+`NotImplementedCommandError` as of this pass (see `packages/cli/README.md`'s
+"What's real vs. stubbed" section).
+
+## TSX vs SFC selection is not wired up yet
+
+`@symbiote-native/cli new --framework vue` currently has no flag or prompt to choose between this
+TSX overlay and `templates/js/vue-sfc`'s SFC flavor — both exist on disk, but nothing in
+`src/commands/new.ts` or `src/prompts.ts` asks the user which one they want yet. Designing that
+flag/prompt (and its default) is separate follow-up work, out of scope for this pass.

package/templates/js/vue-tsx/app.json

@@ -0,0 +1,4 @@
+{
+  "name": "Canary",
+  "displayName": "Canary"
+}

package/templates/js/vue-tsx/babel.config.js

@@ -0,0 +1,67 @@
+// Inline `process.env.DEBUG` at bundle time so the @symbiote diagnostic logs can
+// be toggled from the shell without a dependency:
+//   DEBUG=1 npx react-native start --reset-cache
+// The value is read from Metro's own environment when this config is evaluated
+// and baked into every transformed module (the app entry and the shared source).
+const debugFlag = process.env.DEBUG === '1' ? '1' : '0';
+
+function inlineDebugFlag({ types: t }) {
+  return {
+    name: 'inline-debug-flag',
+    visitor: {
+      MemberExpression(path) {
+        if (path.matchesPattern('process.env.DEBUG')) {
+          path.replaceWith(t.stringLiteral(debugFlag));
+        }
+      },
+    },
+  };
+}
+
+// The RN preset's dev React-JSX transform injects __self={this} and __source={...} on every
+// JSXElement. Under React they are inert dev annotations, but @vue/babel-plugin-jsx copies them
+// verbatim into the Vue vnode's PROPS — and at module scope `this` is the Hermes global HostObject.
+// Any Vue dev warn then formats that prop for its component trace, the formatter reads
+// Symbol.toStringTag off the HostObject, that throws, and the throw unwinds the whole mount → blank
+// screen. Strip both attributes on JSXOpeningElement exit: the self/source plugins add them on enter
+// (so they exist by exit), and the Vue plugin reads attributes on JSXElement exit, which fires after
+// this child-level exit — so the props never carry them.
+function stripReactJsxDevAttrs() {
+  const DEV_ATTRS = new Set(['__self', '__source']);
+  return {
+    name: 'strip-react-jsx-dev-attrs',
+    visitor: {
+      JSXOpeningElement: {
+        exit(path) {
+          path.node.attributes = path.node.attributes.filter(
+            attr =>
+              !(
+                attr.type === 'JSXAttribute' &&
+                attr.name.type === 'JSXIdentifier' &&
+                DEV_ATTRS.has(attr.name.name)
+              ),
+          );
+        },
+      },
+    },
+  };
+}
+
+// The Vue JSX pair comes from the adapter, not from a hand-written '@vue/babel-plugin-jsx' entry:
+// it is the plugin PLUS the isCustomElement option that makes the `view`/`text`/… intrinsic tags
+// compile to their lowered intrinsic element instead of to a Vue component instance each. Either
+// half alone is broken — see @symbiote-native/vue/babel-jsx, which is why they arrive as one
+// require() rather than two lines here. @vue/babel-plugin-jsx is a dependency of the adapter now,
+// so a fresh install of a published @symbiote-native/vue brings it along; this app's own entry for
+// it is redundant but harmless.
+const symbioteVueJsx = require('@symbiote-native/vue/babel-jsx');
+
+module.exports = {
+  presets: ['module:@react-native/babel-preset'],
+  // The Vue JSX pair is listed FIRST so it runs before the RN preset's React-JSX
+  // transform: babel applies `plugins` before `presets`, so the Vue plugin rewrites every
+  // JSXElement into a @vue/runtime-core createVNode call, leaving no JSX for the React
+  // transform to touch (it no-ops). The helper imports it injects come `from 'vue'`, which
+  // metro.config.js aliases to @vue/runtime-core, the one Vue runtime the adapter renders on.
+  plugins: [...symbioteVueJsx(), stripReactJsxDevAttrs, inlineDebugFlag],
+};

package/templates/js/vue-tsx/css.d.ts

@@ -0,0 +1,24 @@
+// Ambient module for a plain, side-effect-only `.css` import (`import './App.css'`) —
+// @symbiote-native/css-parser compiles it at build time (Metro's babelTransformerPath, see
+// metro-css-transformer.js) into a registerStyles() call; there's no runtime export to type.
+// Mirrors examples/react/css.d.ts and examples/angular/css.d.ts.
+declare module '*.css';
+
+// Same shape for the three optional preprocessor sources — css-parser reduces each to plain CSS
+// before compiling, so a side-effect import of one is indistinguishable downstream from a `.css`
+// one.
+declare module '*.scss';
+declare module '*.sass';
+declare module '*.less';
+declare module '*.styl';
+
+// Generic (non-literal) fallback for a `.module.css` import — used by `tsc`/`vue-tsc` outside a
+// file that already has its own generated `Card.module.css.d.ts` (see `css-dts`, wired to
+// `pretypecheck`; a real per-file `.d.ts` takes priority over this wildcard once generated). The
+// `@symbiote-native/vue/typescript-plugin` entry in tsconfig.json's `compilerOptions.plugins` gives the
+// SAME per-file literal-key typing live in the editor — plugins never load for a standalone
+// `tsc`/CI run, which is why both mechanisms exist side by side.
+declare module '*.module.css' {
+  const styles: Record<string, string>;
+  export default styles;
+}

package/templates/js/vue-tsx/index.js

@@ -0,0 +1,14 @@
+/**
+ * @format
+ *
+ * Symbiote Vue canary entry. createApp(App).mount(appName) wires the
+ * native-host seams and RN's own AppRegistry, then mounts via @symbiote-native/engine — RN's own
+ * renderer is never in the path. Same entry point as examples/vue-sfc, going through the
+ * shared AppRegistry seam like every other canary.
+ */
+
+import { createApp } from '@symbiote-native/vue/bootstrap';
+import App from './App';
+import { name as appName } from './app.json';
+
+createApp(App).mount(appName);

package/templates/js/vue-tsx/metro.config.js

@@ -0,0 +1,42 @@
+const path = require('path');
+const { getDefaultConfig, mergeConfig } = require('@react-native/metro-config');
+
+const projectRoot = __dirname;
+
+const defaultConfig = getDefaultConfig(projectRoot);
+
+/**
+ * @symbiote-native/* and @vue/runtime-core resolve as ordinary npm packages from this app's
+ * own node_modules (examples/* is a standalone npm install, decoupled from the monorepo's
+ * pnpm workspace — see pnpm-workspace.yaml). @react-native/babel-preset strips the types.
+ *
+ * @type {import('@react-native/metro-config').MetroConfig}
+ */
+const runtimeCore = path.resolve(projectRoot, 'node_modules/@vue/runtime-core');
+
+const config = {
+  // JSX is still compiled by @vue/babel-plugin-jsx via babel.config.js regardless of which
+  // transformer runs it (unlike the SFC canary, which needs a Metro transformer to compile
+  // .vue) — @symbiote-native/vue ships the standalone .css/.module.css transformer itself
+  // (same framework-agnostic path the React and Angular examples use via their own adapter's
+  // ./metro-css-parser export), so no local wiring file is needed here either.
+  transformer: {
+    babelTransformerPath: require.resolve('@symbiote-native/vue/metro-css-parser'),
+  },
+  resolver: {
+    // Teach Metro that a style file is a source file (the transformer turns it into a module).
+    // scss/sass/less/styl are optional SCSS/Sass/Less/Stylus preprocessor sources — see
+    // core/css-parser/src/preprocessors.ts.
+    sourceExts: [...defaultConfig.resolver.sourceExts, 'css', 'scss', 'sass', 'less', 'styl'],
+    extraNodeModules: {
+      // @vue/babel-plugin-jsx injects helper imports `from 'vue'`; there is no vue/runtime-dom
+      // in a native bundle, and this app never installs the `vue` package itself (only
+      // @vue/runtime-core), so the bare 'vue' specifier is aliased to the runtime-core
+      // singleton the adapter renders on (the resolver twin of the SFC transformer's
+      // 'vue'→runtime-core string rewrite).
+      vue: runtimeCore,
+    },
+  },
+};
+
+module.exports = mergeConfig(defaultConfig, config);

package/templates/js/vue-tsx/package.json.fragment.json

@@ -0,0 +1,26 @@
+{
+  "scripts": {
+    "android": "react-native run-android",
+    "android:release": "react-native run-android --mode Release",
+    "ios": "react-native run-ios",
+    "ios:release": "react-native run-ios --mode Release",
+    "lint": "eslint .",
+    "start": "react-native start",
+    "dev": "react-native start --reset-cache"
+  },
+  "dependencies": {
+    "@symbiote-native/android": "latest",
+    "@symbiote-native/vue": "latest",
+    "@symbiote-native/engine": "latest",
+    "@vue/runtime-core": "^3.5.13",
+    "react": "19.2.3",
+    "react-native": "0.86.0"
+  },
+  "devDependencies": {
+    "vue": "^3.5.38",
+    "@vue/babel-plugin-jsx": "^1.5.0",
+    "@react-native/babel-preset": "0.86.0",
+    "@react-native/metro-config": "0.86.0",
+    "@symbiote-native/css-parser": "latest"
+  }
+}

package/templates/js/vue-tsx/package.json.fragment.typescript.json

@@ -0,0 +1,11 @@
+{
+  "scripts": {
+    "pretypecheck": "css-dts .",
+    "typecheck": "vue-tsc --noEmit -p tsconfig.typecheck.json"
+  },
+  "devDependencies": {
+    "vue-tsc": "^2.2.12",
+    "@react-native/typescript-config": "0.86.0",
+    "typescript": "~6.0.0"
+  }
+}

package/templates/js/vue-tsx/tsconfig.json

@@ -0,0 +1,15 @@
+{
+  "extends": "@react-native/typescript-config",
+  "compilerOptions": {
+    "types": [],
+    // Vue's JSX is compiled by @vue/babel-plugin-jsx, never by tsc — `preserve` leaves it alone
+    // and `jsxImportSource` only tells tsc whose JSX namespace to type-check against. Both
+    // override @react-native/typescript-config's React defaults, which would otherwise type
+    // every element here as React's.
+    "jsx": "preserve",
+    "jsxImportSource": "@symbiote-native/vue",
+    "plugins": [{ "name": "@symbiote-native/css-parser/typescript-plugin" }]
+  },
+  "include": ["**/*.ts", "**/*.tsx"],
+  "exclude": ["**/node_modules", "**/Pods", "e2e"]
+}

package/templates/js/vue-tsx/tsconfig.typecheck.json

@@ -0,0 +1,10 @@
+{
+  "extends": "./tsconfig.json",
+  "comment": "vue-tsc typecheck of the app's Vue JSX (.tsx). @symbiote-native/* resolve to source (the monorepo's by-design source resolution), so this also re-checks adapter/engine source — `types: [node]` restores the runtime globals (setTimeout/process/console/queueMicrotask) the app tsconfig strips with `types: []`. e2e/ is excluded: Detox tests with jest globals, type-checked via ts-jest.",
+  "compilerOptions": {
+    "types": ["node"],
+    "jsx": "preserve",
+    "jsxFactory": "VueJsx.createElement"
+  },
+  "exclude": ["**/node_modules", "**/Pods", "e2e"]
+}

package/templates/js/vue-tsx/vue-jsx.d.ts

@@ -0,0 +1,43 @@
+// TS's JSX type-checking algorithm resolves `JSX.*` types via the configured `jsxFactory`'s OWN
+// namespace FIRST (default factory "React.createElement" → checks "React.JSX", which
+// @types/react DOES export) and only falls back to a global `JSX` namespace when that lookup
+// finds nothing. That priority order — not a declaration-merge conflict — is why a plain
+// `declare global { namespace JSX {...} }` here had no effect: TS never got past the first check.
+// The fix: point `jsxFactory` (tsconfig.typecheck.json) at a namespace React never touches
+// (`VueJsx.createElement`, declared here) so `VueJsx.JSX` fails to resolve and TS falls through
+// to the global `JSX` namespace below — which we DO control. Emit is unaffected (`"jsx": "preserve"`
+// never calls the factory; @vue/babel-plugin-jsx already does the real transform in babel.config.js
+// before React's own JSX plugin ever sees the file) — this is purely a type-checking concern.
+import type { VNode } from '@vue/runtime-core';
+
+declare global {
+  namespace VueJsx {
+    // eslint-disable-next-line @typescript-eslint/no-namespace
+    namespace JSX {
+      interface Element extends VNode {}
+      interface ElementClass {
+        $props: {};
+      }
+      interface ElementAttributesProperty {
+        $props: {};
+      }
+      interface IntrinsicElements {
+        [name: string]: any;
+      }
+      // Index signature, not just `key`: several adapter components (SafeAreaView, StatusBar,
+      // ActivityIndicator, Animated.View/ScrollView accessed off the `Animated` namespace) declare
+      // NO `props` schema at all — they forward everything through Vue's untyped `$attrs`
+      // fallthrough by design (see adapters/vue/src/components/safe-area-view.ts's own comment).
+      // `.vue` SFCs never flag this (the template compiler doesn't excess-property-check against
+      // JSX's `IntrinsicAttributes`); TSX does, since JSX attribute checking always intersects a
+      // component's `$props` with this interface. Without the index signature here, passing
+      // `testID`/`class`/etc. to any of those attrs-passthrough components is a false-positive
+      // excess-property error, not a real type mismatch — the props genuinely do forward at runtime.
+      interface IntrinsicAttributes {
+        key?: string | number | symbol;
+        [name: string]: unknown;
+      }
+    }
+  }
+  const VueJsx: { createElement: (...args: any[]) => any };
+}

package/templates/js/vue-tsx/vue-runtime-core.d.ts

@@ -0,0 +1,3 @@
+declare module 'vue' {
+  export * from '@vue/runtime-core';
+}

package/templates/layers/README.md

@@ -0,0 +1,90 @@
+# `templates/layers`
+
+Framework-agnostic optional overlays, applied on top of `native/` + `js/<framework>` by
+`--expo-modules` / `--navigation` / `--testing` / `--splash-screen` / `--slider` / one `--<id>`
+flag per `EXPO_PACKAGE_LAYERS` entry (`src/expo-package-layers.ts`).
+
+`expo-modules` is dependency-only, same regardless of `--framework` (diffing
+`examples/expo-react` against `examples/react`, and checking `packages/navigation`'s
+`peerDependencies`, showed a dependency-only addition with no framework-specific file content and
+no native (`ios/`/`android/`) changes — see `packages/cli/README.md`'s "Design
+decisions" section). It carries ONLY the core autolinking bits — `expo` and
+`@symbiote-native/expo-modules-link` — never a specific Expo-backed package (2026-09-18): it used
+to bundle all 21 `@symbiote-native/<expo-wrapper>` packages unconditionally, so picking any ONE of
+them (or none at all) always installed every other one too. Each wrapper now has its OWN
+`templates/layers/<id>/package.json.fragment.json` (`application`, `battery`, `brightness`,
+`cellular`, `clipboard`, `crypto`, `device`, `haptics`, `keep-awake`, `local-auth`,
+`localization`, `network`, `screen-orientation`, `secure-store`, `sensors`, `sharing`, `sms`,
+`standard-web-crypto`, `store-review`, `system-ui`, `tracking-transparency`, `web-browser`) —
+same dependency-only shape as `slider`, registered once in `EXPO_PACKAGE_LAYERS` so cli.ts's
+`--<id>` flag, prompts.ts's multiselect option, and `detect-added-layers.ts`'s marker all derive
+from that ONE table instead of 21 hand-written near-duplicates. `@symbiote-native/expo-modules-
+link` (the "Expo-modules autolinking" feature) is never a SEPARATE explicit tick once one of these
+21 is picked — it doesn't make sense to ask for autolinking twice, so `resolveFeatures` /
+`resolveAddLayers` in `src/prompts.ts` fold `hasExpoModules` to true (or append the `expo-modules`
+layer) automatically. (An earlier pass here also unconditionally added the raw npm `expo-linking`
+package — reverted, 2026-09-18: checking the real installed `expo-battery`/`expo-web-browser`/
+`expo-sharing`/`expo-store-review`/`expo-local-authentication`/`expo`/`expo-modules-autolinking`
+`package.json`s found NONE of them depend on it. Nothing in this codebase's dependency graph
+actually needs it, so it isn't shipped.)
+
+`navigation` is NOT dependency-only (2026-09-15): besides `package.json.fragment.json`
+(`@symbiote-native/navigation`, declaring every adapter as an optional peer itself), it carries an
+`app/<framework>` subtree — a 2-screen `Stack` demo (Menu → Details) that OVERWRITES the base
+`js/<framework>` App file, so `--navigation` demonstrates itself instead of silently doing
+nothing visible. `src/generate.ts` renders `app/<framework>` as a separate call from the
+package.json merge (see its own comment) — recursively copying the whole `navigation/` directory
+would land every framework's `app/` folder on the generated root instead of just the selected
+one.
+
+`splash-screen` (2026-09-17) is the first layer that DOES carry native changes: a `native/`
+subtree mirroring `templates/native`'s own layout (`native/android/...`, `native/ios/...`),
+overlaid the same way `renderTemplate` already overlays `navigation`'s `app/<framework>` — no
+`@expo/config-plugins` needed after all, because only 4 files actually require two variants.
+`react-native-bootsplash` (vendored source checked via `/vendor`) has no setup codemod of its own
+— its CLI only generates image assets, never touches app source — so both variants are hand-authored
+here. The split is narrower than it looks: `MainActivity.kt`'s `RNBootSplash.init(...)` call and
+`AppDelegate.swift`'s `RNBootSplash.initWithStoryboard(...)` call are Kotlin/Swift references to
+the plugin's public API (hard compile error without the dependency), and `styles.xml`'s
+`BootTheme` extends the plugin's own `Theme.BootSplash` (an aapt resource-linking error without
+its AAR) — so those 3 files plus the one-line `AndroidManifest.xml` activity theme attribute are
+the ONLY things gated. `colors.xml`, the `drawable-*/bootsplash_logo.png` assets,
+`BootSplash.storyboard`, `Colors.xcassets`, `Images.xcassets`, `Info.plist`'s
+`UILaunchStoryboardName`, and the `.xcodeproj/project.pbxproj` wiring all stay in the BASE
+template unconditionally — none of them reference anything from the plugin (the storyboard only
+draws from our own asset catalog), so leaving them in place when the option is off just means an
+unused-but-harmless launch-screen asset, not a build break.
+
+`testing` (2026-09-17) is also NOT dependency-only: besides the per-framework
+`package.json.fragment.json` (`detox` + `jest` + `ts-jest` + the TypeScript floor, since e2e is a
+separate TS project regardless of `--javascript`), it ships `detox.config.js` at the app root and
+an `e2e/` directory (`jest.config.js`, `tsconfig.json`, `setup.ts`, `smoke.test.ts`). The fragment
+is picked from `fragment/<base|angular>/package.json.fragment.json` — angular's `e2e:build:*`
+scripts need an `ngc` pass before Detox builds the native binary, every other framework shares
+`fragment/base`. Both live in their OWN subdirectory rather than as
+`base.package.json.fragment.json` / `angular.package.json.fragment.json` side by side, because
+`renderTemplate`'s package.json merge branch derives the destination filename from the SOURCE
+file's own basename, not from the `dest` path passed to it — two source files with different
+basenames merging into the same `package.json.fragment.json` silently land as two different
+files instead (caught via smoke test: the merged scripts were missing entirely). The one smoke
+test (`e2e/smoke.test.ts`) asserts the welcome text renders through Fabric — deliberately generic
+so it passes whether or not `--navigation` is also selected (the nav layer's Menu screen renders
+the same line).
+
+| Layer | Adds |
+|---|---|
+| `expo-modules` | `expo` + `@symbiote-native/expo-modules-link` — the core autolinking wiring, no specific Expo-backed package. |
+| `application` / `battery` / `brightness` / `cellular` / `clipboard` / `crypto` / `device` / `haptics` / `keep-awake` / `local-auth` / `localization` / `network` / `screen-orientation` / `secure-store` / `sensors` / `sharing` / `sms` / `standard-web-crypto` / `store-review` / `system-ui` / `tracking-transparency` / `web-browser` | Its own `@symbiote-native/<id>` dependency only — same dependency-only shape as `slider`, registered in `EXPO_PACKAGE_LAYERS`. Implies `expo-modules` (see above). |
+| `navigation` | `@symbiote-native/navigation` + a per-framework `app/<dir>/App.<ext>` (Stack + Menu/Details screens) overwriting the base App. |
+| `testing` | `detox` + `jest`/`ts-jest` + a generic `e2e/smoke.test.ts` + `detox.config.js`, always TypeScript regardless of `--javascript`. |
+| `splash-screen` | `@symbiote-native/splash-screen` + the 4 native files (`MainActivity.kt`, `AndroidManifest.xml`, `styles.xml`, `AppDelegate.swift`) that wire `react-native-bootsplash`, plus a JS-side text-splice (`utils/apply-splash-screen-hide.ts`) wiring the framework's own `hide()` call into the App entry — the native side alone would freeze every scaffold on the splash screen forever, since nothing ever tells it to hide. |
+
+Every `@symbiote-native/*` version in every fragment (base and layer) is pinned to `"latest"`,
+not a literal semver range — the monorepo's packages publish independently and a hand-copied
+literal drifts out of sync with peer requirements almost immediately (measured 2026-09-15:
+`templates/js/angular`'s `@symbiote-native/engine` pin was `^0.1.7` against `@symbiote-native/
+navigation@4.0.1`'s `^0.5.0` peer, and `expo-modules`'s `@symbiote-native/application@2.0.0`
+wants `@symbiote-native/angular@^2.0.0` while the angular fragment pinned `^0.6.1` — two separate
+`npm install ERESOLVE` failures from the same root cause). Third-party dependencies (`react`,
+`react-native`, `vue`, `svelte`, `solid-js`, `@angular/*`, `expo`, …) stay pinned as before —
+only the `@symbiote-native/*` scope moved to `latest`.

package/templates/layers/application/package.json.fragment.json

@@ -0,0 +1,5 @@
+{
+  "dependencies": {
+    "@symbiote-native/application": "latest"
+  }
+}

package/templates/layers/battery/package.json.fragment.json

@@ -0,0 +1,5 @@
+{
+  "dependencies": {
+    "@symbiote-native/battery": "latest"
+  }
+}

package/templates/layers/brightness/package.json.fragment.json

@@ -0,0 +1,5 @@
+{
+  "dependencies": {
+    "@symbiote-native/brightness": "latest"
+  }
+}

package/templates/layers/cellular/package.json.fragment.json

@@ -0,0 +1,5 @@
+{
+  "dependencies": {
+    "@symbiote-native/cellular": "latest"
+  }
+}

package/templates/layers/clipboard/package.json.fragment.json

@@ -0,0 +1,5 @@
+{
+  "dependencies": {
+    "@symbiote-native/clipboard": "latest"
+  }
+}

package/templates/layers/crypto/package.json.fragment.json

@@ -0,0 +1,5 @@
+{
+  "dependencies": {
+    "@symbiote-native/crypto": "latest"
+  }
+}

package/templates/layers/device/package.json.fragment.json

@@ -0,0 +1,5 @@
+{
+  "dependencies": {
+    "@symbiote-native/device": "latest"
+  }
+}

package/templates/layers/expo-modules/ios/Canary/Info.plist

@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+	<key>CADisableMinimumFrameDurationOnPhone</key>
+	<true/>
+	<key>CFBundleDevelopmentRegion</key>
+	<string>en</string>
+	<key>CFBundleDisplayName</key>
+	<string>Canary</string>
+	<key>CFBundleExecutable</key>
+	<string>$(EXECUTABLE_NAME)</string>
+	<key>CFBundleIdentifier</key>
+	<string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>
+	<key>CFBundleInfoDictionaryVersion</key>
+	<string>6.0</string>
+	<key>CFBundleName</key>
+	<string>$(PRODUCT_NAME)</string>
+	<key>CFBundlePackageType</key>
+	<string>APPL</string>
+	<key>CFBundleShortVersionString</key>
+	<string>$(MARKETING_VERSION)</string>
+	<key>CFBundleSignature</key>
+	<string>????</string>
+	<key>CFBundleVersion</key>
+	<string>$(CURRENT_PROJECT_VERSION)</string>
+	<key>LSRequiresIPhoneOS</key>
+	<true/>
+	<key>NSAppTransportSecurity</key>
+	<dict>
+		<key>NSAllowsArbitraryLoads</key>
+		<false/>
+		<key>NSAllowsLocalNetworking</key>
+		<true/>
+	</dict>
+	<key>NSLocationWhenInUseUsageDescription</key>
+	<string></string>
+	<key>RCTNewArchEnabled</key>
+	<true/>
+	<key>UILaunchStoryboardName</key>
+	<string>BootSplash</string>
+	<key>UIRequiredDeviceCapabilities</key>
+	<array>
+		<string>arm64</string>
+	</array>
+	<key>UISupportedInterfaceOrientations</key>
+	<array>
+		<string>UIInterfaceOrientationPortrait</string>
+	</array>
+	<key>UISupportedInterfaceOrientations~ipad</key>
+	<array>
+		<string>UIInterfaceOrientationLandscapeLeft</string>
+		<string>UIInterfaceOrientationLandscapeRight</string>
+		<string>UIInterfaceOrientationPortrait</string>
+		<string>UIInterfaceOrientationPortraitUpsideDown</string>
+	</array>
+	<key>UIViewControllerBasedStatusBarAppearance</key>
+	<false/>
+	<key>NSFaceIDUsageDescription</key>
+	<string>This app uses Face ID to authenticate you.</string>
+	<key>NSMotionUsageDescription</key>
+	<string>This app uses motion sensor data.</string>
+	<key>NSUserTrackingUsageDescription</key>
+	<string>This app tracks your activity across other apps and websites.</string>
+</dict>
+</plist>

package/templates/layers/expo-modules/package.json.fragment.json

@@ -0,0 +1,9 @@
+{
+  "scripts": {
+    "postinstall": "symbiote-expo-link"
+  },
+  "dependencies": {
+    "expo": "57.0.14",
+    "@symbiote-native/expo-modules-link": "latest"
+  }
+}