theslopmachine 0.4.5 → 0.4.7

package/README.md

@@ -1,62 +1,45 @@
 # theslopmachine
 
-`theslopmachine` installs the SlopMachine owner/developer workflow into OpenCode, sets up the required support files on your machine, and bootstraps new project workspaces.
+`theslopmachine` is an installer and bootstrap CLI for the SlopMachine OpenCode workflow. It installs the packaged owner/developer agents, required skills, workflow support files, and project bootstrap logic needed to start a new SlopMachine-managed repository.
 
-**Quickstart**
+## Features
 
-This is the full machine-to-project flow:
+- installs packaged OpenCode agents into `~/.config/opencode/agents/`
+- installs packaged skills into `~/.agents/skills/`
+- installs packaged workflow support files into `~/slopmachine/`
+- installs Claude worker runtime assets under `~/.claude/`
+- bootstraps a new project workspace with `repo/`, `docs/`, `sessions/`, `metadata.json`, `AGENTS.md`, and initialized `br` state
+- configures required OpenCode plugins and MCP entries without overwriting existing `context7` or `exa` configuration
 
-1. install the package
-2. run `slopmachine setup`
-3. add MCP API keys if prompted
-4. log into Codex with OpenCode
-5. initialize a project workspace
-6. enter `repo/`
-7. start OpenCode and choose the `slopmachine` agent
+## Installation
 
-## Requirements
+Requirements:
 
 - Node.js 18+
 - `git`
 - Docker running on the machine
-- `curl` on Unix-like systems for automatic `br` install
+- `curl` on Unix-like systems for automatic `br` installation
 
-`slopmachine setup` can install or verify:
-
-- `opencode`
-- `br` (`beads_rust`)
-
-## 1. Install The Package
-
-From this package directory:
+Build and install the package:
 
 ```bash
 npm install
 npm run check
 npm pack
+npm install -g ./theslopmachine-0.4.4.tgz
 ```
 
-That produces a tarball such as:
-
-```bash
-theslopmachine-0.4.5.tgz
-```
-
-Install it globally:
-
-```bash
-npm install -g ./theslopmachine-0.4.5.tgz
-```
-
-For local package development instead:
+For local package development instead of global install:
 
 ```bash
 npm link
 ```
 
-## 2. Run Setup
+The published package is intentionally source-only. It packages only `bin/`, `src/`, `assets/`, `README.md`, `RELEASE.md`, and `MANUAL.md`.
 
-Run this once per machine, or rerun it any time you want to refresh packaged assets:
+## Setup
+
+Run machine setup:
 
 ```bash
 slopmachine setup
@@ -64,47 +47,37 @@ slopmachine setup
 
 `setup` does the following:
 
-- installs or verifies `git`, `python3`, `opencode`, `br`, and Docker availability
-- installs the packaged OpenCode agents into `~/.config/opencode/agents/`
-- installs the packaged skills into `~/.agents/skills/`
-- installs workflow support files into `~/slopmachine/`
+- installs or verifies `opencode`
+- installs or verifies `br` (`beads_rust`)
+- installs or refreshes packaged agents
+- installs or refreshes packaged skills
+- installs or refreshes packaged workflow files into `~/slopmachine/`
+- installs or refreshes Claude runtime assets under `~/.claude/`
 - updates `~/.config/opencode/opencode.json`
-- prompts for missing Context7 and Exa MCP API keys
-
-If `setup` installs `opencode` for the first time, open a fresh terminal before running `opencode` commands.
+- prompts for missing MCP API keys when needed
 
-## 3. Get MCP API Keys
+If `opencode` was newly installed, open a fresh terminal before running OpenCode commands.
 
-During `slopmachine setup`, you may be prompted for:
+MCP API keys:
 
 - Context7: `https://context7.com`
 - Exa: `https://exa.ai`
 
-You can leave either blank and add it later by editing:
-
-```bash
-~/.config/opencode/opencode.json
-```
-
-If `context7` or `exa` is already configured in `opencode.json`, `setup` leaves the existing entries in place.
-
-## 4. Log Into Codex With OpenCode
-
-Authenticate OpenCode against Codex:
+Codex login with OpenCode:
 
 ```bash
 opencode auth login -p codex
 ```
 
