2.9 KiB
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 initcopies 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 initchanges, 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 initrun (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.