theslopmachine 0.6.2 → 0.7.0

package/assets/slopmachine/scaffold-playbooks/platform-family-matrix.md

@@ -0,0 +1,79 @@
+# Platform Family Scaffold Matrix
+
+Use this matrix to choose a real scaffold family for Android, iOS, and desktop requests.
+Do **not** collapse these into one generic `mobile` or `desktop` bucket: the bootstrap path, Linux-proof boundary, and wrapper-script meaning differ too much across families.
+
+## Family selection rule
+
+1. follow the prompt and existing repo first
+2. choose a concrete family, not a generic platform bucket
+3. apply that family's official/bootstrap path and proof boundary honestly
+4. keep `docker compose up --build` and `./run_tests.sh` real for every family
+5. treat `./run_app.sh` as an optional helper only
+
+## Current defaults vs backlog
+
+- **current default families**
+  - `android-java-views`
+  - `ios-expo-react-native`
+  - `desktop-electron-vite`
+- **current opt-in families when the prompt or repo clearly requires them**
+  - `android-kotlin-views`
+  - `ios-native-swift` → see [`ios-native-swift.md`](./ios-native-swift.md)
+- **current non-default families with a concrete playbook**
+  - `android-kotlin-compose` → see [`android-kotlin-compose.md`](./android-kotlin-compose.md)
+  - `ios-native-objective-c` → see [`ios-native-objective-c.md`](./ios-native-objective-c.md)
+- **future / non-default backlog families**
+  - none
+
+## Android families
+
+| Family | Use when | Official/bootstrap/init path | Safe default versions/config direction | What `docker compose up --build` means | What `./run_tests.sh` means | `./run_app.sh` helpful? | Honest Linux proof | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `android-java-views` | prompt says native Android and does not require Kotlin or Compose | official Android Studio phone/tablet **Empty Views Activity** in **Java**; for automation, commit the equivalent Gradle/AGP skeleton rather than pretending there is a stable non-interactive official CLI | AGP `8.5.x`, Gradle `8.7`, Java `17`, `compileSdk = 34`, `targetSdk = 34`, `minSdk = 29`, XML Views | containerized Gradle build path that at least lints and assembles a debug APK or equivalent artifact; no emulator claims | containerized lint + assemble + JVM/Robolectric tests + schema verification when Room exists | **yes**; useful to normalize `JAVA_HOME` / `ANDROID_HOME`, build a debug APK, and optionally install via `adb` when available | a real APK/debug artifact is produced and JVM tests pass on Linux; no device/emulator proof claimed | **current default, experimentally verified** |
+| `android-kotlin-views` | prompt or repo explicitly requires Kotlin but not Compose | official Android Studio **Empty Views Activity** in **Kotlin** | same Android baseline as Java Views, but pin one AGP-compatible Kotlin plugin version and keep XML Views unless prompt says otherwise | same containerized assemble/lint artifact path as Java Views | same broad path as Java Views, but using Kotlin sources | **yes**; same value as Java family | Kotlin Android app assembles on Linux and passes JVM/Robolectric proof without pretending emulator coverage | **current opt-in** |
+| `android-kotlin-compose` | prompt explicitly requires Compose or existing repo already uses Compose | official Android Studio **Empty Activity** / Compose-first app template in **Kotlin** | keep AGP `8.5.x`, Gradle `8.7`, Java `17`, SDK levels aligned with other Android families; pin one AGP-compatible Kotlin version and one tested stable Compose BOM; keep Material 3 defaults | containerized Compose-capable build path that assembles the app and emits the artifact; do not pretend `docker compose` proves interactive device UX | lint + assemble + JVM/unit coverage that is honest on Linux; only include instrumentation/device checks when a real device/emulator path exists outside the portable baseline | **yes**; useful for local build/install convenience | Compose code now assembles on Linux, `docker compose up --build` reaches artifact-serving healthy state, and containerized lint/JVM tests pass; still no emulator/device proof | **current opt-in, experimentally verified** |
+
+## iOS families
+
+| Family | Use when | Official/bootstrap/init path | Safe default versions/config direction | What `docker compose up --build` means | What `./run_tests.sh` means | `./run_app.sh` helpful? | Honest Linux proof | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `ios-expo-react-native` | work is iOS-targeted but running from Linux, and the prompt does not require a native-only iOS codebase | `npx create-expo-app@latest <app> --template blank-typescript` | Expo-managed workflow, TypeScript, current stable Expo SDK, Jest, React Native Testing Library; keep native modules minimal until a real native requirement exists | containerized Expo-oriented baseline such as dependency install plus Expo dev-server startup and/or `expo export --platform ios`; this proves shared RN wiring, not native iOS runtime | `tsc --noEmit`, `jest --runInBand`, and `expo export --platform ios` or equivalent portable iOS build-shape checks | **yes**; useful to wrap `npx expo start` and print the closest device-adjacent flow | shared JS/TS code, tests, and iOS-targeted Expo export pass on Linux; no Xcode, CocoaPods, simulator, signing, or archive proof claimed | **current default on Linux** |
+| `ios-native-swift` | prompt explicitly requires native Swift iOS or repo already is a native Swift iOS app | official Xcode **App** template in **Swift**; UIKit vs SwiftUI follows prompt/repo; detailed rules live in [`ios-native-swift.md`](./ios-native-swift.md) | treat Xcode/iOS SDK selection as a macOS checkpoint; on Linux, only portable SwiftPM/shared-module defaults may be pinned and tested honestly | on Linux, this means a real **partial-proof** container path: portable SwiftPM build/test when such modules exist, plus static repo-shape validation; it must **not** claim `.app`, simulator, or archive proof | portable Swift package tests, build/lint when available, and static validation only; if there are no portable modules, the script must say native proof requires macOS/Xcode rather than faking success | **usually no** on Linux; only add it if it cleanly hands off to a documented macOS/Xcode flow | shared SwiftPM modules and static Xcode-shape validation are experimentally verified on Linux; the actual iOS app target remains unproven until a real macOS/Xcode checkpoint | **current opt-in, experimentally verified partial-proof** |
+| `ios-native-objective-c` | prompt explicitly requires native Objective-C iOS or repo already is Objective-C | official Xcode **App** template in **Objective-C**; detailed Linux-boundary rules live in [`ios-native-objective-c.md`](./ios-native-objective-c.md) | same macOS/Xcode dependency as native Swift; do not invent a Linux-first default beyond portable shared modules if they exist | on Linux, this means a real verification/support container for static checks and any portable modules only; never pretend it builds or runs the native iOS app | static validation plus any portable shared-module tests only; if there are no portable modules, keep this as a real static gate rather than fake native success | **usually no** on Linux; only add it when it is an honest macOS/Xcode handoff helper | static Xcode-project validation is experimentally verified on Linux; native iOS app proof is still blocked on macOS/Xcode | **current explicit opt-in, experimentally verified partial-proof** |
+
+### iOS honesty boundary
+
+For native Swift and Objective-C families, Linux is a **partial-proof** environment only.
+Honest proof on Linux does **not** include Xcode build success, CocoaPods integration quality, simulator behavior, signing, archives, or App Store readiness.
+
+## Desktop families
+
+| Family | Use when | Official/bootstrap/init path | Safe default versions/config direction | What `docker compose up --build` means | What `./run_tests.sh` means | `./run_app.sh` helpful? | Honest Linux proof | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `desktop-electron-vite` | prompt says desktop app and does not require another desktop shell | `npm create @quick-start/electron@latest <app> -- --template vanilla-ts`, then harden/pin the generated baseline | Electron + Vite + TypeScript, repo-tested pinned versions, `contextIsolation` on, no unnecessary `nodeIntegration`, explicit preload bridge, Linux packaging kept to `electron-builder --linux dir` at scaffold time | containerized build/package/smoke gate: install deps, build renderer/main, create unpacked Linux output, and run one headless smoke under Xvfb/Playwright or equivalent | unit/renderer/main tests plus the headless Electron smoke/build check | **yes**; useful for host-side launch convenience | an unpacked Linux Electron build launches a real window process headlessly and passes smoke/build checks | **current default, experimentally verified** |
+| `desktop-tauri` | prompt explicitly requires Tauri, Rust footprint, or existing repo already uses Tauri | official Tauri bootstrap such as `npm create tauri-app@latest <app>` | Tauri `2.x`, Rust stable, TS frontend by default, Linux WebView/runtime dependencies documented explicitly; do not default to Tauri when prompt is open | containerized Rust + frontend build path that emits a Linux binary/bundle when dependencies permit; keep claims limited to what the container actually proves | `cargo test` plus frontend tests and static checks such as clippy/typecheck as appropriate | **yes** when host Rust/WebView deps are present | Linux now proves a Tauri build/bundle/startup baseline honestly through Docker, but this remains an explicit opt-in family rather than the generic default | **current non-default, experimentally verified** |
+
+## Wrapper meaning by family
+
+- `docker compose up --build`
+  - always means a **real** containerized baseline path
+  - for Android: build/lint/test/artifact proof without pretending emulator runtime
+  - for Expo iOS on Linux: shared-code/runtime-export proof without pretending Xcode proof
+  - for native iOS families: only partial Linux proof; for Swift, follow [`ios-native-swift.md`](./ios-native-swift.md) and do not choose it as a default; for Objective-C, follow [`ios-native-objective-c.md`](./ios-native-objective-c.md) and keep it explicit opt-in only
+  - for desktop: build/package/headless-smoke proof rather than pretending a container is the final end-user desktop runtime
+- `./run_tests.sh`
+  - always means the broad portable verification path
+  - should be the command an owner can run on a clean Linux machine with Docker
+  - must never silently downgrade into `NO-SOURCE`, placeholder, or documentation-only success
+- `./run_app.sh`
+  - useful for Android, Expo, Electron, and often Tauri
+  - usually **not** useful for native iOS-on-Linux families unless it is explicitly a macOS/Xcode handoff helper
+  - never replaces the Docker baseline contract
+
+## Decision summary
+
+- when the prompt says **Android**, split into `android-java-views`, `android-kotlin-views`, or `android-kotlin-compose` instead of one generic native-mobile bucket
+- when the prompt says **iOS on Linux**, default to `ios-expo-react-native`; only choose native Swift or Objective-C families when the prompt explicitly requires them and the proof boundary is documented honestly; both native families now have experimentally verified partial-proof Linux baselines
+- when the prompt says **desktop**, default to `desktop-electron-vite`; treat Tauri as explicit opt-in, and currently only partial-lab-state rather than fully verified
+- if a family cannot produce honest Linux proof for the requested baseline, keep it out of the default path and label it backlog or exception-driven

