theslopmachine 0.4.2 → 0.4.5

package/assets/skills/developer-session-lifecycle/SKILL.md

@@ -11,7 +11,7 @@ Use this skill during `P0 Intake and Setup` and whenever startup or recovery sta
 
 - detect whether the run is new or resumed
 - initialize or recover workflow metadata consistently
-- initialize the planned bounded developer-session slots
+- initialize developer-session tracking for the run
 - recover the current active developer session when one already exists
 
 ## Usage rules
@@ -55,11 +55,11 @@ Optional startup inputs may include:
 2. create `../.ai/metadata.json` for internal workflow state
 3. initialize parent-root `../metadata.json` with the required schema and store the full prompt text in `prompt`
 4. initialize root workflow state and top-level phase Beads items
-5. complete clarification using the clarification skill
-6. wait only for the initial clarification approval before development starts
-7. ensure the parent project root has the required working structure, especially `../sessions/` and `../docs/`
-8. initialize the bounded developer-session slots
-9. start the build developer session only after `P2` is ready to begin
+5. ensure the parent project root has the required working structure, especially `../sessions/` and `../docs/`
+6. complete clarification using the clarification skill
+7. wait only for the initial clarification approval before development starts
+8. initialize developer-session tracking for the run
+9. start the develop developer session only after `P2` is ready to begin
 10. send this exact first planning opener as the first message in that session: `lets plan this <original-prompt>`
 11. wait for the developer's first exchange
 12. send the approved clarification prompt as the second owner message in that same session
@@ -67,9 +67,9 @@ Optional startup inputs may include:
 
 ## First developer-session handshake
 
-The first bounded developer session must begin in this exact order:
+The first developer session of the run must begin in this exact order:
 
-1. owner starts the build developer session
+1. owner starts the develop developer session
 2. owner sends: `lets plan this <original-prompt>`
 3. developer responds
 4. owner sends the approved clarification prompt
@@ -84,7 +84,7 @@ Do not merge those two messages into one.
 - root workflow state exists
 - `../.ai/metadata.json` exists
 - `../metadata.json` exists
-- planned developer session slots are initialized
+- developer-session tracking is initialized
 - required parent-root directories exist
 
 ## Metadata and workflow files
@@ -107,19 +107,26 @@ Track at least:
 - `backend_evaluation_session_id`
 - `frontend_evaluation_session_id`
 - `last_evaluation_session_id`
+- `backend_evaluation_report_path`
+- `frontend_evaluation_report_path`
 - `passed_evaluation_tracks`
 - `developer_sessions`
-- `active_developer_session_index`
+- `active_developer_session_id`
+- `next_develop_session_number`
+- `next_bugfix_session_number`
+- `submission_completed`
 
-Each planned developer session record should include enough to recover it later, such as:
+Each developer session record should include enough to recover and export it later, such as:
 
-- `index`
+- `session_class`
+- `sequence`
 - `label`
-- `phase_group`
+- `created_phase`
 - `session_id`
 - `status`
 - `handoff_in`
 - `handoff_out`
+- `reopened_after_submission`
 
 Required project metadata fields in `../metadata.json` when relevant:
 
@@ -136,20 +143,29 @@ Required project metadata fields in `../metadata.json` when relevant:
 - fill known values immediately and keep the file current as the project becomes clearer
 - prefer explicit values; use `null` only when a field is genuinely unknown or not applicable
 
-## Bounded session model
+## Session model
 
-Track up to three planned developer sessions:
+- keep exactly one active developer session at a time
+- record every developer session in `developer_sessions`
+- classify sessions as `develop` or `bugfix`
+- every session created before the first successful submission packaging is `develop`
+- every session created after successful submission packaging to address external evaluation follow-up is `bugfix`
+- create a new developer session only when:
+  - the user explicitly requests a new session
+  - post-submission external evaluation feedback reopens the project for more fixes
 
-1. build
-2. stabilization
-3. remediation
+If the user explicitly requests a new session while one is active:
 
