theslopmachine 0.3.7 → 0.4.0

package/assets/skills/hardening-gate-v2/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: hardening-gate-v2
+description: Release-readiness hardening rules for slopmachine-v2.
+---
+
+# Hardening Gate v2
+
+Use this skill only during `P6 Hardening`.
+
+## Hardening audit priorities
+
+The hardening phase should explicitly prepare the project to pass the final audit in these priority areas:
+
+1. prompt-fit
+2. security-critical flaws
+3. test sufficiency
+4. major engineering quality
+
+Hardening should treat these as the main review buckets before final evaluation begins.
+
+## Hardening scope
+
+- dependency hygiene
+- secret and config hygiene
+- prototype residue cleanup
+- docs honesty
+- observability and redaction hygiene
+- fragile-test and release-readiness cleanup
+
+## Hardening guidance
+
+- run a prompt-fit sweep for silent requirement substitution, partially delivered hard requirements, frontend/backend mismatch, and business-flow drift
+- audit security boundaries, validation, ownership, and secret handling
+- prioritize authentication, authorization, object ownership, tenant isolation, admin/debug exposure, and secret leakage risk over style issues
+- audit whether the current tests are sufficient to catch major issues in the core business flow, major failure paths, security-critical areas, and obvious high-risk boundaries
+- audit env/config paths so sensitive values are injected safely and are not baked into committed files or images
+- inspect architecture, coupling, file size, and maintainability risks
+- focus engineering review on the major maintainability and architecture concerns that materially affect delivery confidence
+- check for bad engineering practices that accumulated during implementation
+- tighten weak tests, weak docs, and weak operational instructions
+- run exploratory testing around awkward states, repeated actions, and realistic edge behavior
+- re-check frontend and backend observability, redaction, and operator visibility paths
+- run a prototype-residue sweep for hardcoded preview values, placeholder text, seeded defaults, hidden fallbacks, and computed-but-unrendered behavior
+- enforce env-file discipline during hardening
+- run documentation verification against the real codebase and runtime behavior, not just document existence
+- re-check prompt-critical operational obligations such as scheduled jobs, retention, backups, worker behavior, privacy/accountability logging, and admin controls
+- enter release-candidate mode: stop feature work and focus only on fixes, verification, docs, and packaging preparation
+- make sure the system is genuinely reviewable and reproducible
+
+## Required hardening output
+
+Before `P6` can close, the owner should have a clear answer for each of these:
+
+- prompt-fit: does the delivered project still match the business goal, core flows, and implicit constraints?
+- security-critical flaws: are there any unresolved auth, authorization, isolation, exposure, or secret-handling defects?
+- test sufficiency: are the current tests strong enough to rule out most major issues, and if not, what was added or strengthened?
+- major engineering quality: is the project structurally credible and maintainable, rather than piled-up or demo-grade?
+
+## Rules
+
+- do not start hardening until integrated verification is explicitly stable
+- hardening is not a disguised second integrated phase
+- if hardening exposes unresolved integrated instability, reopen the earlier phase cleanly
+- do not use hardening for broad feature work

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

@@ -0,0 +1,47 @@
+---
+name: integrated-verification-v2
+description: Integrated verification convergence and rerun-ladder rules for slopmachine-v2.
+---
+
+# Integrated Verification v2
+
+Use this skill only during `P5 Integrated Verification`.
+
+## Core model
+
+Treat the first broad integrated run as a discovery pass.
+
+Once a failure class is known:
+
+- classify it
+- isolate the likely affected module, route family, spec family, helper family, or shared flow
+- direct narrow proof and narrow repairs first
+- escalate back to a broad rerun only when the narrower evidence is no longer sufficient
+
+## Verification and review guidance
+
+- run the relevant tests for the changed behavior
+- during in-phase verification, prefer the fastest meaningful local test commands for the known failure class
+- use local verification to prepare for the next owner-run broad gate rather than duplicating it casually
+- for applicable fullstack or UI-bearing work, run Playwright for the affected flows in-phase, capture screenshots, and verify the UI behavior and quality directly
+- verify requirement closure, not just feature existence
+- verify behavior against the current plan, the actual requirements, and any settled project decisions that affect the change
+- verify end-to-end flow behavior where the change affects real workflows
+- for fullstack work, run Playwright coverage for major flows and review screenshots for real UI behavior and regressions
+- end-to-end coverage must use the real intended user-facing or admin-facing surfaces for the flow; if the flow cannot be exercised that way, treat the missing surface as incomplete work
+- verify important failure, conflict, stale-state, negative-auth, and cross-user-isolation paths where relevant
+- verify security-sensitive behavior where applicable
+- verify multi-tenant and cross-user isolation where applicable, including negative checks rather than single-actor happy paths only
+- verify file/path safety for file-bearing flows where applicable, including traversal-style negative cases
+- verify secrets are not committed, hardcoded, or leaking through logs/config/docs
+- verify error surfaces and auth-related failures are sanitized for users and operators appropriately
+- trace the changed tests and verification back to the prompt-critical risks, not just the easiest happy paths
+- challenge integration seams and adjacent-module behavior, not just the changed module local path
+
+## Rules
+
+- keep integrated verification as a real full-system gate
+- do not rerun the whole heavy suite after every single failure by default
+- generalize shared failure classes early instead of rediscovering them slice by slice
+- do not allow hardening to start before integrated stability is explicit
+- if a broad rerun is not answering a new question, stop and go back to narrow proof

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