package/assets/slopmachine/scaffold-playbooks/selection-matrix.md

@@ -0,0 +1,72 @@
+# Scaffold Playbook Selection Matrix
+
+Use this as owner-side reference when composing the scaffold request.
+
+## Selection order
+
+1. follow the original prompt and existing repo first
+2. read `docker-shared-contract.md`
+3. if the stack is not directly covered, read `generic-unknown-tech-guide.md`
+4. choose the primary platform family using `platform-family-matrix.md`
+5. choose the frontend family using `frontend-family-matrix.md` when a frontend surface exists
+6. choose the backend family and database module using `backend-family-matrix.md` and `database-module-matrix.md` when a backend surface exists
+7. choose the matching concrete scaffold playbook for the selected family default
+8. add any scaffold-time overlays from `overlay-module-matrix.md`
+9. choose the framework bootstrap path that best matches the prompt
+10. restate the relevant directives in the developer prompt instead of passing external file paths
+
+## Shared references
+
+- shared Docker contract:
+  - `docker-shared-contract.md`
+- generic fallback guide:
+  - `generic-unknown-tech-guide.md`
+- family matrices:
+  - `frontend-family-matrix.md`
+  - `backend-family-matrix.md`
+  - `database-module-matrix.md`
+  - `platform-family-matrix.md`
+  - `overlay-module-matrix.md`
+
+## Primary playbooks
+
+- open-ended web product with no narrower family already selected:
+  - `web-default.md`
+  - for explicit frontend families, prefer `frontend-baseline.md`, `vue-vite-default.md`, or `angular-default.md` as appropriate
+  - for explicit backend families, prefer `backend-baseline.md`, `fastapi-default.md`, `spring-boot-default.md`, `django-default.md`, `laravel-default.md`, or `go-chi-default.md` as appropriate
+  - for explicit Laravel server-driven UI work, prefer `livewire-default.md`
+- native Android request:
+  - `android-native-java.md` (current experimentally verified default)
+  - `android-kotlin-views.md` when the prompt explicitly requires Kotlin + Views
+  - `android-kotlin-compose.md` when the prompt explicitly requires Compose; now experimentally verified
+  - if the prompt explicitly requires Kotlin or Compose, keep the Android runtime/test contract but adapt the language/UI defaults accordingly
+- cross-platform mobile request with no native-only requirement:
+  - `expo-react-native-default.md`
+- desktop app request:
+  - `electron-vite-default.md` (current experimentally verified default)
+  - `tauri-default.md` only when the prompt explicitly requires Tauri; experimentally verified but still explicit opt-in only
+- iOS-targeted work on Linux:
+  - `ios-linux-portable.md`
+  - if the prompt explicitly requires native Swift, use `ios-native-swift.md` (experimentally verified partial-proof baseline)
+  - if the prompt explicitly requires native Objective-C, use `ios-native-objective-c.md` (experimentally verified partial-proof baseline)
+
+## Framework bootstrap guidance
+
+- when the prompt explicitly names a framework with a strong official starter, use that framework's official or best-known bootstrap path and then apply the matching playbook contract
+- examples:
+  - Next.js, Nuxt, Laravel, Rails, Django, Expo, Electron
+- when the prompt names only a language or only a placeholder label, resolve that through the corresponding family matrix before picking a bootstrap command
+- when the prompt leaves the framework open, use the safest package default for that platform family rather than inventing a custom starter
+
+## Runtime contract reminders
+
+- web always requires working `docker compose up --build`
+- web always requires containerized `./run_tests.sh`
+- Android, mobile, iOS, and desktop projects also require working `docker compose up --build` plus containerized `./run_tests.sh`
+- for non-web app platforms, the Docker runtime command may start a meaningful build, artifact, preview, or support environment rather than pretending to be native runtime proof
+- `./run_app.sh` may still exist for non-web local convenience, but it does not replace the Docker-based baseline contract
+
+## Scaffold stop rule
+
+Stop scaffold once the baseline stack, required technologies, runtime contract, wrapper scripts, minimal real tests, and honest README are in place.
+Do not start prompt-specific feature implementation during scaffold unless the runtime baseline genuinely depends on it.

