project-loops

Project Loops

Quick Start

1. Identify the current failure mode: demo gap, diffuse product spine, unsupported pitch, release boundary, fresh-machine setup, repo hygiene, scenario quality, benchmark drift, handoff risk, governance objection, runtime uncertainty, or valuable local dirt.
2. If the user asks to generate loops from analysis, especially interflux or flux-review output, read references/synthesis-from-analysis.md.
3. Otherwise read references/loop-catalog.md for the loop definition.
4. If the user names a project family, read references/project-routing.md.
5. Adapt one loop to the current repo with concrete trigger, action, proof, memory, and stop condition.
6. Execute only the user-approved scope. Report evidence, not confidence.

Loop Selection

Default to one loop. Combine loops only when their proof artifacts are different.

Situation	Default loop
Pitch is stronger than the runnable artifact	Demo-Gap Closure
Product feels diffuse	Product Spine
Application or public claim needs support	Evidence Before Pitch
Release is close but publication ownership is unclear	Release Boundary
Installer or onboarding changed	Fresh-Machine Installer
Work may be stranded locally	Canonical-Repo Hygiene
Product quality needs realistic proof	Scenario Streak
Prompt, model, score, or config changed	Benchmark Baseline
Session may lose context	Agent Handoff Integrity
Governance, safety, or legitimacy is claimed	Adversarial Governance
Config exists but may not be live	Runtime Reality
Repo has accumulated unknown state	Valuable Dirt Recovery

Generate Loops From Analysis

Use this path when the input is an interflux review, flux-review summary, multi-agent findings, incident review, failed session transcript, or repeated project failure pattern.

1. Read references/synthesis-from-analysis.md.
2. Cluster analysis into recurring failure patterns.
3. Draft at most three loops using templates/loop-draft.md.
4. Recommend one small pilot and record it with templates/loop-pilot-report.md.
5. Only promote a loop into references/loop-catalog.md after explicit user approval and pilot evidence. Until then, keep it in draft status.

Operating Rules

• State the chosen loop and why it outranks the nearest alternative.
• Define stop conditions before executing long work.
• Prefer project-native trackers, tests, and release commands.
• Never let the loop hide a publication, credential, or ownership decision.
• Do not describe local-only work as complete when push or publication is part of the requested outcome.

References

• references/loop-catalog.md - full loop definitions.
• references/project-routing.md - mapping for active project families.
• references/synthesis-from-analysis.md - generate draft loops from interflux, flux-review, incident, or session analysis.
• templates/loop-draft.md - draft loop output template.
• templates/loop-pilot-report.md - pilot evidence and promotion decision.

Success Criteria

The loop run is successful when the final answer names the selected loop, the evidence produced, remaining accepted risks or blockers, and the next owner or next command if work remains.