theslopmachine 0.6.2 → 0.7.1

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

@@ -7,145 +7,150 @@ description: Developer-facing scaffold guidance for slopmachine.
 
 Use this skill during `P3 Scaffold` before prompting the developer.
 
-## Scaffold standard
+## Core idea
 
-- create real foundations, not decorative boilerplate
-- establish the real runtime contract
-- establish the local verification path and the standardized gate path
-- make prompt-critical baseline behavior real where required
-- keep repo-local `README.md` honest from the start
-- make the selected-stack primary runtime command and the universal `./run_tests.sh` broad test command real from the scaffold stage
-- make the first scaffold pass strong enough that owner scaffold acceptance can rely on a narrow checklist rather than rereading the whole scaffold broadly
+Scaffold is a simple baseline bootstrap step.
 
-For web projects using the default runtime model, scaffold must make these commands real and working before scaffold can pass:
+- do not treat scaffold as early product implementation
+- do not require prompt-specific business flows during scaffold unless they are necessary to choose the stack, runtime contract, required technologies, or baseline verification path
+- the goal is a safe baseline that boots, tests, and documents itself honestly
+- for web projects, that baseline must always include working `docker compose up --build` and containerized `./run_tests.sh`
+- for Android, iOS, and desktop projects, that baseline must also include working `docker compose up --build` plus containerized `./run_tests.sh`, even when the app's true product proof is platform-specific and differs from web runtime semantics
 
-- `docker compose up --build`
-- `./run_tests.sh`
+## Scaffold contract
 
-## Scaffold and foundation guidance
+Scaffold should deliver only the baseline needed to start real implementation safely:
 
