disinto-admin/disinto

Fork 0

feat: gardener should enrich bug-report issues with context, reproduction plan, and verification checklist #285

New issue

Closed

opened 2026-04-06 09:24:27 +00:00 by dev-bot · 1 comment

dev-bot commented

2026-04-06 09:24:27 +00:00

Collaborator

Problem

When the gardener labels an issue bug-report, it only applies the label and moves on. The issue body stays as the raw user report — no structure, no context, no actionable next steps. Compare this to backlog promotion, which has a full enrichment protocol (acceptance criteria, affected files).

Bug reports need analogous enrichment so the reproduce-agent (or a human) can act immediately without re-reading the whole codebase.

What the gardener should add

When labeling bug-report, the gardener should append these sections to the issue body (keeping the original report intact):

`## What was reported`

Clean summary of the user claim in one or two sentences.

`## Known context`

What the gardener can infer from the codebase without running anything:

Which contracts/components/files are involved
What the expected behavior should be (from VISION.md, contract docs, code)
Any recent changes to these components (git log --oneline -5 -- <paths>)
Related issues or prior fixes

`## Reproduction plan`

Concrete steps for the reproduce-agent or a human:

Which environment to use (e.g. "use scripts/dev.sh restart --full for fresh stack")
Which transactions to execute (with cast commands or UI navigation steps)
What state to check after each step (contract reads, API queries, UI observations)

`## What needs verification`

Distinguish what we know from what we need to confirm. Checkboxes:

- [ ] Does the reported behavior actually occur? (reproduce)
- [ ] Is component X behaving as expected? (check state)
- [ ] Is the data flow correct from A to B? (trace)

This turns a vague "it does not work" into a structured investigation brief.

Example

User reports: "stakers do not get issuance after big buy and recenter"

Gardener enrichment:

## What was reported
Staking issuance stays zero after a recenter triggered by a large buy. User stakes, another user buys big triggering recenter, first user unstakes and receives no issuance — only pays tax.

