Audit behavior cards

A human audit can include behavior cards: a plain-language description of what the code does at the audit's commit, with checked source excerpts. Open your audit report to review them. Each card names the part of your app the rule covers. Reviewers also see whether tests use a real dependency, a local service or a mock.

Choose Right, Wrong or Not sure. Money, sign-in and data cards need your policy in your own words (at least three words) before you can choose Right. You can leave a card open and come back. Only your browser session can record these decisions; an MCP connector cannot confirm them for you.

Wrong asks what is wrong: the card, the test, an app bug, or a request for new behavior. Explain what should be different. The reviewer can turn an app bug into a finding; you then choose whether to post its fix as a paid task. The other answers remain follow-up work in the audit. A revised card needs a fresh answer.

The reviewer can deliver a test pack for the cards you confirm. The report shows its commit, covered-card count, command and reviewer run notes. Download the patch, review it, and apply it to your own repository. TerminalHire does not apply it or open a PR. The run notes are the reviewer's account, not a platform verification result. If a covered card or answer changes, the old download is disabled. The reviewer can replace it before report delivery; further reviewer work after delivery requires a new audit. You can still answer delivered cards. These packs do not change claim acceptance or automatic payment.

For reviewers

Take the order in the audit queue. During the audit pass, write cards from the pinned source and upload a JSON array under Add cards from the audit pass, before delivering the report. Every item has this shape:

{
  "id": "C01",
  "trigger": "A customer requests a quote",
  "result": "Each chair adds $6 to the quote.",
  "domain": "money",
  "dependency": "real",
  "policyQuestion": "What should one chair cost, and for how long?",
  "evidence": [
    {
      "path": "src/prices.ts",
      "startLine": 1,
      "endLine": 1,
      "quote": "export const chairPrice = 6;"
    }
  ]
}

Use general, money, auth or data for domain; real, local-service or mock for dependency. The example quote is illustrative: supply exact lines from the actual repository. The server reads the paid commit and applies the same evidence check as agent-audit findings, including a 30-line limit per citation and secret masking. One invalid card refuses the batch; the error names the card and reason. There are at most 100 current cards per order. Do not upload owner answers or policy text.

When two parts of the code disagree, add an optional conflict object with a plain-language claim and a counterEvidence array using the same citation shape as evidence. Both sets of quotes are checked against the paid commit. For example, say that the package card shows $80 while the booking form shows $95, cite each location, and ask which price the owner wants. Use a specific policyQuestion; the contradiction appears immediately above the owner's policy field.

Complete imports, revisions, findings and test packs before publishing the report. After delivery, App access and all reviewer edits are closed; further work requires a new audit. A revision before delivery preserves the previous card and answers, starts proposed, and invalidates packs that cite the old version.

Review the owner's answers, especially money, sign-in, data and Not sure cards. Use Create finding only when the owner marked The app has a bug. Enter a fix title, outcome and observable acceptance check; the checked evidence travels with the finding. It becomes an option on the owner's report, not a paid posting by itself.

To deliver a pack, select confirmed cards, upload a text .patch or .diff, and state the test command and what you ran. Describe test counts, results, mocks, local services, time zone requirements and gaps. Do not include tests that lock in a disputed behavior. The pack is limited to 500,000 characters; its SHA-256 digest and exact card/answer references are stored with it. It is an artifact for the owner to inspect, not an assertion that the platform ran it or that it will apply cleanly to a newer commit.

No new email or notification is sent when cards or packs change. The owner sees them on the report. The existing report-publication notification is unchanged.