Your feedback loop — now with an issue for it

The last few weeks brought some of the best feedback flua has received — reports that came with the flua version, a minimal repro, and a clear "expected vs observed" per finding. Two things happened as a result: instant mode got its clock fixed, --strict-tests + --result-json were built for trustworthy CI runs, and a property-endpoint mismatch was verified against a live HC3 and corrected. That quality of report is worth making the default — so there is now a purpose-built issue template for it.

The feedback template

File it at github.com/jangabrielsson/flua/issues/new?template=feedback.md — it asks for the things that make a report actionable:

• what you were doing (one paragraph)
• flua --version --machine — version matters: reports against older releases often hit behavior that is already fixed
• results (what passed, what failed, the commands run)
• findings, one per heading — expected vs observed, a minimal repro, the suggested change
• what worked well, and your priorities

Labels take it from there: feedback, needs-repro, verified-fixed, rainy-day.

You use a coding agent — let it file the report

Most of the forum is AI-assisted these days, and the agents are good at this. Hand yours this prompt at the end of a flua session:

File a flua feedback issue for this session. Use the "Feedback / experience
report" template at
https://github.com/jangabrielsson/flua/issues/new?template=feedback.md

Include:
- what we were testing and the goal
- the output of `flua --version --machine` (and --capabilities-json if relevant)
- every finding as its own section: expected vs observed, the smallest Lua
  file/command that reproduces it, and the suggested change
- what worked well, and which findings matter most to me
- mark anything we could not verify as such

Label it `feedback`. If gh is available, create it with
`gh issue create --template feedback.md --label feedback`.

That takes about two minutes of agent time and replaces the paste-ping-pong: the issue keeps the version trail, the repro, and the resolution in one place, and the next person with the same problem finds it instead of re-reporting it.

What happens after you file

• Every finding is verified against the current tree — confirmed defects are fixed with a pinning regression test, so they cannot silently return.
• Non-urgent improvements are parked in docs/rainy_day_todos.md with the rationale, and promoted when someone asks twice.
• Anything that needs a live-HC3 capture is captured read-only before a single route changes.
• You get a written response per round — what was already fixed, what changed, what was parked.

The triage process itself is documented in docs/feedback/README.md — the same loop the maintainer's own agents follow.