theslopmachine 0.6.2 → 0.7.0

package/assets/slopmachine/backend-evaluation-prompt.md

@@ -200,7 +200,7 @@ Hard Rules (must follow)
 ====================
 Output Requirements
 
-Produce the final audit in a concise but complete report and write the consolidated report to `./.tmp/**.md`.
+Produce the final audit in a concise but complete report and write the consolidated report to `../.tmp/**.md`.
 
 The final report must be organized by the six major acceptance sections in order, even if your scan order was different.
 

package/assets/slopmachine/frontend-evaluation-prompt.md

@@ -118,8 +118,8 @@ Based on static evidence only, determine whether the delivery is a credible, Pro
   - marked Cannot Confirm with a clear boundary explanation
 
 5) Exclude Temporary Output
-- Exclude `./.tmp/` and all its subdirectories.
-- `./.tmp/` must not be used as evidence, search scope, reference, summary source, or factual basis.
+- Exclude `./.tmp/`, `../.tmp/`, and all their subdirectories.
+- `./.tmp/` and `../.tmp/` must not be used as evidence, search scope, reference, summary source, or factual basis.
 
 [Pure Frontend-Specific Rules]
 
@@ -277,7 +277,7 @@ Your output must strictly follow this structure:
 
 2. Scope and Verification Boundary
 - what was reviewed
-- which input sources were excluded, including `./.tmp/`
+- which input sources were excluded, including `./.tmp/` and `../.tmp/`
 - what was not executed
 - what cannot be statically confirmed
 - which conclusions require manual verification
@@ -388,10 +388,10 @@ Before finalizing the report, check each of the following:
 3. Did you wrongly assign backend responsibility to the frontend?
 4. Did you misclassify reasonable mock / local data / storage usage as a defect?
 5. Did you state visual or interaction guesses as strong conclusions?
-6. Does any conclusion directly or indirectly rely on `./.tmp/`?
+6. Does any conclusion directly or indirectly rely on `./.tmp/` or `../.tmp/`?
 7. Have all required Blocker / High dimensions been closed?
 8. Have repeated findings been merged by root cause?
 9. If unsupported observations were removed, would the final Verdict still hold?
 
-If writing files is supported, save the final report to `./.tmp/`.
+If writing files is supported, save the final report to `../.tmp/`.
 Otherwise, return the report directly in the conversation.

package/assets/slopmachine/scaffold-playbooks/android-kotlin-compose.md

@@ -0,0 +1,81 @@
+# Android Kotlin Compose Scaffold Playbook
+
+Use this playbook when the prompt explicitly requires native Android with Kotlin + Compose.
+
+## Current status
+
+This family is now **experimentally verified** for a reasonable Linux Docker baseline.
+
+Verified lab:
+
+- `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/android-kotlin-compose-baseline`
+
+## What was achieved in the verified lab
+
+The verified lab now demonstrates all of the following:
+
+- native Kotlin Android project exists
+- Compose is enabled in Gradle
+- pinned Android toolchain Dockerfile exists
+- `docker-compose.yml`, `run_tests.sh`, and artifact-serving scripts exist
+- `artifacts/app-debug.apk` and checksum were produced in the lab tree
+- JVM-side test files exist
+- `docker compose up -d --wait` reached a stable healthy artifact-serving state
+- `./run_tests.sh` passed with containerized lint plus `:app:testDebugUnitTest`
+- the Compose build no longer fails on the broken theme/import issues found during investigation
+
+## Safe default stack
+
+- AGP `8.5.x`
+- Gradle `8.7`
+- Java `17`
+- Kotlin `1.9.x`
+- `compileSdk = 34`
+- `targetSdk = 34`
+- `minSdk = 29`
+- Compose BOM pinned explicitly
+- Material 3 default Compose surface
+
+## Runtime contract
+
+- required Docker command: `docker compose up --build`
+- required broad test command: `./run_tests.sh`
+- both are now real and working in the verified lab
+- `./run_app.sh` may exist as a helper, but it does not replace the Docker baseline
+
+## Intended Docker strategy
+
+This family should follow the same proven Android pattern as the Java/Kotlin-Views baseline:
+
+1. pre-bake the Android SDK/toolchain layers into the image
+2. bind-mount the workspace for source changes
+3. avoid default `clean` tasks
+4. use one long-running artifact-serving/support container for the Compose healthy state
+5. reuse that same running container for lint and JVM-side test commands via `docker compose exec`
+
+## Honest Linux proof boundary
+
+For the verified Linux baseline, Docker honestly proves only:
+
+- Compose code compiles
+- debug APK assembles
+- lint passes
+- JVM-side tests pass
+- artifact-serving healthy state works
+
+Linux should **not** claim emulator or device runtime proof.
+
+## Verified rerun evidence
+
+The final rerun established these concrete facts:
+
+- direct `:app:assembleDebug --stacktrace` passed after fixing the broken app theme and missing `rememberSaveable` import
+- `./run_tests.sh` passed with the container reaching `Healthy`
+- containerized Gradle verification completed with `BUILD SUCCESSFUL in 1m 32s`
+- the generated APK size was non-zero and published from the artifact server
+
+## Guidance
+
+- use this family only when the prompt explicitly requires Compose
+- keep it non-default for open-ended Android work because the Java Views baseline is still the lighter generic default
+- it is now safe to treat this family as experimentally verified rather than only partially prepared