-Later session slots may remain unused if the workflow never needs them.
+1. ask the current developer exactly: `give me a summary of all the work that has been done`
+2. treat that reply as the handoff summary
+3. start the new developer session with that summary as the handoff-in context
+4. keep the session class as `develop` before first successful submission, otherwise keep it as `bugfix`
 
 ## Initial structure rule
 
 - parent-root `../docs/` is the owner-maintained external documentation directory
 - parent-root `../sessions/` is the session artifact directory for exported conversation traces
+- `../docs/questions.md` is a mandatory project artifact produced during clarification and preserved through packaging
 - do not treat repo-local `docs/` as the active external documentation location
 
 ## Recovery rule

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

@@ -29,7 +29,7 @@ Use this skill during `P4 Development` before prompting the developer.
 - verify tenant or ownership isolation where relevant so access is scoped to the authorized context rather than merely functionally working for one actor
 - verify file and export paths are validated and confined to allowed roots when the module reads, writes, imports, or exports files
 - verify error and auth responses are user-safe and do not leak internal reasons, paths, stack details, or sensitive state
-- perform a clean-slate sweep before reporting module completion: remove seeded credentials, weak demo defaults, test-account hints, prototype residue, and other production-inappropriate artifacts
+- perform a clean-slate sweep before reporting module completion: remove weak demo defaults, stray test-account hints, prototype residue, and other production-inappropriate artifacts; deterministic non-secret Dockerized dev/test default credentials are allowed only when clearly labeled local-only and required for startup or test stability
 - do not treat backend existence, composable existence, or partial wiring as completion if the user-visible flow is still incomplete
 - when the prompt says users can manage or configure something, implement full management behavior rather than create-only controls where appropriate
 - if a required user-facing or admin-facing surface is missing, treat that gap as incomplete implementation rather than a reason to bypass the surface with direct API calls or test-only shortcuts
@@ -54,6 +54,7 @@ Use this skill during `P4 Development` before prompting the developer.
 - for mobile projects, default local UI testing to the selected mobile test stack and use a platform-appropriate mobile UI/E2E tool when device-flow proof matters
 - for desktop projects, default local UI verification to Playwright's Electron support or another platform-appropriate desktop UI/E2E tool when window-flow proof matters
 - when the slice materially changes frontend code, frontend tooling, or release-facing build behavior, include production build health in meaningful local verification when practical
+- in each slice reply, report the exact verification commands that were run and the concrete results they produced so the owner can review the evidence without blindly rerunning the same commands
 
 ## Quality rules
 

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

@@ -36,12 +36,13 @@ These two files are the only evaluation prompt sources for evaluation runs.
 - 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
-- never reuse, resume, or continue a prior evaluation session
+- do not reuse, resume, or continue a prior evaluation session except for the explicit pass-3 fallback on the last still-failing track
 - 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
+- record the current accepted backend and frontend evaluation report paths in metadata for later packaging
 - 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
@@ -61,7 +62,7 @@ These two files are the only evaluation prompt sources for evaluation runs.
 
 ## Remediation loop
 
-- route accepted blocking issues back into the active remediation developer-session slot rather than inventing an untracked side path
+- route accepted blocking issues back into the active developer session 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

package/assets/skills/integrated-verification/SKILL.md

@@ -23,6 +23,8 @@ 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
+- when sending a developer fix request for integrated-verification failures, require the reply to name the exact rerun commands and the concrete results they produced
+- do not reflexively rerun the same expensive local test or E2E command on the owner side when the developer's reported evidence is already clear and sufficient
 - 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

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

@@ -91,6 +91,9 @@ Selected-stack defaults:
 - 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
+- for Dockerized web backend/fullstack projects, plan collision-resistant Compose defaults from the start: unique `COMPOSE_PROJECT_NAME`, no unnecessary `container_name`, only the app-facing port exposed to host by default, and internal services kept off host ports unless required
+- for Dockerized web backend/fullstack projects, prefer random host-port binding on `127.0.0.1` for the default runtime so parallel projects can start cleanly; if a fixed host port is genuinely required, plan an override plus a free-port fallback in the runtime or test wrapper
+- when Dockerized dev/test runtime or tests require credentials or bootstrap accounts, plan deterministic non-secret default runtime env values through Compose or wrapper configuration so local startup does not fail on missing credentials, while keeping those defaults out of `.env` files and out of Dockerfile image layers
 - 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