## Known context
- Issuance is distributed via TWAB snapshots in `Stake.sol`
- Recenter is triggered by `LiquidityManager.sol` when price moves enough
- Issuance calculation happens in `Stake.getEarnings()` using cumulative TWAB deltas
- Recent fix (#4/PR#7): ponder was missing LM_ADDRESS — recenter events were not being indexed

## Reproduction plan
1. Start fresh stack: `./scripts/dev.sh restart --full`
2. Connect wallet A, buy KRK via /app/cheats or swap UI
3. Stake KRK with wallet A
4. Connect wallet B, buy large amount of KRK (enough to trigger recenter)
5. Check: did recenter happen? (`cast call $LM positions(uint8)(uint128,int24,int24) 1`)
6. With wallet A, check Active Positions — does issuance show > 0?
7. Unstake with wallet A — does received amount include issuance?

## What needs verification
- [ ] Does issuance actually stay zero after recenter? (reproduce in UI)
- [ ] Is TWAB snapshot updated on recenter? (check Stake.sol state)
- [ ] Is getEarnings() returning zero or is the UI not displaying it?
- [ ] Is the ponder indexer reflecting correct issuance data?

Implementation

In formulas/run-gardener.toml, the bug-report detection section (step 7 in grooming). After the add_label action, add an edit_body action that appends the enrichment sections — same pattern used for backlog promotion body enrichment.

Files

formulas/run-gardener.toml — grooming step, bug-report detection section

## Problem When the gardener labels an issue `bug-report`, it only applies the label and moves on. The issue body stays as the raw user report — no structure, no context, no actionable next steps. Compare this to backlog promotion, which has a full enrichment protocol (acceptance criteria, affected files). Bug reports need analogous enrichment so the reproduce-agent (or a human) can act immediately without re-reading the whole codebase. ## What the gardener should add When labeling `bug-report`, the gardener should append these sections to the issue body (keeping the original report intact): ### `## What was reported` Clean summary of the user claim in one or two sentences. ### `## Known context` What the gardener can infer from the codebase without running anything: - Which contracts/components/files are involved - What the expected behavior should be (from VISION.md, contract docs, code) - Any recent changes to these components (`git log --oneline -5 -- <paths>`) - Related issues or prior fixes ### `## Reproduction plan` Concrete steps for the reproduce-agent or a human: - Which environment to use (e.g. "use `scripts/dev.sh restart --full` for fresh stack") - Which transactions to execute (with `cast` commands or UI navigation steps) - What state to check after each step (contract reads, API queries, UI observations) ### `## What needs verification` Distinguish what we know from what we need to confirm. Checkboxes: - `- [ ]` Does the reported behavior actually occur? (reproduce) - `- [ ]` Is component X behaving as expected? (check state) - `- [ ]` Is the data flow correct from A to B? (trace) This turns a vague "it does not work" into a structured investigation brief. ## Example User reports: "stakers do not get issuance after big buy and recenter" Gardener enrichment: ```markdown ## What was reported Staking issuance stays zero after a recenter triggered by a large buy. User stakes, another user buys big triggering recenter, first user unstakes and receives no issuance — only pays tax. ## Known context - Issuance is distributed via TWAB snapshots in `Stake.sol` - Recenter is triggered by `LiquidityManager.sol` when price moves enough - Issuance calculation happens in `Stake.getEarnings()` using cumulative TWAB deltas - Recent fix (#4/PR#7): ponder was missing LM_ADDRESS — recenter events were not being indexed ## Reproduction plan 1. Start fresh stack: `./scripts/dev.sh restart --full` 2. Connect wallet A, buy KRK via /app/cheats or swap UI 3. Stake KRK with wallet A 4. Connect wallet B, buy large amount of KRK (enough to trigger recenter) 5. Check: did recenter happen? (`cast call $LM positions(uint8)(uint128,int24,int24) 1`) 6. With wallet A, check Active Positions — does issuance show > 0? 7. Unstake with wallet A — does received amount include issuance? ## What needs verification - [ ] Does issuance actually stay zero after recenter? (reproduce in UI) - [ ] Is TWAB snapshot updated on recenter? (check Stake.sol state) - [ ] Is getEarnings() returning zero or is the UI not displaying it? - [ ] Is the ponder indexer reflecting correct issuance data? ``` ## Implementation In `formulas/run-gardener.toml`, the bug-report detection section (step 7 in grooming). After the `add_label` action, add an `edit_body` action that appends the enrichment sections — same pattern used for backlog promotion body enrichment. ## Files - `formulas/run-gardener.toml` — grooming step, bug-report detection section

dev-bot added the

backlog

label 2026-04-06 09:24:27 +00:00

dev-bot self-assigned this 2026-04-06 10:34:02 +00:00

dev-bot added

in-progress

and removed

backlog

labels 2026-04-06 10:34:02 +00:00

dev-bot commented

2026-04-06 10:34:05 +00:00

Author

Collaborator

Blocked — issue #285

Field	Value
Exit reason	`no_push`
Timestamp	`2026-04-06T10:34:05Z`

Diagnostic output

Claude did not push branch fix/issue-285

### Blocked — issue #285 | Field | Value | |---|---| | Exit reason | `no_push` | | Timestamp | `2026-04-06T10:34:05Z` | <details><summary>Diagnostic output</summary> ``` Claude did not push branch fix/issue-285 ``` </details>

dev-bot added

blocked

and removed

in-progress

labels 2026-04-06 10:34:06 +00:00

dev-bot referenced this issue from a commit

2026-04-06 10:35:06 +00:00

fix: feat: gardener should enrich bug-report issues with context, reproduction plan, and verification checklist (#285)

dev-bot referenced this issue from a pull request that will close it,

2026-04-06 10:35:10 +00:00

fix: feat: gardener should enrich bug-report issues with context, reproduction plan, and verification checklist (#285) #294

dev-bot closed this issue