package/assets/slopmachine/scaffold-playbooks/android-kotlin-views.md

@@ -0,0 +1,191 @@
+# Android Kotlin Views Scaffold Playbook
+
+Use this playbook when the prompt explicitly wants native Android with Kotlin and XML/Views rather than Compose.
+
+This concrete playbook follows the shared Docker contract in `docker-shared-contract.md` and is grounded in the experimentally verified lab at `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/android-baseline`.
+
+## Goal
+
+Create a simple Android Kotlin Views baseline that:
+
+- is baseline-only, not feature-complete
+- uses Kotlin plus Android Views, not Compose
+- stays honest about Linux-first Docker verification boundaries
+- keeps `docker compose up --build` as the required runtime/support contract
+- keeps `./run_tests.sh` as the required broad containerized verification path
+- requires no emulator
+
+## Runtime contract
+
+- required Docker command: `docker compose up --build`
+- required broad test command: `./run_tests.sh`
+- both commands must be real, containerized, and working
+- `./run_app.sh` may exist as a host convenience helper, but it does not replace the required Docker contract
+
+## Verified baseline notes
+
+From a real lab verification on 2026-04-15:
+
+- the verified lab is `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/android-baseline`
+- the lab uses Kotlin source plus XML Views and ViewBinding
+- `docker compose up --build -d --wait android-baseline` reached a stable healthy state
+- that healthy state is a loopback-only artifact server serving `artifacts/app-debug.apk` on the mapped host port reported by `docker compose port android-baseline 8080`
+- `./run_tests.sh` reused the running Compose container with `docker compose exec` for `:app:lintDebug` and `:app:testDebugUnitTest`, then smoke-checked the served APK
+- the containerized Gradle verification completed successfully without an emulator
+- the truthful proof boundary is pinned toolchain + APK assembly + lint + JVM unit tests + artifact serving; it does **not** claim emulator boot, adb deployment, or on-device runtime proof
+
+## Safe pinned defaults used in the verified lab
+
+- Android Gradle Plugin: `8.5.2`
+- Gradle wrapper: `8.7`
+- Kotlin Android plugin: `1.9.24`
+- Java: `17`
+- `compileSdk = 34`
+- `targetSdk = 34`
+- `minSdk = 29`
+- view system: XML layouts + Android Views + ViewBinding
+
+## Safe default libraries
+
+- AppCompat `1.7.0`
+- Material `1.12.0`
+- ConstraintLayout `2.1.4`
+- Lifecycle Runtime `2.8.4`
+- JUnit `4.13.2`
+
+Add Room, security, networking, or media libraries only when the prompt actually needs them.
+
+## Preferred repo shape
+
+- `app/`
+- `container-build-and-serve.sh`
+- `container-gradle.sh`
+- `docker-compose.yml`
+- `Dockerfile`
+- `run_tests.sh`
+- `run_app.sh`
+- `artifacts/` for the built APK and checksum
+
+## Docker strategy that was experimentally verified
+
+For Android-on-Linux Kotlin Views scaffolds, prefer a pinned toolchain image plus one long-running support container instead of pretending Docker proves native Android runtime.
+
+Verified pattern:
+
+1. build a pinned Android toolchain image from source in the repo
+2. pre-bake Java 17, Android command-line tools, platform `android-34`, build-tools `34.0.0`, and a seeded Gradle wrapper/plugin cache into the image
+3. bind-mount the workspace at runtime so source edits do not invalidate the heavy SDK layers
+4. start one long-running container that runs `:app:assembleDebug`, copies the APK to `artifacts/`, writes a checksum, and serves that directory over HTTP
+5. expose only one loopback-only host port with an automatic high host-port mapping: `127.0.0.1::8080`
+6. declare health only after the APK exists and the in-container HTTP server returns the APK successfully
+7. reuse that same running container in `./run_tests.sh` with `docker compose exec` so lint/test verification does not rebuild the entire toolchain path again
+
+This strategy satisfied the shared contract because `docker compose up --build` reached a meaningful healthy state and reruns avoided repeated SDK bootstrap work.
+
+## `./run_tests.sh`
+
+`./run_tests.sh` should remain containerized and should prove the portable Android baseline without an emulator:
+
+- start the Compose baseline with `docker compose up --build -d --wait`
+- reuse the running container for Gradle verification with `docker compose exec`
+- run at least `:app:lintDebug` and `:app:testDebugUnitTest`
+- smoke-check the same APK artifact surface that `docker compose up --build` claims to provide
+- tear the stack down after verification
+
+## Minimal real test floor
+
+At scaffold time, include at least:
+
+- one real Kotlin helper/rule test
+- one real state/helper test exercised by the Android entrypoint flow
+- real `lint` proof
+- real `assembleDebug` proof
+
+Do not leave the baseline test path mostly `NO-SOURCE`.
+
+## README floor
+
+`README.md` in the scaffold must already state:
+
+- that this is a baseline scaffold only
+- Kotlin + Android Views scope
+- required Docker command: `docker compose up --build`
+- required broad test command: `./run_tests.sh`
+- host helper command: `./run_app.sh` when present
+- what healthy state means for the artifact-serving support surface
+- what the Docker path does **not** prove on Linux
+- no `.env` / no hidden secret bootstrap policy
+- any known heavier first-run expectations
+
+## Exact commands actually run in the verified lab
+
+```bash
+docker compose build --no-cache
+docker compose up --build -d --wait android-baseline
+docker compose ps
+curl -fsS "http://$(docker compose port android-baseline 8080)/app-debug.apk" -o /tmp/android-kotlin-views-app-debug.apk
+shasum -a 256 artifacts/app-debug.apk
+docker compose down --remove-orphans
+./run_tests.sh
+python3 - <<'PY'
+import signal
+import subprocess
+import time
+from urllib.request import urlopen
+
+cwd = "/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/android-baseline"
+proc = subprocess.Popen(["docker", "compose", "up", "--build"], cwd=cwd)
+error = None
+try:
+    deadline = time.time() + 600
+    while time.time() < deadline:
+        try:
+            port = subprocess.check_output(["docker", "compose", "port", "android-baseline", "8080"], cwd=cwd, text=True).strip()
+            with urlopen(f"http://{port}/app-debug.apk", timeout=5) as response:
+                if response.status == 200:
+                    print("Android Kotlin Views baseline reached artifact-serving healthy state during docker compose up --build")
+                    break
+        except Exception as exc:
+            error = exc
+        time.sleep(5)
+    else:
+        raise RuntimeError(f"Android Kotlin Views baseline never became ready: {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", "--remove-orphans"], cwd=cwd, check=True)
+PY
+```
+
+## Observed verification results in the verified lab
+
+- `docker compose up --build -d --wait android-baseline`: passed and reported the service healthy
+- `curl -fsS "http://$(docker compose port android-baseline 8080)/app-debug.apk"`: passed and downloaded a non-empty APK
+- `./run_tests.sh`: passed after running containerized lint, JVM unit tests, and the APK smoke check
+- foreground `docker compose up --build`: reached the documented artifact-serving state before controlled shutdown, so it converged honestly instead of hanging indefinitely with no proof
+
+## Common pitfalls
+
+- defaulting to Compose or emulator requirements when the prompt asks for Views-only baseline work
+- requiring Robolectric or device runtime proof when the truthful Linux Docker baseline does not need it
+- making `docker compose up --build` a one-shot build that exits without a stable healthy state
+- rebuilding the Android SDK on ordinary reruns because the Dockerfile copies the whole source tree before caching the heavy toolchain layers
+- sharing mutable Gradle cache state across multiple concurrent containers when one running container is enough
+- publishing more host ports than the artifact-serving support surface actually needs
+- checking in `.env` or any plaintext secrets even though this baseline does not need them
+
+## Acceptance checklist
+
+Scaffold is acceptable when:
+
+- `docker compose up --build` works and reaches the documented healthy state
+- `./run_tests.sh` works and stays containerized
+- minimal real Kotlin tests exist
+- the Docker path is honest about stopping at APK build/test/artifact proof on Linux
+- README is honest and traceable
+- no `.env` is required or committed
+- the result is experimentally verified, not just theoretically described