@@ -110,7 +113,7 @@ Selected-stack defaults:
 - 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
 - surface real unresolved risks honestly
-- keep the plan aligned with current policy: owner-managed external docs, no `.env` files, junior-friendly repo-local README, and the v2 verification cadence
+- keep the plan aligned with current policy: owner-managed external docs, no `.env` files, junior-friendly repo-local README, and the current verification cadence
 
 ## Exit target
 

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

@@ -21,7 +21,7 @@ Use this skill only during `P9 Remediation`.
 - rerun the relevant verification after each fix
 - if the issue exposed drift, docs overclaim, or missing acceptance coverage, repair that too before closing the issue
 - update docs if behavior or instructions changed
-- report exactly what was fixed, what was rerun, and what still looks risky if anything remains
+- report exactly what was fixed, the exact verification commands that were rerun, the concrete results they produced, and what still looks risky if anything remains
 
 ## Rules
 

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

@@ -24,17 +24,19 @@ Use this skill only after `P10 Submission Packaging` has materially and formally
 
 ## Output location
 
-Write dated retrospective files under:
+Write run-scoped retrospective files under:
 
 - `~/slopmachine/retrospectives/`
 
 Preferred filenames:
 
-- `retrospective-YYYY-MM-DD.md`
-- `improvement-actions-YYYY-MM-DD.md`
+- `retrospective-<run_id>.md`
+- `improvement-actions-<run_id>.md`
 
 If only one file is needed, the retrospective file is sufficient.
 
+The `run_id` must come from the current project's `../.ai/metadata.json` so the retrospective can be matched back to one exact workflow run.
+
 ## Evidence sources
 
 Prefer existing workflow artifacts first:

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

@@ -49,6 +49,13 @@ For Dockerized web backend/fullstack projects, scaffold must make these commands
 - 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
+- for Dockerized web projects, derive a unique `COMPOSE_PROJECT_NAME` from the repo or worktree identity for runtime wrappers, and use a separate unique test namespace for `./run_tests.sh` so parallel local projects do not collide
+- for Dockerized web projects, expose only the primary app-facing port to the host by default, keep databases/cache/internal services off host ports unless the prompt truly requires exposure, and bind exposed ports to `127.0.0.1`
+- for Dockerized web projects, prefer Docker-assigned random host ports for the default host binding so plain `docker compose up --build` can run without host-port collisions; if the prompt requires a fixed host port, support an overrideable host-port variable and make the runtime or test wrapper fall back to a free port automatically when needed
+- for Dockerized web projects, keep image, network, and volume naming under Compose project scoping; if explicit image names are needed, namespace them with the Compose project name instead of using generic shared names
+- for Dockerized web projects, add healthchecks and make runtime or test wrappers wait for service readiness before proceeding so startup is reliable on slower machines
+- when Dockerized dev/test startup or tests require credentials or bootstrap accounts, provide deterministic non-secret default values through Compose/runtime environment configuration so `docker compose up --build` and `./run_tests.sh` do not fail due to missing credentials
+- keep those Dockerized dev/test default credentials clearly marked as local-only test credentials, do not store them in `.env` files, and do not bake them into the Dockerfile image layers
 - 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

package/assets/skills/session-rollover/SKILL.md

@@ -1,23 +1,36 @@
 ---
 name: session-rollover
-description: Planned developer-session handoff and rollover rules for bounded slopmachine developer sessions.
+description: Developer-session handoff and rollover rules for intentional slopmachine session switches.
 ---
 
 # Session Rollover
 
-Use this skill only when intentionally moving from one planned developer session slot to the next.
+Use this skill only when intentionally starting a new developer session while preserving the old one as history.
 
 ## Typical uses
 