-- create the initial project structure intentionally
-- follow the original prompt and existing repository first; only use the package defaults below when they do not already specify the platform or stack
-- when the selected stack has an official or clearly best-known bootstrap command, prefer using that bootstrap path instead of hand-creating the project tree from scratch
-- prefer the modern recommended bootstrap variant for the chosen stack rather than an outdated minimal skeleton when the prompt leaves room
-- use Context7 first and targeted web research second to choose the strongest bootstrap command, starter, or tooling combination when the stack has multiple viable setup paths
-- treat the generator-created project as the starting foundation, then adapt and harden it to satisfy the runtime, test, E2E, security, infra, and documentation rules below
-- when using an official or best-known bootstrap path, make sure the resulting scaffold also installs and wires the local verification tooling needed for ordinary iteration rather than leaving test/tool setup half-finished
-- only hand-build the scaffold from scratch when no credible bootstrap path exists, the existing repository already dictates a different structure, or the generated scaffold would clearly fight the prompt requirements
-- when the prompt leaves stack or framework details open, choose defaults that maximize execution speed, ecosystem stability, onboarding quality, and compatibility with the required runtime and verification model
-- when the prompt leaves stack or framework details open, make the chosen default stack and bootstrap command explicit before generating the scaffold
-- create `./run_tests.sh` during scaffold for every project as the single broad test entrypoint
-- for web projects, default scaffold to Docker-first runtime foundations unless the prompt or existing repository clearly dictates another model
-- for web projects, make `docker compose up --build` real as the primary runtime command during scaffold unless the prompt or existing repository clearly dictates otherwise
-- for Dockerized web projects, create a dev-only runtime bootstrap script during scaffold and make the Docker startup path call it automatically
-- for Dockerized web projects, the local user should not need any manual `export ...` step before `docker compose up --build`
-- for Dockerized web projects, do not use `.env` files or hardcoded runtime values to satisfy local startup
-- for Dockerized web projects, use the bootstrap script to generate or inject local-development runtime values during startup instead of committing them to the repo
-- for Dockerized web projects, do not pre-seed secret literals in Compose files, config files, Dockerfiles, or startup scripts even if they are labeled dev-only, test-only, or non-production
-- for Dockerized web projects, if runtime values must persist across restarts, persist them only in Docker-managed runtime state rather than committed repo files
-- for Dockerized web projects, place a clear comment in that bootstrap script that it is for local development bootstrap only and is not the production secret-management path
-- when `docker compose up --build` is not the runtime contract, create `./run_app.sh` during scaffold as the single primary runtime wrapper
-- make `./run_tests.sh` self-sufficient from a clean Linux VM that only has Docker and curl available by default
-- do not rely on host package managers or preinstalled host language runtimes for the broad test path when Docker can provide the execution environment instead
-- for web projects using the default Docker-first runtime model, `./run_tests.sh` must execute the broad test path through Docker and should own that Dockerized test flow directly instead of requiring separate manual pre-setup
-- for Dockerized web projects, `./run_tests.sh` must use the same bootstrap path or an equivalent path with the same generated-value rules as `docker compose up --build`
-- when host-level setup would otherwise be required, prefer a Dockerized `./run_tests.sh` path so the broad test remains portable on a bare machine
-- for non-web or non-Docker projects, `./run_tests.sh` must execute the selected stack's platform-equivalent broad test flow while preserving the same single-command interface
-- local non-Docker test commands should still be installed and working for normal development iteration
-- for Electron or other Linux-targetable desktop projects, make `./run_tests.sh` own a Dockerized broad path that covers build, tests, packaging smoke checks, and headless UI/runtime verification through Xvfb or an equivalent Linux-capable desktop harness
-- for Android projects, make `./run_tests.sh` own a Dockerized broad path that covers Gradle build, lint, unit tests, and local Android JVM-side tests such as Robolectric without depending on an emulator
-- for iOS-targeted projects, still create `./run_tests.sh`, but make it the portable Linux verification wrapper for lint, typecheck, shared logic tests, JS/UI-level tests when applicable, and static config/build-shape validation rather than fake native iOS runtime proof
-- create required testing directories and baseline docs structure
-- create the owner-maintained external docs structure under parent-root `../docs/`
-- do not create documentation files inside `repo/` beyond `README.md`
-- put baseline config, logging, validation, and error-normalization structure in place
-- install and configure the local test tooling needed for ordinary iteration during scaffold rather than deferring local testing setup to later phases
-- create baseline test structure intentionally during scaffold so the project can grow toward at least 90 percent meaningful coverage instead of retrofitting tests late
-- when API tests are material, scaffold them so they hit real endpoints and print simple useful response evidence such as status codes and message/body summaries instead of hiding the real API behavior behind helper-only checks
-- for frontend-bearing web projects, install the local browser E2E tooling plus the component/page-or-route frontend test layer during scaffold when the project will need them
-- for mobile projects, install the local mobile testing layer during scaffold, defaulting to Jest plus React Native Testing Library for Expo/React Native work
-- for desktop projects, install the local desktop testing layer during scaffold, defaulting to the selected project test runner and Playwright Electron support or an equivalent desktop UI/E2E tool when UI verification is required
-- for Android projects, install the local Android testing layers needed for the Dockerized broad path during scaffold without relying on an emulator
-- for iOS-targeted projects, install the portable test layers that can run on Linux during scaffold and document any native iOS runtime/build gap honestly instead of hiding it
-- put migrations, worker/job foundation, and real runtime health surfaces in place when the project needs them
-- when the project has database dependencies, create `./init_db.sh` during scaffold as the only project-standard database initialization path
-- if the project has database dependencies, make `./init_db.sh` handle the real database setup already known at scaffold time rather than leaving a placeholder shell
-- if the project has database dependencies, wire the runtime and test entrypoints to call `./init_db.sh` whenever database preparation is required
-- if the project has database dependencies, treat `./init_db.sh` as a living project artifact that must be expanded as migrations, schema setup, bootstrap data, and other database dependencies become real through implementation
-- do not hardcode database connection values or database bootstrap values in the repo; drive database setup through `./init_db.sh`
-- when the project has database dependencies, do not package local database dependency files or local database state as part of delivery; the delivery should rely on the initialization-script path instead
-- treat prompt-critical security controls as real baseline runtime behavior, not placeholder checks or visual wiring
-- if a requirement implies enforcement, persistence, statefulness, or rejection behavior, make that behavior real in the scaffold unless the prompt clearly scopes it down
-- do not accept shape-only security implementations such as header presence checks, passive constants, or partially wired middleware when the requirement implies real protection
-- when applicable at scaffold time, require platform-appropriate real security baselines rather than shape-only placeholders
-- for web service flows, examples include nonce replay rejection, real lockout behavior, CSRF rejection on protected mutations, and meaningful server-side state when the protection model depends on it
-- for mobile flows, examples include safe auth-state handling, no bundled secrets, secure token storage when runtime tokens must be persisted, and protected deep-link or privileged screen behavior when applicable
-- for desktop flows, examples include secure preload/contextBridge boundaries, `contextIsolation` preserved, `nodeIntegration` not exposed by default in the renderer, and privileged actions kept out of untrusted renderer reach
-- remove prototype residue from runtime foundations: no placeholder titles, hidden setup, fake defaults, or seeded live-path assumptions
-- make prompt-critical runtime behavior visible in the scaffold instead of hand-waving it for later, especially offline, worker, backup, or HTTPS requirements
-- for Dockerized web projects, keep runtime isolation clean in shared environments: use self-contained Compose namespacing, avoid fragile generic project names, and prefer Compose-managed service naming over unnecessary hardcoded `container_name` values
-- 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
-- require reproducible build and tooling foundations: prefer lockfile-driven installs where the stack supports them, keep source and build outputs clearly separated, and do not allow generated runtime artifacts to drift back into source directories
-- for typed build pipelines, keep source-of-truth boundaries clean so compiled output does not create TS/JS or similar dual-source drift in the working tree
-- establish README structure early instead of leaving it until the end
-- ensure `README.md` clearly documents the primary runtime command and the broad `./run_tests.sh` contract for the selected stack
-- ensure `README.md` focuses on what the project does, how to run it, how to test it, the main repo contents, and any important new-developer information rather than trying to replace the full API catalog
-- ensure `README.md` also explains the delivered architecture and major implementation structure clearly enough for code review and handoff
-- ensure `README.md` stands on its own and does not tell users or reviewers to rely on parent-root docs for core repo understanding
-- for Dockerized web projects, ensure `README.md` explains that local runtime values are bootstrapped automatically by the development startup path and that this is local-development behavior rather than production secret management
-- maintain the seeded parent-root `../docs/design.md` as the owner-maintained planning/design contract from the start
-- maintain the seeded parent-root `../docs/test-coverage.md` as the owner-maintained evaluator-facing test matrix from the start
-- when API surfaces are material, fill in the seeded parent-root `../docs/api-spec.md` instead of treating it as a later add-on
-- if the project uses mock, stub, fake, interception, or local-data behavior, disclose that scope in `README.md` during scaffold instead of waiting until late phases
-- if mock or interception behavior is enabled by default, disclose that default state in `README.md` during scaffold
-- if feature flags, debug or demo surfaces, or default-enabled config toggles exist, disclose them in `README.md` during scaffold and record the fuller reference in parent-root docs when needed
-- establish a shared logging path during scaffold with meaningful categories, redaction expectations, and no reliance on random print statements as the long-term logging surface
-- establish a shared validation path during scaffold so forms, requests, boundary checks, and normalized error behavior do not get invented ad hoc later
-- prove the scaffold in a clean state before deeper feature work
-- verify clean startup and teardown behavior under the selected stack's runtime contract
-- make the scaffold handoff compact and checklist-driven: the developer should be able to state runtime proof, test proof, docs honesty, and required repo-surface proof without a long narrative dump
-- for Dockerized web projects, verify clean startup and teardown behavior under the chosen project namespace
-- when the architecture materially depends on infrastructure capabilities such as rate limiting, encryption, offline support, or browser-storage policy, put the baseline framework and policy in place during scaffold rather than deferring it to late implementation
-- for backend integration paths, prefer production-equivalent test infrastructure when practical rather than silently substituting a weaker database or runtime model that can hide real defects
-- do not treat scaffold as placeholder boilerplate or rely on hidden setup
-
-## Current policy
+- chosen stack and bootstrap path are explicit
+- requested platform and required technologies are installed and wired
+- the primary runtime command is real
+- `./run_tests.sh` is real as the portable broad test wrapper
+- `docker compose up --build` is real and working
+- `./run_tests.sh` is containerized and working
+- `./run_app.sh` may exist as an additional platform helper when useful, but it does not replace the Docker-based baseline contract
+- minimal real tests exist so the scaffold is not mostly `NO-SOURCE`
+- `README.md` is honest about scaffold status, runtime, tests, and main module layout
+- `README.md` already includes the baseline section shape needed for the final README audit, even if many sections are still marked scaffold-level
+
+## What scaffold is not
+
+Do not turn scaffold into feature delivery.
+
+At scaffold time, do not require:
+
+- prompt-specific business workflows
+- full auth/role/product enforcement unless the runtime baseline genuinely depends on it
+- final module completion
+- integrated product polish
+- deep domain behavior beyond what the chosen stack/runtime/tests need immediately
+
+## Runtime selection rule
+
+- follow the original prompt and existing repository first
+- for web projects, `docker compose up --build` is always required as the runtime baseline contract
+- for Android, iOS, and desktop projects, `docker compose up --build` is also required, but it may start a meaningful containerized build, artifact, preview, or support environment rather than pretending to be native runtime proof
+- `./run_tests.sh` must exist for every project and be containerized
+- when helpful, non-web projects may also provide `./run_app.sh` for host-side convenience or platform-specific local flow, but that does not replace the required Docker commands
+
+## Playbook rule
+
+- use the packaged scaffold docs under `~/slopmachine/scaffold-playbooks/` as owner-side source material
+- start with `~/slopmachine/scaffold-playbooks/selection-matrix.md`
+- use `docker-shared-contract.md` as the common Docker/runtime/test contract
+- when no exact stack playbook exists yet, use `generic-unknown-tech-guide.md` before falling back to nearest-family improvisation
+- use the family matrices to resolve placeholders, language-only prompts, and open-ended stack selections before choosing a concrete playbook
+- do not tell the developer to read those files directly if they are outside `repo/`; restate the relevant directives in the developer prompt
+- when a matching playbook exists, prefer following it over inventing a new scaffold contract from scratch
+- if no exact playbook exists, choose the nearest platform family playbook plus the framework-specific bootstrap command that best matches the prompt
+
+## Bootstrap rule
+
+- when the selected stack has an official or clearly best-known bootstrap command, prefer it
+- prefer the current recommended bootstrap variant rather than an outdated minimal skeleton
+- only hand-build from scratch when no credible bootstrap path exists or the existing repo already dictates a different structure
+- after generation, adapt only enough to make the baseline runtime, tests, wrapper scripts, and README contract real
+
+## Safe defaults
 
 - no `.env` files or env-file variants in the repo
