62 lines
2.9 KiB
Markdown
62 lines
2.9 KiB
Markdown
# 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.
|