theslopmachine 0.4.0 → 0.4.2

package/assets/skills/final-evaluation-orchestration/SKILL.md

@@ -1,73 +1,77 @@
 ---
 name: final-evaluation-orchestration
-description: Dual final-evaluation workflow, prompt composition, triage, report integrity, and bounded remediation-loop rules for repo-cwd execution.
+description: Evaluation execution rules for slopmachine.
 ---
 
 # Final Evaluation Orchestration
 
-Use this skill only after integrated verification and hardening are complete enough for final evaluation.
+Use this skill only during `P7 Evaluation and Triage`.
 
 ## Usage rules
 
-- Load this skill only during final evaluation and evaluation-driven remediation decisions.
-- Treat it as internal orchestration guidance.
-- Do not let evaluator findings automatically override your triage judgment.
-- this phase is the only allowed later human-stop point after development has started; do not create any other approval pauses outside the final evaluation decision itself
+- load this skill only during final evaluation and evaluation-driven remediation decisions
+- treat it as internal orchestration guidance
+- do not let evaluator findings automatically override your triage judgment
 
 ## Prompt sources
 
-- `~/backend-evaluation-prompt.md`
-- `~/frontend-evaluation-prompt.md`
+The canonical evaluation prompt files are:
+
+- `~/slopmachine/backend-evaluation-prompt.md`
+- `~/slopmachine/frontend-evaluation-prompt.md`
+
+These two files are the only evaluation prompt sources for evaluation runs.
 
 ## Evaluation execution rules
 
-- when the project reaches final-evaluation readiness, run two separate evaluations:
-  - backend/non-frontend evaluation using `~/backend-evaluation-prompt.md`
-  - frontend evaluation using `~/frontend-evaluation-prompt.md`
-- read the full original project prompt from parent-root `../metadata.json` field `prompt`
+- run backend and frontend evaluation in separate fresh `General` sessions - never in parallel
+- compose the evaluation prompts yourself; do not tell the evaluator to read prompt files on its own
+- use the original project prompt from metadata
 - read the respective evaluation prompt file contents yourself before launching evaluation
 - compose each evaluation request yourself as one large final prompt block
 - prefix each evaluation request with a clear instruction that the reviewer must work in the current project directory and evaluate that delivered project
-- inject the full original project prompt into the `{prompt}` placeholder for the chosen evaluation prompt content
+- use the exact contents of `~/slopmachine/backend-evaluation-prompt.md` for backend/non-frontend evaluation runs
+- use the exact contents of `~/slopmachine/frontend-evaluation-prompt.md` for frontend evaluation runs
+- inject the full original project prompt into the `{prompt}` placeholder for the chosen evaluation prompt content, but otherwise do not rewrite or replace the template body
 - send that fully composed text block directly to the fresh `General` evaluator session
 - never tell the evaluator to go read prompt files, metadata files, or evaluation template paths on its own
 - never send only a path, filename, or shorthand reference and expect the evaluator to assemble the prompt itself
-- run each evaluation in its own fresh ephemeral `General` session only
 - never reuse, resume, or continue a prior evaluation session
-- run the two evaluations sequentially, not in parallel, so shared runtime state, Docker containers, ports, databases, and artifacts do not conflict
+- run the two evaluations sequentially, not in parallel, so shared runtime state, ports, databases, and artifacts do not conflict
 - track backend and frontend evaluation status separately
 - once backend evaluation passes, do not run backend evaluation again in later remediation rounds
 - once frontend evaluation passes, do not run frontend evaluation again in later remediation rounds
 - require each evaluation session to produce its own detailed evaluation report artifact
 - always compare both evaluations against the original prompt for alignment, not just the delivered implementation
+- keep reports file-backed and bring only short summaries into chat
+- rerun only the evaluation track that still needs re-evaluation after remediation
+
+## Evaluation pass strategy
 
