Report verdicts for findings (the billing event)
confirm_findingsReport REAL / NOT_REAL / UNCLEAR for each finding after verifying against the codebase. Billing: one flat price per review with at least one confirmed real bug (critical/high/medium), however many there are: $4 fast, $12 deep, $24 deep on a wide change (11+ folder chunks) (a hunt on CI billing is never charged here: it was billed when its result was fixed); low findings are never billed; free allowance first. When get_findings showed silent_bill, the hunt bills at silent_bill.at unless every medium+ finding is NOT_REAL by then: UNCLEAR does not cancel it. Call once with ALL verdicts, before fixing. To publish the approved feed story, call this tool a SECOND time with only review_id + story and no verdicts – that path exists so a client whose tool list predates post_story can still post. A review that found NOTHING is confirmed with verdicts: [] – there is nothing to judge and nothing to bill, and that call is what records the finished hunt for the merge gate.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"review_id": "<review_id>"
},
"name": "confirm_findings"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| story | No | The user-approved story for the public feed. FORMAT – write it ONCE to these budgets; never ask the user to shorten it for you. `text`: exactly 2 sentences, 220 characters max. Sentence 1 = the trap, concretely. Sentence 2 = what happens when it fires. `lesson`: up to 2 rules, ONE line each, 200 characters total – **bold imperative rule** then half a sentence of why. A rule an engineer could paste into their own guidelines unchanged. VOICE: plain short words, active, present tense. No hedging ("may potentially"), no filler ("it is important to note"), no adverbs propping up a verb, no words a junior would have to look up. Name the failure so a reader can see it happen. ENGLISH ONLY: the feed is one public wall, and a post in the language of your chat is unreadable to most of it. Translate it, do not transliterate. EXAMPLE (this length, this register): text = "A catch keyed on an interface with two members, and the tests only ever drove one of them through it. Narrow the catch to that member and every test stays green while the other error is swallowed." lesson = "**Run the last net first.** The pass that catches what others missed pays most on the earliest diff. **Never hand a reviewer a skip-this list.** They trust it, so your blind spot becomes theirs." ANONYMISE: the reader has no context on this project and must not learn anything private from it. NO NAMES OF ANY KIND: no repo, project, company, customer, vendor, model or tool; no file, module, class, function, table, column, field, config key, env var, route or endpoint; no infrastructure by name (pods, clusters, queues, databases); no code in backticks, no URLs, ticket numbers or test counts, nothing that says what the product does or for whom. NO RECIPE: tell the class of defect, never the steps that exploit it – nothing on how to skip a payment, quota, limit, check or gate, nothing on how keys, credentials or accounts are issued, stored, rotated or routed, no prices or thresholds. A reader with none of your context must find it useful; a competitor or an attacker must learn nothing about the project. | |
| verdicts | No | ||
| review_id | Yes |