theslopmachine 0.3.0

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

@@ -0,0 +1,268 @@
+---
+name: submission-packaging
+description: Final delivery packaging checklist and artifact assembly rules for repo-cwd blueprint-driven projects. Use only during the submission packaging phase.
+---
+
+# Submission Packaging
+
+Use this skill only when the project has already passed integrated verification, hardening, and the final evaluation/remediation loop closely enough to qualify for packaging.
+
+## Usage rules
+
+- Load this skill only in the submission packaging phase.
+- Treat it as internal packaging guidance, not developer-visible workflow text.
+- Do not use it to justify skipping verification or evaluation gates.
+- Packaging is not cleanup theater. Preserve required evidence and remove only local junk, caches, and accidental noise.
+- Do not declare packaging complete early.
+- Packaging is incomplete until every required step in this skill has been executed and every required artifact path has been verified to exist.
+
+## Completion discipline
+
+- execute packaging in order; do not jump to the end and assume missing pieces can be filled later
+- after each major packaging block, verify the expected outputs before continuing
+- before closing the packaging phase, explicitly check that every required file and directory exists in its final location
+- if any required artifact is missing, packaging is still in progress
+- if any cleanup, move, export, or reporting step is incomplete, packaging is still in progress
+
+## Packaging goals
+
+- produce the exact required delivery structure
+- make the package reviewable and reproducible
+- include the required docs, metadata, evidence, and session artifacts
+- exclude local-only junk, transient noise, and secret material
+
+## Required final structure
+
+The final submission layout in the parent project root must be:
+
+- `docs/`
+  - `design.md`
+  - `api-spec.md` when applicable
+  - `test-coverage.md`
+  - `questions.md`
+  - `submission-self-test-index.md`
+  - `hard-threshold-explanation.md`
+  - `document-completeness-report.md`
+  - `engineering-architecture-quality-report.md`
+  - `engineering-architecture-quality-statement.md`
+  - `engineering-results-report.md`
+  - `engineering-details-professionalism.md`
+  - `implementation-comparison-report.md`
+  - `prompt-understanding-adaptability.md`
+  - `aesthetics.md` when applicable
+  - `aesthetics-assessment.md` when applicable
+  - evaluation reports
+  - screenshots and proof materials
+  - relocated screenshots and proof images needed for submission review
+- current working directory delivered as parent-root `repo/`
+- `../sessions/`
+  - `trajectory.json`
+  - `trajectory-N.json` when multiple session trajectories exist
+- `../metadata.json`
+- `../session.json`
+- `../session-N.json` when multiple exported sessions exist
+- parent-root `../.tmp/` directory moved out of current `.tmp/` when it exists
+
+Do not treat `.ai/` as part of the final submission structure unless the user explicitly changes that requirement later.
+
+## Required packaging actions
+
+- verify the root package structure matches the blueprint exactly
+- make sure parent-root `../metadata.json` is complete and reflects the delivered project truthfully
+- create or finalize parent-root `../docs/design.md` from the working `docs/design.md`
+- create or finalize parent-root `../docs/api-spec.md` from the working `docs/api-spec.md` when applicable
+- create or finalize parent-root `../docs/test-coverage.md` from the working `docs/test-coverage.md`
+- create or finalize parent-root `../docs/questions.md` from the accepted clarification/question record
+- move the final docs set out of current `docs/` into parent-root `../docs/` after development is complete
+- ensure `README.md` matches the delivered runtime, verification, and feature behavior
+- include `run_tests.sh`
+- relocate evaluation artifacts into parent-root `../docs/`, including:
+  - backend evaluation report
+  - frontend evaluation report
+- relocate screenshots and proof materials relevant to runtime behavior and major flows into parent-root `../docs/`
+- gather required screenshots from test-output or artifact directories and relocate them into parent-root `../docs/` during packaging
+- include exported session artifacts at the parent project root using the naming rules:
+  - `../session.json` for a single exported session
+  - `../session-N.json` when multiple exported sessions exist
+- include trajectory artifacts in `../sessions/` using the naming rules:
+  - `../sessions/trajectory.json` for a single trajectory
+  - `../sessions/trajectory-N.json` when multiple trajectories exist
+- include any required package/tree proof or delivery evidence
+
+## Session export sequence
+
+For the developer session, run these exact steps:
+
+- this sequence is mandatory
+- do not skip, reorder, or replace these commands with approximations
+- if one of these commands fails, stop and fix the export pipeline before continuing packaging
+- do not proceed to later packaging steps until the export, strip, and trajectory conversion steps have all succeeded
+
+1. `opencode export <developer-session-id> > ../session-export.json`
+2. `python3 ~/slopmachine/utils/strip_session_parent.py ../session-export.json --output ../session.json`
+3. `python3 ~/slopmachine/utils/convert_ai_session.py -i ../session.json -o ../trajectory.json`
+
+After those steps:
+
+- keep the cleaned final exported session as parent-root `../session.json` unless multiple exports require `../session-N.json`
+- move or copy the generated trajectory into `../sessions/trajectory.json` unless multiple trajectories require `../sessions/trajectory-N.json`
+- treat `../session-export.json` and the intermediate parent-root `../session.json` as temporary packaging intermediates unless the package contract later says otherwise
+- pause immediately after the export/clean/convert sequence and verify that all expected directories and required files exist before running any later packaging scripts
+- if the required utilities or output files are missing, packaging is not ready to continue
+
+## Required file moves
+
+- move the final docs set out of current `docs/` into parent-root `../docs/`
+- after packaging, current `docs/` must not remain in the delivered `repo/` tree
+- if current `.tmp/` exists, collect the relevant evaluation reports and proof artifacts from it into parent-root `../docs/`
+- collect screenshots and other required proof materials from repo-local runtime/output directories into parent-root `../docs/`
+- after relocation, the final submission should not require digging through repo-local output directories to find evidence
+- find required screenshots in their generated locations and move or copy them into parent-root `../docs/` so reviewers do not have to inspect e2e artifact directories manually
+- keep screenshot filenames clear enough that the referenced runtime page, flow, or evidence purpose is understandable from the file name or nearby document reference
+
+## Repo cleanup rules
+
+Clean the current working directory that will be delivered as parent-root `repo/` before final submission.
+
+Remove runtime, editor, cache, and tooling noise such as:
+
+- `.tmp/`
+- `.git/`
+- `.opencode/`
+- `.codex/`
+- `.vscode/`
+- `__pycache__/`
+- `.pytest_cache/`
+- `node_modules/`
+- `.venv/`
+- `.net/`
+- `AGENTS.md`
+- similar environment-dependent or local-only directories
+
+Product attachment packaging is not allowed.
+
+Do not include environment-dependent local runtime content in the delivered package.
+
+## Validation checklist
+
+- confirm the final package contains what reviewers actually need to inspect the project
+- confirm docs describe delivered behavior, not planned or aspirational behavior
+- confirm `docs/test-coverage.md` explains the tested flows, coverage boundaries, and how the evaluator should interpret the coverage evidence
+- confirm evaluation reports and screenshots have been relocated into parent-root `../docs/` and correspond to the final qualified state, not an older revision
+- confirm current `docs/` has been handled correctly so final delivery docs live in parent-root `../docs/`
+- confirm repo-local evidence directories have been harvested so required reports and screenshots now live in parent-root `../docs/`
+- confirm required screenshots have been relocated into parent-root `../docs/`
+- confirm parent-root metadata fields are populated correctly:
+  - `prompt`
+  - `project_type`
+  - `frontend_language`
+  - `backend_language`
+  - `database`
+  - `session_id`
+  - `frontend_framework`
+  - `backend_framework`
+- confirm session export naming rules are followed:
+  - parent-root `../session.json`
+  - parent-root `../session-N.json` when multiple exported sessions exist
+  - `../sessions/trajectory.json`
+  - `../sessions/trajectory-N.json` when multiple trajectories exist
+
+## Submission reporting documents
+
+Create a root document at:
+
+- `docs/submission-self-test-index.md`
+
+Use it as the master index of packaging/self-test outputs.
+
+Rules:
+
+- answer the direct questions inline in this index when a standalone document is not required
+- when a standalone document is required, create the file and include its path in the index
+- keep the answers tied to the real delivered project, not generic template text
+- use real screenshots from the delivered product and real project evidence
+
+Create or populate these deliverables:
+
+1. `docs/submission-self-test-index.md`
+   - answer whether the delivered product can actually run and be verified
+   - link screenshots proving successful runtime pages and, when relevant, error pages
+2. `docs/hard-threshold-explanation.md`
+   - explain success/failure status
+   - state whether the delivered product can actually be operated and verified
+   - state whether the delivered product significantly deviates from the prompt topic
+3. `docs/document-completeness-report.md`
+   - based on `~/slopmachine/document-completeness.md`
+   - create a similar table document for this codebase
+   - include screenshots with real product data where applicable
+4. Add to `docs/submission-self-test-index.md`
+   - Self-Test Status — Delivery Completeness Statement
+   - answer whether the deliverables fully cover the core prompt requirements
+   - answer whether the product has a real 0-to-1 delivery form rather than partial/schematic output
+   - if unable, provide a specific reason
+5. `docs/engineering-architecture-quality-report.md`
+   - based on `~/slopmachine/quality-document.md`
+   - generate a report with the same type of information and proper formatting
+   - include a screenshot of the current working directory folder structure that will be delivered as `repo/`
+   - suggested method: run a tree command such as `tree . -a -L 3 > ../repo-structure.txt`, open that output in the terminal or editor, and capture a screenshot manually
+6. `docs/engineering-architecture-quality-statement.md`
+   - Self-test results: engineering and architecture quality statement
+7. `docs/engineering-results-report.md`
+   - based on `~/slopmachine/engineering-results.md`
+   - generate a similar document for this codebase
+8. `docs/engineering-details-professionalism.md`
+   - cover these exact checks:
+     - Error handling: all APIs return standard HTTP codes and JSON error format
+     - Logging: key flows have structured logs
+     - Input validation: all body/query/path params validated
+     - No secrets/keys in config files
+     - No `node_modules` / `.venv` committed
+     - No stray debug statements such as `console.log("here")`
+9. `docs/implementation-comparison-report.md`
+   - based on `~/slopmachine/implementation-comparison.md`
+   - generate a similar document for this codebase with real evidence
+10. `docs/prompt-understanding-adaptability.md`
+   - explain whether the delivered product accurately understands and responds to business objectives, use cases, and implicit constraints in the prompt rather than merely implementing presentation-layer technical requirements
+11. `docs/aesthetics.md`
+   - for fullstack or pure frontend only
+   - answer whether the visual/interaction fits the scene and is aesthetically pleasing
+   - if not applicable, write `Not Applicable`
+   - if aesthetically unappealing, provide a specific reason
+12. `docs/aesthetics-assessment.md`
+   - for fullstack or pure frontend only
+   - produce the aesthetics assessment in a separate document
+   - if not applicable, write `Not Applicable`
+   - if aesthetically unappealing, provide a specific reason
+
+## Cleanliness rules
+
+- remove caches, temp outputs, build junk, editor noise, and accidental local files that are not part of the package contract
+- do not remove required evidence just because it looks noisy
+- verify no local secret files or sensitive values are included in the final package
+- verify frontend screenshots do not show demo/debug/setup leakage
+- verify evaluation rebuttal notes, if any, remain attached to the relevant evaluation reports
+- verify the final package does not include pointless tests or artifacts whose only purpose was to assert documentation-directory existence
+- verify that required evidence is centralized under parent-root `../docs/` rather than scattered across repo-local output directories
+- do not leave required screenshots stranded only inside raw e2e artifact directories
+
+## Final packaging verification
+
+- do one final package review before declaring packaging complete
+- confirm the package is coherent as a delivered submission, not just a working repo snapshot
+- confirm the final git checkpoint can be created cleanly for the packaged state
+- if packaging reveals a real defect or missing artifact, fix it before closing the phase
+
+## Required completion checklist
+
+Do not close packaging until all of these are true:
+
+- final docs exist in parent-root `../docs/`
+- current `docs/` no longer remains in the delivered repo tree
+- parent-root `../metadata.json` exists and is populated correctly
+- parent-root `../session.json` or `../session-N.json` exists as required
+- `../sessions/trajectory.json` or `../sessions/trajectory-N.json` exists as required
+- evaluation reports are present under parent-root `../docs/`
+- required screenshots and proof materials are present under parent-root `../docs/`
+- required submission-report documents exist in parent-root `../docs/`
+- delivered repo no longer contains forbidden junk directories
+- final structure matches the required layout exactly

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