-- build session -> stabilization session
-- stabilization session -> remediation session
+- the user explicitly asks for a new developer session
+- post-submission external evaluation feedback reopens the project for more fixes
 
 ## Rules
 
-- rollover is planned, not a recovery event
+- rollover is intentional, not a recovery event
+- keep exactly one active developer session at a time
 - do not open the next developer session until the current session has a clear handoff out
 - record the new session id and status immediately after the new session is created
 
+If the user explicitly requests a new session while one is active:
+
+1. ask the current developer exactly: `give me a summary of all the work that has been done`
+2. store that reply as the handoff artifact for the closing session
+3. start the new developer session with that summary as the handoff-in context
+
+If the project is reopened after successful submission because of external evaluation feedback:
+
+1. record the external issue list and any accepted evaluation report references in the handoff
+2. start a new `bugfix` developer session
+3. use that external feedback plus the handoff summary as the starting context
+
 ## Required handoff contents
 
 - current phase and why rollover is happening
@@ -33,7 +46,8 @@ When rollover succeeds, update metadata so it is obvious:
 - which prior session is now completed or inactive
 - which new session is active
 - where the handoff artifact lives
-- which phase group the new session now owns
+- which session class the new session belongs to
+- whether the new session was opened after successful submission
 
 ## Avoid
 

package/assets/skills/submission-packaging/SKILL.md

@@ -73,14 +73,16 @@ The final submission layout in the parent project root must be:
   - `questions.md`
 - `submission/`
   - generated submission documents based on the reference files in `~/`
-  - evaluation reports
+  - `backend-evaluation-report.md` when applicable
+  - `frontend-evaluation-report.md` when applicable
+  - cleaned original session exports for every tracked developer session
   - repo file structure screenshot
   - working app screenshots
   - relocated screenshots and proof materials needed for submission review
 - current working directory delivered as parent-root `repo/`
 - `../sessions/`
-  - `develop-N.json`
-  - `bugfix-N.json`
+  - converted `develop-N.json` session exports for all pre-submission developer sessions
+  - converted `bugfix-N.json` session exports for all post-submission external-follow-up developer sessions
 - `../metadata.json`
 - parent-root `../.tmp/` directory moved out of current `.tmp/` when it exists
 
@@ -91,7 +93,7 @@ The final submission layout in the parent project root must be:
 - verify parent-root `../docs/design.md` exists and reflects the final delivered design when applicable
 - verify parent-root `../docs/api-spec.md` exists and reflects the final delivered interfaces when applicable
 - verify parent-root `../docs/test-coverage.md` exists and reflects the final delivered verification coverage
-- verify parent-root `../docs/questions.md` exists from the accepted clarification/question record when applicable
+- verify parent-root `../docs/questions.md` exists from the accepted clarification/question record
 - create parent-root `../submission/` for final generated submission artifacts and reviewer-facing proof
 - use these exact `~/slopmachine/` document templates as the packaging reference sources:
   - `~/slopmachine/document-completeness.md`
@@ -100,11 +102,13 @@ The final submission layout in the parent project root must be:
   - `~/slopmachine/quality-document.md`
 - ensure `README.md` matches the delivered codebase, functionality, runtime steps, and test steps, stays friendly to a junior developer, and does not reference the external docs set in `../docs/`
 - include `./run_tests.sh` and any supporting runner logic it needs to execute the project's broad test path from a clean environment
-- relocate evaluation artifacts into parent-root `../submission/`
+- relocate accepted backend and frontend evaluation reports into parent-root `../submission/` as `backend-evaluation-report.md` and `frontend-evaluation-report.md` when those tracks apply
 - relocate screenshots and proof materials relevant to runtime behavior and major flows into parent-root `../submission/`
 - preserve parent-root `../sessions/` as the session artifact directory for converted workflow session exports
 - export all tracked workflow sessions before generating the final submission documents
