chore(api): regenerate static API for new docs (F133, settings tabs, framework consumers)

Bulk regeneration of public/api/{docs,docs/[slug],index,search}.json
to include all docs added since the last regen — F133 deploy providers,
14 Settings tabs (EN+DA), framework consumer guides, and the rest of the
recent doc additions. No content changes, just rebuilt static API.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: cbroberg

public/api/docs.json

@@ -0,0 +1,26 @@
+{
+  "slug": "agent-cost-guards-da",
+  "title": "Per-agent budgetkontrol",
+  "description": "Sæt et loft over en agents forbrug pr. dag, uge eller måned. Stopper løbske agenter før de brænder hele budgettet.",
+  "category": "concepts",
+  "order": 2,
+  "locale": "da",
+  "translationGroup": "2604df61-4bf8-4431-b699-0706c01084e8",
+  "helpCardId": null,
+  "content": "## Hvorfor per-agent budgetter?\n\nCockpit har ét globalt månedligt budget der dækker alle LLM-kald på sitet. Det fungerer fint indtil en agent kommer i et loop eller en kurator har planlagt et dagligt job de har glemt — og hele budgettet forsvinder på én agent mens alt andet sulter.\n\nPer-agent budgetkontrol løser det. Hver agent kan have et valgfrit **dagligt**, **ugentligt** og **månedligt** udgiftsloft. Når agentens faktiske forbrug i den periode når loftet, stopper både manuelle og planlagte kørsler før det næste LLM-kald foretages.\n\n## Sådan sætter du lofterne\n\nÅbn en agents detaljeside og find **Cost guards (USD)** kortet under skema-sektionen. Alle tre felter er valgfrie — efterlad et felt tomt for at betyde \"intet loft for den periode\".\n\n| Felt | Periode | Nulstilles |\n|------|---------|------------|\n| Daily  | Siden 00:00 i dag (lokal tid) | Midnat |\n| Weekly | Rullende 7 dage | Løbende — ældste kørsel falder af efter 7 dage |\n| Monthly | Siden den 1. i indeværende kalendermåned | Den 1. i måneden |\n\nLofterne er **uafhængige**. Hvis du sætter daily=1 og monthly=10, kan agenten bruge $1 om dagen i 10 dage før noget loft trippes. Begge grænser alene er nok til at stoppe en kørsel.\n\n## Sådan virker tjekket\n\nKontrollen kører som et **pre-flight tjek** tre steder:\n\n1. **`runAgent`** (manuelle eller API-kørsler) — tjekker budgettet før LLM-kaldet. Hvis overskredet, kastes en klar fejl med periode og beløb.\n2. **`scheduler`** (planlagte kørsler) — tjekker før hver due agent. Springer kørslen over og logger hvilken periode der trippede, så du kan se det i instrumentation-logs.\n3. **`runWorkflow`** — hver step's agent budget-tjekkes uafhængigt før dens LLM-kald.\n\nDet beløb der bruges er agentens **faktiske analytics-forbrug** for perioden (summeret fra `recordRun`-poster), ikke et estimat. Så loftet afspejler hvad der allerede er brugt, ikke hvad der måske endnu vil blive brugt på den aktuelle kørsel.\n\n## Fejlmeddelelser\n\nNår en manuel kørsel rammer et loft, returnerer API'et 500 med en besked som:\n\n> Agent \"Content Writer\" has reached its daily budget ($1.5234 of $1.50 cap). Increase the cap on the agent's settings page or wait for the period to reset.\n\nScheduleren logger samme besked og springer kørslen over uden at fyre en `agent.failed` webhook — fordi intet rent faktisk fejlede.\n\n## Anbefalede værdier\n\nFornuftige startpunkter:\n\n- **Daily $0.50** — fint til en daglig blogskribent der producerer ét indlæg.\n- **Weekly $5** — dækker et par re-runs eller justeringer i løbet af ugen.\n- **Monthly $20** — generøst månedligt sikkerhedsnet.\n\nHvis du har en agent der genererer billeder, bump det daglige loft med ~$0.04 per billede du forventer pr. kørsel. Nano Banana koster i øjeblikket $0.039 pr. billede.\n\n## Samspil med det globale Cockpit-budget\n\nPer-agent lofter **erstatter ikke** det globale Cockpit månedsbudget — de lægges ovenpå. Scheduleren tjekker begge:\n\n1. Globalt Cockpit budget (95% headroom-regel, legacy)\n2. Per-agent budget (Phase 4)\n\nDet der trippes først stopper kørslen. Så en agent uden per-agent lofter stoppes stadig af det globale loft, og en agent med per-agent lofter kan stoppes tidligt før det globale loft er i nærheden.\n\n## Se også\n\n- [Performance dashboard](/docs/ai-analytics) — historiske omkostninger og kørselsdata pr. agent.\n- [Agent feedback loop](/docs/agent-feedback-loop) — rettelser der reducerer omkostning pr. kørsel over tid.",
+  "excerpt": "Hvorfor per-agent budgetter?\n\nCockpit har ét globalt månedligt budget der dækker alle LLM-kald på sitet. Det fungerer fint indtil en agent kommer i et loop eller en kurator har planlagt et dagligt job de har glemt — og hele budgettet forsvinder på én agent mens alt andet sulter.\n\nPer-agent budgetkon",
+  "seo": {
+    "metaTitle": "Per-agent budgetkontrol — webhouse.app Docs",
+    "metaDescription": "Sæt et loft over en agents daglige, ugentlige eller månedlige LLM-forbrug. Pre-flight tjek blokerer løbske agenter før det næste kald foretages.",
+    "keywords": [
+      "webhouse",
+      "cms",
+      "ai",
+      "budget",
+      "omkostninger",
+      "agenter"
+    ]
+  },
+  "createdAt": "2026-04-08T00:00:00.000Z",
+  "updatedAt": "2026-04-08T00:00:00.000Z"
+}