@@ -0,0 +1,15 @@
+---
+name: owner-evidence-discipline-v2
+description: Owner evidence-ingestion rules for lower-token slopmachine-v2 review loops.
+---
+
+# Owner Evidence Discipline v2
+
+Use this skill when owner review risks rereading too much evidence.
+
+## Rules
+
+- read evidence once, summarize the decision-relevant facts, and reopen only on material change
+- avoid rereading the same large artifact sets late in the run unless something actually changed
+- keep evidence notes concrete so later decisions do not require large re-ingestion passes
+- prefer reading only the file sections needed to answer the current question

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

@@ -9,22 +9,24 @@ Use this skill during `P2 Development Bootstrap and Planning` when reviewing, ti
 
 ## Usage rules
 
-- Load this skill before accepting planning, before declaring the plan sufficient, and before creating deep execution sub-beads from the plan.
+- Load this skill before accepting planning, before declaring the plan sufficient, and before creating deep execution sub-items from the plan.
 - Treat it as owner-side planning gate guidance, not developer-visible text.
 - Use `get-overlays` as the source of truth for developer-facing planning guidance.
 - Use this skill as the source of truth for owner-side planning acceptance and decomposition readiness.
+- do not pause for planning approval or any other human check-in while using this skill; planning must continue until it is accepted internally or sent back to the developer for fixes
+- maintain the owner-managed external planning docs in parent-root `../docs/` from the accepted plan rather than treating them as developer-owned files
 
 ## Core planning gate
 
 - the developer should produce the first in-depth technical plan
-- do not create deep execution sub-beads before the technical plan is accepted
+- do not create deep execution sub-items before the technical plan is accepted
 - do not accept planning that reduces, weakens, narrows, or silently reinterprets the original prompt
 - declare prompt-critical planning acceptance criteria before accepting the first planning pass when those criteria are already visible from the prompt
 - require relevant cross-cutting system contracts to be explicitly planned rather than left to per-module invention
 
 ## Cross-document discipline
 
-- require working planning docs under `docs/` when relevant, especially `docs/design.md`, `docs/api-spec.md`, and `docs/test-coverage.md`
+- require owner-maintained planning docs under parent-root `../docs/` when relevant, especially `../docs/design.md`, `../docs/api-spec.md`, and `../docs/test-coverage.md`
 - require cross-document consistency so design, API/spec, and test-planning artifacts do not drift on lifecycle/state models, permissions, flow coverage, or operational behavior
 - if planning docs disagree on core system behavior, planning is still in progress
 
@@ -65,4 +67,4 @@ Before accepting planning, apply this checklist when relevant:
 
 - the first real technical plan is accepted against this gate
 - planning artifacts are internally consistent enough to guide implementation
-- deep execution sub-beads can be created from the accepted plan without guesswork
+- deep execution sub-items can be created from the accepted plan without guesswork

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