@@ -0,0 +1,106 @@
+---
+name: verification-gates
+description: Owner-side review, verify-fix loop, heavy-gate interpretation, and runtime acceptance rules for repo-cwd blueprint-driven projects.
+---
+
+# Verification Gates
+
+Use this skill after development begins whenever you are reviewing developer work, deciding acceptance, interpreting phase exits, or enforcing hard verification boundaries.
+
+## Usage rules
+
+- Load this skill before review, acceptance, rejection, runtime gate interpretation, hardening readiness decisions, or heavy-gate decisions.
+- Treat it as owner-side review and gate guidance, not developer-visible text.
+- Use `get-overlays` as the source of truth for developer-facing execution guidance.
+- Use this skill as the source of truth for owner-side verification, review pressure, and gate interpretation.
+
+## Review standard
+
+- do not accept weak tests
+- do not accept shallow Docker verification
+- do not accept documentation drift
+- do not accept happy-path-only implementation when failure paths matter
+- do not accept unsupported claims
+- do not accept work that looks complete but is not resilient
+- do not accept committed secrets, hardcoded sensitive values, or sloppy env handling
+- 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 Playwright evidence when the change affects real frontend behavior
+- do not accept frontend placeholder, demo, setup, or debug messaging in product-facing UI
+- do not accept prototype residue such as seeded credentials, weak demo defaults, login hints, or unsanitized user-facing error behavior
+- 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
+- do not accept known user-facing, release-facing, production-path, or build failures as compatible with completion unless explicitly scoped out
+- do not accept frontend-bearing slice completion without checking production build health when the change materially affects frontend code or tooling
+- do not accept module completion that ignores integration seams or cross-cutting consistency with the existing system
+- do not accept end-to-end evidence that bypasses a required user-facing or admin-facing surface with direct API shortcuts
+
+## Verify-fix loop
+
+- inspect the result and the evidence, not just the developer's confidence
+- review technical quality, prompt alignment, architecture impact, and verification depth of the current work
+- during normal implementation iteration, prefer fast local language-native or framework-native verification for the changed area instead of forcing `run_tests.sh` every turn
+- 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
+- if the local toolchain is missing, require the developer to install or enable it first; allow fallback to `run_tests.sh` only when that is not practical
+- do not accept hand-wavy claims that local verification is unavailable without a real setup attempt and clear explanation
+- for applicable fullstack or UI-bearing work, require local Playwright on affected flows plus screenshot review and explicit UI validation
+- if verification is weak, missing, or failing, require fixes and reruns before acceptance
+- if docs drift, secrets leak, contracts drift, or frontend integrity is compromised, require cleanup before acceptance
+- keep looping until the current work is genuinely acceptable
+
+## Heavy-gate definition
+
+- a heavy gate is an owner-run integrated verification boundary, not every ordinary phase change
+- a phase change alone does not automatically require a heavy gate unless that phase's exit criteria explicitly call for one
+- a heavy gate normally means some combination of full clean runtime proof, full `run_tests.sh`, and Playwright plus screenshot evidence when UI or fullstack flows exist
+- heavy gates are required at scaffold acceptance, integrated/full verification, and post-evaluation remediation re-acceptance
+- a mid-phase extra heavy gate is allowed only when the risk profile justifies it, such as major runtime, infra, migration, auth, security, build, or cross-module integration changes
+- planning acceptance, ordinary module acceptance, and routine in-phase verification are not heavy gates by default and should rely on targeted local verification unless the risk profile says otherwise
+
+## Testing cadence interpretation
+
+- the first required `run_tests.sh` pass happens in scaffold once the clean foundation exists
+- after scaffold, do not force `docker compose up --build` or `run_tests.sh` on every normal development step when faster local verification is sufficient
+- prefer local targeted or native test commands during module implementation and ordinary verify-fix iteration
+- local verification should run inside the current working directory using the project's own environment and tooling rather than hidden global assumptions
+- during applicable fullstack or UI-bearing implementation work, require local Playwright on affected flows and review screenshots
+- treat `docker compose up --build` and `run_tests.sh` as critical-gate verification commands for integrated/full verification, hard gates, and final-evaluation readiness rather than normal iteration tools
+- the workflow owner handles those expensive critical-gate runs; do not require the developer to duplicate them during normal phase progression
+- run `run_tests.sh` again at integrated/full verification
+- integrated/full verification must also run Playwright for major flows and inspect screenshots
+- run `run_tests.sh` again after post-evaluation remediation before re-acceptance
+- after post-evaluation remediation affecting real flows or UI, rerun Playwright and inspect fresh screenshots before re-acceptance
+
+## Runtime gate interpretation
+
+Use evidence such as Bead metadata, structured Bead comments, verification command results, and file/project-state checks.
+
+- clarification requires the `clarification-gate` conditions plus explicit approval record
+- development bootstrap requires the `developer-session-lifecycle` conditions plus a fresh planning-oriented start in the current working directory with working planning docs under `docs/`
+- scaffold requires evidence for `docker compose up --build`, `run_tests.sh`, baseline logging/config, and when relevant the chosen frontend stack and UI approach being set intentionally
+- scaffold also requires safe env/config handling, no persisted local secrets, real migration/runtime foundations, and a usable local test environment in the current working directory when practical
+- 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
+- Dockerized scaffold acceptance also requires self-contained Compose namespacing, no unnecessary fragile `container_name` usage, and clean startup plus teardown behavior in the intended shared-environment model
+- module implementation requires module planning notes, module definition of done, relevant local verification for the changed area, and for applicable fullstack or UI work local Playwright evidence with screenshots, plus docs sync and review acceptance
+- module implementation also requires integration-seam verification against adjacent modules and cross-cutting concerns where relevant, and known release-facing or build failures block acceptance unless explicitly scoped out
+- module implementation acceptance should also challenge tenant isolation, path confinement, sanitized error behavior, and prototype residue when those concerns are in scope
+- integrated verification requires owner-run `docker compose up --build`, owner-run `run_tests.sh`, end-to-end, Playwright, prompt-alignment, README/runtime, and cross-module evidence
+- fullstack integrated verification must include Playwright coverage for every major flow, plus screenshots used to evaluate frontend behavior and UI quality along the flow using `frontend-design`
+- if a required flow cannot be exercised through the intended UI surface, treat that as incomplete implementation rather than acceptable E2E coverage
+- hardening requires security, maintainability, exploratory, and release-freeze evidence
+- hardening must explicitly re-check secret handling, redaction, and frontend/backend observability hygiene
+- final evaluation readiness requires automated evaluation to be complete and triaged, with a clear go-to-packaging vs return-to-fixes decision
+- remediation requires accepted issue records plus rerun verification, and after post-evaluation remediation it requires an owner-run fresh `run_tests.sh` pass and Playwright rerun where applicable before re-acceptance
+
+## Hardening and pre-evaluation discipline
+
+When all planned modules are complete:
+
+- run integrated verification
+- run hardening and exploratory testing
+- for fullstack applications, rerun Playwright coverage for major flows and inspect screenshots for frontend regressions or weak UX
+- enforce release-candidate freeze
+- allow only fixes, verification improvements, doc corrections, and packaging work
+- prepare the package and evidence cleanly before the final evaluation decision gate

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