-## Triage rules
-
-- read both reports and merge the findings into one explicit triage set before deciding what happens next
-- use the evaluator's priority ordering directly when triaging findings
-- any finding marked `Blocker` or `High` must be returned to the original `Developer` session for remediation
-- findings marked `Medium` may be passed in limited cases, but should usually be fixed when they materially improve confidence, correctness, or acceptance readiness
-- findings marked `Low` may be passed without remediation
-- do not treat complaints about test coverage depth, unverifiable tests, or evaluator inability to confirm a test path as automatic blockers by themselves
-- if your own direct evidence shows the tests run and the coverage is acceptable for qualification, defend the project and pass those findings instead of automatically remediating
-- evaluation findings are advisory inputs to triage, not automatic implementation orders
-- if a report says it could not verify some behavior because of environment limits or avoidable verification setup issues, first decide whether you can remove that constraint and rerun the evaluation in a cleaner state
-- if the evaluator could not verify something but your own verified evidence already shows the behavior is acceptable, do not treat that as an automatic remediation trigger
-- challenge weak, random, or overreaching findings using your stronger project context and direct codebase knowledge
-- never edit or rewrite the evaluation report itself
-- if you need to add context, disagreement, or justification, append it only as a clearly labeled `User comment/message` section at the bottom of the report
-- do not enter remediation just because a new evaluation found something; the evaluator will almost always find additional issues
-- once all `Blocker` and `High` findings are resolved, do not loop forever chasing every newly surfaced `Medium` or `Low` issue
-- after each re-evaluation, decide explicitly whether the remaining findings still justify another remediation round or whether the project is now qualified to package
+- use a maximum of 3 full evaluation passes
+- after each evaluation pass, extract a detailed concrete issue list from the failing report(s)
+- send that list back to the active developer session with a direct instruction like: `fix these issues found in evaluation, verify affected flows dont regress after your fixes`
+- if one evaluation track passes, mark it as passed and do not rerun that track in later passes unless a later fix clearly reopens it
+- do not rerun both backend and frontend evaluation tracks when only one still needs re-evaluation
+- after pass 1 and pass 2, use the detailed issue list from the latest failing report(s) to drive the next remediation pass
+- after pass 3, do not create a new evaluation session for the still-failing track
+- after pass 3, send the final fix list back to the developer, then return to the last evaluation session used for that still-failing track and ask whether the last reported issues are now fixed
+- if they are fixed, have that same evaluation session update the report to reflect the current state cleanly, without mentioning recheck, retest, previous issues, or iterative review history
+- the final report should read like a normal current-state evaluation report, not like a patch log
 
 ## Remediation loop
 
-- route accepted blocking issues back into remediation in the same long-lived `Developer` session
+- route accepted blocking issues back into the active remediation developer-session slot rather than inventing an untracked side path
 - after remediation, rerun strong local verification before any re-evaluation:
-  - relevant local test commands
-  - local runtime checks when affected behavior needs runtime proof
-  - Playwright where applicable, with fresh screenshots
-- if remediation materially reopens an owner-run milestone boundary, route the project back to that milestone gate before any re-evaluation instead of treating every remediation pass as an automatic Docker and `run_tests.sh` moment
-- rerun only the evaluation tracks that have not already passed, each in a brand new fresh `General` session and still sequentially
+    - relevant local test commands
+    - local runtime checks when affected behavior needs runtime proof
+    - the selected stack's platform-appropriate UI/E2E verification where applicable, with fresh screenshots or equivalent artifacts
+- if remediation materially reopens an owner-run broad milestone boundary, route the project back to that boundary before re-evaluation instead of treating every remediation pass as an automatic broad rerun moment
 - keep the remediation loop bounded and explicit so you never lose track of the active evaluation round or the accepted issue set
-- remember the external process allows a maximum of 3 repair rounds
+- store backend, frontend, and last-used evaluation session ids in metadata so later passes and packaging can safely reuse the correct session when needed
+- remember the evaluation flow allows a maximum of 3 full evaluation passes before the final issue-verification update path must be used
+
+## Boundaries
+
+- this phase is owner-side analysis, not the final human decision gate
+- do not create extra human pauses while evaluation and triage are still active

package/assets/skills/{hardening-gate-v2 → hardening-gate}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: hardening-gate-v2
-description: Release-readiness hardening rules for slopmachine-v2.
+name: hardening-gate
+description: Release-readiness hardening rules for slopmachine.
 ---
 
-# Hardening Gate v2
+# Hardening Gate
 
 Use this skill only during `P6 Hardening`.
 