@@ -0,0 +1,91 @@
+---
+name: planning-gate-v2
+description: Owner-side planning acceptance and correction rules for slopmachine-v2.
+---
+
+# Planning Gate v2
+
+Use this skill during `P2 Planning` when reviewing or accepting the plan.
+
+## Planning gate priorities
+
+Before planning is accepted, the owner should explicitly review the plan against these later audit buckets:
+
+1. prompt-fit
+2. security-critical flaws
+3. test sufficiency
+4. major engineering quality
+
+Planning should not pass if these have been ignored in a way that is likely to create expensive late failures.
+
+## Core rule
+
+If the owner notices a concrete role, contract, or scope mismatch, planning does not pass until one of these is true:
+
+- the mismatch is corrected
+- an explicit disposition note explains why acceptance is still valid
+
+## Usage rules
+
+- keep the existing high bar for implementation-grade planning
+- treat this as owner-side planning gate guidance, not developer-visible text
+- do not create deep execution decomposition before the plan is accepted
+- keep planning as a cheap correction point rather than pushing known ambiguity into execution
+
+## Core planning gate
+
+- the developer should produce the first in-depth technical plan
+- do not create deep execution sub-items before the technical plan is accepted
+- do not accept planning that reduces, weakens, narrows, or silently reinterprets the original prompt
+- declare prompt-critical planning acceptance criteria before accepting the first planning pass when those criteria are already visible from the prompt
+- require relevant cross-cutting system contracts to be explicitly planned rather than left to per-module invention
+
+## Cross-document discipline
+
+- require owner-maintained planning docs under parent-root `../docs/` when relevant, especially `../docs/design.md`, `../docs/api-spec.md`, and `../docs/test-coverage.md`
+- require cross-document consistency so design, API/spec, and test-planning artifacts do not drift on lifecycle/state models, permissions, flow coverage, or operational behavior
+- if planning docs disagree on core system behavior, planning is still in progress
+
+## Cross-cutting planning requirements
+
+- require shared lifecycle and state models to be aligned across planning artifacts when the product has meaningful workflow state
+- require explicit cross-cutting system contracts when relevant, especially:
+  - error normalization and user-visible error behavior
+  - audit/logging and redaction patterns
+  - permission alignment across UI, route guards, and API enforcement
+  - state-transition and context-switch behavior
+  - auth/session edge cases such as expiry, refresh, or clock skew tolerance
+- when the prompt says behavior is configurable, require the real configuration surface, permissions, operator flow, and backend support to be planned explicitly
+- when a feature must be admin-manageable or operator-manageable, require a real usable UI surface for that management flow, not just API endpoints or data-model notes
+
+## Architecture-depth requirements
+
+- for complex security, offline, sync, authorization, storage, or data-governance features, define what `done` means across all prompt-promised dimensions rather than accepting a partial foundation or hook layer
+- define infrastructure requirements early when they are material to correctness, such as rate limiting, encryption boundaries, production-equivalent test infrastructure, and browser-storage rules for sensitive data
+- define frontend validation and accessibility expectations when the product surface materially depends on them
+- if the prompt names literal storage, indexing, partitioning, retention, or performance dimensions, represent them literally in the planning artifacts rather than abstracting them away
+
+## Acceptance checklist
+
+- scope is still prompt-faithful
+- the plan has explicitly addressed prompt-fit risks and requirement drift
+- major user-facing flows are mapped to backend support and verification targets
+- security-critical areas are planned early enough that they will not be left to accidental late cleanup
+- test sufficiency has been considered at the level of core happy path, major failure paths, security-critical paths, and obvious high-risk boundaries
+- major engineering quality has been addressed through maintainable boundaries, clear decomposition, and shared contracts
+- frontend route, page, component, and state boundaries are planned when the UI is material
+- configurable behaviors are concretely planned where the prompt requires configurability
+- lifecycle and state models are aligned across design and API/spec artifacts
+- prompt-critical operational obligations and operator visibility paths are concretely planned
+- prompt-literal storage, partitioning, indexing, retention, or performance requirements are explicitly represented
+- relevant cross-cutting system contracts are explicitly defined rather than left to per-module invention
+- each major module has a clear integration contract with existing modules and shared patterns
+- verification plans include cross-module seam checks, not just isolated feature tests
+- visible mismatches are corrected or explicitly dispositioned
+- planning comments and artifacts reflect current policy truth
+
+## Exit conditions
+
+- the first real technical plan is accepted against this gate
+- planning artifacts are internally consistent enough to guide implementation
+- deep execution sub-items can be created from the accepted plan without guesswork

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