public/api/docs/agent-cost-guards-da.json

@@ -0,0 +1,26 @@
+{
+  "slug": "agent-cost-guards",
+  "title": "Per-Agent Cost Guards",
+  "description": "Cap an agent's spend per day, week, or month. Stops runaway agents before they burn the global budget.",
+  "category": "concepts",
+  "order": 2,
+  "locale": "en",
+  "translationGroup": "2604df61-4bf8-4431-b699-0706c01084e8",
+  "helpCardId": null,
+  "content": "## Why per-agent budgets?\n\nThe Cockpit has a single global monthly budget that covers every LLM call across the site. That works fine until one agent gets stuck in a loop or a curator schedules a daily job they forget about — and the entire budget evaporates on a single agent while everything else starves.\n\nPer-agent cost guards solve this. Each agent can have an optional **daily**, **weekly**, and **monthly** spending cap. When the agent's actual spend in that period reaches the cap, both manual runs and scheduled runs bail out before another LLM call is made.\n\n## Setting the caps\n\nOpen any agent's detail page and find the **Cost guards (USD)** card under the schedule section. All three fields are optional — leave a field blank to mean \"no cap for that period\".\n\n| Field | Period | Resets |\n|-------|--------|--------|\n| Daily  | Since 00:00 today (local time) | Midnight |\n| Weekly | Rolling 7 days | Continuously — the oldest run drops off after 7 days |\n| Monthly | Since the 1st of the current calendar month | First of the month |\n\nThe caps are **independent**. If you set daily=1 and monthly=10, the agent can spend $1 per day for 10 days before any cap trips. Either limit alone is enough to stop a run.\n\n## How the check works\n\nThe guard runs as a **pre-flight check** in three places:\n\n1. **`runAgent`** (manual or API runs) — checks the budget before the LLM call. If exceeded, throws a clear error with the period and amount.\n2. **`scheduler`** (scheduled runs) — checks before each due agent. Skips the run and logs which period tripped, so you can see the skip in instrumentation logs.\n3. **`runWorkflow`** — each step's agent is independently budget-checked before its LLM call.\n\nThe cost number used is the agent's **actual analytics spend** for the period (summed from `recordRun` entries), not an estimate. So the cap reflects what's already been spent, not what might still be spent on the current run.\n\n## Error messages\n\nWhen a manual run hits a cap, the API returns a 500 with a message like:\n\n> Agent \"Content Writer\" has reached its daily budget ($1.5234 of $1.50 cap). Increase the cap on the agent's settings page or wait for the period to reset.\n\nThe scheduler logs the same message and skips the run silently — it does not fire a `agent.failed` webhook for budget-skip cases, because nothing actually failed.\n\n## Recommended values\n\nSensible starting points:\n\n- **Daily $0.50** — fine for a once-a-day blog writer producing one post.\n- **Weekly $5** — covers a few re-runs or tweaks during the week.\n- **Monthly $20** — generous monthly safety net.\n\nIf you have an image-generating agent, bump the daily cap by ~$0.04 per image you expect per run. Nano Banana is currently $0.039 per image.\n\n## Interaction with the global Cockpit budget\n\nPer-agent caps **do not replace** the global Cockpit monthly budget — they layer on top. The scheduler checks both:\n\n1. Global Cockpit budget (95% headroom rule, legacy)\n2. Per-agent budget (Phase 4)\n\nWhichever trips first stops the run. So an agent without per-agent caps still gets stopped by the global cap, and an agent with per-agent caps can be stopped early before the global cap is anywhere near.\n\n## See also\n\n- [Performance dashboard](/docs/ai-analytics) — historical cost and run data per agent.\n- [Agent feedback loop](/docs/agent-feedback-loop) — corrections that reduce per-run cost over time.",
+  "excerpt": "Why per-agent budgets?\n\nThe Cockpit has a single global monthly budget that covers every LLM call across the site. That works fine until one agent gets stuck in a loop or a curator schedules a daily job they forget about — and the entire budget evaporates on a single agent while everything else star",
+  "seo": {
+    "metaTitle": "Per-Agent Cost Guards — webhouse.app Docs",
+    "metaDescription": "Cap an agent's daily, weekly or monthly LLM spend. Pre-flight checks block runaway agents before another call is made.",
+    "keywords": [
+      "webhouse",
+      "cms",
+      "ai",
+      "budget",
+      "cost",
+      "agents"
+    ]
+  },
+  "createdAt": "2026-04-08T00:00:00.000Z",
+  "updatedAt": "2026-04-08T00:00:00.000Z"
+}