-- do not edit `AGENTS.md` or other workflow/rulebook files unless explicitly asked
+- no committed secrets or plaintext bootstrap credentials
 - keep generated artifacts out of source-of-truth paths
-- keep real secrets out of the repository and use the selected stack's runtime/platform mechanism for sensitive values
-- if the stack requires env-file format at runtime, generate it ephemerally from the selected runtime environment rather than storing it in the repo or package
-- for Dockerized web projects, `docker compose up --build` must work as a single command without user-side exports
-- for Dockerized web projects, `./run_tests.sh` must work under the same no-export, no-`.env`, no-pre-seeded-secret-literals model
-- if the project has database dependencies, `./init_db.sh` must exist from scaffold onward and stay current with the real database setup
-- if the project uses mock, stub, fake, interception, or local-data behavior, the scaffold must already make those boundaries statically visible in docs and code structure
-- the repo must not depend on parent-root docs or sibling artifacts for startup, testing, build/preview, config, security understanding, or evaluator traceability
+- make the repo self-sufficient through code plus `README.md`
+- do not create extra in-repo docs beyond `README.md`
+- use one bootstrap source of truth when seed/setup data is needed
+- keep runtime/test/bootstrap paths aligned instead of inventing separate hidden setup flows
 
-## Acceptance target
+## Baseline requirements
+
+- create the initial project structure intentionally
+- wire the required technologies named by the prompt or selected by the default stack
+- install local targeted test tooling needed for ordinary development iteration
+- create baseline test structure intentionally during scaffold
+- when backend or fullstack API surfaces already exist at scaffold time, create the test structure in a way that later endpoint-by-endpoint mapping and true no-mock HTTP testing can grow without churn
+- create `./run_tests.sh` during scaffold for every project
+- create `./run_app.sh` during scaffold for non-web platforms when it helps expose the host-side or platform-specific local flow, but keep `docker compose up --build` and containerized `./run_tests.sh` as required baseline commands
+- if the project has database dependencies, create `./init_db.sh` during scaffold as the only project-standard database initialization path
+- make the scaffold handoff compact and checklist-driven rather than a long narrative dump
+
+## Minimal real test floor
+
+Do not leave the broad path mostly empty.
+
+At scaffold, require at least:
+
+- one or more real tests for a core baseline contract or rules/helper layer
+- one real runtime/build verification path in `./run_tests.sh`
+- one real smoke-level proof that the chosen stack is wired correctly
+- any static verification tasks that the selected platform needs to keep the baseline honest, such as schema export verification, lint, typecheck, or package/build health
+- one real Docker-backed runtime/build path behind `docker compose up --build`
+
+## README floor
+
+`README.md` inside `repo/` must already state:
+
+- project type near the top using one of `backend`, `fullstack`, `web`, `android`, `ios`, or `desktop`
+- scaffold status versus implemented product scope
+- primary runtime command
+- required Docker command: `docker compose up --build`
+- broad test command
+- startup instructions
+- access method
+- verification method
+- authentication section with demo credentials for known roles or the exact statement `No authentication required`
+- tech stack clarity and brief architecture explanation
+- important roles or workflows when relevant
+- major module or repo layout
+- important bootstrap/setup notes
+- any major honesty boundaries such as local-only, mock-only, offline-only, no-emulator, or no-native-runtime proof when those limits apply
+
+When the project type requires extra README shape for the final audit:
+
+- backend, fullstack, and web projects should include the exact legacy compatibility string `docker-compose up` somewhere in startup guidance in addition to the canonical `docker compose up --build` contract
+- Android projects should include a host-side build or emulator or device guidance section even though Docker remains required for the final broad contract
+- iOS projects should include Xcode or simulator or device guidance when applicable even though Docker remains part of the broader SlopMachine contract
+- desktop projects should include host-side run or build guidance when applicable even though Docker remains part of the broader SlopMachine contract
+
+## Parallelism rule
+
+- once the stack, runtime contract, and wrapper-script shape are fixed, use parallel branches for independent scaffold foundations when that materially reduces elapsed time
+- good scaffold parallel candidates include app shell, test harness, config wiring, and README baseline work that touch different areas
+- do not parallelize overlapping generator churn or shared foundation invention before the baseline contract is stable
 
