[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_248":249,"_250":251},"routes/_app.x.$handle.$name",{"_11":12,"_13":14,"_15":-7,"_18":19,"_17":-7,"_187":-5,"_20":188,"_22":189,"_190":191,"_192":193,"_26":194,"_24":195,"_196":-5,"_197":-5,"_198":51,"_199":200,"_201":43,"_202":-5,"_203":-5,"_204":205},"routes/_app.x.$handle.$name.code.$",{"_11":12,"_13":14,"_15":16,"_17":-7,"_18":19,"_20":21,"_22":23,"_24":25,"_26":27,"_28":-5,"_29":-5,"_30":-5,"_31":-5,"_32":-5},"handle","jungfreud","name","plain-agent-setup","branchName","main","version","path","reference.md","project",{"_33":134,"_13":14,"_44":135,"_136":-5,"_137":51,"_138":101,"_139":101,"_140":141,"_142":-5,"_143":144,"_145":75,"_146":43,"_147":-5,"_148":-5,"_149":88,"_150":151,"_152":-5,"_153":-5,"_154":-5,"_155":-5,"_156":157,"_158":157,"_159":160,"_161":160,"_162":160,"_163":157,"_164":157,"_165":166,"_167":168,"_169":170,"_171":51},"tree",[54,55,56,57,58,59],"file",{"_33":34,"_13":19,"_35":36,"_37":-5,"_38":39,"_40":41,"_42":43,"_44":45,"_17":46,"_47":24,"_48":49,"_50":51,"_52":-5,"_18":53},"contents",[],"upstream","pull","ahead","behind","envVars","id","307c2899-895e-457c-9a27-d2e3d89a462e","fileId","4f726ce8-a6c2-11f1-9a6d-1607ee4eb77e","parentId","branchId","3b7b1fb6-bbdc-49a4-9a99-33a7cf2f9a15","branchVersion",34,"latest",true,"createdAt",["D",1788363377561],13,"fileType","content","# Plain GraphQL setup reference\n\nEvery mutation below has been **executed against a live Plain workspace** and corrected against what the\nAPI actually accepts — not just what the schema implies. Where the schema and the runtime validator\ndisagree, the runtime wins and is noted.\n\n**Endpoint:** `https://core-api.uk.plain.com/graphql/v1` (POST only)\n**Auth:** `Authorization: Bearer plainApiKey_xxx` plus `Content-Type: application/json`\n**Body:** `{ \"query\": \"...\", \"variables\": {...}, \"operationName\": \"...\" }`\n\n### Verifying anything here\n\nOfficial per-operation docs, including the exact permission each needs:\n```\nhttps://www.plain.com/docs/graphql-reference/mutations/.md\nhttps://www.plain.com/docs/graphql-reference/queries/.md\n```\nFull docs index: `https://www.plain.com/docs/llms.txt`. Raw schema (for input-type and enum shapes):\n`https://core-api.uk.plain.com/graphql/v1/schema.graphql`.\n\n---\n\n## Gotchas that will bite you (all verified the hard way)\n\n1. **`DateTime` is an object, not a scalar.** Every timestamp needs subfields:\n `publishedAt { iso8601 }` or `{ unixTimestamp }`. Selecting it bare is a validation error.\n2. **Icons are slugs, not emoji.** `icon` must match `^[a-z0-9_-]+$` — e.g. `credit-card`, `fire`.\n Passing `💳` fails with *\"icon must be lowercase alphanumeric, _, or -\"*.\n3. **The schema marks some fields optional that the validator requires.** Known cases:\n `upsertHelpCenterArticle.description`, and `threadsFilter.displayOptions.hasLinearIssues` /\n `hasJiraIssues` (which are also `@deprecated` — still required).\n4. **`inviteUserToWorkspace` is forbidden to machine users.** A setup API key *cannot* invite teammates\n (`ForbiddenError: Machine user not allowed to perform this operation`). Team invites are UI-only.\n `assignRolesToUser` on an *existing* user does work with a machine key.\n5. **SLA response times are mutually exclusive.** One SLA record holds *either*\n `firstResponseTimeMinutes` *or* `nextResponseTimeMinutes`, never both. Want both? Create two records\n against the same tier.\n6. **`breachActions` cannot be empty.** Every entry must carry\n `beforeBreachAction: { beforeBreachMinutes: Int! }`.\n7. **`KnowledgeSource` is a union** (`KnowledgeSourceSitemap` | `KnowledgeSourceUrl`) — select through\n inline fragments.\n8. **Workflow event names ≠ webhook event names.** Two different namespaces; see §8 and §13.\n9. **Permission scope suffixes are inconsistent**: `tier:edit` (not `:update`),\n `tenantFieldSchema:update` but `threadFieldSchema:edit`. Don't extrapolate — check the operation's doc.\n\n---\n\n## 0. Order of operations\n\n1. Tiers → 2. SLAs (need `tierId`) → 3. Business hours → 4. Label types → 5. Tenant field schemas →\n6. Thread field schemas → 7. Escalation paths → 8. Workflows (need label/user/tier IDs) → 9. Saved views →\n10. Help center + groups + articles → 11. Knowledge sources → 12. Sidekick → 13. Webhooks →\n14. Roles (invites are UI-only) → 15. Tenants + field values\n\n---\n\n## 1. Tiers ✅ verified\n\n```graphql\nmutation { createTier(input: {\n name: \"Enterprise\", externalId: \"enterprise\", color: \"#5B5FEF\"\n defaultThreadPriority: 1 # 0=urgent 1=high 2=normal 3=low\n memberIdentifiers: [] # [{ companyId } | { tenantId }]\n isDefault: false # only one tier may be true\n}) { tier { id name } error { message code fields { field message } } } }\n```\nScopes: `tier:create`, `tier:read`, `tier:edit`, `tier:delete`, `tierMembership:create/delete/read`.\nAdd members later with `addMembersToTier`.\n\n## 2. SLAs (per tier) ✅ verified\n\nOne record per response type — **not both in one call.**\n\n```graphql\n# First-response SLA\nmutation { createServiceLevelAgreement(input: {\n tierId: \"tier_...\"\n serviceLevelAgreement: {\n firstResponseTimeMinutes: 60\n threadPriorityFilter: [0, 1] # optional; defaults to all priorities\n useBusinessHoursOnly: true\n breachActions: [{ beforeBreachAction: { beforeBreachMinutes: 15 } }]\n }\n}) { serviceLevelAgreement { id } error { message code fields { field message } } } }\n\n# Next-response SLA — a SECOND call against the same tier\nmutation { createServiceLevelAgreement(input: {\n tierId: \"tier_...\"\n serviceLevelAgreement: {\n nextResponseTimeMinutes: 240\n useBusinessHoursOnly: true\n breachActions: [{ beforeBreachAction: { beforeBreachMinutes: 30 } }]\n }\n}) { serviceLevelAgreement { id } error { message code } } }\n```\nScopes: `serviceLevelAgreement:create/edit/delete`.\n\n## 3. Business hours ✅ verified\n\nOutput field is `slots`. `BusinessHoursSlot` has **no `id`** — only timezone/weekday/opensAt/closesAt.\n\n```graphql\nmutation { syncBusinessHoursSlots(input: {\n slots: [\n { timezone: \"Europe/London\", weekday: MONDAY, opensAt: \"09:00\", closesAt: \"17:30\" }\n { timezone: \"Europe/London\", weekday: FRIDAY, opensAt: \"09:00\", closesAt: \"17:00\" }\n ]\n}) { slots { weekday opensAt closesAt } error { message code fields { field message } } } }\n```\nThis replaces the full set of slots each call. Scopes: `businessHours:edit`, `businessHours:read`.\n(`upsertBusinessHours` exists but is deprecated.)\n\n## 4. Label types ✅ verified\n\n```graphql\nmutation { createLabelType(input: {\n name: \"Billing\"\n icon: \"credit-card\" # slug only — NOT emoji\n color: \"#22C55E\"\n type: DEFAULT # or TEAM\n description: \"Billing and invoicing questions\"\n externalId: \"billing\"\n isExcludedFromAi: true # DEFAULT TO TRUE — see below\n}) { labelType { id name } error { message code fields { field message } } } }\n```\n\n**Always create labels with `isExcludedFromAi: true` unless the customer explicitly asks otherwise.**\nPlain's built-in AI triage applies labels independently of your workflows, so leaving this `false` means\ntwo systems label the same threads and your carefully-built triage tree stops being authoritative — a\nthread routed to `Security` also picked up an unrelated `Bug` label in testing. Excluding labels from the\nbuilt-in AI makes your workflow the single source of truth, which is what a customer designing explicit\ntriage rules actually wants. Existing labels can be flipped with\n`updateLabelType(input: { labelTypeId: \"lt_...\", isExcludedFromAi: { value: true } })`.\nScopes: `labelType:create/edit/read`, `label:create`, `suggestedLabelType:read`.\nAlso `archiveLabelType`/`unarchiveLabelType` (prefer archiving), `moveLabelType`,\n`suggestedLabelTypes` + `acceptSuggestedLabelTypes` (useful when migrating).\n\n## 5. Tenant field schemas ✅ verified\n\n```graphql\nmutation { upsertTenantFieldSchema(input: {\n tenantFieldSchemas: [{\n source: \"api\" # new schemas must be \"api\"\n externalFieldId: \"arr\", label: \"ARR\"\n type: NUMBER_TYPE # STRING_TYPE | NUMBER_TYPE | BOOLEAN_TYPE | STRING_ARRAY | DATETIME_TYPE | USER_REFERENCE_TYPE\n options: [], isVisible: true, order: 0\n }]\n}) { tenantFieldSchemas { id label } error { message code fields { field message } } } }\n```\nScopes: `tenantFieldSchema:create/update/read/delete` (note `:update`, not `:edit`).\n\n## 6. Thread field schemas ✅ verified\n\n```graphql\nmutation { createThreadFieldSchema(input: {\n label: \"Resolution reason\"\n key: \"resolution_reason\" # ^[a-z0-9_]+$, immutable\n description: \"Why this ticket was closed\"\n order: 0\n type: ENUM # STRING | BOOL | ENUM | NUMBER | CURRENCY | DATE\n enumValues: [\"fixed\", \"wontfix\", \"duplicate\", \"user_error\"]\n isRequired: false\n isAiAutoFillEnabled: true # let Ari fill it from the conversation\n isAvailableToAgents: true\n isClientReadonly: false\n dependsOnLabelTypeIds: []\n}) { threadFieldSchema { id key } error { message code fields { field message } } } }\n```\nScopes: `threadFieldSchema:create/edit/read/delete` (`:edit`, not `:update`), `threadField:create/update/read/delete`.\n\n## 7. Escalation paths ✅ verified\n\n`EscalationPathStepType` is **`USER`** (with `userId` — machine users allowed) or **`LABEL_TYPE`** (with\n`labelTypeId`). There is no `ASSIGN_USER`/`ADD_LABEL`.\n\n```graphql\nmutation { createEscalationPath(input: {\n name: \"Billing escalation\"\n description: \"Escalate unresolved billing issues\"\n steps: [\n { type: USER, userId: \"mu_...\" }\n { type: LABEL_TYPE, labelTypeId: \"lt_...\" }\n ]\n}) { escalationPath { id name } error { message code fields { field message } } } }\n```\nScopes: `escalationPath:create/edit/read/delete/execute`.\n\n## 8. Workflows ✅ verified end-to-end\n\n**Four steps, or it silently never runs:** create (draft) → add steps → set `startStepId` → publish.\n\n### 8a. Create with trigger\n\n`trigger` is a JSON-encoded string:\n\n| type | extra fields |\n|---|---|\n| `manual` | none — runs via `triggerWorkflow` or a UI button |\n| `events` | `events: string[]` (≥1) |\n| `schedule` | `cron: string` (UTC) — this is what makes recurring digests possible |\n\nWorkflow event names: `thread.thread_created`, `thread.message_added`, `thread.thread_field_updated`,\n`thread.thread_labels_changed`, `thread.thread_status_transitioned`.\n\n```graphql\nmutation { createWorkflow(input: {\n name: \"Route billing tickets\"\n trigger: \"{\\\"type\\\":\\\"events\\\",\\\"events\\\":[\\\"thread.thread_created\\\"]}\"\n}) { workflow { id trigger publishedAt { iso8601 } } error { message code } } }\n```\n`publishedAt: null` ⇒ inactive draft.\n\n### 8b. Add steps\n\n```graphql\nmutation { createWorkflowStep(input: {\n workflowId: \"wf_...\"\n type: ACTION # CONDITION | ACTION | WAIT\n name: \"Label as billing\"\n payload: \"{\\\"version\\\":1,\\\"type\\\":\\\"apply_labels\\\",\\\"labelTypeIds\\\":[\\\"lt_...\\\"]}\"\n transitions: [null] # ACTION: 1 element; CONDITION: 2 (true,false); null = terminal\n positionX: 0, positionY: 0\n}) { workflowStep { id type } error { message code fields { field message } } } }\n```\nPayloads are `{ version: 1, type: , ... }`:\n- **CONDITION** — `contains_label`, `thread_field_equals`, `thread_field_is_set`, `priority_equals`,\n `assigned_to`, `customer_equals`, `ai_workflow_rule_condition`, or combinators `and`/`or`/`not`/`else_if`.\n- **ACTION** — `apply_labels`, `remove_labels`, `set_priority`, `set_status`, `set_tier`,\n `assign_to_user`, `assign_to_team`, `add_note`, `send_message`, `send_slack_notification`,\n `send_http_request`, `set_thread_field`, `snooze_thread`, `escalate_thread`.\n- **WAIT** — `{ \"duration\": , \"cancelCondition\"?: }`.\n\nPayloads embed workspace-specific IDs — never copy them between workspaces; resolve real IDs first.\n`bulkUpsertWorkflowSteps` can set the whole step list plus `startStepId` and `trigger` in one call.\n\n### 8c. Publish\n\n```graphql\nmutation { updateWorkflow(input: {\n workflowId: \"wf_...\"\n startStepId: { value: \"wfs_...\" }\n isPublished: { value: true }\n}) { workflow { id startStepId publishedAt { iso8601 } } error { message code } } }\n```\nNote: there is **no `workflow:*` permission scope** — only `workflowRule:create/edit/read/trigger`.\nWorkflow mutations succeeded with an Admin-preset key. `startStepId` can't be cleared while published.\n\n### 8d. AI prompt conditions and branching ✅ verified live, end-to-end\n\nThe AI condition takes a **plain-English prompt inline** — you do *not* need to create a `WorkflowRule`\nfirst:\n\n```json\n{\"version\":1,\"type\":\"ai_workflow_rule_condition\",\"prompt\":\"This is a security vulnerability report or responsible disclosure\"}\n```\n\n**Build branching chains leaf-first.** `transitions` needs real step IDs, so create the terminal actions\nfirst, then the conditions that point at them, then set `startStepId` to the top condition. An if /\nelse-if / else router looks like this:\n\n| step | type | payload | transitions |\n|---|---|---|---|\n| D | ACTION | `apply_labels` → Bug | `[null]` |\n| E | ACTION | `apply_labels` → Feature Request | `[null]` |\n| B | ACTION | `apply_labels` → Security | `[null]` |\n| C | CONDITION | AI prompt: *\"customer is reporting something broken\"* | `[D, E]` |\n| A | CONDITION | AI prompt: *\"security vulnerability report\"* | `[B, C]` |\n\n…then `updateWorkflow { startStepId: A, isPublished: true }`. Condition transitions are strictly\n`[trueStepId, falseStepId]`.\n\nVerified behaviour on three real threads (~3.2s per run, `executionStatus: SUCCESS`):\n- *\"Possible XSS in comment field…\"* → A matched → Security. Only two steps ran.\n- *\"Export button throws 500…\"* → A false, C matched → Bug.\n- *\"Please add dark mode\"* → A false, C false → Feature Request.\n\nBranching is genuinely exclusive — the untaken branch never executes.\n\n**Debugging executions.** `workflowExecutions(workflowId:, first:)` returns per-run traces, and each\n`stepExecutions[].output` is JSON containing `conditionMatched` — the fastest way to see which branch the\nAI chose:\n```graphql\nquery { workflowExecutions(workflowId: \"wf_...\", first: 5) { edges { node {\n triggeredBy executionStatus executionDurationMs errorMessage\n stepExecutions { workflowStepId status output }\n} } } }\n```\nNote `triggeredBy` comes back prefixed — `domain.thread.thread_created` — while the trigger config uses\n`thread.thread_created`.\n\n### 8e. Architecture: how to actually structure triage + routing ⚠️ read before designing\n\nThree constraints, all verified live, that dictate the design:\n\n1. **Workflow actions do not cascade into other workflows.** A label applied by a workflow\n (`systemId: workflows_handler`) does **not** fire a workflow triggered on\n `thread.thread_labels_changed`. Verified: triage applied `Security`, the label-triggered routing\n workflow recorded **zero executions**.\n2. **API- or human-applied label changes *do* fire those workflows.** The same routing workflow fired\n immediately (`conditionMatched: true`, priority set to urgent) when the label came from `addLabels`.\n3. **Triggers are an OR-list of events.** No AND, no predicates at the trigger level — all narrowing\n happens in condition steps.\n\n**So the intuitive two-layer design — \"triage labels on thread_created, routing reacts to label added\" —\ndoes not work for automated triage.** The second layer never fires.\n\n#### The efficient, controllable shape\n\n**One workflow per entry trigger, doing classify → label → route inline.** On\n`thread.thread_created`:\n\n1. **Cheap deterministic conditions first** — `support_email_equals`, tier/`customer_equals`,\n `contains_label`. They're instant and free, and they shrink the population before you spend AI latency.\n2. **One `else_if` switch for the classification**, not a chain of binary AI conditions. `else_if` is a\n genuine **N-way switch**: `conditions: [c1, c2, c3]` with `transitions: [s1, s2, s3, fallback]`. It\n returns `matchedConditionIndex` and **stops at the first match**:\n ```json\n {\"version\":1,\"type\":\"else_if\",\"conditions\":[\n {\"version\":1,\"type\":\"ai_workflow_rule_condition\",\"prompt\":\"security vulnerability report\"},\n {\"version\":1,\"type\":\"ai_workflow_rule_condition\",\"prompt\":\"something is broken or erroring\"},\n {\"version\":1,\"type\":\"ai_workflow_rule_condition\",\"prompt\":\"requesting a new feature\"}]}\n ```\n Verified: a \"charts not loading, console shows 502\" thread returned `matchedConditionIndex: 1` and\n applied `Bug` — **one step, one execution**, and the third prompt was never evaluated.\n3. **Chain the per-branch actions** — ACTION steps take `transitions: [nextStepId]`, so a branch can run\n `apply_labels` → `set_priority` → `assign_to_team` → `escalate_thread` in sequence.\n\n**Why this beats a chain:** each `ai_workflow_rule_condition` is an LLM call (~1–3s). Three chained binary\nAI conditions is three sequential calls on the worst-case path; one `else_if` is a single step that\nshort-circuits. Order the branches most-likely-first.\n\n**What label-triggered workflows are still for:** reacting to a *human* agent manually re-labelling a\nthread. Keep them for that — just never rely on them to catch automated output.\n\n**If you genuinely need decoupled layers**, the escape hatches are a `send_http_request` action calling\nback into the API (re-enters as an API actor, so it *would* cascade — at the cost of latency and loop\nrisk) or a webhook out to your own service. Both are infrastructure, not no-code; avoid unless the\nseparation is worth it.\n\n**Don't stack multiple workflows on the same trigger.** During testing a leftover workflow that applied\n`Billing` unconditionally on `thread.thread_created` silently labelled *every* thread alongside the real\ntriage. Multiple published workflows on one event all fire, with no ordering guarantee — audit\n`workflows(first: N) { edges { node { name publishedAt { iso8601 } } } }` before adding another, and\ndelete the experiments.\n\n### 8f. How to write AI prompt conditions\n\nOfficial guidance (worth reading, and mirrored in the in-product UI):\n`https://www.plain.com/docs/product/workflows/workflows-conditions#ai-prompts`\n\nEach prompt returns a single **match / no match** boolean, evaluated against a context snapshot Plain\nassembles: the thread's message history (up to 600 messages, 3,000 chars each), thread metadata (title,\ndescription, status, priority, labels), customer name and email, channel, assignees, thread fields and\ntheir schemas, and attachment count. **Nothing else** — no CRM, no product usage, no external data.\n\n1. **Use Plain's `Match if… / Don't match if…` convention.** State what takes the Yes branch, then\n clarify what shouldn't:\n > *\"Match if the customer explicitly requests a refund. Don't match for general billing questions or\n > payment issues without refund mentions.\"*\n2. **Give specific criteria and concrete examples**, in the customer's own vocabulary:\n > *\"Match if the customer reports that existing functionality is broken, erroring, or timing out — for\n > example a 500 error, a failed export, or a page that will not load.\"*\n Never *\"use your best judgment to decide if this is important\"* — the model can't guess what\n \"important\" means to this workspace.\n3. **One decision per prompt.** Don't stuff several outcomes into one condition, and don't ask the prompt\n to take actions — it only returns match/no-match; actions are separate steps. If you need real boolean\n logic, use the `and` / `or` / `not` combinators. Prefer positive statements over stacked negations.\n4. **Order is your tiebreaker, and it does real work.** `else_if` stops at the first match, so put the\n highest-stakes and most specific case first. A security bug should hit `security` before `bug` purely\n because security is listed first. Later prompts may assume the earlier ones were false — don't\n over-qualify them (\"a bug but not a security issue\" is unnecessary and hurts).\n5. **Only ask about what's actually in the thread.** The model sees the conversation, not your CRM,\n plan tier, or the sending domain. Route on those with deterministic conditions\n (`customer_equals`, tier, `support_email_equals`) — they're free and instant. Save prompts for\n genuine language judgement.\n6. **Always wire the fallback branch.** `transitions` has N+1 entries; the last one is \"nothing matched\".\n Point it at a `Needs triage` label rather than `null`, so unclassified threads are visible instead of\n silently untouched. Verified: *\"Thanks for the help\"* matched nothing and landed in `Needs triage`.\n7. **Tune from traces, not vibes.** `stepExecutions[0].output.matchedConditionIndex` tells you exactly\n which prompt won. Push your real historical threads through it and reword wherever the index is wrong.\n8. **One or two sentences.** Long prompts drift.\n\nOrdering by *frequency* also cuts latency, since a match short-circuits the remaining prompts.\n\n### ⚠️ `assign_to_user` needs a human user id — machine ids fail silently\n\n`assign_to_user` with a machine user id (`mu_...`) returns **`status: SUCCESS` with `entities: []` and\nassigns nobody.** No error, no warning. With a human id (`u_...`) it assigns correctly.\n\n```json\n{\"version\":1,\"type\":\"assign_to_user\",\"userId\":\"u_...\"} // ✅ works\n{\"version\":1,\"type\":\"assign_to_user\",\"userId\":\"mu_...\"} // ⚠️ SUCCESS, but no assignment\n```\nFetch real human IDs with `users(first: N) { edges { node { id publicName } } }` before building\nassignment steps, and verify `thread.assignedTo` is non-null after a test run rather than trusting the\nstep status.\n\n### ⚠️ Plain's built-in AI triage also labels threads **and sets priority**\n\nPlain runs its own AI triage independently of your workflows. In testing, a thread got the workflow's\n`Security` label **and** an unrelated `Bug` label — the latter applied by a different system actor:\n\n```\nlabels[].createdBy.systemId == \"workflows_handler\" ← your workflow\nlabels[].createdBy.systemId == \"thread_triage_handler\" ← Plain's built-in AI triage\n```\nIf a label should be controlled *only* by your workflow, create it with **`isExcludedFromAi: true`**.\nOtherwise expect built-in triage to apply it too, and don't mistake that for a workflow bug. Checking\n`createdBy.systemId` on a thread's labels tells you instantly which system applied what.\n\n**It sets priority too.** A thread whose workflow only applied a label (no priority action existed) still\ncame back at priority `0` — built-in triage set it. And a thread where the workflow set priority `1`\n(high) ended up at `0`, i.e. the two systems compete and last-writer-wins. There is **no setting in the\nGraphQL schema to disable built-in triage** — it appears to be UI/plan-level, so if deterministic\npriority matters to a customer, check Settings → Agents in the app rather than assuming the workflow is\nauthoritative. Always verify the end state on a test thread instead of trusting the step trace.\n\n## 8g. Metrics — for auditing an existing workspace ✅ verified\n\nUseful when tuning rather than setting up: find where response times are worst, which labels drag CSAT\ndown, how AI-handled threads compare to human-handled.\n\n```graphql\nquery { threadSingleValueMetric(input: {\n metricName: threads_first_response_time\n from: \"2026-08-01T00:00:00Z\"\n to: \"2026-09-02T12:00:00Z\"\n groupBy: [{ dimension: LABEL_TYPE }] # field is `dimension`, not `groupBy`\n percentile: 90 # P90; defaults to median\n mode: METRIC # or THREAD_IDS\n}) { values { value group { dimension value } } } }\n```\n\n- **Queries:** `threadSingleValueMetric`, `threadTimeSeriesMetric`, `threadHeatmapMetric` (the\n un-prefixed `singleValueMetric`/`timeSeriesMetric`/`heatmapMetric` are deprecated — they don't support\n filtering or group-by).\n- **`groupBy` dimensions:** `ASSIGNEE`, `LABEL_TYPE`, `TIER`, `PRIORITY`, `COMPANY`, `TENANT`,\n `CUSTOMER_GROUP`, `MESSAGE_SOURCE`, `THREAD_FIELD` and `TENANT_FIELD` (both need `subKey`).\n `ASSIGNEE` requires `metricsAgent:read`.\n- **Metric names:** `threads_first_response_time`, `threads_resolution_time`,\n `threads_time_customer_waiting`, `threads_time_between_follow_up_responses`,\n `threads_csat__percentage`, `threads_csat__count`, `service_level_agreement_compliance_frt` / `_nrt`,\n `threads_created_count` (time-series only), `threads_status_count__todo|done|snoozed`,\n `threads_all_time_count_done`. Most have an `agent_` variant for AI-handled threads.\n- **`mode: THREAD_IDS`** returns the actual thread IDs behind a number — use it to cite evidence for a\n recommendation instead of asserting it.\n- Scopes: `metrics:read`, plus `metricsAgent:read` for assignee/agent breakdowns.\n\n**Gotchas:**\n- `to` **cannot be in the future** — a date even a day ahead fails validation.\n- Output is `values { value group { … } }` — `group` singular, not `groups`.\n- **CSAT metrics require `filters.surveyResponse.rating`** — omitting it fails with *\"rating is required\n for CSAT metrics\"*, which the schema doesn't tell you.\n- All-time counts (e.g. `threads_all_time_count_done`) **reject** a date range; everything else requires\n one.\n- `percentile` is only accepted on the configurable-percentile duration metrics; it's rejected elsewhere.\n\n## 9. Saved (custom) views ✅ verified\n\nNearly every `threadsFilter` field is non-null — an empty `{}` is rejected. Pass empty arrays. And the\ntwo `@deprecated` display flags are still **required**.\n\n```graphql\nmutation { createSavedThreadsView(input: {\n name: \"Urgent billing\", icon: \"fire\", color: \"#EF4444\", isHidden: false\n threadsFilter: {\n statuses: [TODO] # TODO | SNOOZED | DONE\n statusDetails: [], priorities: [0, 1]\n assignedToUser: [], participants: [], customerGroups: [], companies: []\n tenants: [], tiers: [], labelTypeIds: [\"lt_...\"]\n messageSource: [], supportEmailAddresses: [], slaTypes: [], slaStatuses: []\n threadFields: [], tenantFields: [], threadLinkGroupIds: [], threadLinkSources: []\n groupBy: NONE # NONE|PRIORITY|STATUS|COMPANY|LABEL|TIER|CHANNEL|ASSIGNEE|CUSTOMER_GROUP|TENANT\n layout: TABLE # TABLE | BOARD\n sort: { field: CREATED_AT, direction: DESC }\n # ThreadsSortField: STATUS_CHANGED_AT | CREATED_AT | CLOSEST_TO_BREACH_SLA\n # | LAST_INBOUND_MESSAGE_AT | PRIORITY | THREAD_FIELD\n displayOptions: {\n hasStatus: true, hasCustomer: true, hasCompany: false, hasPreviewText: true\n hasTier: true, hasCustomerGroups: false, hasLabels: true\n hasLinearIssues: false, hasJiraIssues: false # deprecated BUT REQUIRED\n hasLinkedThreads: false, hasServiceLevelAgreements: true\n hasChannels: true, hasLastUpdated: true, hasAssignees: true, hasRef: true\n }\n }\n}) { savedThreadsView { id name } error { message code fields { field message } } } }\n```\n`and`/`or`/`not` accept nested filters. Scopes: `savedThreadsView:create/edit/read/delete`.\n\n## 10. Help center + migration ✅ verified\n\n```graphql\nmutation { createHelpCenter(input: {\n publicName: \"Acme Help Center\", internalName: \"acme-help-center\"\n type: PUBLIC # PUBLIC | PRIVATE | INTERNAL\n description: \"Support docs for Acme\"\n subdomain: \"acme\" # must be globally unique\n isChatEnabled: true\n isCustomerFacingAiEnabled: true # Ari answers directly on the help center\n}) { helpCenter { id publicName } error { message code fields { field message } } } }\n\nmutation { createHelpCenterArticleGroup(input: {\n helpCenterId: \"hc_...\", name: \"Getting started\"\n # parentHelpCenterArticleGroupId: \"...\" to nest\n}) { helpCenterArticleGroup { id name } error { message code } } }\n\nmutation { upsertHelpCenterArticle(input: {\n helpCenterId: \"hc_...\", helpCenterArticleGroupId: \"hcag_...\"\n title: \"How to reset your password\"\n description: \"Steps to reset a forgotten password\" # REQUIRED despite schema saying optional\n contentHtml: \"

Click forgot password.

\"\n status: PUBLISHED\n slug: \"reset-password\"\n}) { helpCenterArticle { id title } error { message code fields { field message } } } }\n```\nScopes: `helpCenter:create/edit/read/delete` plus **separate** `helpCenterArticle:*` and\n`helpCenterArticleGroup:*` scopes. `generateHelpCenterArticle` AI-drafts from a thread.\nFor bulk migration: fetch each source page, convert to clean HTML, create groups mirroring their nav,\nthen loop `upsertHelpCenterArticle`.\n\n## 11. Ari knowledge sources ✅ verified\n\n`KnowledgeSource` is a union — use inline fragments.\n\n```graphql\nmutation { createKnowledgeSource(input: {\n url: \"https://acme.com/sitemap.xml\"\n type: SITEMAP # SITEMAP (crawls the sitemap) | URL (single page)\n labelTypeIds: []\n}) {\n knowledgeSource {\n __typename\n ... on KnowledgeSourceSitemap { id url }\n ... on KnowledgeSourceUrl { id url }\n }\n error { message code fields { field message } }\n} }\n```\nA help center you create is auto-indexed — no separate source needed. Scopes:\n`knowledgeSource:create/read/delete`. Also `reindexKnowledgeSource`, `deleteKnowledgeSource`.\n\n## 12. Sidekick ✅ verified (settings + custom skill)\n\n```graphql\nmutation { updateSidekickSettings(input: {\n customPrompt: \"Always mention our 30-day refund policy.\"\n}) { error { message code } } }\n\nmutation { createSidekickCustomSkill(input: {\n displayName: \"Check subscription status\"\n description: \"Looks up a customer's plan and billing status\"\n instructions: \"Use the billing MCP for lookups only.\"\n}) { customSkill { id displayName } error { message code } } } # output is `customSkill`\n```\nScopes: `sidekickSettings:read/update`, `sidekickCustomSkill:create/edit/read/delete`,\n`sidekickMcpServer:read/update` — **note there is no `sidekickMcpServer:create` scope**, so\n`createSidekickMcpServer` may be restricted; verify before promising it.\nPer-integration scopes exist and are individually gated:\n`sidekickPosthogIntegration:update`, `sidekickSentryIntegration:update`,\n`sidekickLinearIntegration:update`, `sidekickJiraIntegration:update`, `sidekickGithubIntegration:update`,\n`sidekickNotionIntegration:update`, `sidekickHubspotIntegration:update`, `sidekickDatadogIntegration:update`,\n`sidekickGrafanaIntegration:update`, `sidekickIncidentioIntegration:update`, `sidekickAttioIntegration:update`,\n`sidekickLaunchdarklyIntegration:update`, plus `workspaceSlackSidekickIntegration:create/update/delete`.\nOAuth-based connectors still need a human to complete consent in the browser.\n\n## 13. Webhook targets ✅ verified\n\n```graphql\nmutation { createWebhookTarget(input: {\n url: \"https://acme.com/plain-webhook\"\n eventSubscriptions: [\n { eventType: \"thread.service_level_agreement_status_transitioned\" }\n { eventType: \"thread.thread_created\" }\n ]\n isEnabled: true\n description: \"Ops alerts\"\n}) { webhookTarget { id } error { message code fields { field message } } } }\n```\n**`thread.sla_status_transitioned` does not exist.** Valid webhook event types (distinct from workflow\nevents): `thread.thread_created`, `thread.thread_status_transitioned`,\n`thread.thread_assignment_transitioned`, `thread.email_received`, `thread.email_sent`,\n`thread.slack_message_received`, `thread.slack_message_sent`, `thread.slack_message_updated`,\n`thread.discord_message_received`, `thread.discord_message_sent`, `thread.discord_message_updated`,\n`thread.ms_teams_message_sent`, `thread.ms_teams_message_received`, `thread.chat_sent`,\n`thread.chat_received`, `thread.note_created`, `thread.note_mention_created`,\n`discussion.discussion_created`, `discussion.message_created`, `thread.thread_labels_changed`,\n`thread.thread_priority_changed`, `thread.thread_field_created`, `thread.thread_field_updated`,\n`thread.thread_field_deleted`, `thread.service_level_agreement_status_transitioned`,\n`thread.thread_tenant_updated`, `thread.thread_locked`, `customer.customer_created`,\n`customer.customer_updated`, `customer.customer_deleted`, `customer.customer_changed`,\n`customer.customer_group_changed`, `customer.customer_group_memberships_changed`,\n`timeline.timeline_entry_changed`. Scopes: `webhookTarget:create/edit/read/delete`.\n\n## 14. Team members and roles ⚠️ invites are UI-only\n\n```graphql\n# ❌ FAILS with a machine-user key:\n# inviteUserToWorkspace(input: { email: \"...\", roleKey: SUPPORT })\n# → ForbiddenError: Machine user not allowed to perform this operation\n```\n**Inviting teammates cannot be automated with a setup API key** — it requires a human actor context.\nPut invites in the handoff report as a UI task (Settings → Members), don't try to script them.\n\n`assignRolesToUser` *does* work with a machine key for users who already exist:\n```graphql\nmutation { assignRolesToUser(input: { userId: \"u_...\", roleKey: SUPPORT }) { error { message code } } }\n```\n`RoleKey`: `OWNER | ADMIN | SUPPORT | VIEWER | NONE`, or `customRoleId`. Scopes: `roles:read/assign/create/edit`.\n\n## 15. Tenants and field values ✅ verified\n\n```graphql\nmutation { upsertTenant(input: {\n identifier: { externalId: \"acme-inc\" }\n name: \"Acme Inc\", externalId: \"acme-inc\"\n # primaryDomain / alternateDomains / isDomainAutoJoinEnabled are beta — may not be enabled\n}) { tenant { id name } error { message code fields { field message } } } }\n\nmutation { upsertTenantField(input: {\n tenantFieldIdentifier: {\n tenantIdentifier: { externalId: \"acme-inc\" } # or tenantId\n externalFieldId: \"arr\"\n }\n type: NUMBER_TYPE\n numberValue: 48000 # set exactly the one value field matching `type`\n}) { tenantField { id } error { message code fields { field message } } } }\n```\nScopes: `tenant:create/read/delete`, `tenantField:create/update/read/delete`. Tier a tenant with\n`updateTenantTier`.\n\n---\n\n## Permission scopes — corrected against a live key\n\nAn Admin-preset key reported **390 scopes**. Corrections to earlier guesses:\n\n| Area | Real scopes |\n|---|---|\n| Tiers | `tier:create`, `tier:read`, `tier:edit`, `tier:delete`, `tierMembership:create/delete/read` |\n| SLAs | `serviceLevelAgreement:create/edit/delete` |\n| Business hours | `businessHours:edit`, `businessHours:read` |\n| Labels | `labelType:create/edit/read`, `label:create`, `suggestedLabelType:read` |\n| Tenant fields | `tenantFieldSchema:create/update/read/delete`, `tenantField:create/update/read/delete` |\n| Tenants | `tenant:create/read/delete` |\n| Thread fields | `threadFieldSchema:create/edit/read/delete`, `threadField:create/update/read/delete` |\n| Escalation paths | `escalationPath:create/edit/read/delete/execute` |\n| Workflows | **no `workflow:*` scope exists** — only `workflowRule:create/edit/read/trigger` |\n| Saved views | `savedThreadsView:create/edit/read/delete` |\n| Help centre | `helpCenter:*` **plus separate** `helpCenterArticle:*`, `helpCenterArticleGroup:*` |\n| Knowledge sources | `knowledgeSource:create/read/delete`, `knowledgeGap:*`, `knowledgeGapSignal:*` |\n| Sidekick | `sidekickSettings:read/update`, `sidekickCustomSkill:create/edit/read/delete`, `sidekickMcpServer:read/update` (no `:create`), per-integration `sidekickIntegration:read/update` |\n| Webhooks | `webhookTarget:create/edit/read/delete` |\n| Roles | `roles:read/assign/create/edit` |\n| Sanity check | `permission:read` → call `myPermissions` first to see exactly what you hold |\n\nEasiest path for a one-time setup key remains the **Admin preset**. Delete the machine user\n(`deleteMachineUser`) or narrow the key afterwards.\n\n## Confirmed UI-only (cannot be done with a setup key)\n\n- **Inviting teammates** — `inviteUserToWorkspace` rejects machine users outright. Settings → Members.\n- **Personal notification preferences** — no mutation exists (`updateInternalNotifications` only marks\n notifications read/archived). Avatar → Preferences, per user.\n- **OAuth completion for channels and OAuth MCP servers** — Slack / MS Teams / Discord / email\n forwarding have `create*Integration` mutations that provision the shell, but consent and DNS\n verification need a human browser session. Support is **not live until a channel is connected.**\n- **Chat widget snippet placement** — happens on the customer's own site.\n","deleted",false,"label",[19],{"_33":100,"_13":101,"_35":102,"_37":-5,"_38":39,"_40":95,"_42":43,"_44":103,"_17":88,"_47":104,"_48":-5,"_50":51,"_52":-5,"_67":105,"_18":106},{"_33":92,"_13":93,"_35":94,"_37":-5,"_38":39,"_40":95,"_42":43,"_44":96,"_17":88,"_47":24,"_48":97,"_50":51,"_52":-5,"_67":98,"_18":99},{"_33":83,"_13":84,"_35":85,"_37":-5,"_38":39,"_40":86,"_42":43,"_44":87,"_17":88,"_47":24,"_48":89,"_50":51,"_52":-5,"_67":90,"_18":91},{"_33":73,"_13":74,"_35":75,"_37":-5,"_38":39,"_40":76,"_42":43,"_44":77,"_17":78,"_47":79,"_48":80,"_50":51,"_52":14,"_67":81,"_18":82},{"_33":34,"_13":19,"_35":36,"_37":-5,"_38":39,"_40":41,"_42":43,"_44":70,"_17":46,"_47":24,"_48":49,"_50":51,"_52":-5,"_67":71,"_18":72},{"_33":60,"_13":61,"_35":62,"_37":-5,"_38":39,"_40":63,"_42":43,"_44":64,"_17":65,"_47":24,"_48":66,"_50":51,"_52":-5,"_67":68,"_18":69},"81533beb-dc4b-40a0-b82a-3ff3e8b850ad","skill.md","2b885d4c-a6c2-11f1-a2fb-1607ee4eb77e",39,["D",1788364326355],14,"---\nname: plain-workspace-setup\ndescription: Designs and builds a new Plain workspace end-to-end in one conversation — tiers, SLAs, business hours, labels, tenant/thread fields, workflows, help center migration, Ari knowledge sources, Sidekick, team invites. Talks through how their support actually works first, narrating what each answer buys them, then asks for a single API key at the end and applies the whole config. Finishes with a live Sidekick demo and an HTML handoff report for the few things that need a human click.\n---\n\n# Plain workspace setup\n\nYou're helping someone design and build a Plain workspace. Everything you create goes through the public\nGraphQL API at `https://core-api.uk.plain.com/graphql/v1` — you have no internal Plain access.\n\n**You own the conversation, not the API calls.** Your job is the user journey: understand what they want\nPlain to do, design it with them, and make them feel the value. When it's time to actually build it, you\nhand a config spec to the configuration skill:\n\n> `https://plain-agent-setup.val.run/configure.md`\n\nFetch that when you reach Phase 2 — it owns the GraphQL detail, the dependency order, the verified\nmutation shapes and the traps. You don't need to know any of that to run Phase 1, and you shouldn't clutter\nthe conversation with it. (The raw API reference it uses is at\n`https://plain-agent-setup.val.run/reference.md` if you ever need to look something up directly.)\n\nRead anything you fetch silently — don't narrate that you're reading it, don't summarise it, don't dump it\nback at them.\n\n## The shape of this conversation — read this first\n\n**The config conversation comes first. The API key comes last.** This ordering is deliberate and you must\nnot rearrange it. Asking someone to create machine users and export environment variables before they've\nseen any value is the fastest way to lose them. Instead: talk through how their support works, design the\nworkspace with them, *then* ask for one key to apply the whole thing at once.\n\nPhase 1 — design (no key, no account needed): understand their support setup, decide the config together,\nnarrate what each answer buys them.\nPhase 2 — apply: show them what you're about to build, get an API key, execute it for real.\nPhase 3 — prove it: a live Sidekick demo, then the handoff report.\n\n## How to actually talk to them\n\n- **One thing at a time.** One question or one small action per message. Never stack several questions,\n or a question plus a block of instructions, into one reply. Send it, stop, wait.\n- **No headers, no section dumps.** Write like you're messaging a colleague — short paragraphs, plain\n sentences, no `##` headings in chat, no numbered mega-lists. The final HTML report is a document and can\n look like one; the conversation is not.\n- **Don't narrate the meta level.** Never say \"Now we're kicking off the onboarding,\" \"I'll read the\n reference first,\" \"Here's the plan,\" or \"Step 1 (your part).\" Just ask the thing or do the thing.\n- **Narrate value, not applause.** After each answer, say plainly what it bought them and what's next —\n *\"That gives us five labels to categorize on, which is what lets Ari route tickets to the right person\n instead of dumping them in one queue. Next: do different customers get different response times?\"* Dry\n and specific, like a competent colleague. Never \"Great! 🎉 Your tickets are smarter now!\" — this audience\n finds that grating.\n- **Never overclaim.** Only state the value the thing actually delivers. Labels alone don't mean\n \"everything is routed\" — routing needs the workflow too. If a channel isn't connected, support isn't\n live yet. One inflated claim and they stop trusting the rest.\n- **Mind the tense.** In Phase 1 nothing exists in Plain yet — say \"that gives us,\" \"we'll set up.\" Only\n after you've actually run the mutation in Phase 2 can you say \"created,\" and then show the real ID.\n- **Keep momentum.** Merge purely mechanical steps into one message where nothing hinges on their answer.\n Slow down only for real decisions.\n\n## Phase 1 — design the workspace\n\n**Open with the pitch — punchy, specific, and ending in a question.** Not a feature tour, not an\nexplanation of what labels are. Establish what Plain is, show what's actually possible, then immediately\nturn it into your first piece of discovery. Adapt this, don't recite it:\n\nRead the tone right: **this person has already decided to try Plain.** They're not a prospect you're\nconverting — they're someone who signed up and wants to get going. So this reads as quiet confidence and\nreassurance that they picked well, not as a sales pitch. Say it once, lightly, and move. Never mention,\nname, or allude to any other support tool — no comparisons, no \"unlike other helpdesks.\" The subtext is\ncarried entirely by showing what Plain can do that they'd assume was impossible. If they signal impatience\nat any point (\"let's just go\", \"skip it\"), cut the pitch immediately and start designing — the worst\nversion of this is making an already-sold person sit through a sell.\n\n> Plain is the most advanced support platform for software companies — it's what teams like Cursor and\n> Vercel run their support on. Fast, AI-first, and built on a world-class API, so it scales from startup to\n> unicorn without re-platforming. The bet it makes is that what your customers tell you is one of the most\n> valuable signals in your business — so support shouldn't be an isolated team deflecting tickets, it\n> should be a core part of how you ship. Plain is the infrastructure for those conversations.\n>\n> In the next ten minutes you can have things like this running:\n> - AI triaging, routing, and answering questions straight from your docs — and if you don't have docs\n> yet, Plain's help center can host them\n> - Sidekick posting a weekly digest of every feature request into a shared Slack channel for your\n> product team\n> - Auto-created Linear or Jira issues for any customer request that needs engineering work\n> - Customer health reporting, by wiring Sidekick to PostHog for real product usage\n> - Sidekick investigating Sentry issues and checking whether incoming tickets tie back to them — so you\n> catch a widespread problem before it spreads\n>\n> Which of those is closest to what you actually need? That tells me what to prioritise.\n\nTheir answer is real signal — use it. If they pick the feature-request digest, product feedback matters\nmore to them than deflection, so weight labels and thread fields toward capturing that. If they pick the\nSentry one, they're engineering-led and probably want issue-tracker wiring early. Don't ask the whole\ninterview as if you learned nothing from this.\n\nThen set expectations once, in a sentence: *\"I'll ask you how support works today, we'll design the\nworkspace as we go, and at the end you'll create one API key and I'll build the whole thing.\"*\n\nThen, before designing anything, one quick qualifier: *\"Quick check first — will you be able to create an\nAPI key in Plain, i.e. are you an admin on the workspace (or about to create it yourself)?\"* If they can't,\nsay so plainly now rather than designing a config they have no rights to apply — they'll need someone with\nadmin access, though you can still design it with them and hand the plan over.\n\nAlso suggest, once: *\"Worth keeping Plain open in another tab — when we get to the building part you'll see\nthis appear in real time.\"*\n\n**Then ask how they want to do this:**\n\n> \"How do you want to do this? I can (1) pull structure from your current help desk if you're migrating\n> from one, (2) research your company site and docs myself and propose a full setup, then just check a few\n> things with you, or (3) walk through it together from scratch. Which sounds best?\"\n\nNone of these need an API key — that's the point. All three end with an agreed config.\n\n**Mode 1 — Migrate from an existing help desk.** Ask which tool (Zendesk, Help Scout, Intercom…) and\nwhether they have an export or a URL. Infer categories, help center content, and team structure from it.\nAsk only what the export can't tell you — usually SLA targets, business hours, and who to invite. Don't\nre-ask what you already have.\n\n**Mode 2 — Research and propose.** Ask for their company site and docs URL (one message, wait). Fetch and\nread both silently. Come back with **one consolidated proposal** — the label types you'd create based on\ntheir product, a tier structure, a help center migration plan if you found docs, Ari knowledge sources\npointed at what you found — then a *short* list of what you genuinely can't infer (support hours and\ntimezone, SLA targets, team emails). This is the fast path; don't re-derive by interview what research\nalready answered.\n\n**Mode 3 — Walk through it together.** The interview below, one question at a time, value narrated after\neach answer.\n\n**When the config is settled, write it down as a spec.** Save it to a local file (e.g.\n`plain-workspace-config.yaml`) in the shape the configuration skill expects — fetch\n`https://plain-agent-setup.val.run/configure.md` and use its \"config spec\" contract, which covers labels,\ntiers and SLAs, business hours, thread and tenant fields, escalation paths, the triage tree, saved views,\nhelp center, knowledge sources, Sidekick, webhooks, tenants, and a `needsHumanClick` section for the\nthings no API key can do.\n\nThree reasons this file matters: creating a machine user takes a few minutes of tab-switching and if the\nsession drops it saves them redoing the whole interview; it's something they can show their team for\nsign-off before anything real is created; and it's the clean handoff to the configuration skill, which\nmeans the build step can't drift from what you agreed.\n\n## Phase 2 — get the key and apply it\n\n**Open Phase 2 by showing them what they're about to get.** Concrete and countable, not vague:\n*\"Alright, I've got your config ready: 6 labels, 3 tiers with SLAs, business hours for Europe/London,\n2 thread fields, a help center with 14 articles migrated from your docs, Ari indexing your sitemap, and\nSidekick with your billing MCP. To actually build this I need an API key — takes about a minute to make.\"*\n\nThen, and only then, the key instructions. Two turns, not four:\n\n1. *\"In Plain: Settings → Machine Users → Create machine user (name it `Plain Setup`) → open it → Add API\n key. Ping me when you're looking at the permissions screen.\"* (If they don't have a workspace yet, this\n is where they sign up: `https://app.plain.com/workspaces/create/` — skip the in-product tour, we cover\n the same ground.) Wait.\n2. *\"Does that screen offer an Admin or role preset?\"*\n - Yes → *\"Pick that — covers everything we need, and we'll delete this key when we're done anyway.\"*\n - No / searchable picker → give the search terms **a few at a time**: *\"Search `tier`,\n `serviceLevelAgreement`, `businessHours` and check what comes up\"* → then `labelType`, `label`,\n `suggestedLabelType` → `tenantFieldSchema`, `tenant` → `threadFieldSchema`, `threadField`,\n `escalationPath` → `workflow`, `savedThreadsView`, `helpCenter` → `knowledgeSource`, `sidekick`,\n `webhookTarget` → `roles`, `permission`. (Add `customerGroup`, `machineUser`/`apiKey` only if this\n workspace needs them.) If the back-and-forth is annoying them, offer the whole list in one block —\n speed over ceremony.\n Then: *\"Save the key — it only shows once. Don't paste it to me though, one more step first.\"*\n\n**Getting the key to you without it ever being typed into the chat.** Ask now — not earlier — whether\nthey're in a terminal-capable session (Claude Code, Codex, Cursor) or a browser-only chat:\n- **Terminal:** *\"Set it as an environment variable yourself, outside anything I run — open a terminal and\n run `echo 'export PLAIN_SETUP_KEY=\"plainApiKey_xxx\"' >> ~/.zshrc && source ~/.zshrc` with your real key\n swapped in. Then just tell me it's set — I'll reference `$PLAIN_SETUP_KEY` and never need to see it.\"*\n- **Browser-only chat:** say plainly there's no way to keep a pasted key out of the transcript here. Have\n them scope it narrowly and delete or rotate it the moment you're done.\n\nNever echo, print, log, or repeat the key's value — not even to confirm you have it. `myWorkspace` and\n`myPermissions` returning successfully is all the proof you need.\n\n**Then hand off to the configuration skill.** Fetch\n`https://plain-agent-setup.val.run/configure.md` and follow it, passing the config spec you saved. It\nknows the dependency order, the verified mutation shapes and the silent-failure traps — you don't need to\ncarry any of that.\n\nYou stay responsible for the *conversation* while it runs: keep narrating in plain language as things get\nbuilt (\"tiers and SLAs are in — here's the help center going up now\"), keep the running sense of progress,\nand keep the value language in past tense now that objects genuinely exist and they can see them in that\nPlain tab. If the configuration skill reports a failure, relay it honestly with the real reason and what's\nbeing done about it — never smooth it over.\n\n**Teammate invites will come back as a human task, not a failure.** `inviteUserToWorkspace` refuses\nmachine users, so collect names and emails in Phase 1 and expect them in the report's UI-task list.\n\n## Phase 3 — prove it works\n\nIf they set up Sidekick, don't stop at configuration — **demonstrate it.** Create a test thread that looks\nlike a real customer question in their domain, let Sidekick triage and draft a reply, and walk them through\nwhat it did and why. This is the moment the whole setup pays off: they watch an AI support engineer work\ntheir queue. Configuration is a promise; this is proof.\n\nThen the handoff report — a self-contained HTML page with two sections:\n\n1. **Built for you** — every tier, SLA, label, field, workflow, help center article, knowledge source,\n Sidekick config, webhook and invite you created, with its real ID and a link into Plain where the URL\n pattern is known (e.g. `https://app.plain.com/workspace//settings/tiers`).\n2. **Needs a click from you** — everything that genuinely requires a human in a browser: **inviting the\n teammates they named** (Settings → Members — the API refuses machine users, so this is always a UI\n task), connecting Slack / MS Teams / Discord / email channels, embedding the chat widget on their site,\n completing OAuth for any MCP servers, and each teammate's personal notification preferences. Name the\n exact Settings page for each.\n\nBe straight about the fact that **support isn't live until a channel is connected** — the workspace is\nconfigured, but tickets can't arrive until they finish the channel OAuth. Don't let them leave thinking\nthey're taking calls when they aren't. If they have five minutes left, walk them through connecting one\nchannel right now instead of leaving it in the report.\n\nClose with a short plain-spoken summary and the reminder to delete or narrow that setup key.\n\n## What each thing is (for weaving into questions)\n\nOne sentence of context before the relevant question — not a feature tour up front:\n\n- **Tiers** — segment customers (Enterprise / Pro / Free) so SLAs and priority differ by who's asking.\n- **Labels** — the categories you tag tickets with (Billing, Bug, Feature Request).\n- **Tenant & thread fields** — custom data on accounts (ARR, plan) and tickets (resolution reason), for\n reporting and routing rules.\n- **Workflows** — no-code automations: when X happens, do Y (auto-label, auto-assign, auto-escalate).\n- **Help Center + Ari** — a public docs site, plus an AI that answers customers from it and any other\n knowledge sources you point at it.\n- **Sidekick** — an AI support engineer that works the queue in the background — triaging, researching,\n drafting, resolving what it can — pulling a human in only when needed, under approval rules you set.\n- **Channels** — where conversations actually arrive: email, Slack, MS Teams, chat widget, Discord.\n Connecting these needs a human OAuth click.\n\n## The interview (Mode 3, and for filling gaps in Modes 1 and 2)\n\nGrouped by topic for your reference, not for how you send them. One question per message, value narrated\nafter each answer. Skip anything already answered by an export or your research.\n\n**The basics**\n- What do you support, and what's the company called?\n- Who's on the support team? (names/emails → invites)\n\n**When a ticket comes in — what should happen?** (the important one: drives labels, workflows, escalation, SLAs)\n- What are the main things customers contact you about? (→ Label Types)\n- Do some customers get different treatment — paid vs free, or specific white-glove accounts? (→ Tiers)\n- What response times do you want to hold to, and does that vary by tier or urgency? (→ SLAs)\n- Support hours and timezone? Should SLAs pause outside them? (→ Business hours)\n- Should anything auto-route or auto-escalate? (→ Workflows, Escalation paths)\n- Any data you want tracked per ticket or per account for reporting? (→ Thread fields, Tenant fields)\n\n**Docs and knowledge**\n- Do you have customer-facing docs anywhere? URL? (→ help center migration; pull the sitemap yourself)\n- Public help center, or logged-in customers only? Should Ari answer directly from it?\n- Anything else Ari should know — status page, changelog, API docs? (→ knowledge sources)\n\n**Sidekick**\n- Should it draft replies, send them, or just assist the team? What always needs a human's OK?\n- Any internal tools it should check — Stripe, your backend, a CRM? (→ MCP servers; OAuth ones need a\n follow-up click, API-key ones you can wire now)\n- Standing instructions — tone, policies, things to never promise?\n\n**Channels and views**\n- Where do customers reach you today? (note for the report / connect at the end)\n- Any saved views the team wants on day one? (\"my open tickets,\" \"unassigned urgent\")\n\n## Building triage and routing (read the reference's §8 before you build any workflow)\n\nA few rules that matter enough to repeat here:\n\n- **Create every label with `isExcludedFromAi: true` by default.** Plain's built-in AI triage labels\n threads independently, so leaving it off means two systems fight over the same threads and the workflow\n you just built with them stops being authoritative. Only leave the AI on if they explicitly want Plain's\n own triage doing the labelling.\n- **One triage workflow, not several.** Workflow actions don't cascade into other workflows, so the\n \"triage applies a label → a routing workflow reacts to that label\" design silently never fires. Do\n classification *and* routing in one workflow on `thread.thread_created`: deterministic conditions first,\n then a single `else_if` switch of AI prompts, then chain each branch's actions\n (`apply_labels` → `set_priority` → `assign_to_user`).\n- **Audit before adding.** List existing workflows (`workflows(first: N)`) and check what's already\n published — several workflows on one trigger all fire, in no guaranteed order.\n- **Always wire the `else_if` fallback branch** to a \"Needs triage\" label so unclassified threads are\n visible rather than silently untouched.\n- **Write AI prompts in Plain's `Match if… / Don't match if…` form**, one decision each, with concrete\n examples, ordered highest-stakes first (the switch stops at the first match). Full guidance in the\n reference §8f, which mirrors Plain's own docs.\n- **Offer to hone the prompts on their real tickets.** Before writing the classification prompts, say\n something like: *\"If you can drop in an export or even a handful of recent tickets — subject lines and\n a bit of body — I'll write the AI prompts around the language your customers actually use. Otherwise\n I'll write sensible ones from what you've told me and you can tweak them in the UI later.\"* Real\n examples are the single biggest quality lever on triage accuracy: they give you the customer's own\n vocabulary, the genuine category mix, and the edge cases. If they do share tickets, group them by the\n categories they described, name the recurring phrasing in each group, and use that wording in the\n prompts. If they don't, don't push — build it and tell them where to tune it.\n- **Once the workflow is live, test it on their real examples.** Create a thread from a couple of the\n tickets they shared (or realistic ones in their domain), then read\n `stepExecutions[0].output.matchedConditionIndex` to show which branch each took. If one lands wrong,\n reword that prompt and re-run — this is the tuning loop, and doing it once in front of them teaches\n them how to maintain it.\n- **Verify the end state, not the step status** — some actions report SUCCESS while doing nothing\n (`assign_to_user` with a machine-user id is the known trap). Check the thread actually changed.\n\n## Guardrails\n\n- Don't ask for the API key until Phase 2, and never accept it as plain chat text or echo its value.\n- Never invent a mutation or field name. If it's not in the reference, or you're unsure of an argument,\n fetch the official per-operation doc — `https://www.plain.com/docs/graphql-reference/mutations/.md`\n (or `/queries/.md`), which states the arguments and the exact permission required. Full index at\n `https://www.plain.com/docs/llms.txt`; the raw schema\n (`https://core-api.uk.plain.com/graphql/v1/schema.graphql`) has the precise input-type and enum shapes.\n If you still can't confirm something exists, say so rather than guessing.\n- Always check the `error` field on a mutation's output before treating it as success.\n- Before creating things with real-world side effects (inviting teammates, publishing public help center\n articles), read back what you're about to send and get a quick confirmation. This is their production\n support workspace from day one, not a sandbox.\n- Migrating content? Actually fetch their existing pages — don't invent article text.\n- The use cases in the opening pitch aren't all equally instant, so don't promise them as if they are.\n Directly API-backed and buildable in this session: Ari answering from docs/help center, help center\n creation and migration, Linear/Jira issue creation (`createIssueTrackerIssue`, plus the Linear/Jira\n service integrations), and PostHog wiring for Sidekick (`updateSidekickPosthogConfig`). Needing a human\n OAuth click before they work: anything posting into Slack (including the weekly feature-request digest),\n and any OAuth-based MCP server such as Sentry. If they picked a Slack- or OAuth-dependent use case as\n their priority, say up front that it needs one browser click from them at the end, and make sure you\n actually walk them through that click rather than filing it in the report.\n- `Workflow.trigger` and `WorkflowRule.payload` are opaque JSON strings whose exact shape isn't documented.\n Don't guess: build one workflow in the Plain UI with them, read it back via the `workflow` query to learn\n the shape, then template from it. If that's too slow for the session, leave workflows for the report and\n say so.\n","children",[],[61],["D",1788363377561],[],[19],"926f34a3-7197-4916-a750-6b39ed4b5331","index.tsx","01a061e4-3acb-7070-a926-90fc5b0aa181",36,["D",1788364280307],3,"http","import { Hono } from \"npm:hono@4\";\nimport { parseVal, readFile } from \"https://esm.town/v/std/utils/index.ts\";\n\nconst app = new Hono();\n\napp.get(\"/\", async (c) => {\n const html = await readFile(\"/public/index.html\", import.meta.url);\n return c.html(html);\n});\n\napp.get(\"/skill.md\", async (c) => {\n const md = await readFile(\"/skill.md\", import.meta.url);\n return c.text(md, 200, {\n \"content-type\": \"text/markdown; charset=utf-8\",\n \"content-disposition\": 'inline; filename=\"skill.md\"',\n });\n});\n\napp.get(\"/reference.md\", async (c) => {\n const md = await readFile(\"/reference.md\", import.meta.url);\n return c.text(md, 200, {\n \"content-type\": \"text/markdown; charset=utf-8\",\n \"content-disposition\": 'inline; filename=\"reference.md\"',\n });\n});\n\napp.get(\"/configure.md\", async (c) => {\n const md = await readFile(\"/configure.md\", import.meta.url);\n return c.text(md, 200, {\n \"content-type\": \"text/markdown; charset=utf-8\",\n \"content-disposition\": 'inline; filename=\"configure.md\"',\n });\n});\n\n// View source on Val Town\napp.get(\"/source\", (c) => c.redirect(parseVal().links.self.val));\n\n// Unwrap and rethrow Hono errors as the original error\napp.onError((err) => Promise.reject(err));\n\nexport default app.fetch;\n",[],[74],"2132424c-eda7-4678-9577-bcea615d1a9a","configure.md","1d1f56a6-a6e6-11f1-a232-1607ee4eb77e",35,["D",1788364268625],0,"---\nname: plain-configuration\ndescription: Applies a Plain workspace configuration over the GraphQL API. Takes an agreed config spec, validates it, creates everything in the correct dependency order, verifies each result, and reports what was built plus what still needs a human click. Called by the onboarding skill for new workspaces and by the tuning skill for changes to existing ones.\n---\n\n# Plain configuration\n\nYou apply configuration to a Plain workspace over the GraphQL API. You are the executor — something else\n(usually the onboarding skill at `https://plain-agent-setup.val.run/skill.md`, or a human directly) has\nalready decided *what* should exist. Your job is to build it correctly, verify it, and report honestly.\n\n**Read the API reference before you call anything:**\n`https://plain-agent-setup.val.run/reference.md`. Every mutation in it has been executed against a live\nworkspace, and it documents the traps that fail silently. Don't guess field names — if something isn't in\nthere, fetch the official per-operation doc at\n`https://www.plain.com/docs/graphql-reference/mutations/.md`, which also states the permission\nrequired.\n\n## Endpoint and auth\n\n`POST https://core-api.uk.plain.com/graphql/v1` with\n`Authorization: Bearer $PLAIN_SETUP_KEY` and `Content-Type: application/json`.\n\n**Never read, print, echo or log the key's value.** Reference the environment variable. If the caller\nhasn't set one, ask them to — don't accept a pasted key in the conversation. See the onboarding skill's\nkey-handling section for the exact instructions to give.\n\nBefore building anything: run `myWorkspace` and `myPermissions`. Confirm you're pointed at the workspace\nthey meant (read the name back to them — this is the last moment to catch a production workspace someone\nthought was a sandbox), and check the scopes you hold against what the config needs.\n\n---\n\n## The config spec — your input contract\n\nWhatever calls you should hand you a spec in this shape. Anything omitted simply isn't built. If you were\nhanded something looser (prose, a half-finished list), normalise it into this shape and **read it back for\nconfirmation before executing** — that read-back is the last checkpoint before real objects exist.\n\n```yaml\nworkspace: \"Acme\" # for reference only; you can't rename via this flow\n\nlabels: # → createLabelType\n - name: Billing\n icon: credit-card # slug, NOT emoji\n color: \"#22C55E\"\n externalId: billing\n excludeFromAi: true # DEFAULT TRUE — see reference §4\n\ntiers: # → createTier, then createServiceLevelAgreement per SLA\n - name: Enterprise\n externalId: enterprise\n color: \"#5B5FEF\"\n defaultThreadPriority: 1 # 0=urgent 1=high 2=normal 3=low\n isDefault: false # at most one tier true\n slas:\n - kind: first_response # first_response | next_response — SEPARATE RECORDS, never both\n minutes: 60\n priorities: [0, 1]\n businessHoursOnly: true\n warnBeforeMinutes: 15 # required; breachActions can't be empty\n\nbusinessHours: # → syncBusinessHoursSlots (replaces the whole set)\n timezone: Europe/London\n slots:\n - { weekday: MONDAY, opensAt: \"09:00\", closesAt: \"17:30\" }\n\nthreadFields: # → createThreadFieldSchema\n - label: Resolution reason\n key: resolution_reason # ^[a-z0-9_]+$, immutable\n type: ENUM # STRING | BOOL | ENUM | NUMBER | CURRENCY | DATE\n enumValues: [fixed, wontfix, duplicate, user_error]\n required: false\n aiAutoFill: true\n dependsOnLabels: [] # label names from `labels` above\n\ntenantFields: # → upsertTenantFieldSchema\n - externalFieldId: arr\n label: ARR\n type: NUMBER_TYPE # STRING_TYPE | NUMBER_TYPE | BOOLEAN_TYPE | STRING_ARRAY | DATETIME_TYPE | USER_REFERENCE_TYPE\n\nescalationPaths: # → createEscalationPath\n - name: Billing escalation\n steps:\n - { type: USER, user: \"jane@acme.com\" } # resolve to u_… ; NOT machine users\n - { type: LABEL_TYPE, label: Billing }\n\ntriage: # ONE workflow. See reference §8e before changing this shape.\n trigger: thread_created # thread_created | labels_changed | status_transitioned | schedule\n cron: null # only when trigger: schedule\n preFilters: [] # deterministic conditions first — cheap and instant\n classify: # else_if branches, evaluated IN ORDER, first match wins\n - prompt: \"Match if the customer reports a security vulnerability, exploit or data exposure — for example XSS, SQL injection or leaked credentials. Don't match for general questions about security features.\"\n then:\n label: Security\n priority: 0\n assignTo: \"security@acme.com\" # resolve to a human user id\n - prompt: \"Match if the customer reports that existing functionality is broken, erroring or timing out — for example a 500 error or a failed export. Don't match for feature requests.\"\n then:\n label: Bug\n priority: 1\n fallbackLabel: Needs triage # never leave this null\n\nsavedViews: # → createSavedThreadsView\n - name: Urgent billing\n icon: fire # slug, not emoji\n color: \"#EF4444\"\n statuses: [TODO]\n priorities: [0, 1]\n labels: [Billing]\n\nhelpCenter: # → createHelpCenter (+ groups + articles)\n publicName: Acme Help Center\n internalName: acme-help-center\n subdomain: acme # globally unique\n type: PUBLIC # PUBLIC | PRIVATE | INTERNAL\n chatEnabled: true\n ariEnabled: true\n migrateFrom: \"https://docs.acme.com/sitemap.xml\" # fetch real pages; never invent article text\n\nknowledgeSources: # → createKnowledgeSource\n - { url: \"https://acme.com/sitemap.xml\", type: SITEMAP }\n\nsidekick:\n customPrompt: \"Always mention the 30-day refund policy.\"\n customSkills:\n - { displayName: Check subscription, description: \"...\", instructions: \"...\" }\n mcpServers: [] # OAuth ones need a human click — report, don't promise\n\nwebhooks: # → createWebhookTarget\n - url: \"https://acme.com/plain-webhook\"\n events: [thread.thread_created] # webhook event names ≠ workflow event names\n\ntenants: # → upsertTenant + upsertTenantField\n - { name: Acme Inc, externalId: acme-inc, fields: { arr: 48000 }, tier: enterprise }\n\nneedsHumanClick: # things you CANNOT do — carry into the report\n invites: [{ email: jane@acme.com, role: SUPPORT }]\n channels: [email, slack]\n```\n\n---\n\n## Execution order\n\nDependencies are real — out of order means failures or orphaned config.\n\n1. **Tiers** → 2. **SLAs** (need `tierId`) → 3. **Business hours** → 4. **Labels** → 5. **Tenant field\nschemas** → 6. **Thread field schemas** (may reference labels) → 7. **Escalation paths** (reference\nlabels + users) → 8. **Triage workflow** (needs label, user and tier IDs to exist) → 9. **Saved views** →\n10. **Help center** → groups → articles → 11. **Knowledge sources** → 12. **Sidekick** → 13. **Webhooks**\n→ 14. **Tenants + field values**.\n\nKeep a running map of `name → real ID` as you go. Everything downstream references IDs, and workflow step\npayloads embed them — a name-based payload silently applies nothing.\n\n## How to execute\n\n- **Resolve identities first.** Fetch `users(first: N) { edges { node { id publicName } } }` and map any\n emails in the spec to real `u_…` IDs. `assign_to_user` with a machine user id returns SUCCESS and\n assigns nobody — see reference. If an email doesn't match a workspace member, don't guess: move that\n assignment into `needsHumanClick` and say so.\n- **One thing at a time, narrated.** Say what you're creating, create it, confirm with the real ID. Group\n only trivially-related items (a batch of labels). Never fire ten mutations and report once.\n- **Check `error` on every mutation** before treating it as success — `error { message code fields { field message } }`. The\n `fields` array names exactly what's wrong and is usually enough to fix and retry immediately.\n- **On failure:** say what failed, in plain language, with the real message. Then either fix and retry\n (validation errors usually tell you the fix), skip it and record it for the report, or ask — but never\n silently swallow it and never loop.\n- **Verify end state, not step status.** Some operations report success while doing nothing. After the\n triage workflow is published, create one test thread and read\n `workflowExecutions → stepExecutions[].output.matchedConditionIndex` to prove the branch fired and the\n label, priority and assignment actually landed on the thread.\n\n## Building the triage workflow\n\nThe single most error-prone part. Full detail in reference §8, but the shape:\n\n1. `createWorkflow` with the JSON trigger — this creates an **inactive draft**.\n2. Create the **terminal action steps first** (leaf-first), because `transitions` needs real step IDs.\n Chain each branch's actions: `apply_labels` → `set_priority` → `assign_to_user`.\n3. Create the **`else_if` classify step** with one prompt per branch and\n `transitions: [branch1, branch2, …, fallback]` — N conditions, N+1 transitions.\n4. Any deterministic pre-filters go *above* the classify step, pointing at it on the true branch.\n5. `updateWorkflow { startStepId, isPublished: true }` — until you do this it never runs.\n\n**Before creating a new workflow, audit what's already published:**\n`workflows(first: 20) { edges { node { id name publishedAt { iso8601 } } } }`. Multiple published\nworkflows on one trigger all fire with no ordering guarantee — the classic symptom is every thread getting\nan unexpected label. If a conflicting one exists, tell the caller and agree whether to unpublish it rather\nthan stacking another on top.\n\nTo modify an existing published workflow: unpublish (`isPublished: false`), restructure, republish.\n`startStepId` can't be cleared while published.\n\n## What you cannot do — always report these\n\n- **Invite teammates.** `inviteUserToWorkspace` refuses machine users outright. Collect them into the\n report as a UI task (Settings → Members). `assignRolesToUser` on an existing user does work.\n- **Complete channel OAuth** (Slack, MS Teams, Discord, email forwarding) or OAuth MCP servers. You can\n provision shells; consent needs a browser. **Support is not live until a channel is connected** — say\n so plainly rather than letting someone believe they're taking tickets.\n- **Set personal notification preferences.** No mutation exists; per-user, avatar → Preferences.\n- **Place the chat widget snippet** on their own site.\n- **Disable Plain's built-in AI triage**, which labels *and* sets priority independently of your workflow.\n Mitigate by creating labels with `excludeFromAi: true`; for priority, flag Settings → Agents.\n\n## Output\n\nReturn two things to whatever called you:\n\n1. **Built** — every object created, with its real ID, grouped by area. Machine-readable enough that a\n caller can render it (the onboarding skill turns this into an HTML report).\n2. **Needs a human** — invites, channel OAuth, notification preferences, widget snippet, plus anything\n that failed and why. Name the exact Settings page for each.\n\nThen remind them to delete the setup machine user or narrow its key — it can create tiers, invite-adjacent\nconfig and publish public help center content.\n",[],[84],"67a4f1c1-3637-4404-9e16-6d13683b3dae","README.md","01a061e4-3acb-7070-a926-8c4f90b26c5e",1,["D",1788348742264],"# hono-jsx-starter\n\nA minimal [Hono](https://hono.dev) + Hono JSX starter for Val Town.\nServer-rendered HTML, no build step, no React.\n\n## Picking a starter\n\n| Starter | When to pick it |\n| --- | --- |\n| [`basic-html-starter`](https://www.val.town/x/templates/basic-html-starter) | Static HTML pages. Sprinkle of vanilla JS. No server-side rendering. |\n| **[`hono-jsx-starter`](https://www.val.town/x/templates/hono-jsx-starter)** *(you're here)* | Dynamic server-rendered HTML with JSX. API routes. No React, no SPA. |\n| [`react-hono-starter`](https://www.val.town/x/templates/react-hono-starter) | Client-side React SPA with a Hono API backend. |\n\n## What's here\n\n```\nindex.tsx Hono app, Layout, routes\npublic/\n favicon.svg Static asset\n counter.ts Tiny client-side script\n```\n\nThe whole app fits in one file. As you grow it, the natural next moves are:\n\n- Pull `Layout` into its own `.tsx` file once you have 3+ pages.\n- Split routes with `app.route(\"/api\", api)` if `/api/*` grows.\n- Add more files under `public/` — they're served by a single\n `app.get(\"/public/*\", ...)` route.\n\n## Patterns worth knowing\n\n**JSX pragma.** Every `.tsx` file that uses JSX needs this at the top:\n\n```tsx\n/** @jsxImportSource npm:hono@4/jsx */\n```\n\n**Server state.** The counter on `/` is `let count = 0` at module scope. It\nlives in memory on the Val Town server and survives across requests — but resets\nwhenever the val restarts (deploys, idle timeouts, etc.). For persistent state,\nswap it for [`std/sqlite`](https://www.val.town/x/std/sqlite) or\n[`std/blob`](https://www.val.town/x/std/blob).\n\n**API routes.** The `Increment` button POSTs to `/api/increment`, which returns\nJSON. Mix server-rendered pages and JSON endpoints in the same Hono app:\n\n```ts\napp.post(\"/api/increment\", (c) => c.json({ count: ++count }));\n```\n\n**Static files.** `serveFile` reads the file by path and serves it with the\nright content-type. `.ts` files are transpiled to JS on request by Val Town — so\nyou can write `public/counter.ts` and reference it as\n`\n\n\n\n",[],[101,111],"dfa17abd-085c-45c1-81d7-cd10c11b9b60","favicon.svg","01a061e4-3acb-7070-a926-842f4e54d674",["D",1788348742264],"\n",[],[101,120],"70c7bc19-dc6c-4ab8-b78f-c08042ad49f0","counter.ts","01a061e4-3acb-7070-a926-8362bdc08d67",["D",1788348742264],"script","const count = document.getElementById(\"count\")!;\nconst button = document.getElementById(\"increment\")!;\n\nbutton.addEventListener(\"click\", async () => {\n const res = await fetch(\"/api/increment\", { method: \"POST\" });\n const data = await res.json();\n count.textContent = String(data.count);\n});\n",[],[101,127],"3c1c900e-c1e8-4f87-bbbe-df295b0d59ee",["D",1788348742264],"deletedAt","legacyEnvVars","privacy","httpPrivacy","description","Live setup page + skill files for Plain's Claude Code onboarding","imageUrl","userId","019bd3e5-3016-76dc-9fbe-33f578301ebf","pinnedFileId","pinPreview","pinMigrated","screenshotVersion","likeCount","orgId","019bd3e5-3016-76dc-9fbe-352b283c5ab0","tursoName","tursoHostname","tursoMeasuredAt","pinned","userPerm","r","valPerm","blobPerm","rw","emailPerm","sqlitePerm","projectPerm","telemetryPerm","user",{"_11":12,"_186":182},"org",{"_11":12,"_180":-5,"_181":182,"_143":144,"_183":184,"_185":51},"branch",{"_17":63,"_13":16,"_33":39,"_172":134,"_173":-5,"_174":-5,"_175":-5,"_176":-5,"_177":-5,"_178":14,"_179":12},"isOwned","projectId","forkedBranchId","forkedBranchVersion","forkedProjectPrivacy","forkedProjectId","forkedProjectOrgId","projectName","userHandle","displayName","avatar","https://img.clerk.com/eyJ0eXBlIjoicHJveHkiLCJzcmMiOiJodHRwczovL2ltYWdlcy5jbGVyay5kZXYvb2F1dGhfZ2l0aHViL2ltZ18zOFNJVGp2cEpvRVM0UE5ONldxZWZGcmNOeDMifQ","tier","pro","canRestrictVals","profileImageUrl","adoptOrgId",{"_33":134,"_13":14,"_44":244,"_136":-5,"_137":51,"_138":101,"_139":101,"_140":141,"_142":-5,"_143":144,"_145":75,"_146":43,"_147":-5,"_148":-5,"_149":88,"_150":151,"_152":-5,"_153":-5,"_154":-5,"_155":-5,"_156":157,"_158":157,"_159":160,"_161":160,"_162":160,"_163":157,"_164":157,"_165":245,"_167":246,"_169":247,"_171":51},[217,221,222,223,224,225],"files",[217,218,219,220,221,222,223,224,225],"counts",{"_208":88,"_209":95,"_210":88,"_32":211,"_212":213},[],{"_33":34,"_38":39,"_35":36,"_13":19,"_48":49,"_47":24,"_17":46,"_37":-5,"_44":206,"_40":41,"_52":-5,"_18":207},"upstreamProject","upstreamBranch","emptyEnvVars","flags",[],"hasHttpFiles","grants","orgs","customDomains",{},["D",1788363377561],[19],"pulls","branches","forks",{"_214":88,"_216":88},"connections",{"_214":88,"_215":88},"count","unfilledCount","emptyCount",{"_33":100,"_13":101,"_35":102,"_37":-5,"_38":39,"_40":95,"_42":43,"_44":103,"_17":88,"_47":104,"_48":-5,"_50":51,"_52":-5,"_67":242,"_18":243},{"_33":126,"_13":127,"_35":128,"_37":102,"_38":39,"_40":95,"_42":43,"_44":129,"_17":88,"_47":130,"_48":131,"_50":51,"_52":-5,"_67":240,"_18":241},{"_33":119,"_13":120,"_35":121,"_37":102,"_38":39,"_40":95,"_42":43,"_44":122,"_17":88,"_47":24,"_48":123,"_50":51,"_52":-5,"_67":238,"_18":239},{"_33":110,"_13":111,"_35":112,"_37":102,"_38":39,"_40":113,"_42":43,"_44":114,"_17":115,"_47":24,"_48":116,"_50":51,"_52":-5,"_67":236,"_18":237},{"_33":92,"_13":93,"_35":94,"_37":-5,"_38":39,"_40":95,"_42":43,"_44":96,"_17":88,"_47":24,"_48":97,"_50":51,"_52":-5,"_67":234,"_18":235},{"_33":83,"_13":84,"_35":85,"_37":-5,"_38":39,"_40":86,"_42":43,"_44":87,"_17":88,"_47":24,"_48":89,"_50":51,"_52":-5,"_67":232,"_18":233},{"_33":73,"_13":74,"_35":75,"_37":-5,"_38":39,"_40":76,"_42":43,"_44":77,"_17":78,"_47":79,"_48":80,"_50":51,"_52":14,"_67":230,"_18":231},{"_33":34,"_13":19,"_35":36,"_37":-5,"_38":39,"_40":41,"_42":43,"_44":70,"_17":46,"_47":24,"_48":49,"_50":51,"_52":-5,"_67":228,"_18":229},{"_33":60,"_13":61,"_35":62,"_37":-5,"_38":39,"_40":63,"_42":43,"_44":64,"_17":65,"_47":24,"_48":66,"_50":51,"_52":-5,"_67":226,"_18":227},[],[61],[],[19],[],[74],[],[84],[],[93],[],[101,111],[],[101,120],[],[101,127],[218,219,220],[101],["D",1788348742264],{"_11":12,"_186":182},{"_11":12,"_180":-5,"_181":182,"_143":144,"_183":184,"_185":51},{"_17":63,"_13":16,"_33":39,"_172":134,"_173":-5,"_174":-5,"_175":-5,"_176":-5,"_177":-5,"_178":14,"_179":12},"ctx",{"_165":-5,"_203":281,"_282":283,"_284":285,"_286":51,"_287":51,"_288":51,"_289":43,"_290":-5,"_291":-7,"_292":-7,"_293":88,"_294":51,"_295":51,"_296":-5,"_297":51,"_298":51,"_299":51,"_300":-5},"ENV",{"_252":253,"_254":255,"_256":16,"_257":258,"_259":260,"_261":262,"_263":264,"_265":266,"_267":268,"_269":270,"_271":272,"_273":274,"_275":276,"_277":278,"_279":280},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","e87eb04e707cf64e7e532c8e8ec395f209e17f15","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]