public/api/docs/agent-cost-guards.json

@@ -0,0 +1,26 @@
+{
+  "slug": "agent-feedback-loop-da",
+  "title": "Agent feedback-loop",
+  "description": "Kuratorrettelser og afvisningsnoter gemmes pr. agent og injectes i næste kørsel som few-shot eksempler — agenter lærer automatisk af rettelser.",
+  "category": "concepts",
+  "order": 3,
+  "locale": "da",
+  "translationGroup": "410a9b4a-67e6-4f48-bb75-28bee7aa5640",
+  "helpCardId": null,
+  "content": "## Problemet\n\nTidligt læste agent-runneren tidligere rettelser fra `_data/agents/{id}/feedback.json` og injectede dem i systempromp'ten som few-shot eksempler. Idéen var at agenter ville lære af kuratorrettelser over tid. Hagen: **intet sted i kodebasen blev der nogensinde skrevet til den fil.** Kuratorer kunne rette hver kladde og afvise hver dårlig én og agenten ville glad gentage de samme fejl næste dag.\n\nFeedback-loop'en lukker det hul. Hver kuratorhandling — redigering af et felt før godkendelse, afvisning med en note — persisteres nu automatisk til agentens feedback-fil. Næste gang agenten kører, bages de seneste rettelser ind i dens systemprompt som konkrete eksempler.\n\n## Sådan registreres rettelser\n\nNår en queue item oprettes af en agent, snapshotter runneren det oprindelige `contentData` på queue item under `originalContentData`. Når en kurator godkender, diff'er kuratering-routen det aktuelle `contentData` mod det snapshot og skriver én **correction** post pr. ændret string-felt:\n\n```json\n{\n  \"id\": \"fb-...-...\",\n  \"type\": \"correction\",\n  \"queueItemId\": \"qi-...\",\n  \"field\": \"title\",\n  \"original\": \"Why TypeScript Generics Matter\",\n  \"corrected\": \"How TypeScript Generics Save You From Refactoring Hell\",\n  \"createdAt\": \"2026-04-08T...\"\n}\n```\n\nHvis du ikke redigerer noget før godkendelse, registreres ingen rettelser — det oprindelige output var godt nok.\n\n## Sådan registreres afvisninger\n\nNår du afviser et queue item med en note, skriver afvisning-routen en **rejection**-post med kuratorens noter:\n\n```json\n{\n  \"id\": \"fb-...-...\",\n  \"type\": \"rejection\",\n  \"queueItemId\": \"qi-...\",\n  \"notes\": \"Tonen er for tør — mangler personlighed og specifikke eksempler\",\n  \"createdAt\": \"2026-04-08T...\"\n}\n```\n\nAfvisningsnoter er synlige på agentens detaljeside men **injectes ikke aktuelt i næste systemprompt** (kun `correction` og `edit` poster med både `original` og `corrected` strings bruges som few-shot eksempler). De er stadig nyttige som audit trail og kan blive foldet ind i prompt-konteksten i en fremtidig revision.\n\n## Hvad bliver injectet i næste kørsel\n\nAgent-runneren kalder `loadFeedbackForPrompt(agentId, 5)` og henter de **seneste 5 correction-eksempler** i kronologisk rækkefølge. De tilføjes til systemprompt'en under en `## Learn from past corrections` sektion:\n\n```\n## Learn from past corrections\nExample 1:\nOriginal: Why TypeScript Generics Matter\nCorrected: How TypeScript Generics Save You From Refactoring Hell\n\nExample 2:\nOriginal: A serene sunrise over snow-capped mountains\nCorrected: Snow-covered alpine valley with frozen lake at golden hour\n```\n\nModellen behandler dem som konkrete redaktionelle præferencer og har tendens til at efterligne mønstrene i sin næste kørsel.\n\n## Recent feedback panelet\n\nAgentens detaljeside viser et **Recent feedback** kort med de seneste 5 poster. Hver post har et farvet type-badge (grøn for correction, blå for edit, rød for rejection), feltnavn hvor relevant, et strikethrough diff for corrections og en timestamp.\n\nFooteren noterer det maksimale antal injectede så kuratorer forstår hvad der faktisk flyder tilbage i agenten.\n\n## API\n\nEndpointet er på `POST /api/cms/agents/[id]/feedback` og accepterer:\n\n```json\n{\n  \"type\": \"correction\" | \"rejection\" | \"edit\",\n  \"queueItemId\": \"qi-...\",\n  \"field\": \"title\",\n  \"original\": \"...\",\n  \"corrected\": \"...\",\n  \"notes\": \"...\"\n}\n```\n\nDe fleste kuratorer kalder aldrig dette direkte — kuraterings-routes for godkendelse/afvisning håndterer det automatisk. Det findes til programmatiske submissions og til in-page-panelet.\n\n## Lagring og grænser\n\n- Fil: `_data/agents/{agentId}/feedback.json`\n- Maks poster: **200** (ældste droppes ved append)\n- Format: JSON-array af `FeedbackEntry` objekter\n- Bagudkompatibel: legacy `{ original, corrected }` shape læses som en `correction` type\n\n## Hvorfor kun 5 eksempler?\n\nFew-shot eksempler er den dyreste del af systempromp'ten — hvert er hundredevis af tokens, og prisen betales på hver kørsel. Fem er nok til at kommunikere konsistente redaktionelle præferencer uden at bloate prompten til token-spild. Hvis du vil have agenten til at lære en *ny* præference hurtigt, lander den i top 5 inden for få godkendelser.\n\n## Se også\n\n- [Per-agent budgetkontrol](/docs/agent-cost-guards) — hold en for-ivrig agent fra at ignorere dine rettelser ved at begrænse dens budget.\n- [Kurateringskøen](/docs/curation-queue) — hvor rettelser sker.",
+  "excerpt": "Problemet\n\nTidligt læste agent-runneren tidligere rettelser fra data/agents/{id}/feedback.json og injectede dem i systempromp'ten som few-shot eksempler. Idéen var at agenter ville lære af kuratorrettelser over tid. Hagen: intet sted i kodebasen blev der nogensinde skrevet til den fil. Kuratorer kun",
+  "seo": {
+    "metaTitle": "Agent feedback-loop — webhouse.app Docs",
+    "metaDescription": "Kuratorrettelser og afvisninger gemmes pr. agent og injectes i næste kørsel som few-shot eksempler. Agenter lærer automatisk af rettelser.",
+    "keywords": [
+      "webhouse",
+      "cms",
+      "ai",
+      "feedback",
+      "agenter",
+      "læring"
+    ]
+  },
+  "createdAt": "2026-04-08T00:00:00.000Z",
+  "updatedAt": "2026-04-08T00:00:00.000Z"
+}