-Scaffold should make later slices easier, not force them to retrofit missing fundamentals.
+## Acceptance target
 
-Before scaffold is handed back for owner acceptance, the developer should already have a compact answer for these scaffold checklist items:
+Scaffold is acceptable when:
 
-- runtime bootstrap works
-- database/bootstrap path works when relevant
-- `./run_tests.sh` works at the broad-scaffold level
-- frontend/backend wiring shape is real
-- config/env/bootstrap path is honest
-- `README.md` and scaffold docs are honest about what is and is not implemented
-- required scaffold files and directories exist
+- `docker compose up --build` works
+- `./run_tests.sh` works at the scaffold baseline level
+- required wrapper scripts exist and are honest
+- required technologies are wired
+- minimal real tests exist
+- `README.md` is honest and traceable
 - prohibited shortcuts or residue are not present
 
 ## Verification cadence
 
 - use local and narrow checks while correcting scaffold work
 - reserve one broad owner-run scaffold gate for actual scaffold acceptance
-- do not spend extra broad reruns once the acceptance question is already answered
-- for web projects using the default Docker-first runtime model, the owner must run `docker compose up --build` and `./run_tests.sh` once after scaffold completion to confirm the baseline actually works
-- after that single scaffold proof, ordinary development should use only local fast verification until development-complete / integrated-verification entry unless a real blocker forces earlier broad reruns
-- after that scaffold confirmation, do not run Docker again during ordinary development work; the next Docker-based run should be at development completion when integrated behavior is checked
+- for web projects, the owner should run `docker compose up --build` and `./run_tests.sh` once after scaffold completion
+- after scaffold acceptance, return to local fast verification until the next major gate unless a real blocker forces earlier escalation

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

