disinto-ops/sprints/example-project-lifecycle.md

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 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.