package/assets/skills/{integrated-verification-v2 → integrated-verification}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: integrated-verification-v2
-description: Integrated verification convergence and rerun-ladder rules for slopmachine-v2.
+name: integrated-verification
+description: Integrated verification convergence and rerun-ladder rules for slopmachine.
 ---
 
-# Integrated Verification v2
+# Integrated Verification
 
 Use this skill only during `P5 Integrated Verification`.
 
@@ -23,11 +23,12 @@ Once a failure class is known:
 - run the relevant tests for the changed behavior
 - during in-phase verification, prefer the fastest meaningful local test commands for the known failure class
 - use local verification to prepare for the next owner-run broad gate rather than duplicating it casually
-- for applicable fullstack or UI-bearing work, run Playwright for the affected flows in-phase, capture screenshots, and verify the UI behavior and quality directly
+- for applicable UI-bearing work, run the selected stack's platform-appropriate UI/E2E tool for the affected flows in-phase, capture screenshots or equivalent artifacts, and verify the UI behavior and quality directly
 - verify requirement closure, not just feature existence
 - verify behavior against the current plan, the actual requirements, and any settled project decisions that affect the change
 - verify end-to-end flow behavior where the change affects real workflows
-- for fullstack work, run Playwright coverage for major flows and review screenshots for real UI behavior and regressions
+- for web fullstack work, run Playwright coverage for major flows and review screenshots for real UI behavior and regressions
+- for mobile and desktop work, run the selected stack's platform-appropriate UI/E2E coverage for major flows and review screenshots or equivalent artifacts for real UI behavior and regressions
 - end-to-end coverage must use the real intended user-facing or admin-facing surfaces for the flow; if the flow cannot be exercised that way, treat the missing surface as incomplete work
 - verify important failure, conflict, stale-state, negative-auth, and cross-user-isolation paths where relevant
 - verify security-sensitive behavior where applicable

package/assets/skills/{owner-evidence-discipline-v2 → owner-evidence-discipline}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: owner-evidence-discipline-v2
-description: Owner evidence-ingestion rules for lower-token slopmachine-v2 review loops.
+name: owner-evidence-discipline
+description: Owner evidence-ingestion rules for lower-token slopmachine review loops.
 ---
 
-# Owner Evidence Discipline v2
+# Owner Evidence Discipline
 
 Use this skill when owner review risks rereading too much evidence.
 

package/assets/skills/planning-gate/SKILL.md

@@ -1,20 +1,36 @@
 ---
 name: planning-gate
-description: Owner-side planning acceptance, cross-document consistency, and decomposition gate rules for repo-cwd blueprint-driven projects.
+description: Owner-side planning acceptance and correction rules for slopmachine.
 ---
 
 # Planning Gate
 
-Use this skill during `P2 Development Bootstrap and Planning` when reviewing, tightening, or accepting the first real technical plan.
+Use this skill during `P2 Planning` when reviewing or accepting the plan.
+
+## Planning gate priorities
+
+Before planning is accepted, the owner should explicitly review the plan against these later audit buckets:
+
+1. prompt-fit
+2. security-critical flaws
+3. test sufficiency
+4. major engineering quality
+
+Planning should not pass if these have been ignored in a way that is likely to create expensive late failures.
+
+## Core rule
+
+If the owner notices a concrete role, contract, or scope mismatch, planning does not pass until one of these is true:
+
+- the mismatch is corrected
+- an explicit disposition note explains why acceptance is still valid
 
 ## Usage rules
 
-- Load this skill before accepting planning, before declaring the plan sufficient, and before creating deep execution sub-items from the plan.
-- Treat it as owner-side planning gate guidance, not developer-visible text.
-- Use `get-overlays` as the source of truth for developer-facing planning guidance.
-- Use this skill as the source of truth for owner-side planning acceptance and decomposition readiness.
-- do not pause for planning approval or any other human check-in while using this skill; planning must continue until it is accepted internally or sent back to the developer for fixes
-- maintain the owner-managed external planning docs in parent-root `../docs/` from the accepted plan rather than treating them as developer-owned files
+- keep the existing high bar for implementation-grade planning
+- treat this as owner-side planning gate guidance, not developer-visible text
+- do not create deep execution decomposition before the plan is accepted
+- keep planning as a cheap correction point rather than pushing known ambiguity into execution
 
 ## Core planning gate
 