@@ -28,15 +28,21 @@ The final delivery layout in the parent project root must be:
   - `api-spec.md` when applicable
   - `test-coverage.md`
   - `questions.md`
-- `sessions/`
-  - `<label>.json` for every tracked developer session, including `develop-N.json` and `bugfix-N.json` when present
-- `session-<label>.json` for every tracked developer session
+- for non-Claude developer sessions:
+  - `sessions/`
+  - `sessions/<label>.json` for every tracked developer session, including `develop-N.json` and `bugfix-N.json` when present
+- for Claude-backed developer sessions:
+  - `claude-sessions.zip` in the parent root containing the whole Claude project session folder once
+  - no `sessions/` directory is required when all tracked developer sessions are Claude-backed
 - `metadata.json`
-- `self_test_reports/`
-  - `cycle-0/`
-  - `cycle-1/`
+- `.tmp/`
+  - `audit_report-<N>.md` only for bugfix-triggering `partial pass` audits
+  - `audit_report-<N>-fix_check-<M>.md` when present
+  - `test_coverage_and_readme_audit_report.md`
 - `repo/`
 
+In the clean two-bugfix path, `.tmp/` should end with at least 5 required markdown reports once the final coverage/README audit is included: 2 kept partial-pass audit reports, at least 2 corresponding fix-check reports, and the final coverage/README audit report. Extra fix checks may legitimately increase that count.
+
 Inside the delivered `repo/`, the repository must remain self-sufficient:
 
 - `README.md`
