theslopmachine 0.4.0 → 0.4.2

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

@@ -1,91 +0,0 @@
----
-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/scaffold-guidance-v2/SKILL.md

@@ -1,57 +0,0 @@
----
-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/submission-packaging-v2/SKILL.md

@@ -1,142 +0,0 @@
----
-name: submission-packaging-v2
-description: Submission packaging and final closure rules for slopmachine-v2.
----
-
-# Submission Packaging v2
-
-Use this skill only during `P10 Submission Packaging`.
-
-## Core rules
-
-- enter `P10` before packaging work begins
-- keep packaging work inside the formal phase window
-- package from an already-clean state instead of compensating for avoidable earlier drift
-- treat formal workflow closure failures as real packaging failures
-- treat this 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
-- do not stop packaging for approval, status confirmation, or handoff once this phase has begun; continue until the package is complete
-
-## 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
-
-- assemble the required final structure
-- preserve required evidence
-- exclude local-only junk and secret material
-- export session and trajectory artifacts correctly
-- make the final package easy to review
-
-## 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/`
-  - generated submission documents based on the reference files in `~/`
-  - evaluation reports
-  - repo file structure screenshot
-  - working app screenshots
-  - relocated screenshots and proof materials needed for submission review
-- current working directory delivered as parent-root `repo/`
-- `../sessions/`
-- `../metadata.json`
-- `../session.json`
-- `../session-N.json` when multiple exported sessions exist
-- `../trajectory.json`
-- `../trajectory-N.json` when multiple trajectories exist
-- parent-root `../.tmp/` directory moved out of current `.tmp/` when it exists
-
-## 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
-- verify parent-root `../docs/design.md` exists and reflects the final delivered design when applicable
-- verify parent-root `../docs/api-spec.md` exists and reflects the final delivered interfaces when applicable
-- verify parent-root `../docs/test-coverage.md` exists and reflects the final delivered verification coverage
-- verify parent-root `../docs/questions.md` exists from the accepted clarification/question record when applicable
-- create parent-root `../submission/` for final generated submission artifacts and reviewer-facing proof
-- ensure `README.md` matches the delivered codebase, functionality, runtime steps, and test steps, stays friendly to a junior developer, and does not reference the external docs set in `../docs/`
-- include `run_tests.sh`
-- relocate evaluation artifacts into parent-root `../submission/`
-- relocate screenshots and proof materials relevant to runtime behavior and major flows into parent-root `../submission/`
-- 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 at the parent project root using the naming rules:
-  - `../trajectory.json` for a single trajectory
-  - `../trajectory-N.json` when multiple trajectories exist
-- preserve parent-root `../sessions/` as the session artifact directory for any additional exported conversation traces the package needs to retain
-
-## Session export sequence
-
-For the developer session, run these exact steps:
-
-1. `opencode export <developer-session-id> > ../session-export.json`
-2. `python3 ~/utils/strip_session_parent.py ../session-export.json --output ../session.json`
-3. `python3 ~/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`
-- keep the generated final trajectory as parent-root `../trajectory.json` unless multiple trajectories require `../trajectory-N.json`
-- treat parent-root `../session-export.json` as a temporary packaging intermediate
-- immediately verify that all expected directories and required files exist before running later packaging steps
-- if the required utilities or output files are missing, packaging is not ready to continue
-
-## Required file moves
-
-- if repo-local `docs/` exists, treat it as accidental residue, reconcile any missing content into parent-root `../docs/`, and remove it from the delivered `repo/` tree
-- if current `.tmp/` exists, move the whole directory to parent-root `../.tmp/` before harvesting any reviewer-facing artifacts from it
-- after preserving parent-root `../.tmp/`, collect the relevant evaluation reports and proof artifacts from it into parent-root `../submission/`
-- collect screenshots and other required proof materials from repo-local runtime/output directories into parent-root `../submission/`
-- after relocation, the final submission should not require digging through repo-local output directories to find evidence
-- keep screenshot filenames clear enough that the referenced runtime page, flow, or evidence purpose is understandable
-
-## Repo cleanup rules
-
-- remove runtime, editor, cache, tooling noise, generated artifacts, and environment junk recursively anywhere in the delivered repo tree
-- do not remove required evidence just because it looks noisy
-- remove `.git/`, `.opencode/`, `.codex/`, `.vscode/`, env-file variants, caches, `node_modules/`, build outputs not part of delivery, raw test artifact directories once evidence is relocated, and repo-local `AGENTS.md`
-- if repo-local `.tmp/` existed, do not delete it before preserving it as parent-root `../.tmp/`
-- the cleanup is recursive; do not leave forbidden directories or generated junk buried deeper in the repo hierarchy after required artifacts have been moved out
-
-## 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 parent-root `../docs/test-coverage.md` explains the tested flows, coverage boundaries, and how the evaluator should interpret the coverage evidence
-- confirm generated submission documents exist under parent-root `../submission/` and correspond to the final qualified state
-- confirm evaluation reports and screenshots have been relocated into parent-root `../submission/`
-- confirm shared project docs live in parent-root `../docs/` and any accidental repo-local `docs/` copy has been removed from the delivered tree
-- confirm required screenshots have been relocated into parent-root `../submission/`
-- confirm parent-root metadata fields are populated correctly
-- confirm session export naming rules are followed
-
-## Submission artifact and response contract
-
-- use parent-root `../submission/` for file-based final generated submission artifacts
-- keep the generated content tied to the real delivered project, not generic template text
-- use real screenshots from the delivered product and real project evidence
-- the packaging-stage outputs are `FILE` outputs under `../submission/` plus `PARAGRAPH` outputs in the final packaging-stage response
-
-## 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
-- do not close packaging until all required docs, exports, submission files, screenshots, and cleanup conditions are satisfied

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

