slop-refinery-pipeline

name	slop-refinery-pipeline
description	Implement a feature through a concise autonomous pipeline with human gates for planning, consequential findings, and merge authorization. Use when a feature needs issue and PR setup, implementation, testing, review, final checks, and publication.
license	MIT

Execute this pipeline for the supplied feature:

1. Prepare the issue and PR:
   1. Create an appropriately named feature branch.
   2. Create and push an empty commit with the exact message Initial empty commit to open PR.
   3. Open a draft PR using the unchanged PR template as the verbatim starting text of its first comment.
   4. Use the supplied GitHub issue, reuse an existing matching issue, or create one from the feature description.
   5. Link the issue in the PR's Development section so merging closes it.
2. Execute the pipeline sequentially. Allow human interaction only for initial deliberation, implementation permission, findings deliberation, and final readiness permission. After implementation is authorized, work autonomously through step 2.3, pause for step 2.4, then complete step 2.5 autonomously before requesting final readiness permission; use best judgment, complete all unblocked work, check each completed PR checkbox, and use those checkboxes to recover progress.

   1. Deliberate with the human until the problem and an irreducibly simple implementation plan are sufficiently defined. Explicitly agree on every changed or introduced seam, interface, and API, especially exposed HTTP endpoints and database tables.

   2. With explicit human permission, implement the feature completely, then commit and push all changes.

   3. Run the following thirteen analyses in parallel, each in a fresh, context-independent subagent over the entire current branch change set, including uncommitted changes. Give each subagent the feature intent, change scope, repository instructions, and only its assigned analysis; it must not edit files, change Git or PR state, or see another subagent's work, and must report evidence, findings, recommendations, test results, and blockers to the main orchestrator. Use isolated transient test state where concurrent testing could interfere.

      1. Backward compatibility: Report every definite or possible mechanism preserving an old interface, behavior, schema, format, version, or implementation path, with evidence for human review; do not propose or make changes.
      2. Manual testing: Exercise every materially affected workflow through its real interface under realistic success, boundary, invalid-input, failure, permission, persistence, accessibility, viewport, and integration scenarios; assess end-to-end behavioral correctness and report evidence and defects.
      3. Automated testing: Run proportionate tests and identify missing coverage, defaulting recommendations to meaningful property-based or model-based tests with independent properties and supplementing them with examples, integration tests, or end-to-end tests where those provide distinct evidence. Do not run mutation testing or recommend changes to mutation-testing configuration.
      4. System design irreducible simplicity: Identify requirements, behaviors, concepts, workflows, states, data models, seams, interfaces, and dependencies that can be removed or merged while preserving the feature's essential purpose and integrity constraints; assess the system design rather than the code that implements it.
      5. Implementation irreducible simplicity: Given the feature's current system design, identify unnecessary code, state, branches, layers, dependencies, duplication, and indirection that can be removed while preserving every requirement and integrity constraint; assess the implementation rather than redesigning the feature.
      6. Edge cases: Identify all practical edge cases across inputs, state transitions, timing, concurrency, permissions, persistence, failures, retries, integrations, and resource limits, and verify each is handled or mitigated. Report technically possible cases whose mitigation may be impractical or disproportionate with evidence, likelihood, impact, current safeguards, and trade-offs for human deliberation.
      7. Declarativeness: Identify where intended rules, relationships, and outcomes could be expressed more directly through language, framework, schema, or data constructs.
      8. Modularity: Assess module cohesion, public surfaces, dependencies, boundary leaks, cycles, shared state, broad interfaces, and unnecessary coupling.
      9. Immutability: Identify state changes that could be more explicit, local, and predictable through immutable data flow or smaller mutation boundaries.
      10. Abstractness: Identify duplication, leakage, premature generalization, pass-through layers, and indirection that fails to capture a stable concept or hides essential behavior.
      11. Performance: Inspect affected paths under realistic load for practical latency, throughput, memory, I/O, query, rendering, serialization, concurrency, and unbounded-work risks, measuring when magnitude affects the finding.

      After all reports return, the main orchestrator must validate and adjudicate them, implement what it judges best, directly validate its changes, and commit and push. The orchestrator alone determines which findings are consequential subjective matters for step 2.4, but must carry every backward-compatibility finding and every edge-case finding whose mitigation may be impractical or disproportionate into that step without implementing it.

   4. Record and deliberate with the human on every consequential subjective finding, blocker, backward-compatibility finding, and edge-case finding whose mitigation may be impractical or disproportionate:

      1. Create or update one ## Human Review Findings section at the end of the PR description; do not create a repository findings file, and write No findings require human review. when none exist.
      2. Represent each finding as an unchecked - [ ] **<title>** task containing its review area, affected code, evidence, consequence, implemented resolution or blocker, material alternatives and trade-offs, and the decision or confirmation needed.
      3. Never check a finding for the human. On reruns, preserve human checkbox states and notes, add new findings unchecked, and explain rather than delete findings that no longer apply.

   5. Perform final checks: Fetch and integrate fresh origin/main, verify the branch is zero commits behind, and audit the diff, committed paths, and untracked files for unrelated lockfiles, unnecessary Markdown specifications, logs, generated or local artifacts, and sensitive data. Verify new migrations are chronologically after base migrations, replay cleanly, upgrade production-like data safely, avoid unintended destruction, and can perform any intentional destruction under enforced production preconditions; restore any weakening of lint or test enforcement relative to the base, run every required check, refetch the base, restart if it advanced, and commit and push any final fixes.

   6. With explicit human permission, convert the PR from draft to ready and enable auto-merge.