@@ -64,34 +70,32 @@ No screenshots are required as packaging artifacts.
 - include `./run_tests.sh` and any supporting runner logic it needs to execute the project's broad test path from a clean environment
 - when the project has database dependencies, include `./init_db.sh` and ensure it reflects the final delivered database setup rather than an earlier scaffold placeholder
 - when the project has database dependencies, package the initialization-script path rather than raw environment-specific database dependency artifacts or local database state
-- verify parent-root `../self_test_reports/` exists and contains the required counted cycle directories
+- verify parent-root `../.tmp/` exists and contains the required audit and fix-check reports
+- verify parent-root `../.tmp/test_coverage_and_readme_audit_report.md` exists from the final post-bugfix coverage/README audit
 - export all tracked developer sessions before closing packaging
 - when packaging succeeds, update workflow metadata to mark `packaging_completed` as true
 
 ## Session export sequence
 
-Export every tracked developer session from metadata, keep a numbered cleaned root export, and convert each session into its lane-aware trajectory file.
-
-Use the tracked lane labels for converted developer sessions, for example:
+Export tracked developer sessions from metadata using the tracked lane labels, for example:
 
 - `develop-1`
 - `bugfix-1`
 
-For each tracked developer session:
+For session export:
 
-1. if `<backend>` is `claude`, run `node ~/slopmachine/utils/export_ai_session.mjs --backend claude --cwd "$PWD" --session-id <session-id> --output ../session-<N>.json`
-2. if `<backend>` is not `claude`, run `opencode export <session-id> > ../session-export-<label>.raw`
-3. if `<backend>` is not `claude`, run `python3 ~/slopmachine/utils/strip_session_parent.py ../session-export-<label>.raw --output ../session-<N>.json`
-4. `node ~/slopmachine/utils/convert_exported_ai_session.mjs --converter-script ~/slopmachine/utils/convert_ai_session.py --input ../session-<N>.json --output ../sessions/<label>.json`
+1. if at least one tracked developer session backend is `claude` or `claude-live`, run `node ~/slopmachine/utils/package_claude_session.mjs --cwd "$PWD" --session-id <any-claude-session-id> --label claude-sessions --output ../claude-sessions.zip`
+2. if `<backend>` is neither `claude` nor `claude-live`, run `opencode export <session-id> > ../session-export-<label>.raw`
+3. if `<backend>` is neither `claude` nor `claude-live`, run `python3 ~/slopmachine/utils/strip_session_parent.py ../session-export-<label>.raw --output ../sessions/<label>.json`
 
 Where `<backend>` comes from the tracked developer session record in metadata.
-Use `opencode` when no explicit backend field exists.
-Use the tracked developer-session order to assign `<N>`.
+Use `opencode` when no explicit backend field exists or when the backend is not Claude-backed.
+For Claude-backed sessions, the package helper resolves the Claude project folder under `~/.claude/projects/` from a tracked `session_id` plus the current project `cwd`, normalizes the copied JSONL session files by flattening channel-originated user turns, and packages that folder once.
 
 After those steps:
 
-- verify every tracked developer session has been exported and converted into `../sessions/` before continuing
-- keep `../session-<N>.json` in the parent root as the cleaned or direct exported session artifact
+- verify every non-Claude developer session has been exported into `../sessions/<label>.json`
+- verify Claude-backed sessions have been packaged once into `../claude-sessions.zip`
 - treat only the raw `../session-export-<label>.raw` files as temporary packaging intermediates
 - remove the raw `../session-export-<label>.raw` files before closing packaging
 - if the required utilities, metadata session ids, or output files are missing, packaging is not ready to continue