-Optional check:
+Optional verification:
 
 ```bash
 opencode auth list
 ```
 
-## 5. Initialize A Project Workspace
+## Startup
 
-Create a new workspace directory and bootstrap it:
+Create and initialize a new project workspace:
 
 ```bash
 mkdir my-project
@@ -112,54 +85,106 @@ cd my-project
 slopmachine init
 ```
 
-This creates:
-
-- `repo/` for the actual codebase work
-- parent-level workflow files such as `metadata.json` and `.ai/metadata.json`
-- parent-level `docs/` and `sessions/`
-- `repo/AGENTS.md`
-- initialized `br` state
-- an initial git commit
-
-If you want `init` to open OpenCode automatically in `repo/`, use:
+Or initialize and open OpenCode immediately:
 
 ```bash
+mkdir my-project
+cd my-project
 slopmachine init -o
 ```
 
-## 6. Enter `repo/`
-
-If you used plain `slopmachine init`, move into the working repository:
+If you used plain `slopmachine init`, then continue with:
 
 ```bash
 cd repo
+opencode
 ```
 
-## 7. Start OpenCode
+Inside OpenCode, select the `slopmachine` agent to start the workflow.
 
-Start OpenCode inside `repo/`:
+Bootstrapped workspace layout:
+
+- `repo/` for the working codebase
+- `docs/` for workflow documentation and evidence
+- `sessions/` for exported session artifacts
+- `metadata.json` for project workflow metadata
+- `repo/AGENTS.md` for the repo-local agent instructions
+
+## Testing
+
+Package-level checks:
 
 ```bash
-opencode
+npm run check
+npm pack --dry-run
 ```
 
-Then select the `slopmachine` agent and begin the workflow.
+Generated project conventions:
+
+- every bootstrapped project must expose one primary runtime command
+- every bootstrapped project must expose one primary broad test command: `./run_tests.sh`
+- for Dockerized web backend or fullstack projects, the expected broad runtime command is `docker compose up --build`
+- for non-Docker runtime cases, the expected broad runtime command is usually `./run_app.sh`
+
+Verification policy:
+
+- use local fast verification during normal development
+- treat `./run_tests.sh` as a broad gate, not an ordinary every-step verification command
+- for Dockerized web backend and fullstack projects, scaffold acceptance should establish both `docker compose up --build` and `./run_tests.sh`
 
-The normal operating split is:
+## Architecture
 
-- `slopmachine` is the owner/orchestrator
+Operating model:
+
+- `slopmachine` is the owner and orchestrator
 - `developer` is the implementation worker
+- detailed workflow behavior is primarily carried by loaded skills rather than one monolithic owner prompt
+
+High-level lifecycle:
+
+1. clarification
+2. planning
+3. scaffold
+4. development
+5. integrated verification
+6. hardening
+7. evaluation and triage
+8. final human decision
+9. remediation when needed
+10. submission packaging
+11. retrospective
+
+Design constraints:
+
+- keep the owner shell small and load phase-specific skills when needed
+- prefer targeted reads and focused local verification during implementation
+- keep environment-specific state out of the package
+- do not package local runtime artifacts, caches, editor folders, or generated dependency environments
+
+Database dependency rule:
+
+- database dependencies must be provisioned by initialization scripts, migrations, container startup hooks, or equivalent runtime setup
+- do not hardcode database-specific environment state into packaged assets
+- do not ship database files such as `.db`, `.sqlite`, dumps, or seeded local database artifacts in the package
+
+For this package specifically, the installer ships workflow logic and templates only. It does not ship database dependency files or packaged database state.
 
-## Configured Items
+## Installed Configuration
 
-These are the main files and directories `setup` configures.
+Main locations:
 
-### OpenCode Agents
+- agents: `~/.config/opencode/agents/`
+- skills: `~/.agents/skills/`
+- OpenCode config: `~/.config/opencode/opencode.json`
+- packaged workflow files: `~/slopmachine/`
+- Claude runtime assets: `~/.claude/`
+
+Installed agents:
 
 - `~/.config/opencode/agents/slopmachine.md`
 - `~/.config/opencode/agents/developer.md`
 