package/assets/slopmachine/scaffold-playbooks/android-native-java.md

@@ -0,0 +1,203 @@
+# Android Native Java Scaffold Playbook
+
+Use this playbook for native Android requests unless the prompt explicitly requires Kotlin, Compose, or a different Android stack.
+
+## Goal
+
+Create a fast, repeatable Android scaffold that is:
+
+- native Android
+- baseline-only, not feature-complete
+- honest about offline/bootstrap/runtime constraints
+- portable broad-testable on Linux with Docker
+- safe by default on secrets and bootstrap data
+
+## Runtime contract
+
+- required Docker command: `docker compose up --build`
+- required broad test command: `./run_tests.sh`
+- both commands must be real and working
+- `./run_app.sh` may exist as a helper for host-side convenience, but it does not replace the required Docker baseline
+
+## Verified baseline notes
+
+From a real lab verification on 2026-04-14:
+
+- the current Android baseline does converge honestly in Docker without an emulator
+- `docker compose up --build -d --wait` reached a stable healthy state
+- the healthy state was a loopback-only artifact server serving the built APK from `artifacts/app-debug.apk`
+- `./run_tests.sh` reused the running container with `docker compose exec` for `:app:lintDebug` and `:app:testDebugUnitTest`, then smoke-checked the served APK
+- the observed containerized Gradle verification completed successfully with `BUILD SUCCESSFUL in 1m 42s`
+- the current practical proof boundary is: pinned toolchain + APK assembly + lint + JVM unit tests + artifact serving; it does **not** claim emulator or device runtime proof
+- the current Docker strategy is acceptable because the heavy Android SDK/toolchain layers are pre-baked and cached instead of being reinstalled on every rerun
+
+## Safe default stack
+
+- Android Gradle Plugin: `8.5.x`
+- Gradle wrapper: `8.7`
+- Java: `17`
+- `compileSdk = 34`
+- `targetSdk = 34`
+- `minSdk = 29`
+- Android Views by default unless the prompt explicitly requires Compose
+
+## Safe default libraries
+
+- AppCompat
+- Material
+- ConstraintLayout
+- Lifecycle
+- Room
+- JUnit
+
+Robolectric is **optional**, not mandatory. Use it only when the verified Linux/Docker baseline can run it without extra native-runtime breakage or flaky heavyweight downloads. If that is not true, fall back to JVM tests + lint + assemble and document the proof boundary honestly.
+
+Add security/storage libraries only when the prompt or selected baseline actually needs them.
+
+## Preferred repo shape
+
+- `app/`
+- `core/model/`
+- `core/rules/`
+- `core/data/`
+- `feature/*/`
+
+Only add deeper security/media/operator modules during scaffold when the requested technologies already make them necessary.
+
+## Required scripts
+
+- `./init_db.sh` when the app has database dependencies
+- `docker compose up --build`
+- `./run_tests.sh`
+- `./run_app.sh` when useful for host-side convenience
+
+## Bootstrap model
+
+- use one bootstrap source of truth
+- no committed plaintext bootstrap credentials
+- no `.env` files
+- if local bootstrap data is needed for dev/test, generate it only under ignored build output
+- if packaged seed data is needed, package only non-sensitive assets
+- app runtime must not contain duplicate hidden seed logic outside the chosen bootstrap path
+
+## Room and schema rules
+
+- enable `exportSchema = true` when Room is present
+- write schemas to a real repo-visible path such as `app/schemas/`
+- add a real schema verification task when Room is part of the baseline
+- route runtime/test/bootstrap through `./init_db.sh` when database setup exists
+
+## Docker runtime baseline
+
+For Android-on-Linux scaffolds, prefer a **toolchain image + bind-mounted workspace + stable support surface** instead of pretending Docker proves full device runtime.
+
+Recommended baseline shape from real verification:
+
+1. build a pinned Android toolchain image once
+2. pre-bake only the heavy reusable layers into that image:
+   - Java 17
+   - Android command-line tools
+   - pinned `compileSdk` platform package
+   - pinned build-tools package
+   - seeded Gradle wrapper/plugin cache when practical
+3. bind-mount the project source at runtime so source edits do **not** force SDK reinstall layers to rebuild
+4. run `:app:assembleDebug` without `clean`
+5. copy the real APK to a repo-visible `artifacts/` path
+6. keep the Compose stack alive with a lightweight long-running support service such as an artifact HTTP server
+7. expose at most one loopback-only host port when that support surface is published
+
+This gives `docker compose up --build` a stable healthy state that is both honest and observable.
+
+With the verified lab shape, the Compose command should be treated as acceptable when it:
+
+- reaches healthy artifact-serving state predictably
+- avoids SDK reinstall on reruns
+- avoids default `clean` builds
+- keeps the expensive work in image/toolchain layers and one running container rather than bouncing across multiple heavyweight containers
+
+Avoid the failed pattern of separate Compose build/test containers sharing one mutable Gradle cache volume by default. That strategy easily produces cache-lock contention and does not improve baseline honesty.
+
+If `./run_app.sh` also exists, it should:
+
+1. normalize `JAVA_HOME`
+2. detect `ANDROID_HOME` when available
+3. run `./init_db.sh` when relevant
+4. build a debug APK or equivalent baseline artifact
+5. print the artifact path and any non-sensitive local bootstrap output path when useful
+
+## `./run_tests.sh`
+
+`./run_tests.sh` should be containerized and cover the honest Android broad baseline without requiring an emulator:
+
+- lint
+- assemble
+- JVM tests
+- Robolectric tests only when the verified Docker baseline supports them reliably
+- schema verification when Room is used
+
+Recommended broad-path execution pattern:
+
+1. start the baseline container with `docker compose up --build -d --wait`
+2. reuse that same running container for Gradle verification (`docker compose exec`) so the already-built toolchain state and build outputs are reused
+3. smoke-check the same artifact/support surface that `docker compose up --build` claims to provide
+4. tear the stack down in the script after verification
+
+This avoids avoidable second-pass rebuild loops while still proving both the build and the documented Docker contract.
+
+## Minimal real test floor
+
+At scaffold, include at least:
+
+- one real rule/helper test
+- one real Android-side unit or Robolectric test **when the verified Linux baseline supports it reliably**
+- one real build/lint verification path
+- schema verification when Room is used
+
+If Android-side host-runtime tests are not stable on the truthful Linux baseline, replace that requirement with:
+
+- at least two real scaffold JVM tests tied to shipped Android entrypoint logic
+- real `lint` + `assemble` proof
+- explicit README disclosure that Docker stops short of Robolectric/emulator proof on that baseline
+
+Do not leave the broad path mostly `NO-SOURCE`.
+
+## README floor
+
+`README.md` must already state:
+
+- scaffold status versus implemented product scope
+- Android-only scope
+- required Docker command: `docker compose up --build`
+- broad test command: `./run_tests.sh`
+- host-side helper command: `./run_app.sh` when present
+- bootstrap/setup honesty
+- main module map and entry-point traceability
+- what stable healthy state means for the Docker support surface
+- what the Docker path does **not** prove on Linux
+
+## Common pitfalls
+
+- hardcoded default passwords
+- committed plaintext bootstrap credentials
+- duplicate bootstrap paths in both script and app code
+- unconditional amd64 forcing on arm hosts
+- broad test path with almost no real tests
+- fake emulator/runtime claims
+- `docker compose up --build` that exits immediately after a one-shot build with no stable healthy support surface
+- repeated Gradle or SDK downloads because the Dockerfile copies the entire source tree before caching heavy toolchain layers
+- shared Gradle cache volumes across concurrent containers when a single running container would be enough
+- default `clean` tasks in Docker commands
+- insisting on Robolectric/native host-runtime coverage when it makes the Linux Docker baseline materially less reliable than honest JVM + lint + assemble proof
+
+## Acceptance checklist
+
+Scaffold is acceptable when:
+
+- `docker compose up --build` succeeds
+- `./run_tests.sh` succeeds
+- bootstrap path is single-source and secret-safe
+- schema export and verification are real when relevant
+- README is honest and traceable
+- minimal real scaffold tests exist
+- no plaintext credentials or `.env` artifacts exist in the repo or package
+- the Docker path reaches a stable healthy artifact-serving state in a reasonable amount of time and avoids obvious rebuild loops on reruns