@@ -49,11 +65,14 @@ Use this skill during `P2 Development Bootstrap and Planning` when reviewing, ti
 - define frontend validation and accessibility expectations when the product surface materially depends on them
 - if the prompt names literal storage, indexing, partitioning, retention, or performance dimensions, represent them literally in the planning artifacts rather than abstracting them away
 
-## Planning acceptance checklist
-
-Before accepting planning, apply this checklist when relevant:
+## Acceptance checklist
 
+- scope is still prompt-faithful
+- the plan has explicitly addressed prompt-fit risks and requirement drift
 - major user-facing flows are mapped to backend support and verification targets
+- security-critical areas are planned early enough that they will not be left to accidental late cleanup
+- test sufficiency has been considered at the level of core happy path, major failure paths, security-critical paths, and obvious high-risk boundaries
+- major engineering quality has been addressed through maintainable boundaries, clear decomposition, and shared contracts
 - frontend route, page, component, and state boundaries are planned when the UI is material
 - configurable behaviors are concretely planned where the prompt requires configurability
 - lifecycle and state models are aligned across design and API/spec artifacts
@@ -62,6 +81,8 @@ Before accepting planning, apply this checklist when relevant:
 - relevant cross-cutting system contracts are explicitly defined rather than left to per-module invention
 - each major module has a clear integration contract with existing modules and shared patterns
 - verification plans include cross-module seam checks, not just isolated feature tests
+- visible mismatches are corrected or explicitly dispositioned
+- planning comments and artifacts reflect current policy truth
 
 ## Exit conditions
 

package/assets/skills/{planning-guidance-v2 → planning-guidance}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: planning-guidance-v2
-description: Developer-facing planning guidance for slopmachine-v2.
+name: planning-guidance
+description: Developer-facing planning guidance for slopmachine.
 ---
 
-# Planning Guidance v2
+# Planning Guidance
 
 Use this skill during `P2 Planning` to compose the developer-facing planning prompt.
 
@@ -35,10 +35,17 @@ The goal is to reduce late audit failures by designing for these concerns up fro
 
 - never create or keep `.env` files anywhere in the repo tree
 - do not allow committed `.env` files even as placeholders or examples
-- keep real secrets out of the repository and rely on Docker-provided runtime variables for sensitive values
-- if the stack requires env-file format at runtime, generate it ephemerally from Docker-provided runtime variables rather than storing it in the repo or package
+- keep real secrets out of the repository and use the selected stack's appropriate runtime or platform secret/config mechanism for sensitive values
+- if the stack requires env-file format at runtime, generate it ephemerally from the selected runtime environment rather than storing it in the repo or package
 - verify the delivered project can start from scratch without any preexisting `.env` file in the repo or package
 
+Selected-stack defaults:
+
+- follow the original prompt and existing repository first; use the defaults below only when they do not already specify the platform or stack
+- web backend/fullstack: prefer Docker/runtime-provided variables, never committed env files
+- mobile: use app config only for non-secret public configuration and keep real secrets out of the client bundle
+- desktop: use main-process/runtime configuration and platform-appropriate secure storage when local secret persistence is required
+
 ## Planning guidance
 
 - require implementation-grade planning, not brainstorming
@@ -75,17 +82,30 @@ The goal is to reduce late audit failures by designing for these concerns up fro
 - define auth edge-case expectations when relevant, such as token refresh, session expiry, or clock-skew tolerance
 - call out operational obligations early when they are prompt-critical, such as scheduling, retention, backups, workers, auditability, or offline behavior
 - define infrastructure requirements early when they are material to correctness, such as rate limiting, encryption boundaries, production-equivalent test infrastructure, and browser-storage rules for sensitive data