package/assets/slopmachine/scaffold-playbooks/spring-boot-default.md

@@ -0,0 +1,182 @@
+# Spring Boot Default Scaffold Playbook
+
+Use this playbook when the prompt explicitly asks for Spring Boot, Java backend conventions, or a JVM-first backend baseline.
+
+## Goal
+
+Create a Spring Boot scaffold baseline that:
+
+- starts from the official Spring Initializr bootstrap path
+- keeps defaults pinned and boring
+- proves one real API plus one real persistence path
+- exposes `docker compose up --build` as the runtime contract
+- exposes `./run_tests.sh` as the broad containerized verification path
+- stays baseline-only and honest about exclusions
+
+Verified lab: `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/spring-boot-baseline`
+
+## Chosen baseline defaults
+
+- Spring Boot `3.5.13`
+- Java `21`
+- Maven Wrapper `3.9.14`
+- dependencies: `web`, `actuator`, `data-jpa`, `validation`, `h2`
+- database pattern: file-backed H2 stored in Docker-managed volumes
+
+Why these defaults:
+
+- Spring Initializr is the official bootstrap path and yields the wrapper, parent BOM, and baseline Maven layout cleanly
+- Spring Boot `3.5.x` is the safer practical line than jumping straight to Boot `4.x` for a neutral baseline
+- Java `21` is a current LTS choice with wide container availability
+- H2 file mode gives real persistence without introducing credentials or a second infrastructure service
+
+## Official bootstrap command
+
+Use the official starter generator, then adapt only what is needed for Docker, DB wiring, tests, and README honesty:
+
+```bash
+curl -fsSL "https://start.spring.io/starter.zip?type=maven-project&language=java&bootVersion=3.5.13&baseDir=spring-boot-baseline&groupId=com.eaglepoint&artifactId=spring-boot-baseline&name=spring-boot-baseline&description=Verified%20Spring%20Boot%20baseline%20lab&packageName=com.eaglepoint.springbaseline&packaging=jar&javaVersion=21&dependencies=web,actuator,data-jpa,h2,validation" -o /tmp/spring-boot-baseline.zip
+unzip -q /tmp/spring-boot-baseline.zip -d .
+```
+
+## Safe config / database pattern
+
+- do not require `.env`
+- import optional runtime config from `/runtime/config/application-runtime.properties`
+- generate that file at container startup and before containerized tests
+- point Spring Data at `jdbc:h2:file:/runtime/db/spring-boot-baseline...`
+- keep runtime config and DB files in named Docker volumes
+- expose only the app port to loopback with a random host port
+
+This is the recommended local-only baseline when the prompt does not require Postgres/MySQL yet.
+
+## Docker / Compose pattern
+
+- `compose.yaml` with one `app` service and one `test` service behind the `test` profile
+- multi-stage Dockerfile: Maven test/build stages plus a smaller runtime stage
+- real app healthcheck against `http://127.0.0.1:8080/actuator/health`
+- host port binding: `127.0.0.1::8080`
+- named volumes for runtime config and file-backed H2 state
+
+## Minimum API surface
+
+At scaffold time include at least:
+
+- `GET /health` proving app boot and DB query success
+- `POST /items` creating one persisted record
+- `GET /items` listing persisted records
+
+This is enough to prove API routing, JSON handling, persistence, and Docker readiness without pretending the app is product-ready.
+
+## Minimum test floor
+
+- `./run_tests.sh` must start the app container, wait for health, and smoke the real routes with `curl`
+- the test container must run `./mvnw -q verify`
+- JUnit tests should use `@SpringBootTest(webEnvironment = RANDOM_PORT)` or equivalent so HTTP and DB wiring are both exercised
+
+## README requirements
+
+`README.md` must explicitly state:
+
+- that the scaffold is baseline-only
+- the pinned Spring Boot / Java / Maven defaults
+- required runtime command: `docker compose up --build`
+- required broad test command: `./run_tests.sh`
+- how the runtime config file is generated without `.env`
+- why H2 file mode is the chosen default database pattern
+- what is intentionally excluded
+
+## Verification commands actually run
+
+Experimentally verified: **yes**.
+
+Commands run in `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/spring-boot-baseline`:
+
+```bash
+docker compose build
+docker compose up --build -d && docker compose ps && docker compose port app 8080
+python3 - <<'PY'
+import json, time, urllib.request
+base = 'http://127.0.0.1:32785'
+last_error = None
+for _ in range(60):
+    try:
+        with urllib.request.urlopen(base + '/health', timeout=5) as response:
+            payload = json.load(response)
+        if payload.get('status') == 'ok' and payload.get('database') == 'ok':
+            print('HEALTH', json.dumps(payload, separators=(',', ':')))
+            break
+    except Exception as exc:
+        last_error = exc
+        time.sleep(2)
+else:
+    raise SystemExit(f'Health endpoint never became ready: {last_error}')
+
+req = urllib.request.Request(base + '/items', data=b'{"name":"manual-smoke-item"}', headers={'Content-Type': 'application/json'}, method='POST')
+with urllib.request.urlopen(req, timeout=5) as response:
+    created = json.load(response)
+print('CREATE', json.dumps(created, separators=(',', ':')))
+with urllib.request.urlopen(base + '/items', timeout=5) as response:
+    items = json.load(response)
+print('LIST', json.dumps(items, separators=(',', ':')))
+PY
+docker compose down --volumes --remove-orphans
+./run_tests.sh
+python3 - <<'PY'
+import json
+import signal
+import subprocess
+import time
+import urllib.request
+
+cwd = '/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/spring-boot-baseline'
+proc = subprocess.Popen(['docker', 'compose', 'up', '--build'], cwd=cwd)
+error = None
+try:
+    deadline = time.time() + 240
+    while time.time() < deadline:
+        try:
+            port_output = subprocess.check_output(['docker', 'compose', 'port', 'app', '8080'], cwd=cwd, stderr=subprocess.DEVNULL, text=True).strip()
+            if port_output:
+                host, port = port_output.rsplit(':', 1)
+                base_url = f'http://127.0.0.1:{port}'
+                with urllib.request.urlopen(base_url + '/health', timeout=3) as response:
+                    payload = json.load(response)
+                if payload.get('status') == 'ok' and payload.get('database') == 'ok':
+                    print(f'interactive compose reached ready health at {base_url}')
+                    break
+        except Exception as exc:
+            error = exc
+        time.sleep(2)
+    else:
+        raise RuntimeError(f'interactive docker compose up --build never reached readiness: {error}')
+finally:
+    proc.send_signal(signal.SIGINT)
+    try:
+        proc.wait(timeout=30)
+    except subprocess.TimeoutExpired:
+        proc.kill()
+        proc.wait(timeout=30)
+    subprocess.run(['docker', 'compose', 'down', '--volumes', '--remove-orphans'], cwd=cwd, check=True)
+PY
+docker compose --profile test run --rm test sh -lc 'sh /workspace/scripts/bootstrap_config.sh && ./mvnw -U test'
+docker compose down --volumes --remove-orphans
+```
+
+Observed results:
+
+- `docker compose up --build -d` published the app on `127.0.0.1:32785`
+- smoke verification returned healthy JSON plus a persisted `manual-smoke-item`
+- `./run_tests.sh` passed and printed `Spring Boot baseline smoke and container tests passed at http://127.0.0.1:32787`
+- interactive `docker compose up --build` reached ready health at `http://127.0.0.1:32789`
+- `docker compose --profile test run --rm test ... ./mvnw -U test` reported `Tests run: 2, Failures: 0, Errors: 0, Skipped: 0` and `BUILD SUCCESS`
+
+## Acceptance checklist
+
+Baseline is acceptable when:
+
+- `docker compose up --build` works
+- `./run_tests.sh` works
+- a real API route and a real persistence route are verified
+- the Docker path does not require `.env`
+- the README is honest about scope and exclusions