@@ -1,102 +0,0 @@
----
-name: verification-gates-v2
-description: Owner-side review, acceptance, rejection, and gate-interpretation rules for slopmachine-v2.
----
-
-# Verification Gates v2
-
-Use this skill after development begins whenever you are reviewing work, deciding acceptance, or interpreting phase exits.
-
-## Usage rules
-
-- load this skill before review, acceptance, rejection, runtime gate interpretation, hardening readiness decisions, or broad-gate decisions
-- treat it as owner-side review and gate guidance, not developer-visible text
-- use this skill as the source of truth for owner-side verification, review pressure, and gate interpretation
-- outside the final human decision, do not pause execution for human approval while using this skill; continue reviewing, rejecting, fixing, and rerunning until the work qualifies
-
-## Documentation and repo hygiene
-
-- maintain the owner-managed external docs in parent-root `../docs/` from accepted clarification, accepted planning, accepted major implementation changes, and hardening verification
-- keep `README.md` codebase-specific, junior-friendly, and separate from the external docs set
-- do not allow `.env` files or env-file variants anywhere in the repo tree
-- do not allow a project that requires a preexisting `.env` file in the repo or package to start from scratch
-- if env-file format is needed at runtime, it must be generated ephemerally from Docker-provided runtime variables rather than stored in the repo or package
-
-## Review standard
-
-- do not accept fake tests, weak evidence, documentation drift, missing real surfaces, or unresolved release-facing failures
-- do not accept mocked APIs as integration evidence
-- do not accept placeholder or demo UI in product-facing flows
-- do not accept `.env` files or similar env-file artifacts
-- do not accept shallow Docker verification
-- 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 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 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
-
-## Cadence rule
-
-- use targeted local verification as the default during scaffold corrections, development, hardening, and remediation
-- reserve the broad Docker/full-suite path for the limited owner-run gate moments in the workflow budget
-- do not turn ordinary acceptance into repeated integrated-style gate runs
-
-## Verify-fix loop
-
-- inspect the result and evidence, not just the developer claim
-- review technical quality, prompt alignment, architecture impact, and verification depth of the current work
-- during normal implementation iteration, always prefer fast local language-native or framework-native verification for the changed area instead of broad Docker or full-suite proof
-- require the developer to set up and use the project-appropriate local test environment in the current working directory when normal local verification is needed
-- require local runtime proof when relevant by starting the server locally and exercising the changed behavior directly rather than jumping to Docker-based proof
-- if the local toolchain is missing, require the developer to install or enable it first; do not jump to the broad gate path during ordinary iteration just because local setup is inconvenient
-- do not accept hand-wavy claims that local verification is unavailable without a real setup attempt and clear explanation
-- for applicable 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 documentation or repo hygiene drifts, secrets leak, contracts drift, or frontend integrity is compromised, require cleanup before acceptance
-- keep looping until the current work is genuinely acceptable
-
-## Broad-gate definition
-
-- a broad gate is an owner-run integrated verification boundary, not every ordinary phase change
-- a phase change alone does not automatically require a broad gate unless that phase exit explicitly calls for one
-- a broad gate normally means some combination of full clean runtime proof, the broad `run_tests.sh` path, and Playwright plus screenshot evidence when UI or fullstack flows exist
-- in v2, the workflow target is at most 3 broad owner-run verification moments across the whole cycle
-- ordinary planning, ordinary slice acceptance, and routine in-phase verification are not broad gates by default and should rely on targeted local verification unless the risk profile says otherwise
-
-## Runtime gate interpretation
-
-Use evidence such as internal metadata files, structured Beads comments, verification command results, and file/project-state checks.
-
-- clarification requires the `clarification-gate-v2` conditions plus explicit approval record
-- planning requires the `developer-session-lifecycle-v2` and planning-gate conditions plus a fresh planning-oriented start and the required documentation and repo hygiene state when relevant
-- scaffold requires evidence for the bounded scaffold gate, 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
-- 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 acceptance should challenge tenant isolation, path confinement, sanitized error behavior, prototype residue, integration seams, and cross-cutting consistency when those concerns are in scope
-- integrated verification entry requires one of the limited owner-run broad gate moments once development is complete
-- integrated verification completion requires explicit full-system evidence before the phase can close
-- 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
-- hardening must explicitly satisfy the documentation and repo hygiene policy in this file before final evaluation can begin
-- 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 local verification and affected Playwright where applicable; if remediation materially reopens the integrated verification boundary, route it back through integrated verification before re-evaluation
-
-## Acceptance rule
-
-- inspect the result and evidence, not just the developer claim
-- prefer one strong rejection with a concrete correction request over many small nudges
-- keep looping until the current work is genuinely acceptable