-### OpenCode Skills
+Installed skills:
 
 - `~/.agents/skills/clarification-gate/`
 - `~/.agents/skills/developer-session-lifecycle/`
@@ -181,30 +206,20 @@ These are the main files and directories `setup` configures.
 - `~/.agents/skills/report-output-discipline/`
 - `~/.agents/skills/frontend-design/`
 
-### SlopMachine Support Files
-
-Installed under `~/slopmachine/`:
+Installed workflow files under `~/slopmachine/`:
 
 - `backend-evaluation-prompt.md`
 - `frontend-evaluation-prompt.md`
 - `document-completeness.md`
-- `quality-document.md`
 - `engineering-results.md`
 - `implementation-comparison.md`
-- `workflow-init.js`
+- `quality-document.md`
 - `templates/AGENTS.md`
+- `workflow-init.js`
 - `utils/strip_session_parent.py`
 - `utils/convert_ai_session.py`
 
-### OpenCode Config
-
-Config file:
-
-```bash
-~/.config/opencode/opencode.json
-```
-
-`setup` ensures these entries exist:
+OpenCode config entries ensured by `setup`:
 
 - plugin: `oc-chatgpt-multi-auth`
 - MCP server: `chrome-devtools`
@@ -212,21 +227,4 @@ Config file:
 - MCP server: `exa`
 - MCP server: `shadcn` disabled by default
 
-If you want to customize agents, MCP settings, or plugins, these are the files to edit.
-
-## Daily Use
-
-After the machine is set up, the common flow is:
-
-```bash
-cd my-project/repo
-opencode
-```
-
-Or for a brand new project in one shot:
-
-```bash
-mkdir my-project
-cd my-project
-slopmachine init -o
-```
+These are the user-editable locations if you want to customize agents, skills, plugins, or MCP configuration after setup.

package/RELEASE.md

@@ -42,13 +42,13 @@ npm pack
 This should produce a tarball such as:
 
 ```bash
-theslopmachine-0.4.5.tgz
+theslopmachine-0.4.7.tgz
 ```
 
 ## Inspect package contents
 
 ```bash
-tar -tzf theslopmachine-0.4.5.tgz
+tar -tzf theslopmachine-0.4.7.tgz
 ```
 
 Check that the tarball includes:

package/assets/agents/developer.md

@@ -85,6 +85,8 @@ Selected-stack defaults:
 - do not ship placeholder, demo, setup, or debug UI in product-facing screens
 - do not create `.env` files or similar env-file variants
 - do not hardcode secrets or leave prototype residue behind
+- when the project has database dependencies, keep database setup in `./init_db.sh` rather than scattered repo logic
+- do not hardcode database connection values or database bootstrap values anywhere in the repo
 
 ## Skills
 

package/assets/agents/slopmachine.md

@@ -115,7 +115,7 @@ Do not create another competing workflow-state system.
 Use git to preserve meaningful workflow checkpoints.
 
 - after each meaningful accepted work unit, run `git add .` and `git commit -m "<message>"`
-- meaningful work includes accepted scaffold completion, accepted major development slices, accepted remediation passes, and other clearly reviewable milestones
+- meaningful work includes accepted scaffold completion, accepted major development slices, accepted evaluation-fix rounds, and other clearly reviewable milestones
 - keep the git flow simple and checkpoint-oriented
 - commit only after the relevant work and verification for that checkpoint are complete enough to preserve useful history
 - keep commit messages descriptive and easy to reason about later
@@ -158,21 +158,19 @@ Use these exact root phases:
 - `P4 Development`
 - `P5 Integrated Verification`
 - `P6 Hardening`
-- `P7 Evaluation and Triage`
+- `P7 Evaluation and Fix Verification`
 - `P8 Final Human Decision`
-- `P9 Remediation`
-- `P10 Submission Packaging`
-- `P11 Retrospective`
+- `P9 Submission Packaging`
+- `P10 Retrospective`
 
 Phase rules:
 
 - exactly one root phase should normally be active at a time
 - enter the phase before real work for that phase begins
 - do not close multiple root phases in one transition block