-- after the session exports are complete, use the last evaluation session recorded in metadata when generating the final submission report content so the report answers can come from cached evaluation context instead of rebuilding that context from scratch
+- preserve all cleaned original session exports under parent-root `../submission/`
+- when packaging succeeds, mark `submission_completed` as true in internal metadata so later reopen handling can classify post-submission sessions correctly
+- after the session exports are complete, the owner should answer the final submission-document questions based on the recent review responses gathered across evaluation reports, remediation results, verification notes, and packaging checks
 
 ## Session export sequence
 
@@ -112,22 +116,34 @@ This export sequence must happen first in packaging, before final submission doc
 
 Export every tracked workflow session from metadata.
 
+Use a class-and-sequence label for each tracked session, for example:
+
+- `develop-1`
+- `develop-2`
+- `bugfix-1`
+
 For each tracked session:
 
 1. `opencode export <session-id> > ../session-export-<label>.json`
 2. `python3 ~/utils/strip_session_parent.py ../session-export-<label>.json --output ../session-clean-<label>.json`
 3. `python3 ~/utils/convert_ai_session.py -i ../session-clean-<label>.json -o ../sessions/<final-name>.json`
+4. copy `../session-clean-<label>.json` to `../submission/session-clean-<label>.json`
 
 Naming rule for converted files under `../sessions/`:
 
-- development-phase sessions become `develop-N.json`
-- hardening or remediation sessions become `bugfix-N.json`
+- every pre-submission developer session becomes `develop-N.json`
+- every post-submission external-follow-up developer session becomes `bugfix-N.json`
+
+Naming rule for cleaned original session exports under `../submission/`:
+
+- `session-clean-develop-N.json`
+- `session-clean-bugfix-N.json`
 
 After those steps:
 
-- verify every planned developer session has been exported and converted before continuing packaging
+- verify every tracked developer session has been exported, cleaned, converted, and copied into `../submission/` before continuing packaging
 - keep the converted session outputs in `../sessions/` using the naming rules above
-- treat the `../session-export-*.json` and `../session-clean-*.json` files as temporary packaging intermediates unless the package contract later says otherwise
+- treat only the raw `../session-export-*.json` files as temporary packaging intermediates unless the package contract later says otherwise
 - if the required utilities, metadata session ids, or output files are missing, packaging is not ready to continue
 - only after these exports are complete may you generate the final submission documents
 
@@ -135,19 +151,19 @@ After those steps:
 
 After all session exports are complete:
 
-1. recover the last evaluation session id from metadata
-2. use that last evaluation session to answer the final submission-document questions from its cached context
-3. generate the required final submission documents from that evaluation context plus the canonical `~/slopmachine/` reference files
+1. gather the recent review responses from evaluation reports, accepted triage notes, remediation outcomes, verification notes, and packaging checks
+2. answer the final submission-document questions from that gathered review evidence
+3. generate the required final submission documents from that gathered review evidence plus the canonical `~/slopmachine/` reference files
 
 Do not start generating the final submission documents before the session exports are complete.
-Do not create a new evaluation session for final report generation if the last evaluation session is still available.
-If the last evaluation session id is missing or unusable, stop and repair metadata/session recovery before continuing packaging.
+Do not rely on one single cached evaluation session as the only source for final submission-document answers.
+If the gathered review evidence is incomplete, stop and repair the missing evidence before continuing packaging.
 
 ## Required file moves
 
 - if repo-local `docs/` exists, treat it as accidental residue, reconcile any missing content into parent-root `../docs/`, and remove it from the delivered `repo/` tree
 - if current `.tmp/` exists, move the whole directory to parent-root `../.tmp/` before harvesting any reviewer-facing artifacts from it
-- after preserving parent-root `../.tmp/`, collect the relevant evaluation reports and proof artifacts from it into parent-root `../submission/`
+- after preserving parent-root `../.tmp/`, collect the accepted backend and frontend evaluation reports plus other relevant proof artifacts into parent-root `../submission/`
 - collect screenshots and other required proof materials from repo-local runtime/output directories into parent-root `../submission/`
 - after relocation, the final submission should not require digging through repo-local output directories to find evidence
 - keep screenshot filenames clear enough that the referenced runtime page, flow, or evidence purpose is understandable