@@ -101,11 +105,12 @@ After those steps:
 - run `python3 ~/slopmachine/utils/cleanup_delivery_artifacts.py .` once near the end of packaging to remove known recursive cleanup targets from the delivered repo tree
 - remove runtime, editor, cache, tooling noise, generated artifacts, and environment junk recursively anywhere in the delivered repo tree
 - do not remove required delivery artifacts just because they look noisy
-- remove `.opencode/`, `.codex/`, `.vscode/`, env-file variants, caches, `node_modules/`, `.venv/`, `.net/`, build outputs not part of delivery, raw test artifact directories, `__pycache__/`, `.pytest_cache/`, repo-local `AGENTS.md`, and accidental in-repo docs directories or extra documentation files beyond `README.md`
+- the cleanup helper removes common known targets such as `.opencode/`, `.codex/`, `.vscode/`, env-file variants, `node_modules/`, `.venv/`, `.net/`, common build/cache directories, `__pycache__/`, `.pytest_cache/`, and repo-local `AGENTS.md` / `CLAUDE.md`
 - remove environment-dependent content, local dependency trees, editor state, package-manager caches, and runtime caches anywhere in the delivery tree
 - do not package database dependency files or local database state when the delivered database setup is supposed to be injected through initialization scripts
-- do not package AI session conversion scripts or similar workflow utility scripts inside the delivered product attachment
-- remove repo-local `.tmp/` or parent-root `../.tmp/` if they exist; they are not part of the final delivery contract
+- manually review for accidental in-repo docs directories or workflow utility scripts that the helper does not remove automatically, and remove them before closing packaging
+- remove repo-local `.tmp/` if it exists and is not part of the delivered product
+- do not remove parent-root `../.tmp/`; it now holds the required `P7` audit and fix-check artifacts
 - the cleanup is recursive; do not leave forbidden directories or generated junk buried deeper in the repo hierarchy after cleanup
 
 ## Validation checklist
@@ -120,11 +125,12 @@ After those steps:
 - when the project has database dependencies, confirm database setup is injected through initialization scripts rather than packaged local database dependency artifacts
 - confirm the cleanup helper has been run and that no known recursive cleanup targets remain in the delivered repo tree
 - confirm no environment-dependent dependency directories, editor-state folders, runtime caches, or workflow utility scripts are packaged into the delivered product
-- confirm parent-root `../self_test_reports/` exists and contains the required counted cycle directories
-- confirm each counted cycle directory contains the initial audit report plus any fix-check reports generated for that cycle
+- confirm parent-root `../.tmp/` exists and contains the required kept `audit_report-<N>.md` files for partial-pass audits only
+- confirm every bugfix-triggering audit number has its matching `audit_report-<N>-fix_check-<M>.md` files when fix checks were required
+- confirm parent-root `../.tmp/test_coverage_and_readme_audit_report.md` exists and is the final replaced copy rather than a numbered variant
 - confirm parent-root `../docs/test-coverage.md` explains the tested flows, mapped tests, and coverage boundaries
-- confirm exported developer sessions exist under parent-root `../sessions/` using the tracked `<label>.json` names
-- confirm cleaned session exports exist in the parent root as numbered `../session-<N>.json` files
+- confirm every non-Claude developer session exists under parent-root `../sessions/` using the tracked `<label>.json` names
+- confirm Claude-backed developer sessions exist in the parent root as `claude-sessions.zip`
 - confirm parent-root `../docs/` remains consistent as an external reference set when workflow policy still requires it, but the delivered repo does not depend on it
 - confirm parent-root metadata fields are populated correctly
 - confirm workflow metadata marks `packaging_completed` as true
@@ -137,4 +143,4 @@ After those steps:
 - confirm the delivered project is actually runnable in the promised startup model, the documented tests are runnable, frontend behavior is usable when applicable, UI quality is acceptable, core logic is complete, and Docker startup works when Docker is the runtime contract
 - confirm the final git checkpoint can be created cleanly for the packaged state when a checkpoint is needed
 - if packaging reveals a real defect or missing artifact, fix it before closing the phase
-- do not close packaging until all required docs, session exports, self-test files, cleanup conditions, and final structure checks are satisfied
+- do not close packaging until all required docs, session exports, audit/fix-check files, cleanup conditions, and final structure checks are satisfied