-- `P9 Remediation` stays its own root phase once evaluation has accepted follow-up work
 - `P6 Hardening` may reopen `P5` if hardening exposes unresolved integrated instability
-- `P11 Retrospective` runs automatically after successful packaging and is non-blocking unless it finds a real delivery defect
-- post-submission external evaluation feedback may reopen `P9 Remediation`, then rerun `P10 Submission Packaging`, and then rerun `P11 Retrospective`
+- `P10 Retrospective` runs automatically after successful packaging and is non-blocking unless it finds a real delivery defect
+- post-packaging external evaluation feedback may reopen `P7 Evaluation and Fix Verification`, then rerun `P8 Final Human Decision`, `P9 Submission Packaging`, and `P10 Retrospective`
 
 ## Developer Session Model
 
@@ -181,21 +179,21 @@ Maintain exactly one active developer session at a time.
 Track every developer session in metadata, but create a new one only in these cases:
 
 1. you explicitly request a new session
-2. after successful submission, you return with external evaluation issues that require more fixes
 
-Session classes:
+All tracked developer sessions use the `develop-N` naming line.
 
-1. `develop`: every developer session created before the first successful submission packaging
-2. `bugfix`: every developer session created after successful submission packaging when the project is reopened for external-evaluation follow-up
+There may be multiple `develop` sessions over the life of one project.
 
-There may be multiple `develop` sessions and multiple `bugfix` sessions over the life of one project.
+During the first full run from planning through initial packaging, keep all work in the `develop-N` sequence, including integrated verification, hardening, evaluation issue fixing inside `P7`, and packaging follow-through.
 
-During the first full run from planning through initial submission packaging, keep all work in the `develop` session class, including integrated verification, hardening, evaluation-driven remediation, and packaging follow-through.
+If the project is reopened after packaging because of later reported issues, continue with the existing developer session unless you explicitly request a new one.
+
+Fresh `General` sessions used for evaluation and fix verification do not change the single-active-developer-session rule.
 
 If you explicitly request a new session while one is active, ask the current developer exactly `give me a summary of all the work that has been done`, then use that handoff to seed the next session.
 
 Use `developer-session-lifecycle` for startup, resume detection, session consistency checks, and recovery.
-Use `session-rollover` only when intentionally starting a new developer session because of an explicit user request or post-submission external-feedback reopen.
+Use `session-rollover` only when intentionally starting a new developer session because of an explicit user request.
 
 Do not launch the developer during `P0` or `P1`.
 
@@ -290,9 +288,8 @@ Core map:
 - `P5` -> `integrated-verification`
 - `P6` -> `hardening-gate`
 - `P7` -> `final-evaluation-orchestration`, `evaluation-triage`, `report-output-discipline`
-- `P9` -> `remediation-guidance`
-- `P10` -> `submission-packaging`, `report-output-discipline`
-- `P11` -> `retrospective-analysis`, `owner-evidence-discipline`, `report-output-discipline`
+- `P9` -> `submission-packaging`, `report-output-discipline`
+- `P10` -> `retrospective-analysis`, `owner-evidence-discipline`, `report-output-discipline`
 - state mutations -> `beads-operations`
 - evidence-heavy review -> `owner-evidence-discipline`
 - intentional new developer session -> `session-rollover`
@@ -307,7 +304,7 @@ When talking to the developer:
 - lead with the engineering point, not process framing
 - keep prompts natural, sharp, and compact unless the moment really needs more context
 - translate workflow intent into normal software-project language
-- for each development slice or bugfix request, require the reply to state the exact verification commands that were run and the concrete results they produced
+- for each development slice or follow-up fix request, require the reply to state the exact verification commands that were run and the concrete results they produced
 
 Do not leak workflow internals such as:
 
@@ -364,14 +361,11 @@ After each substantive developer reply, do one of four things:
 
 Treat packaging as a first-class delivery contract from the start, not as late cleanup.
 