@@ -166,13 +182,15 @@ If the last evaluation session id is missing or unusable, stop and repair metada
 - confirm docs describe delivered behavior, not planned or aspirational behavior
 - confirm parent-root `../docs/test-coverage.md` explains the tested flows, coverage boundaries, and how the evaluator should interpret the coverage evidence
 - confirm generated submission documents exist under parent-root `../submission/` and correspond to the final qualified state
-- confirm evaluation reports and screenshots have been relocated into parent-root `../submission/`
+- confirm accepted backend and frontend evaluation reports have been relocated into parent-root `../submission/` when those tracks apply
+- confirm cleaned original session exports for every tracked developer session exist under parent-root `../submission/`
 - confirm shared project docs live in parent-root `../docs/` and any accidental repo-local `docs/` copy has been removed from the delivered tree
 - confirm required screenshots have been relocated into parent-root `../submission/`
 - confirm parent-root metadata fields are populated correctly
+- confirm internal metadata marks `submission_completed` as true for a successful packaged state
 - confirm session export naming rules are followed under `../sessions/`:
-  - `develop-N.json` for development-phase sessions
-  - `bugfix-N.json` for hardening/remediation sessions
+  - `develop-N.json` for every pre-submission developer session
+  - `bugfix-N.json` for every post-submission external-follow-up developer session
 
 ## Submission artifact and response contract
 

package/assets/skills/verification-gates/SKILL.md

@@ -42,7 +42,8 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - do not accept frontend/backend drift in fullstack work
 - do not accept missing end-to-end coverage for major fullstack flows
 - do not accept UI claims without screenshot-backed or platform-equivalent visual evidence when the change affects real UI behavior
-- do not accept prototype residue such as seeded credentials, weak demo defaults, login hints, or unsanitized user-facing error behavior
+- do not accept production-inappropriate residue such as weak demo defaults, stray login hints, or unsanitized user-facing error behavior
+- deterministic non-secret Dockerized dev/test default credentials are acceptable only when they are clearly labeled local-only, supplied through runtime configuration rather than `.env` files or Dockerfile image layers, and required so local startup or tests do not fail on missing credentials
 - do not accept multi-tenant or cross-user security claims without negative isolation evidence when that boundary matters
 - do not accept file-bearing flows without path confinement and traversal-style validation when that boundary matters
 - do not accept partial foundation work for complex features when the prompt implies broader usable scope, infrastructure depth, or security depth than what was actually delivered
@@ -55,6 +56,8 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - use targeted local verification as the default during scaffold corrections, development, hardening, and remediation
 - reserve the selected stack's broad verification path for the limited owner-run gate moments in the workflow budget
 - do not turn ordinary acceptance into repeated integrated-style gate runs
+- do not run `./run_tests.sh` casually on the owner side
+- do not run `docker compose up --build` casually on the owner side
 - 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 scaffold baseline
 - after that scaffold confirmation, the next Docker-based run should be at development completion or integrated-verification entry unless a real blocker forces earlier escalation
 
@@ -64,10 +67,12 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - review technical quality, prompt alignment, architecture impact, and verification depth of the current work
 - during normal implementation iteration, always prefer fast local language-native or framework-native verification for the changed area instead of the selected stack's broad gate path
 - require the developer to set up and use the project-appropriate local test environment in the current working directory when normal local verification is needed
+- require the developer to report the exact verification commands that were run and the concrete results they produced
 - require local runtime proof when relevant by starting the app or service through the selected stack's local run path and exercising the changed behavior directly rather than jumping to the broad gate path
 - if the local toolchain is missing, require the developer to install or enable it first; do not jump to the broad gate path during ordinary iteration just because local setup is inconvenient
 - do not accept hand-wavy claims that local verification is unavailable without a real setup attempt and clear explanation
 - for applicable UI-bearing work, require the selected stack's local UI/E2E tool on affected flows plus screenshot review or equivalent platform artifacts and explicit UI validation
