johba/disinto
1
0
Fork 0
Code Issues 4 Pull requests Projects Releases Packages Wiki Activity Actions

chore: gardener housekeeping 2026-03-23

Browse source
This commit is contained in:
openhands 2026-03-23 12:47:32 +00:00
parent eb7e24cb1d
commit 0775514bf8
11 changed files with 24 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

6
gardener/pending-actions.json
View file

@ -1,12 +1,12 @@
[
{
"action": "edit_body",
"issue": 598,
"body": "## Problem\n\nThe gardener promotes tech-debt issues to backlog by swapping labels, but does not enrich the issue body. The quality gate (#483) then strips the backlog label because required sections are missing. Circular loop — issue bounces between tech-debt and backlog.\n\nExample: #435 — \"monitor_phase_loop docstring lists 'break' as possible value but never set.\" Body is a bare review finding with no `## Acceptance criteria` or `## Affected files`. The gardener promotes it, quality gate strips it, repeat.\n\n## Fix\n\nWhen the gardener promotes an issue to backlog (from tech-debt or any other label), it must also enrich the issue body to meet the quality gate requirements.\n\nDuring the grooming step, for each issue being promoted:\n\n1. **Infer affected files** from the issue body. The information is usually there — #435 mentions `lib/agent-session.sh:266` explicitly. Use AGENTS.md knowledge to fill gaps.\n\n2. **Write acceptance criteria** based on the problem description.\n\n3. Append both sections to the issue body via the `edit_body` manifest action before adding the backlog label.\n\n## Affected files\n\n- `formulas/run-gardener.toml` — grooming step: add body enrichment logic before writing add_label backlog to manifest\n\n## Acceptance criteria\n\n- [ ] Gardener enriches issue body (appends `## Affected files` + `## Acceptance criteria`) when promoting to backlog\n- [ ] Promoted issues pass the quality gate on the same gardener run (backlog label not stripped)\n- [ ] Affected files are inferred from existing issue body text when possible"
"issue": 466,
"body": "## Problem\n\nVISION.md Adoption milestone calls for an \"Example project that demonstrates the full lifecycle\" but no such project exists. New developers evaluating disinto have no reference for what the end-to-end flow looks like — from `disinto init` through issue creation, dev-agent implementation, CI, review, merge, and deployment.\n\n## Why it matters\n\nDocumentation (#394) and the landing page need a concrete example to reference. Abstract descriptions of the agent loop are less convincing than a working repo where people can see real PRs, real CI runs, and real reviews. This is the \"show, don't tell\" for adoption.\n\n## Approach\n\n1. Create a minimal example repo (e.g., `johba/disinto-example` or a directory within this repo) with:\n - A simple web app (e.g., Express/Flask hello world)\n - A `projects/*.toml` config pointing at the example repo\n - A VISION.md with 3-4 simple goals\n - CI pipeline (.woodpecker.yml)\n2. Run the factory against it: let the planner create issues, dev-agent implement them, review-agent review.\n3. Document the results: link to merged PRs, show the issue lifecycle, capture agent conversations.\n4. Reference from the docs site (#394) and landing page.\n\n## Dependencies\n\n- #393 (disinto init would make bootstrapping the example trivial)\n\n## Affected files\n\n- `projects/disinto-example.toml.example` — new example project config template\n- `README.md` or `docs/` — documentation referencing the example project\n\n## Acceptance criteria\n\n- [ ] A working example repo exists with at least 3 merged PRs from the factory\n- [ ] The docs site references the example with links to real PRs and issues\n- [ ] A new developer can follow the example to understand the full lifecycle"
},
{
"action": "add_label",
"issue": 598,
"issue": 466,
"label": "backlog"
}
]