package/assets/slopmachine/scaffold-playbooks/tauri-default.md

@@ -0,0 +1,80 @@
+# Tauri Default Scaffold Playbook
+
+Use this playbook only when the prompt explicitly requires Tauri or the existing repo is already Tauri-based.
+
+## Current status
+
+This family is now **experimentally verified** for an honest Linux Docker baseline.
+
+Verified lab:
+
+- `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/tauri-baseline`
+
+## What was achieved in the verified lab
+
+The verified lab now proves all of the following:
+
+- Tauri + Vite + TypeScript scaffold exists
+- Rust shell under `src-tauri/` exists
+- Dockerfile and Compose report-service strategy exist
+- `run_tests.sh` exists
+- built frontend assets exist under `dist/`
+- verification helper scripts exist under `.docker/`
+- README documents a plausible Linux Docker verification boundary
+- `docker compose up --build --wait` reaches a stable healthy report service
+- containerized `./run_tests.sh` passes
+- a Linux `.deb` bundle is generated and preserved under the verified artifact path
+- the packaged Tauri binary passes the documented headless smoke path
+
+## Safe default stack
+
+- Tauri `2.x`
+- Vite `8.x`
+- TypeScript `6.x`
+- Rust stable compatible with the chosen Tauri version
+
+## Runtime contract
+
+- required Docker command: `docker compose up --build`
+- required broad test command: `./run_tests.sh`
+- both are now confirmed working in the verified lab
+
+## Intended Docker strategy
+
+This family should follow the desktop shared contract with a Tauri-specific interpretation:
+
+1. build frontend assets inside Docker
+2. compile the Rust/Tauri shell inside Docker
+3. produce a meaningful Linux-side artifact or bundle
+4. run one honest Linux smoke/proof path if feasible
+5. converge Compose to a stable report/support service rather than a one-shot exited container
+
+## Honest Linux proof boundary
+
+For the verified Linux baseline, Docker honestly proves only:
+
+- Tauri frontend builds
+- Rust shell compiles
+- Linux-side bundle/build path works
+- any documented smoke path actually runs
+
+It should **not** claim full cross-platform desktop UX proof outside Linux.
+
+## Verified rerun evidence
+
+The successful rerun established these concrete facts:
+
+- the multi-stage Docker build completed end-to-end
+- `npm run test:unit` passed
+- `npx tauri build --bundles deb --ci` passed
+- `cargo test --release --manifest-path src-tauri/Cargo.toml` passed
+- the headless smoke path passed under `dbus-run-session` + `Xvfb`
+- verification artifacts were copied out of the cache-mounted build target into `.verified/`
+- the final Compose service reached `Healthy`
+- `./run_tests.sh` returned a verified summary endpoint
+
+## Guidance
+
+- treat Tauri as explicit opt-in only
+- do not auto-select it for open-ended desktop work yet because Electron remains the lighter generic default
+- it is now safe to treat this family as experimentally verified rather than partial

