# Loop Gallery

The gallery is for real-world or realistic loop examples contributed by the community.

Use it to show how a loop works in practice, not just what resources describe it. A good gallery entry should be concrete enough that another builder can adapt the pattern without guessing the trigger, state, verification, or escalation rules.

## Contribution Format

Create one file per loop:

```text
gallery/<short-loop-name>.md
```

Use [`gallery/template.md`](template.md) as the starting point.

## Reference Entries

These entries are reference examples, not claimed production deployments. They show the level of specificity expected from future real or anonymized gallery contributions.

- [PR babysitter reference loop](pr-babysitter-reference.md)
- [CI repair reference loop](ci-repair-reference.md)
- [Docs drift reference loop](docs-drift-reference.md)

## Quality Bar

Gallery entries should include:

- the runtime or tool used;
- trigger or cadence;
- work intake source;
- agent roles or delegation pattern;
- workspace and permissions;
- verification gates;
- durable state artifact;
- retry budget and stop condition;
- escalation path;
- screenshots, PR links, issue links, trace IDs, or anonymized receipts when available;
- lessons learned.

Do not include secrets, private customer data, proprietary code, or internal links that readers cannot inspect. If a real example cannot be public, write an anonymized version and say which details were generalized.

## Minimum Useful Case Study

An entry is worth publishing once it answers all of these. If you cannot fill one in, say so explicitly rather than inventing it.

- [ ] **Objective**: the single outcome the loop optimizes for.
- [ ] **Trigger**: schedule, event, or manual bootstrap.
- [ ] **Intake**: where the loop finds work each run.
- [ ] **Runtime / tool**: which runtime and agent system ran it.
- [ ] **Agent roles**: who explores, acts, checks, and decides.
- [ ] **Verification**: the deterministic gate that decided done.
- [ ] **State**: what survived between runs, and where.
- [ ] **Budget**: the retry or runtime cap.
- [ ] **Escalation**: when and how a human took over.
- [ ] **Receipts**: public or anonymized evidence (PR, issue, trace, dashboard, commands).
- [ ] **Lesson learned**: what changed after the loop met reality.

## Safe Anonymization Checklist

Run this before publishing a real-world entry:

- [ ] Remove secrets, tokens, keys, and credentials.
- [ ] Remove private customer data and any PII.
- [ ] Remove internal URLs, hostnames, and dashboards readers cannot reach.
- [ ] Replace personal names with roles (for example "the on-call engineer", "the reviewer").
- [ ] Include only public or anonymized receipts; redact anything in a screenshot you would not paste in plain text.
- [ ] State which details were generalized so readers know what was changed.

## Suggested First Gallery Entries

- PR babysitter loop for a small open-source repository.
- CI repair loop that turns failed checks into small verified patches.
- Docs drift loop that compares CLI output with README examples.
- Deploy verifier loop that watches dashboards and escalates on threshold breaches.
- Feedback clusterer loop that groups issues or support tickets into themes.