+- define the project-standard runtime contract and the universal broad test entrypoint `./run_tests.sh` early, and keep both compatible with the selected stack
+- for Dockerized web backend/fullstack projects, the runtime contract may be `docker compose up --build` directly when the prompt or existing repo does not already dictate another stack-compatible contract
+- when `docker compose up --build` is not the runtime contract, require `./run_app.sh` as the single primary runtime wrapper for the project
+- for mobile, desktop, CLI, library, or other non-web projects, `./run_app.sh` should own the selected stack's runtime flow instead of assuming host tooling conventions
+- `./run_tests.sh` must exist for every project as the platform-independent broad test wrapper
+- `./run_tests.sh` must prepare or install anything required before running the tests when that setup is needed for a clean environment
+- for Dockerized web backend/fullstack projects, `./run_tests.sh` must run the full test path through Docker rather than a purely local test invocation
+- for non-web or non-Docker projects, `./run_tests.sh` must call the selected stack's equivalent full test path while keeping the same single-command interface
+- local tests should still exist for ordinary developer iteration, but `./run_tests.sh` is the broad final test path for the project
 - define frontend validation and accessibility expectations when the product surface materially depends on them, including keyboard, focus, feedback, and other user-interaction quality requirements where relevant
 - if backup or recovery behavior is prompt-critical, plan the designated media, operator drill flow, visibility, and verification expectations explicitly
 - if the prompt names literal storage, indexing, partitioning, retention, or performance dimensions, represent them literally in the planning artifacts rather than abstracting them away
-- for frontend work, unless the prompt, existing repository, or established stack clearly dictates otherwise, default to Tailwind CSS for styling and `shadcn/ui` for component primitives
+- for web frontend work, unless the prompt, existing repository, or established stack clearly dictates otherwise, default to Tailwind CSS for styling and `shadcn/ui` for component primitives
 - if the existing project already uses a different UI system, preserve and extend that system instead of forcing Tailwind CSS or `shadcn/ui` into it
+- for mobile work, unless the prompt or existing repository clearly dictates otherwise, default to Expo + React Native + TypeScript
+- for desktop work, unless the prompt or existing repository clearly dictates otherwise, default to Electron + Vite + TypeScript
 - define end-to-end coverage for major user flows before coding
 - define enough test coverage up front to catch major issues later, especially core happy path, important failure paths, security-critical paths, and obvious high-risk boundaries
-- for fullstack work, explicitly plan Playwright coverage for the synchronized frontend/backend flows when end-to-end testing is applicable
-- when UI-bearing flows are material, explicitly plan screenshot review as part of Playwright verification so UI correctness is checked, not just browser success
+- for web fullstack work, explicitly plan Playwright coverage for the synchronized frontend/backend flows when end-to-end testing is applicable
+- for mobile work, plan Jest plus React Native Testing Library as the local default test layer and add a platform-appropriate mobile UI/E2E tool when real device-flow proof is needed
+- for desktop work, plan a local desktop test runner plus Playwright Electron support or another platform-appropriate desktop UI/E2E tool when real window-flow proof is needed
+- when UI-bearing flows are material, explicitly plan screenshot review or equivalent platform artifacts as part of UI verification so correctness is checked, not just command success
 - aim for at least 90 percent meaningful coverage of the relevant behavior surface
-- define verification strategy, Docker expectations, and documentation implications before coding
+- define verification strategy, selected-stack runtime expectations, and documentation implications before coding
 - make major engineering quality a planning concern by defining maintainable boundaries, separation of concerns, shared patterns, extension points, and anti-chaos constraints before coding begins
 - for each major module, define how it integrates with existing modules and which shared contracts it must follow consistently
 - define verification plans that include cross-module scenarios and seam checks, not just isolated feature checks

package/assets/skills/{remediation-guidance-v2 → remediation-guidance}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: remediation-guidance-v2
-description: Focused remediation rules for slopmachine-v2.
+name: remediation-guidance
+description: Focused remediation rules for slopmachine.
 ---
 
-# Remediation Guidance v2
+# Remediation Guidance
 
 Use this skill only during `P9 Remediation`.
 

package/assets/skills/{report-output-discipline-v2 → report-output-discipline}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: report-output-discipline-v2
-description: File-backed reporting discipline for slopmachine-v2.
+name: report-output-discipline
+description: File-backed reporting discipline for slopmachine.
 ---
 
-# Report Output Discipline v2
+# Report Output Discipline
 
 Use this skill whenever an owner-side review or evaluation task would otherwise dump a large report into chat.
 

