Pick the draft that sounds like you

Adapt this for [what I want to build].

You're working in my codebase. Add a taste step: given my description of what good looks like and a few candidates (drafts, photos described in text, replies, submissions), one call to the Spinda decision API picks one and returns the probability of every candidate. Clear picks go ahead on their own; close calls come to me with the odds attached.

## How the recipe works

- My taste lives in one editable file (for example `taste.md`): voice, style notes, things I never want, and a few short examples of picks I've made. It's sent as part of the request every time. The model does not learn or remember it between calls.
- The candidates come from wherever my app already has them (a writer, a form, an upload queue, another model). This step never writes or edits content; it only chooses among what it's given.
- One HTTPS request asks a `choice` question whose options are the candidates. Optionally add a `noul` question ("does the best one meet our bar at all?") so the step can reject a whole batch.
- The response has `answers.<name>.choice`, `answers.<name>.probabilities` for every candidate, `answers.<name>.noul` for yes/no questions, and `usage`. Rule: if `probabilities[choice]` is at least a threshold (default 0.80) and the bar question passes, go ahead automatically; otherwise put the candidates in front of me, best first, with their probabilities. Don't use the `confidence` field as the top probability; it's a different quantity.

## Reference request

POST https://api.spinda.ai/v1/systemone
Headers: `Authorization: Bearer $SPINDA_API_KEY`, `Content-Type: application/json`, `Idempotency-Key: <stable id per batch, e.g. batch-<id>-v1>`

```json
{
  "model": "decision-model-large",
  "state": "Brand voice: warm, plain and a little dry. Short sentences. No exclamation marks, no hype words like \"game-changer\". Post: our new single-origin coffee from Huila. Notes of red apple and panela.",
  "questions": {
    "caption": {
      "type": "choice",
      "instructions": "Which caption fits our brand voice best?",
      "criteria": {
        "a": "New in: Huila. Red apple, panela, and a reason to slow down.",
        "b": "GAME-CHANGER ALERT!!! Our new Huila coffee is HERE!!!",
        "c": "Introducing our exciting new Huila single-origin, bursting with flavor!"
      }
    },
    "meets_bar": {
      "type": "noul",
      "instructions": "Would we be happy to publish the best of these captions as written?"
    }
  }
}
```

Option names (`a`, `b`, `c`) are just keys; keep a map from key to my candidate's ID. Up to 255 candidates per question and 64 questions per request; the state is billed once per request. Price: $0.039 per million input tokens; output is free.

## What to do

1. Read my project and find where these candidates appear and where a person currently picks one (or should). If you can't tell what's being chosen or where the result goes, ask me one short question; otherwise proceed.
2. Create the taste file from anything my project already says about voice or style (brand guide, README, existing copy). Mark it clearly as mine to edit. Keep it under a page; long examples cost tokens on every call.
3. Build the request from the taste file plus the current item's context as `state`, and the candidates as `choice` options. Keep candidate descriptions as the candidates themselves (or a faithful text description for images).
4. Call the API only from server-side code. Read the key from `SPINDA_API_KEY`. Never put the key in browser code, logs, fixtures or this chat. If it isn't set, keep going in sample mode and tell me: request access at https://spinda.ai (each request is reviewed by hand), create a key in https://console.spinda.ai, and add `SPINDA_API_KEY=...` to my local `.env` (git-ignored).
5. Send an `Idempotency-Key` per batch. On 429, back off and retry with the same key and body (honor `Retry-After`). On 503 (not charged), on 402 (allowance exhausted) or on any error, fall back to asking me; never auto-pick on failure.
6. Add the threshold as configuration (default 0.80) and a review view or message that shows every candidate with its probability, best first, so I can overrule it in one action. Record my overrules next to the model's pick so I can see later where we disagree.
7. Add a sample mode with three fixed responses in the real shape (a clear pick, a close call, a "nothing meets the bar"), labeled as sample output wherever shown. Never present sample results as model output.
8. Write tests for: the request built from the taste file, the clear/close/below-bar branches, failure handling, and that the key never reaches client code. Run them. If `SPINDA_API_KEY` is set, make one live call on a harmless example and show me the full response and `usage`. Then tell me what you changed, how to run it, and what you couldn't verify.

## Keep

- Spinda only picks among candidates; my code decides what happens, and I can always overrule.
- Close calls and failures come to me. The probabilities stay visible next to every automatic pick.
- No logging of my content alongside credentials; log batch IDs, picks and probabilities.