@@ -0,0 +1,275 @@
+You are the reviewer responsible for Delivery Acceptance and Project Architecture Audit.
+
+In the current working directory, review the project against the Business / Task Prompt and the Acceptance / Scoring Criteria.
+
+[Business / Task Prompt]
+{prompt}
+
+[Acceptance / Scoring Criteria (the only authority)]
+{
+
+1. Hard Gates
+
+1.1 Whether the delivered project can actually be run and verified
+
+- Whether clear startup or run instructions are provided
+- Whether the project can be started or run without modifying core code
+- Whether the actual runtime behavior is broadly consistent with the delivery documentation
+
+    1.2 Whether the delivered project materially deviates from the Prompt
+
+- Whether the implementation is centered on the business goal or usage scenario described in the Prompt
+- Whether there are major parts of the implementation that are only loosely related, or unrelated, to the Prompt
+- Whether the project replaces, weakens, or ignores the core problem definition in the Prompt without justification
+
+2. Delivery Completeness
+
+2.1 Whether the delivered project fully covers the core requirements explicitly stated in the Prompt
+
+- Whether all explicitly stated core functional requirements in the Prompt are implemented
+
+    2.2 Whether the delivered project represents a basic end-to-end deliverable from 0 to 1, rather than a partial feature, illustrative implementation, or code fragment
+
+- Whether mock / hardcoded behavior is used in place of real logic without explanation
+- Whether the project includes a complete project structure rather than scattered code or a single-file example
+- Whether basic project documentation is provided, such as a README or equivalent
+
+3. Engineering and Architecture Quality
+
+3.1 Whether the project adopts a reasonable engineering structure and module decomposition for the scale of the problem
+
+- Whether the project structure is clear and module responsibilities are reasonably defined
+- Whether the project contains redundant or unnecessary files
+- Whether the implementation is excessively piled into a single file
+
+    3.2 Whether the project shows basic maintainability and extensibility, rather than being a temporary or stacked implementation
+
+- Whether there are obvious signs of chaotic structure or tight coupling
+- Whether the core logic leaves room for extension rather than being completely hard-coded
+
+4. Engineering Details and Professionalism
+
+4.1 Whether the engineering details and overall shape reflect professional software practice, including but not limited to error handling, logging, validation, and API design
+
+- Whether error handling is basically reliable and user-friendly
+- Whether logs support troubleshooting rather than being random print statements or completely absent
+- Whether necessary validation is present for key inputs and boundary conditions
+
+    4.2 Whether the project is organized like a real product or service, rather than remaining at the level of an example or demo
+
+- Whether the overall deliverable resembles a real application instead of a teaching sample or demonstration-only project
+
+5. Prompt Understanding and Requirement Fit
+
+5.1 Whether the project accurately understands and responds to the business goal, usage scenario, and implicit constraints described in the Prompt, rather than merely implementing surface-level technical features
+
+- Whether the core business objective in the Prompt is implemented correctly
+- Whether there are obvious misunderstandings of the requirement semantics or deviations from the actual problem
+- Whether key constraints in the Prompt are changed or ignored without explanation
+
+6. Aesthetics (frontend-only / full-stack tasks only)
+
+6.1 Whether the visual and interaction design fits the scenario and demonstrates reasonable visual quality
+
+- Whether different functional areas of the page are visually distinguishable through background, spacing, separation, or hierarchy
+- Whether the overall layout is reasonable, and whether alignment, spacing, and proportions are broadly consistent
+- Whether UI elements, including text, images, and icons, render and display correctly
+- Whether visual elements are consistent with the page theme and textual content, and whether there are obvious mismatches between images, illustrations, decorative elements, and the actual content
+- Whether basic interaction feedback is provided, such as hover states, click states, or transitions, so users can understand the current interaction state
+- Whether fonts, font sizes, colors, and icon styles are generally consistent, without obvious visual inconsistency or mixed design language
+  }
+
+Review Objective
+
+Determine whether the delivered project is a credible, runnable, prompt-aligned, and minimally professional 0-to-1 deliverable.
+
+Priority Order
+
+1. delivery runnability boundary
+2. prompt requirement fit
+3. security-critical flaws
+4. test sufficiency
+5. major engineering quality issues
+6. frontend aesthetics only if clearly applicable
+
+Execution Rules
+
+1. Review only the highest-impact findings that can change the final verdict.
+   Do not perform exhaustive enumeration of every secondary or tertiary checklist item.
+
+2. Do not relax standards for:
+
+- security
+- prompt-fit
+- delivery completeness
+- test sufficiency
+- evidence for material conclusions
+
+3. Do not skip any issue that could independently cause a Fail or Partial Pass verdict.
+
+4. If a security, prompt-fit, runnability, or core test-sufficiency issue is suspected, continue investigation until it is either evidenced or explicitly marked Cannot Confirm.
+
+5. Stop after either:
+
+- identifying up to 10 findings total, or
+- identifying up to 5 High / Blocker findings,
+  whichever comes first.
+
+6. Do not modify project code.
+
+7. Use evidence only for material conclusions.
+   For any conclusion that changes the final verdict, provide concrete, traceable evidence using file path + line number, tool output, or explicit runtime result.
+
+8. If evidence is insufficient, do not guess.
+   Use "Cannot Confirm" or explicitly label the assumption and its boundary.
+
+9. Perform runtime verification only when all of the following are true:
+
+- the command is explicitly documented
+- no Docker is required
+- no Docker-related command is required
+- no container orchestration is required
+- no privileged system access is required
+- no external network / third-party dependency is required
+- expected completion is short
+
+10. Never run Docker-related commands.
+    This includes, but is not limited to:
+
+- docker
+- docker compose
+- docker-compose
+- podman
+- container runtime / orchestration commands with equivalent effect
+
+11. If verification would require Docker or any container-related command, do not execute it.
+    Instead:
+
+- state that Docker-based runtime verification was not performed
+- treat it as a verification boundary, not automatically as a project defect
+- provide the local reproduction command(s) the user can run
+- state what was confirmed statically
+- state what remains unconfirmed
+
+12. Docker non-execution is a verification constraint, not a project defect by itself.
+    Only report a defect if the project itself lacks runnable documentation, has broken setup logic, or shows static evidence of delivery failure.
+
+13. Security review has priority over style issues.
+    Always assess:
+
+- authentication entry points
+- route-level authorization
+- object-level authorization
+- tenant / user isolation
+
+Expand security review further only if relevant code paths exist, such as:
+
+- admin / internal / debug endpoints
+- function-level authorization
+- privilege escalation paths
+
+14. Test review is mandatory, but do not build a full requirement-to-test traceability matrix.
+    Assess only whether tests sufficiently cover:
+
+- the core business happy path
+- major failure paths such as validation failure, 401, 403, 404, 409 where relevant
+- security-critical areas
+- obvious high-risk boundaries directly relevant to the business flow
+
+15. For test coverage, state only:
+
+- covered / partially covered / missing / cannot confirm
+- one or two supporting evidence points
+- the minimum additional test needed if coverage is weak
+
+16. Logging review is mandatory but concise.
+    Assess only:
+
+- whether logging exists for meaningful troubleshooting
+- whether logging categories are reasonably clear if present
+- whether there is obvious sensitive-data leakage risk in logs or responses
+
+17. Mock / stub / fake behavior is not a defect by itself unless the Prompt or documentation requires real integration.
+    If present, explain only:
+
+- the mock scope
+- how it is enabled
+- whether there is obvious accidental production-use risk
+
+18. Do not continue searching for additional low-severity issues after the final verdict is already supportable.
+
+19. Do not read unrelated files once enough evidence has been collected to support the verdict and top findings.
+
+Required Output Format
+
+Return exactly these sections:
+
+1. Verdict
+
+- Pass / Partial Pass / Fail / Cannot Confirm
+
+2. Scope and Verification Boundary
+
+- what was reviewed
+- what was not executed
+- whether Docker-based verification was required but not executed
+- what remains unconfirmed
+
+3. Top Findings
+
+- up to 10 findings only
+- each finding must include:
+    - Severity: Blocker / High / Medium / Low
+    - Conclusion
+    - Brief rationale
+    - Evidence
+    - Impact
+    - Minimum actionable fix
+
+4. Security Summary
+
+- authentication
+- route authorization
+- object-level authorization
+- tenant / user isolation
+  For each, return:
+- Pass / Partial Pass / Fail / Cannot Confirm
+- brief evidence or verification boundary
+
+5. Test Sufficiency Summary
+   Return:
+
+- Test Overview
+    - whether unit tests exist
+    - whether API / integration tests exist
+    - obvious test entry points if present
+- Core Coverage
+    - happy path: covered / partial / missing / cannot confirm
+    - key failure paths: covered / partial / missing / cannot confirm
+    - security-critical coverage: covered / partial / missing / cannot confirm
+- Major Gaps
+    - up to 3 highest-risk missing tests
+- Final Test Verdict
+    - Pass / Partial Pass / Fail / Cannot Confirm
+
+6. Engineering Quality Summary
+   Assess only major maintainability / architecture concerns that materially affect delivery confidence.
+
+7. Next Actions
+
+- up to 5 minimum actions only
+- prioritize by severity and unblock value
+
+Final Verification Before Output
+
+Before finalizing, check all of the following:
+
+1. Does each material conclusion have supporting evidence?
+2. Are any claims stronger than the evidence supports?
+3. If unsupported observations are removed, does the final verdict still hold?
+4. Has any uncertain point been incorrectly presented as a confirmed fact?
+5. Has security or test sufficiency been judged too loosely without evidence?
+6. Has any Docker non-execution boundary been incorrectly described as a confirmed runtime failure?
+
+If file writing is supported, save the final report to a markdown file.
+Otherwise, return the report in-chat.