+- if the developer already ran the relevant targeted test or E2E command and reported it clearly, do not rerun the same command on the owner side unless the evidence is weak, contradictory, flaky, high-risk, or needed to answer a new question
 - if verification is weak, missing, or failing, require fixes and reruns before acceptance
 - if documentation or repo hygiene drifts, secrets leak, contracts drift, or frontend integrity is compromised, require cleanup before acceptance
 - keep looping until the current work is genuinely acceptable
@@ -77,7 +82,7 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - a broad gate is an owner-run integrated verification boundary, not every ordinary phase change
 - a phase change alone does not automatically require a broad gate unless that phase exit explicitly calls for one
 - a broad gate normally means some combination of full clean runtime proof, `./run_tests.sh`, and platform-appropriate UI/E2E evidence when UI-bearing flows exist
-- in v2, the workflow target is at most 3 broad owner-run verification moments across the whole cycle
+- the workflow target is at most 3 broad owner-run verification moments across the whole cycle
 - ordinary planning, ordinary slice acceptance, and routine in-phase verification are not broad gates by default and should rely on targeted local verification unless the risk profile says otherwise
 
 For Dockerized web backend/fullstack projects, the default Docker cadence is:
@@ -101,6 +106,8 @@ Use evidence such as internal metadata files, structured Beads comments, verific
 - when scaffold includes prompt-critical security controls, acceptance requires real runtime or endpoint verification of the protection rather than helper-only or shape-only proof
 - for security-bearing scaffolds, require applicable rejection evidence such as stale replay rejection, nonce reuse rejection, CSRF rejection on protected mutations, lockout triggering when lockout is in scope, or equivalent proof that the control is truly enforced
 - scaffold acceptance also requires clean startup and teardown behavior in the selected runtime model; for Dockerized web projects this includes self-contained Compose namespacing and no unnecessary fragile `container_name` usage
+- for Dockerized web projects, scaffold acceptance also requires collision-resistant shared-machine defaults: only the primary app-facing port exposed to host by default, internal services not bound to host without prompt need, default host binding on `127.0.0.1`, and either random host-port assignment or a real free-port fallback when fixed ports are required
+- for Dockerized web projects, scaffold acceptance also requires deterministic non-secret local-only default credentials in runtime configuration when startup or tests depend on credentials, and those defaults must not live in `.env` files or Dockerfile image layers
 - for Dockerized web backend/fullstack projects, scaffold acceptance is not complete until the owner has actually run `docker compose up --build` and `./run_tests.sh` once successfully after scaffold completion
 - module implementation requires platform-appropriate local verification and selected-stack UI/E2E evidence when UI-bearing flows are material
 - module implementation acceptance should challenge tenant isolation, path confinement, sanitized error behavior, prototype residue, integration seams, and cross-cutting consistency when those concerns are in scope

package/assets/slopmachine/document-completeness.md

@@ -1,45 +1,59 @@
-## 5.1 Document Completeness
+## Delivery Completeness Template
+
+Use this file as the structure reference for the delivery-completeness and hard-threshold submission outputs.
+
+Do not copy sample-project content into the final document.
+Replace every placeholder with evidence from the current delivered project.
+
+## Document completeness
 
 | Document Type | File Path | Completeness | Description |
 | :---- | :---- | :---- | :---- |
-| **User Instructions** | README.md | ✅ Complete | Includes functional features, installation steps, and usage guides |
-| **Testing Instructions** | TESTING.md | ✅ Complete | Test environment isolation and execution methods |
-| **Data Persistence Instructions** | DATA\_PERSISTENCE.md | ✅ Complete | Docker volume mounting and data protection |
+| **User Instructions** | `<path>` | `<Complete/Partial/Missing>` | `<what is present and whether it is enough>` |
+| **Testing Instructions** | `<path>` | `<Complete/Partial/Missing>` | `<how local and broad test paths are documented>` |
+| **Runtime/Deployment Instructions** | `<path>` | `<Complete/Partial/Missing>` | `<how runtime startup is documented>` |
+| **Other Required Project Docs** | `<path>` | `<Complete/Partial/Missing>` | `<other prompt-required or delivery-required docs>` |
 