package/assets/skills/retrospective-analysis/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: retrospective-analysis
+description: Owner-only final retrospective rules for slopmachine.
+---
+
+# Retrospective Analysis
+
+Use this skill only after `P10 Submission Packaging` has materially and formally succeeded.
+
+## Purpose
+
+- inspect what happened across the whole workflow run
+- identify what caused churn, waste, late defects, or preventable corrections
+- capture lessons that should improve future runs
+- write package-specific retrospective files under `~/slopmachine/retrospectives/`
+
+## Phase role
+
+- this is an automatic owner-only phase
+- it is quiet and non-blocking by default
+- it does not create a new human stop
+- it does not rerun broad verification by default
+- it should not reopen development unless it finds a real defect in the already-packaged result
+
+## Output location
+
+Write dated retrospective files under:
+
+- `~/slopmachine/retrospectives/`
+
+Preferred filenames:
+
+- `retrospective-YYYY-MM-DD.md`
+- `improvement-actions-YYYY-MM-DD.md`
+
+If only one file is needed, the retrospective file is sufficient.
+
+## Evidence sources
+
+Prefer existing workflow artifacts first:
+
+- root metadata
+- questions/clarification record
+- clarification prompt
+- planning artifacts
+- Beads comments and transitions
+- developer-session handoffs
+- review and rejection history
+- verification gate notes
+- evaluation reports
+- remediation records
+- packaging outputs
+
+Do not reread the entire codebase unless a real inconsistency requires it.
+Do not rerun broad Docker or full-suite verification just for retrospective analysis.
+
+## Required retrospective sections
+
+1. outcome summary
+2. what worked well
+3. what caused waste or looping
+4. what was caught too late
+5. findings by phase
+6. findings by instruction plane:
+   - owner shell
+   - developer prompt
+   - skills
+   - `AGENTS.md`
+7. actionable improvements
+
+## Audit buckets
+
+Evaluate at least these buckets in hindsight:
+
+1. prompt-fit
+2. security-critical flaws
+3. test sufficiency
+4. major engineering quality
+5. token/time waste
+
+For each meaningful finding, prefer:
+
+- what happened
+- why it happened
+- where the fix belongs
+- how it should change future runs
+
+## Rule for reopening work
+
+- if retrospective finds a real packaging or delivery defect, reopen `P10` and fix it
+- if it finds only improvements, document them and close the retrospective phase

