submit_feedback
Submit optional run feedback to the engineering-audit tool author, with consented telemetry, as a GitHub issue or mailto fallback.
Instructions
Send optional run feedback to the tool author.
Requires a resolved configuration. There is nothing to send unless
config.feedback_text was set on the configuration page, or the
calling agent supplies extra_text; if neither is present this
raises rather than filing an empty, pointless issue.
The feedback body always carries the free text plus a run-metadata
section (tool version, rules pack, assistant, model, repository,
timestamps), and then each telemetry section the user consented to
on the configuration page (coverage totals, findings rollup by
severity/domain id, self-assessment, environment, consulted sources
by rule id/url/why, rule verdict distribution by domain and in
total, run duration and the divergence verdict between its two
measurements, which domains had their rule text fetched via
get_domain, and the reader's own conclusions after reading the
report); an unconsented section is left out entirely. Finding text
itself is never included, only counts.
report_conclusion and report_fix_first (issue #135) are the
reader's own answers, in their own words, to the two questions the
finished report's own feedback form asks: in one sentence, what did
this report tell them about their repository, and what would they
fix first. Pass these only if the human using this session actually
read the finished report and dictated an answer back; never guess
or paraphrase one on their behalf. Both are ignored unless the
reader_conclusions section was consented to on the configuration
page, same as every other telemetry section here.
Files a labelled issue on the tool author's feedback repository via
gh. If gh is unavailable or filing fails for any reason, the
feedback is never lost: this returns a mailto fallback instead,
with the same body, so the agent can offer to open the user's mail
client or hand over the text to paste in manually.
May be called either before or after render_report. Called after,
it sends feedback for the run just finished and rewrites that run's
report.html and run-state.json so both carry the feedback issue's
link; the response's report_updated field says whether that rewrite
succeeded, and a failed rewrite is reported as a warning rather than
an error, because the issue is already filed by then and raising
would invite a retry that double-files it.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| extra_text | No | ||
| report_fix_first | No | ||
| report_conclusion | No |
Output Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||