@@ -0,0 +1,100 @@
+---
+name: planning-guidance-v2
+description: Developer-facing planning guidance for slopmachine-v2.
+---
+
+# Planning Guidance v2
+
+Use this skill during `P2 Planning` to compose the developer-facing planning prompt.
+
+## Planning audit priorities
+
+Planning should explicitly shape the project against these later audit buckets before implementation begins:
+
+1. prompt-fit
+2. security-critical flaws
+3. test sufficiency
+4. major engineering quality
+
+The goal is to reduce late audit failures by designing for these concerns up front instead of discovering them only in hardening or evaluation.
+
+## Usage rules
+
+- use this skill for planning guidance only
+- keep the developer message natural and focused; do not dump the whole skill verbatim
+- combine this guidance with the approved clarification and current policy truth
+
+## Cross-cutting documentation discipline
+
+- the owner maintains external docs under parent-root `../docs/`
+- the developer should keep `README.md` and any codebase-local docs accurate for repo-local use
+- planning guidance should stay explicit enough that owner-maintained external docs can later be updated accurately
+- `README.md` must stay codebase-specific and must not become an index or explanation of the external docs set
+
+## Cross-cutting env-file discipline
+
+- never create or keep `.env` files anywhere in the repo tree
+- do not allow committed `.env` files even as placeholders or examples
+- keep real secrets out of the repository and rely on Docker-provided runtime variables for sensitive values
+- if the stack requires env-file format at runtime, generate it ephemerally from Docker-provided runtime variables rather than storing it in the repo or package
+- verify the delivered project can start from scratch without any preexisting `.env` file in the repo or package
+
+## Planning guidance
+
+- require implementation-grade planning, not brainstorming
+- start from the actual project prompt and build the plan from there
+- carry the settled project requirements forward consistently as you plan
+- identify the hard non-negotiable requirements early and do not quietly trade them away for implementation convenience
+- explicitly check that the plan still fits the business goal, main flows, and implicit constraints from the prompt
+- when planning technical items that depend on a library, framework, API, or tool, check Context7 documentation first for authoritative usage details
+- when planning needs targeted outside research beyond direct documentation, use Exa web search next
+- use technical research to strengthen concrete planning decisions, interfaces, constraints, and verification strategy rather than leaving them vague
+- break the problem into explicit requirements, constraints, flows, boundaries, and edge cases
+- map requirements to real modules, surfaces, contracts, and verification targets
+- make the planning explicit enough that the owner can maintain external design notes and API/spec docs accurately when relevant
+- keep the spec focused on required behavior rather than turning it into a progress or completion narrative
+- define major modules as meaningful delivery units, not arbitrary folders
+- make frontend/backend crosswalks explicit when the project is fullstack
+- for fullstack work, map frontend surfaces, routes, components, and state boundaries to the backend modules and contracts that support them
+- for fullstack work, make the frontend-to-backend crosswalk explicit enough that each major route, page, component group, or state boundary has a defined supporting backend module, endpoint, and data shape
+- define cross-cutting contracts early instead of leaving them to per-slice invention
+- plan security-critical areas early instead of treating them as cleanup work, especially authentication, authorization, object ownership, tenant isolation, admin/debug exposure, secret handling, file/path safety, and sensitive-data exposure
+- when the prompt says behavior is configurable, plan the real configuration surface, data model, permissions, and operator flow rather than treating configurability as an implementation detail to invent later
+- when a feature must be admin-manageable or operator-manageable, plan the real usable UI surface for that management flow, not just the backing API or data model
+- define failure paths, permissions, validation, logging, runtime assumptions, and test strategy before coding
+- for complex security, offline, sync, authorization, or data-governance features, define what `done` means across all prompt-promised dimensions rather than stopping at a partial foundation or hook layer
+- define shared lifecycle and state models when the product has meaningful workflow state, and keep those models aligned across design notes and API/spec notes
+- require cross-document consistency so design, API/spec, and test-planning artifacts do not drift on lifecycle/state models, flow coverage, permissions, or operational behavior
+- define logging and observability expectations for both frontend and backend
+- define operator visibility and operator workflow expectations when the prompt implies admin, operational, audit, backup, or support responsibilities
+- when the system has meaningful cross-cutting behavior, define shared implementation contracts early rather than leaving each module to invent its own pattern
+- define error-handling contracts when relevant, including normalization patterns for user-visible errors and backend error-shape expectations
+- define audit contracts when relevant, including centralized helper or service expectations and redaction rules
+- define permission contracts when relevant so navigation visibility, route guards, and API enforcement stay aligned
+- define state-lifecycle contracts when relevant, including context-switch or tenant-switch cleanup expectations
+- define auth edge-case expectations when relevant, such as token refresh, session expiry, or clock-skew tolerance
+- call out operational obligations early when they are prompt-critical, such as scheduling, retention, backups, workers, auditability, or offline behavior
+- define infrastructure requirements early when they are material to correctness, such as rate limiting, encryption boundaries, production-equivalent test infrastructure, and browser-storage rules for sensitive data
+- define frontend validation and accessibility expectations when the product surface materially depends on them, including keyboard, focus, feedback, and other user-interaction quality requirements where relevant
+- if backup or recovery behavior is prompt-critical, plan the designated media, operator drill flow, visibility, and verification expectations explicitly
+- if the prompt names literal storage, indexing, partitioning, retention, or performance dimensions, represent them literally in the planning artifacts rather than abstracting them away
+- for frontend work, unless the prompt, existing repository, or established stack clearly dictates otherwise, default to Tailwind CSS for styling and `shadcn/ui` for component primitives
+- if the existing project already uses a different UI system, preserve and extend that system instead of forcing Tailwind CSS or `shadcn/ui` into it
+- define end-to-end coverage for major user flows before coding
+- define enough test coverage up front to catch major issues later, especially core happy path, important failure paths, security-critical paths, and obvious high-risk boundaries
+- for fullstack work, explicitly plan Playwright coverage for the synchronized frontend/backend flows when end-to-end testing is applicable
+- when UI-bearing flows are material, explicitly plan screenshot review as part of Playwright verification so UI correctness is checked, not just browser success
+- aim for at least 90 percent meaningful coverage of the relevant behavior surface
+- define verification strategy, Docker expectations, and documentation implications before coding
+- make major engineering quality a planning concern by defining maintainable boundaries, separation of concerns, shared patterns, extension points, and anti-chaos constraints before coding begins
+- for each major module, define how it integrates with existing modules and which shared contracts it must follow consistently
+- define verification plans that include cross-module scenarios and seam checks, not just isolated feature checks
+- surface real unresolved risks honestly
+- keep the plan aligned with current policy: owner-managed external docs, no `.env` files, junior-friendly repo-local README, and the v2 verification cadence
+
+## Exit target
+
+- make the plan detailed enough to guide real implementation and later verification
+- review the module map and make sure it is stable before deeper implementation begins
+- do not move into deeper implementation with vague architecture or unstable module boundaries
+- make sure the plan has explicitly considered prompt-fit, security-critical flaws, test sufficiency, and major engineering quality before implementation starts

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