-5.2 Code Completeness
+## Code completeness
 
-| Module | Implementation Status | Description |
+| Module / Area | Implementation Status | Description |
 | :---- | :---- | :---- |
-| **Configuration Management** | ✅ Complete | complaint\_system/settings.py |
-| **URL Routing** | ✅ Complete | complaint\_system/urls.py, main/urls.py |
-| **Data Models** | ✅ Complete | main/models.py (FoodVote, Suggestion) |
-| **View Functions** | ✅ Complete | main/views.py (5 view functions) |
-| **Backend Management** | ✅ Complete | main/admin.py |
-| **Template Files** | ✅ Complete | main/templates/ (4 templates) |
-| **Test Suite** | ✅ Complete | tests/ (41 test cases) |
-| **Dependency Config** | ✅ Complete | requirements.txt |
-| **Docker Config** | ✅ Complete | Dockerfile, docker-compose.yml |
-| **Startup Script** | ✅ Complete | docker-entrypoint.sh |
-| **Test Data** | ✅ Complete | add\_test\_data.py |
-
-5.3 Deployment Completeness
-
-| Deployment Method | Implementation Status | Description |
+| **Core runtime** | `<Complete/Partial/Missing>` | `<what exists>` |
+| **Primary user-facing flows** | `<Complete/Partial/Missing>` | `<what exists>` |
+| **Admin/operator flows** | `<Complete/Partial/Missing/Not Applicable>` | `<what exists>` |
+| **Persistence / state / data model** | `<Complete/Partial/Missing/Not Applicable>` | `<what exists>` |
+| **Tests** | `<Complete/Partial/Missing>` | `<what exists>` |
+| **Build / packaging / runtime config** | `<Complete/Partial/Missing>` | `<what exists>` |
+
+## Runtime and deployment completeness
+
+| Runtime Method | Implementation Status | Description |
 | :---- | :---- | :---- |
-| **Local Execution** | ✅ Complete | requirements.txt \+ python manage.py runserver |
-| **Docker Deployment** | ✅ Complete | docker compose up one-click startup |
-| **Data Persistence** | ✅ Complete | Volume mounting for media\_data and db\_data |
-| **Auto-Initialization** | ✅ Complete | Automatic database migration, admin creation, and test data addition |
+| **Primary runtime command** | `<Complete/Partial/Missing>` | `<docker compose up --build or ./run_app.sh, etc.>` |
+| **Broad test command** | `<Complete/Partial/Missing>` | `<./run_tests.sh behavior>` |
+| **Local development verification** | `<Complete/Partial/Missing>` | `<local tests/tools present for normal iteration>` |
+| **Persistence / initialization / automation** | `<Complete/Partial/Missing/Not Applicable>` | `<what happens automatically>` |
 
-5.4 Delivery Completeness Rating
+## Delivery completeness rating
 
-**Rating: 10/10**
+**Rating:** `<score or qualitative result>`
 
 **Strengths:**
 
-* **Complete Documentation**: README and other documents are comprehensive  
-* **Complete Code**: All functional modules are implemented with nothing missing  
-* **Runnability**: Supports both local execution and Docker one-click deployment  
-* **Test Coverage**: 41 test cases with a completely isolated test environment  
-* **Automation**: Docker startup automatically completes all initialization tasks
+- `<strength 1>`
+- `<strength 2>`
+- `<strength 3>`
+
+**Gaps or limits:**
+
+- `<gap 1 or 'None material'>`
+- `<gap 2 if needed>`
+
+## Hard-threshold summary inputs
+
+Explicitly answer:
 
+1. Can the delivered product actually run through its primary runtime command?
+2. Can the delivered product actually be verified through `./run_tests.sh`?
+3. Does the delivered output fully cover the core prompt requirements?
+4. Is the delivered product a real 0-to-1 delivery rather than a partial or schematic implementation?