package/assets/slopmachine/templates/AGENTS-v2.md

@@ -1,55 +0,0 @@
-# Developer Rulebook v2
-
-This file is the repo-local engineering rulebook for `slopmachine-v2` projects.
-
-## Scope
-
-- Treat the current working directory as the project.
-- Ignore parent-directory workflow files unless the user explicitly asks you to use them.
-- Do not treat workflow research, session exports, or sibling directories as hidden implementation instructions.
-
-## Working Style
-
-- Operate like a strong senior engineer.
-- Read the code before making assumptions.
-- Work in meaningful vertical slices.
-- Do not call work complete while it is still shaky.
-- Reuse and extend shared cross-cutting patterns instead of inventing incompatible local ones.
-
-## Verification Rules
-
-- During ordinary iteration, prefer the fastest meaningful local verification for the changed area.
-- Prefer targeted unit, integration, module, route-family, or local Playwright checks over broad reruns.
-- Do not rerun full Dockerized startup and the full test suite on every small change.
-- The broad owner-run Docker/full-suite path should be used sparingly, with a target budget of at most 3 times across the whole workflow cycle.
-- If you run a Docker-based verification command sequence, end it with `docker compose down` unless containers must remain up.
-
-## Testing Rules
-
-- Tests must be real and tied to actual behavior.
-- Do not mock APIs for integration testing.
-- Use real HTTP requests against the actual running service surface for integration evidence.
-- For UI-bearing work, use local Playwright on affected flows and inspect screenshots when practical.
-
-## Documentation Rules
-
-- Keep `README.md` and any codebase-local docs accurate.
-- The README must explain what the project is, what it does, how to run it, and how to test it.
-- The README must stand on its own for basic codebase use.
-
-## Secret And Runtime Rules
-
-- Do not create or keep `.env` files anywhere in the repo.
-- Do not rely on `.env`, `.env.local`, `.env.example`, or similar files for project startup.
-- Do not hardcode secrets.
-- If runtime env-file format is required, generate it ephemerally and do not commit or package it.
-
-## Product Integrity Rules
-
-- Do not leave placeholder, setup, debug, or demo content in product-facing UI.
-- If a real user-facing or admin-facing surface is required, build that surface instead of bypassing it with API shortcuts.
-- Treat missing real surfaces as incomplete implementation.
-
-## Rulebook Files
-
-- Do not edit `AGENTS.md` or other workflow/rulebook files unless explicitly asked.