package/assets/skills/scaffold-guidance/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: scaffold-guidance
+description: Developer-facing scaffold guidance for slopmachine.
+---
+
+# Scaffold Guidance
+
+Use this skill during `P3 Scaffold` before prompting the developer.
+
+## Scaffold standard
+
+- create real foundations, not decorative boilerplate
+- establish the real runtime contract
+- establish the local verification path and the standardized gate path
+- make prompt-critical baseline behavior real where required
+- keep repo-local `README.md` honest from the start
+- make the selected-stack primary runtime command and the universal `./run_tests.sh` broad test command real from the scaffold stage
+
+For Dockerized web backend/fullstack projects, scaffold must make these commands real and working before scaffold can pass:
+
+- `docker compose up --build`
+- `./run_tests.sh`
+
+## Scaffold and foundation guidance
+
+- create the initial project structure intentionally
+- follow the original prompt and existing repository first; only use the package defaults below when they do not already specify the platform or stack
+- create `./run_tests.sh` during scaffold for every project as the single broad test entrypoint
+- for Dockerized web backend/fullstack projects, make `docker compose up --build` real as the primary runtime command during scaffold
+- when `docker compose up --build` is not the runtime contract, create `./run_app.sh` during scaffold as the single primary runtime wrapper
+- make `./run_tests.sh` self-sufficient from a clean environment by preparing or installing anything it needs before executing the tests
+- for Dockerized web backend/fullstack projects, `./run_tests.sh` must execute the broad test path through Docker and should own that Dockerized test flow directly instead of requiring separate manual pre-setup
+- for non-web or non-Docker projects, `./run_tests.sh` must execute the selected stack's platform-equivalent broad test flow while preserving the same single-command interface
+- local non-Docker test commands should still be installed and working for normal development iteration
+- create required testing directories and baseline docs structure
+- put baseline config and logging structure in place
+- install and configure the local test tooling needed for ordinary iteration during scaffold rather than deferring local testing setup to later phases
+- for web UI projects, install the local browser E2E tooling during scaffold when the project will need it
+- for mobile projects, install the local mobile testing layer during scaffold, defaulting to Jest plus React Native Testing Library for Expo/React Native work
+- for desktop projects, install the local desktop testing layer during scaffold, defaulting to the selected project test runner and Playwright Electron support or an equivalent desktop UI/E2E tool when UI verification is required
+- put migrations, worker/job foundation, and real runtime health surfaces in place when the project needs them
+- treat prompt-critical security controls as real baseline runtime behavior, not placeholder checks or visual wiring
+- if a requirement implies enforcement, persistence, statefulness, or rejection behavior, make that behavior real in the scaffold unless the prompt clearly scopes it down
+- do not accept shape-only security implementations such as header presence checks, passive constants, or partially wired middleware when the requirement implies real protection
+- when applicable at scaffold time, require platform-appropriate real security baselines rather than shape-only placeholders
+- for web service flows, examples include nonce replay rejection, real lockout behavior, CSRF rejection on protected mutations, and meaningful server-side state when the protection model depends on it
+- for mobile flows, examples include safe auth-state handling, no bundled secrets, secure token storage when runtime tokens must be persisted, and protected deep-link or privileged screen behavior when applicable
+- for desktop flows, examples include secure preload/contextBridge boundaries, `contextIsolation` preserved, `nodeIntegration` not exposed by default in the renderer, and privileged actions kept out of untrusted renderer reach
+- remove prototype residue from runtime foundations: no placeholder titles, hidden setup, fake defaults, or seeded live-path assumptions
+- make prompt-critical runtime behavior visible in the scaffold instead of hand-waving it for later, especially offline, worker, backup, or HTTPS requirements
+- for Dockerized web projects, keep runtime isolation clean in shared environments: use self-contained Compose namespacing, avoid fragile generic project names, and prefer Compose-managed service naming over unnecessary hardcoded `container_name` values
+- require reproducible build and tooling foundations: prefer lockfile-driven installs where the stack supports them, keep source and build outputs clearly separated, and do not allow generated runtime artifacts to drift back into source directories
+- for typed build pipelines, keep source-of-truth boundaries clean so compiled output does not create TS/JS or similar dual-source drift in the working tree
+- establish README structure early instead of leaving it until the end
+- ensure `README.md` clearly documents the primary runtime command and the broad `./run_tests.sh` contract for the selected stack
+- prove the scaffold in a clean state before deeper feature work
+- verify clean startup and teardown behavior under the selected stack's runtime contract
+- for Dockerized web projects, verify clean startup and teardown behavior under the chosen project namespace
+- when the architecture materially depends on infrastructure capabilities such as rate limiting, encryption, offline support, or browser-storage policy, put the baseline framework and policy in place during scaffold rather than deferring it to late implementation
+- for backend integration paths, prefer production-equivalent test infrastructure when practical rather than silently substituting a weaker database or runtime model that can hide real defects
+- do not treat scaffold as placeholder boilerplate or rely on hidden setup
+
+## Current policy
+
+- no `.env` files or env-file variants in the repo
+- do not edit `AGENTS.md` or other workflow/rulebook files unless explicitly asked
+- keep generated artifacts out of source-of-truth paths
+- keep real secrets out of the repository and use the selected stack's runtime/platform mechanism for sensitive values
+- if the stack requires env-file format at runtime, generate it ephemerally from the selected runtime environment rather than storing it in the repo or package
+
+## Acceptance target
+
+Scaffold should make later slices easier, not force them to retrofit missing fundamentals.
+
+## Verification cadence
+
+- use local and narrow checks while correcting scaffold work
+- reserve one broad owner-run scaffold gate for actual scaffold acceptance
+- do not spend extra broad reruns once the acceptance question is already answered
+- for Dockerized web backend/fullstack projects, the owner must run `docker compose up --build` and `./run_tests.sh` once after scaffold completion to confirm the baseline actually works
+- after that scaffold confirmation, do not run Docker again during ordinary development work; the next Docker-based run should be at development completion when integrated behavior is checked

package/assets/skills/{session-rollover-v2 → session-rollover}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: session-rollover-v2
-description: Planned developer-session handoff and rollover rules for bounded slopmachine-v2 developer sessions.
+name: session-rollover
+description: Planned developer-session handoff and rollover rules for bounded slopmachine developer sessions.
 ---
 
-# Session Rollover v2
+# Session Rollover
 
 Use this skill only when intentionally moving from one planned developer session slot to the next.