@@ -0,0 +1,31 @@
+---
+name: remediation-guidance-v2
+description: Focused remediation rules for slopmachine-v2.
+---
+
+# Remediation Guidance v2
+
+Use this skill only during `P9 Remediation`.
+
+## Remediation model
+
+- fix only accepted evaluation findings and the directly related proof gaps
+- keep the work bounded and concrete
+- require owner-reproducible proof before phase closure
+
+## Remediation guidance
+
+- focus only on accepted defects and the work needed to fix them cleanly
+- fix the issue completely instead of layering hacks on top
+- trace the fix back to the original requirement so the remediation restores fidelity instead of only hiding the symptom
+- rerun the relevant verification after each fix
+- if the issue exposed drift, docs overclaim, or missing acceptance coverage, repair that too before closing the issue
+- update docs if behavior or instructions changed
+- report exactly what was fixed, what was rerun, and what still looks risky if anything remains
+
+## Rules
+
+- do not reopen broad feature development inside remediation
+- do not patch over symptoms with hacks
+- if the fix changes behavior or instructions, update repo-local docs too
+- keep remediation proof strong on the first pass whenever possible

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

@@ -0,0 +1,15 @@
+---
+name: report-output-discipline-v2
+description: File-backed reporting discipline for slopmachine-v2.
+---
+
+# Report Output Discipline v2
+
+Use this skill whenever an owner-side review or evaluation task would otherwise dump a large report into chat.
+
+## Rules
+
+- write the full report to a file whenever the output would be long or reused later
+- return only a short decision-oriented summary in chat
+- keep chat focused on findings, decisions, and next actions
+- use this for evaluation reports, large audits, artifact inspections, and packaging summaries when appropriate

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