-- the canonical package documents live under `~/slopmachine/`
-- the two evaluation prompt files are used exactly during evaluation runs
-- the four non-evaluation package documents are used during submission packaging to generate the required submission outputs
-- exact packaging file outputs and final paragraph outputs are mandatory in `P10`
-- accepted evaluation reports and cleaned original session exports are mandatory submission artifacts in `P10`
-- do not leave packaging structure, screenshots, self-test outputs, or exports to be improvised at the end
+- the evaluation prompt files under `~/slopmachine/` are used only during evaluation runs
+- `../self-test-run.md`, `../self-test-fixes.md`, `../sessions/`, `../metadata.json`, `../docs/`, and the delivered `repo/` are the mandatory late-stage artifacts
+- do not invent `submission/`, packaging-only report files, screenshots, or other extra artifact structures during ordinary packaging
 
-When `P10 Submission Packaging` begins:
+When `P9 Submission Packaging` begins:
 
 - load `submission-packaging` before any packaging action
 - follow its exact artifact, export, cleanup, and output contract
@@ -379,9 +373,9 @@ When `P10 Submission Packaging` begins:
 
 ## Retrospective
 
-After `P10 Submission Packaging` closes successfully:
+After `P9 Submission Packaging` closes successfully:
 
-- automatically enter `P11 Retrospective`
+- automatically enter `P10 Retrospective`
 - load `retrospective-analysis`
 - write `run_id`-scoped retrospective output under `~/slopmachine/retrospectives/`
 - keep it owner-only and non-blocking by default

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

@@ -101,24 +101,19 @@ Track at least:
 - `current_phase`
 - `awaiting_human`
 - `clarification_approved`
-- `remediation_round`
 - `clarification_validator_session_id`
-- `evaluation_pass`
-- `backend_evaluation_session_id`
-- `frontend_evaluation_session_id`
-- `last_evaluation_session_id`
-- `backend_evaluation_report_path`
-- `frontend_evaluation_report_path`
-- `passed_evaluation_tracks`
+- `evaluation_prompt_kind`
+- `evaluation_session_id`
+- `self_test_run_path`
+- `fix_verification_session_id`
+- `self_test_fixes_path`
 - `developer_sessions`
 - `active_developer_session_id`
 - `next_develop_session_number`
-- `next_bugfix_session_number`
-- `submission_completed`
+- `packaging_completed`
 
 Each developer session record should include enough to recover and export it later, such as:
 
-- `session_class`
 - `sequence`
 - `label`
 - `created_phase`
@@ -126,7 +121,6 @@ Each developer session record should include enough to recover and export it lat
 - `status`
 - `handoff_in`
 - `handoff_out`
-- `reopened_after_submission`
 
 Required project metadata fields in `../metadata.json` when relevant:
 
@@ -147,19 +141,15 @@ Required project metadata fields in `../metadata.json` when relevant:
 
 - 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
