# Sprint: example project — full lifecycle demo

## Vision issues
- #697 — vision: example project demonstrating the full disinto lifecycle

## What this enables

After this sprint, a new user can see disinto working end-to-end on a real project:
`disinto init` → seed issues appear → dev-agent picks one up → PR opens → CI runs →
review-agent approves → merge → repeat. The example repo serves as both proof-of-concept
and onboarding reference.

This unblocks:
- **Adoption — Example project demonstrating full lifecycle** (directly)
- **Adoption — Landing page** (indirectly — the example is the showcase artifact)
- **Contributors** (lower barrier — people can see how disinto works before trying it)

## What exists today

- `disinto init <url>` fully bootstraps a project: creates repos, ops repo, branch protection,
  issue templates, VISION.md template, docker-compose stack, cron scheduling
- Dev-agent pipeline is proven: issue → branch → implement → PR → CI → review → merge
- Review-agent, gardener, supervisor all operational
- Project TOML templates exist (`projects/*.toml.example`)
- Issue template for bug reports exists; `disinto init` copies it to target repos

What's missing: an actual example project repo with seed content and seed issues that
demonstrate the loop.

## Complexity

Files touched: 3-5 in the disinto repo (documentation, possibly `disinto init` tweaks)
New artifacts: 1 example project repo with seed files, 3-5 seed issues
Subsystems: bootstrap, dev-agent, CI, review
Sub-issues: 3-4
Gluecode ratio: ~70% content/documentation, ~30% scripting

## Risks

- **Maintenance burden**: The example project must stay working as disinto evolves.
  If `disinto init` changes, the example may break. Mitigation: keep the example
  minimal so there's less surface to break.
- **CI environment**: The example needs a working Woodpecker pipeline. If the
  example uses a language that needs a specific Docker image in CI, that's a dependency.
  Mitigation: choose a language/stack with zero build dependencies.
- **Seed issue quality**: If seed issues are too vague, the dev-agent will refuse them
  (`underspecified`). If too trivial, the demo doesn't impress. Need a sweet spot.
- **Scope creep**: "Full lifecycle" could mean bootstrap-to-deploy. For this sprint,
  scope to bootstrap-to-merge. Deploy profiles are a separate milestone.

## Cost — new infra to maintain

- One example project repo (hosted on Forgejo, mirrored to Codeberg/GitHub)
- Seed issues re-created on each fresh `disinto init` run (or documented as manual step)
- No new services, agents, or cron jobs

## Recommendation

Worth it. This is the single most impactful adoption artifact. A working example
answers "does this actually work?" in a way that documentation cannot. The example
should be dead simple — a static site or a shell-only project — so it works on any
machine without language-specific dependencies.