package/assets/slopmachine/scaffold-playbooks/vue-vite-default.md

@@ -0,0 +1,162 @@
+# Vue Vite Default Scaffold Playbook
+
+Use this when the prompt explicitly wants a Vue frontend on top of Vite and does not already require a broader runtime such as Nuxt.
+
+## Decision summary
+
+- **chosen default:** Vue 3 + Vite + TypeScript via `create-vue`
+- **why:** official Vue-owned bootstrap path, easy to keep baseline-only, and straightforward to verify with Docker plus Vitest component tests
+- **verified runtime:** `docker compose up --build`
+- **verified broad test path:** `./run_tests.sh`
+- **experimentally verified lab:** `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/vue-vite-baseline`
+
+## Official bootstrap matrix
+
+| Stack | Official/bootstrap path | Good fit | Why not the default prototype here |
+| --- | --- | --- | --- |
+| Vue + Vite via `create-vue` | `npm create vue@latest <project-name> -- --ts --vitest --eslint --bare` | Best Vue-first SPA baseline with first-party feature flags | Chosen default |
+| Vite Vue TypeScript template | `npm create vite@latest <project-name> -- --template vue-ts` | Good fallback when only a raw Vue/Vite template is needed | Slightly less aligned with Vue's recommended starter path |
+| Nuxt | `npm exec nuxi@latest init <project-name>` | Best when SSR, file routing, or server APIs are required | Larger runtime model than a baseline SPA needs |
+
+## Evidence basis for the matrix
+
+- Vue docs recommend `npm create vue@latest` for scaffolding a Vue SPA locally.
+- The `create-vue` repository describes itself as the recommended way to start a Vite-powered Vue project and documents feature flags such as `--ts`, `--vitest`, `--eslint`, and `--bare`.
+- Vite docs document `npm create vite@latest <project-name> -- --template vue` / `vue-ts` as the direct template path and surface the Vue starter as the official Vue option.
+
+For a **Vue-specific frontend baseline**, the safest verified prototype is the smallest official Vue-owned starter that still prewires type-checking, linting, and unit tests. That is `create-vue` with `--ts --vitest --eslint --bare` here.
+
+## Chosen default stack and version pins
+
+Verified prototype pins:
+
+- Node image: `node:22.21.1-alpine3.22`
+- Vue: `3.5.32`
+- Vite: `8.0.8`
+- TypeScript: `6.0.2`
+- `@vitejs/plugin-vue`: `6.0.6`
+- Vitest: `4.1.4`
+- `@vue/test-utils`: `2.4.6`
+- ESLint: `10.2.0`
+- `@vue/eslint-config-typescript`: `14.7.0`
+- `@vitest/eslint-plugin`: `1.6.15`
+- `oxlint`: `1.57.0`
+- `vue-tsc`: `3.2.6`
+- `jsdom`: `29.0.2`
+
+Compatibility pins used in this verified lab:
+
+- `@emnapi/core`: `1.9.2`
+- `@emnapi/runtime`: `1.9.2`
+- `@rolldown/binding-darwin-arm64`: `1.0.0-rc.15` as an optional dependency for current macOS arm64 local installs
+
+## Safe defaults
+
+- no `.env` file required
+- no secrets committed
+- baseline-only SPA, not a feature-complete product
+- no router, state store, API client, SSR, or E2E browser tooling by default
+- Docker host port bound to `127.0.0.1` with a random host port to reduce local collisions
+- healthcheck required before the smoke step proceeds
+- exact dependency versions pinned in `package.json` and `package-lock.json`
+
+## Docker / Compose pattern
+
+Recommended baseline pattern:
+
+1. **multi-stage Dockerfile**
+   - shared `npm ci` base
+   - `development` target runs `vite` on `0.0.0.0:5173`
+   - `verify` target runs `npm run verify`
+2. **Compose services**
+   - `web` service for `docker compose up --build`
+   - `test` service behind a `test` profile for containerized verification
+3. **port strategy**
+   - expose only the app port
+   - prefer `127.0.0.1::5173` so parallel local worktrees do not collide
+4. **health strategy**
+   - wait for `wget http://127.0.0.1:5173` healthcheck before curl smoke tests
+
+## Testing baseline
+
+Minimum real testing floor for this playbook:
+
+- Vitest component tests
+- Vue Test Utils rendering assertions
+- one small interaction test (`Show verification commands` toggle)
+- one containerized smoke check that confirms the app shell is served through Compose
+- one containerized broad path that runs lint + unit tests + production build
+
+Suggested scripts:
+
+- `npm run test:unit`
+- `npm run verify`
+- `./run_tests.sh`
+
+`./run_tests.sh` should:
+
+1. build Docker images
+2. start `web`
+3. wait for health
+4. `curl` the served HTML shell
+5. run the `test` profile container
+6. tear down cleanly
+
+## README requirements
+
+The scaffold `README.md` should explicitly state:
+
+- that this is a **baseline scaffold**
+- chosen stack and why it was picked
+- exact bootstrap command used
+- `docker compose up --build`
+- `./run_tests.sh`
+- any optional local iteration commands
+- what is included now vs intentionally deferred
+- no `.env` / no secrets policy
+- main files worth reusing later
+
+## Verification commands actually run in the verified prototype
+
+User-facing commands verified:
+
+```bash
+npm create vue@latest vue-vite-baseline -- --ts --vitest --eslint --bare
+npm install
+npm run verify
+docker compose up --build
+./run_tests.sh
+```
+
+Supporting commands used during verification:
+
+```bash
+docker compose port web 5173
+curl -fsS http://127.0.0.1:<mapped-port>
+docker compose down --remove-orphans
+```
+
+Observed verification results in the prototype lab:
+
+- local `npm run verify`: passed
+- containerized `./run_tests.sh`: passed
+- runtime `docker compose up --build`: passed and served the app shell
+
+## Known caveats
+
+- The curl smoke check validates the served HTML shell, not hydrated browser DOM behavior. Keep Vitest component tests for actual UI assertions.
+- `create-vue` is interactive by default; the verified baseline uses feature flags so the scaffold stays reproducible and baseline-only.
+- Nuxt remains a documented alternative, not the verified prototype, because its runtime model is intentionally broader than a baseline SPA.
+
+## What to reuse later
+
+Reuse these parts directly for later Vue frontend prompts:
+
+- the official `create-vue` bootstrap path with baseline-only flags
+- the multi-stage Dockerfile pattern
+- random localhost host-port mapping
+- healthcheck + curl smoke test flow
+- `./run_tests.sh` as the canonical broad-path wrapper
+- the README honesty checklist
+
+Do **not** treat this playbook as a signal to pre-add routing, Pinia, auth, API clients, or E2E browsers unless the prompt explicitly needs them.