+- label every developer session using `develop-N`
+- create a new developer session only when the user explicitly requests a new session
 
 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. 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`
+4. assign the next `develop-N` label in sequence
 
 ## Initial structure rule
 

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

@@ -29,7 +29,10 @@ 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 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
+- perform a clean-slate sweep before reporting module completion: remove weak demo defaults, stray test-account hints, prototype residue, and other production-inappropriate artifacts
+- when the project has database dependencies, keep `./init_db.sh` aligned with the real schema, migrations, bootstrap data, and dependency setup as implementation evolves
+- do not leave `./init_db.sh` as a scaffold placeholder once real database requirements are known
+- do not hardcode database connection values or database bootstrap values anywhere in the repo; database setup must stay driven by `./init_db.sh`
 - 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

package/assets/skills/evaluation-triage/SKILL.md

@@ -1,77 +1,38 @@
 ---
 name: evaluation-triage
-description: Owner-side evaluation report triage rules for slopmachine.
+description: Owner-side evaluation issue handoff and fix-verification rules for slopmachine.
 ---
 
-# Evaluation Triage
+# Evaluation Issue Handoff
 
-Use this skill during `P7 Evaluation and Triage` after evaluation reports exist.
+Use this skill during `P7 Evaluation and Fix Verification` after `../self-test-run.md` exists.
 
 ## Rules
 
-- evaluation findings are advisory inputs, not automatic orders
-- accept or reject findings explicitly
-- keep accepted findings concrete and bounded
-- do not enter remediation just because a report found something; enter it only when the accepted findings justify it
-- if no remediation is needed, move directly to the final human decision
+- treat `../self-test-run.md` as the authoritative issue source for ordinary post-hardening completion flow
+- keep the issue set concrete and exact
+- use the existing active developer session; do not start a new developer session for these fixes
+- do not split the issue set into backend/frontend tracks
+- do not silently drop, merge away, or wave through issues from `../self-test-run.md`
+- after the developer claims the fixes are complete, use one fresh `General` fix-verification session to verify the earlier issues and generate `../self-test-fixes.md`
+- do not route ordinary post-hardening evaluation issues into a separate remediation phase; keep them inside `P7`
 
-## Non-negotiable evaluation buckets
+## Issue handoff standard
 
-These areas are hard gates and should not be passed with known meaningful failures:
+- send the developer the exact issues from `../self-test-run.md` in explicit detail
+- require the developer to address all listed issues, not a negotiated subset
+- require the developer to report the exact verification commands that were run and the concrete results they produced
+- if the developer reports that some issue is invalid or already fixed, require that claim to be justified concretely against the report rather than silently omitting it
 
-1. prompt compliance
-2. requirement fulfillment / delivery completeness
-3. security-critical flaws
+## Fix-verification standard
 
-If evaluation finds a real issue in one of those buckets, the default outcome is remediation, not leniency.
+- the follow-up `General` session should receive the exact earlier issue list and a direct instruction to verify whether each item is now resolved
+- the follow-up `General` session should only confirm whether those exact earlier items are fixed; it should not perform a broader new review
+- the follow-up report should describe what is resolved, what remains open, and any important verification caveats
+- save that report as `../self-test-fixes.md`
+- do not rewrite the report text after generation except for the file move and filename normalization
 
-Do not wave through:
+## Exit standard
 
-- prompt drift or meaningful requirement mismatch
-- missing core flows or partial delivery of prompt-critical functionality
-- real security defects involving auth, authorization, ownership, isolation, exposure, or secret handling
-
-## Leniency buckets
-
-These areas may pass with minor residual issues when the product is still clearly acceptable overall:
-
-1. testing cases / test sufficiency
-2. engineering architecture / engineering quality
-3. aesthetics
-
-Leniency is allowed only when the issue is:
-
-- minor in impact
-- not hiding a likely blocker in another bucket
-- not undermining overall confidence in the delivered product
-
-High-severity findings in these leniency buckets may still be passed when they are not materially relevant to actual acceptance readiness, but that should be a deliberate exception backed by direct evidence.
-
-If the hard gates pass cleanly, the leniency buckets should usually not force remediation unless the issue is a true `Blocker` or a materially relevant `High` finding.
-
-## Triage rules
-
-- read both reports and merge the findings into one explicit triage set before deciding what happens next
-- use the evaluator priority ordering directly when triaging findings unless stronger direct evidence says otherwise
-- any finding in the non-negotiable buckets should normally be returned for remediation if it is real
-- findings marked `Blocker` should normally be returned for remediation
-- findings marked `High` should normally be returned for remediation unless they fall in a leniency bucket and your direct evidence shows they are not materially relevant to acceptance
-- 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
-- minor engineering-architecture quality issues may pass if the system is still structurally credible and maintainable overall
-- minor aesthetics issues may pass if the UI is still clearly usable and credible for the actual use case
-- if prompt compliance, requirement fulfillment, and security all pass, testing/engineering/aesthetics findings should generally be treated more leniently unless they are blocking or materially high-risk
-- 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 loop forever chasing every newly surfaced medium or low issue once the project is otherwise qualified
-
-## Output standard
-
-- keep a clear accepted-finding set
-- keep a clear rejected or passed set when disagreement matters
-- keep the remediation brief focused on accepted issues only
+- do not move to `P8` until both `../self-test-run.md` and `../self-test-fixes.md` exist
+- if `../self-test-fixes.md` still shows meaningful unresolved issues, stay in `P7` and keep the issue-correction loop focused on those concrete remaining items