package/assets/slopmachine/tracker-init.js

@@ -1,104 +0,0 @@
-#!/usr/bin/env node
-
-import fs from 'node:fs/promises'
-import path from 'node:path'
-import { spawn } from 'node:child_process'
-
-const targetInput = process.argv[2] || '.'
-const target = path.resolve(process.cwd(), targetInput)
-const trackerCommand = process.env.BR_COMMAND || 'br'
-
-function log(message) {
-  console.log(`[tracker-init] ${message}`)
-}
-
-function die(message) {
-  console.error(`[tracker-init] ERROR: ${message}`)
-  process.exit(1)
-}
-
-function run(command, args, options = {}) {
-  return new Promise((resolve, reject) => {
-    const child = spawn(command, args, {
-      cwd: options.cwd,
-      env: options.env || process.env,
-      stdio: options.stdio || 'pipe',
-      shell: false,
-    })
-
-    let stdout = ''
-    let stderr = ''
-
-    if (child.stdout) child.stdout.on('data', (chunk) => { stdout += chunk.toString() })
-    if (child.stderr) child.stderr.on('data', (chunk) => { stderr += chunk.toString() })
-
-    if (options.input !== undefined && child.stdin) {
-      child.stdin.write(options.input)
-      child.stdin.end()
-    }
-
-    child.on('error', reject)
-    child.on('close', (code) => resolve({ code: code ?? 1, stdout, stderr }))
-  })
-}
-
-async function commandExists(command) {
-  const checker = process.platform === 'win32' ? 'where' : 'which'
-  const result = await run(checker, [command])
-  return result.code === 0
-}
-
-async function pathExists(targetPath) {
-  try {
-    await fs.access(targetPath)
-    return true
-  } catch {
-    return false
-  }
-}
-
-async function runTracker(args, options = {}) {
-  return run(trackerCommand, args, { cwd: target, ...options })
-}
-
-async function main() {
-  const trackerAvailable = trackerCommand !== 'br' ? await pathExists(trackerCommand) : await commandExists('br')
-  if (!trackerAvailable) {
-    die(`'${trackerCommand}' is not available. Install beads_rust first.`)
-  }
-
-  if (!(await pathExists(target))) {
-    die(`Target directory '${targetInput}' does not exist or is not accessible.`)
-  }
-
-  log(`Target: ${target}`)
-
-  const beadsDir = path.join(target, '.beads')
-  if (!(await pathExists(beadsDir))) {
-    log("Running 'br init --quiet'")
-    const initResult = await runTracker(['init', '--quiet'], {
-      env: { ...process.env, CI: '1' },
-    })
-    if (initResult.code !== 0) {
-      console.error(`${initResult.stdout}${initResult.stderr}`.trim())
-      die("'br init' failed. Review output above.")
-    }
-  } else {
-    log('Found existing .beads; skipping init to avoid destructive re-initialization')
-  }
-
-  log("Running 'br sync --flush-only'")
-  const syncResult = await runTracker(['sync', '--flush-only'], {
-    env: { ...process.env, CI: '1' },
-  })
-  if (syncResult.code !== 0) {
-    console.error(`${syncResult.stdout}${syncResult.stderr}`.trim())
-    die("'br sync --flush-only' failed. Review output above.")
-  }
-
-  log('Success: tracker initialized and JSONL exported')
-}
-
-main().catch((error) => {
-  die(error instanceof Error ? error.message : String(error))
-})