@@ -0,0 +1,57 @@
+---
+name: scaffold-guidance-v2
+description: Developer-facing scaffold guidance for slopmachine-v2.
+---
+
+# Scaffold Guidance v2
+
+Use this skill during `P3 Scaffold` before prompting the developer.
+
+## Scaffold standard
+
+- create real foundations, not decorative boilerplate
+- establish the real runtime contract
+- establish the local verification path and the standardized gate path
+- make prompt-critical baseline behavior real where required
+- keep repo-local `README.md` honest from the start
+
+## Scaffold and foundation guidance
+
+- create the initial project structure intentionally
+- create `run_tests.sh` as the standard broad test entrypoint when the stack needs it
+- create required testing directories and baseline docs structure
+- put baseline config and logging structure in place
+- put migrations, worker/job foundation, and real runtime health surfaces in place when the project needs them
+- treat prompt-critical security controls as real baseline runtime behavior, not placeholder checks or visual wiring
+- if a requirement implies enforcement, persistence, statefulness, or rejection behavior, make that behavior real in the scaffold unless the prompt clearly scopes it down
+- do not accept shape-only security implementations such as header presence checks, passive constants, or partially wired middleware when the requirement implies real protection
+- when applicable at scaffold time, require real security baselines such as nonce reuse rejection rather than nonce-header presence, real lockout behavior rather than config-only lockout values, CSRF rejection on protected mutations, and meaningful server-side state when the protection model depends on it
+- 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
+- keep Docker runtime isolation clean in shared environments: use self-contained Compose namespacing, avoid fragile generic project names, and prefer Compose-managed service naming over unnecessary hardcoded `container_name` values
+- require reproducible build and tooling foundations: prefer lockfile-driven installs where the stack supports them, keep source and build outputs clearly separated, and do not allow generated runtime artifacts to drift back into source directories
+- for typed build pipelines, keep source-of-truth boundaries clean so compiled output does not create TS/JS or similar dual-source drift in the working tree
+- establish README structure early instead of leaving it until the end
+- prove the scaffold in a clean state before deeper feature work
+- verify clean startup and teardown behavior under the chosen project namespace when Dockerized execution is in scope
+- when the architecture materially depends on infrastructure capabilities such as rate limiting, encryption, offline support, or browser-storage policy, put the baseline framework and policy in place during scaffold rather than deferring it to late implementation
+- for backend integration paths, prefer production-equivalent test infrastructure when practical rather than silently substituting a weaker database or runtime model that can hide real defects
+- do not treat scaffold as placeholder boilerplate or rely on hidden setup
+
+## Current policy
+
+- no `.env` files or env-file variants in the repo
+- do not edit `AGENTS.md` or other workflow/rulebook files unless explicitly asked
+- keep generated artifacts out of source-of-truth paths
+- keep real secrets out of the repository and rely on Docker-provided runtime variables for sensitive values
+- if the stack requires env-file format at runtime, generate it ephemerally from Docker-provided runtime variables rather than storing it in the repo or package
+
+## Acceptance target
+
+Scaffold should make later slices easier, not force them to retrofit missing fundamentals.
+
+## Verification cadence
+
+- use local and narrow checks while correcting scaffold work
+- reserve one broad owner-run scaffold gate for actual scaffold acceptance
+- do not spend extra broad reruns once the acceptance question is already answered

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

@@ -0,0 +1,41 @@
+---
+name: session-rollover-v2
+description: Planned developer-session handoff and rollover rules for bounded slopmachine-v2 developer sessions.
+---
+
+# Session Rollover v2
+
+Use this skill only when intentionally moving from one planned developer session slot to the next.
+
+## Typical uses
+
+- build session -> stabilization session
+- stabilization session -> remediation session
+
+## Rules
+
+- rollover is planned, not a recovery event
+- do not open the next developer session until the current session has a clear handoff out
+- record the new session id and status immediately after the new session is created
+
+## Required handoff contents
+
+- current phase and why rollover is happening
+- what is complete
+- what is still active or risky
+- what verification status currently exists
+- what the next session should focus on first
+
+## Metadata updates
+
+When rollover succeeds, update metadata so it is obvious:
+
+- which prior session is now completed or inactive
+- which new session is active
+- where the handoff artifact lives
+- which phase group the new session now owns
+
+## Avoid
+
+- carrying old session context longer than needed once the work mode changed materially
+- reopening a new developer session without a handoff artifact