@pikku/skills 0.12.6 → 0.12.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pikku/skills",
-  "version": "0.12.6",
+  "version": "0.12.9",
   "description": "The Pikku agent skills — the instruction set coding agents read to build, wire and deploy Pikku projects",
   "author": "yasser.fadl@gmail.com",
   "license": "MIT",

package/skills/pikku-addon/SKILL.md

@@ -50,9 +50,13 @@ wireAddon({
   mcp?: boolean,
   tags?: string[],                 // Tags applied to all addon functions
   scopes?: string[],               // Required of every function, on top of its own
-  secretOverrides?: Record<string, string>,      // Remap secret names
+  secretOverrides?: Record<string, string>,      // Remap secret names (and grant them)
   variableOverrides?: Record<string, string>,    // Remap variable names
-  credentialOverrides?: Record<string, string>,  // Remap credential names
+  credentialOverrides?: Record<string, string>,  // Remap credential names (and grant them)
+  secretGrants?: string[],                       // Secrets the app lends this addon
+  credentialGrants?: string[],                   // Credentials the app lends this addon
+  globalSecrets?: string,                        // Reason for handing over the whole SecretService
+  globalCredentials?: string,                    // Reason for handing over the whole CredentialService
 })
 ```
 
@@ -61,6 +65,58 @@ it would weaken the wiring's own gate — so the addon-level setting can require
 session but never waive one. The same package wired twice under two namespaces is
 governed by the union of both instances' scopes and tags.
 
+### An addon reads only the secrets it declared
+
+An addon's `SecretService` and `CredentialService` are **scoped**: it may read
+the secrets its own source declares (literal `getSecret('X')` calls and
+`wireSecret` definitions, which the CLI collects into `declaredSecrets`) and
+nothing else. Anything undeclared throws `Access denied to secret key: X` at
+runtime. The same holds for credentials, and a scoped addon can never call
+`getAllUsers()`.
+
+That works for an addon naming its own secrets. It does not work for a _generic_
+addon whose secret names arrive as data — `@pikku/addon-graph` reads
+`getSecret(auth.credential)`, where the name comes off the workflow node — so
+such an addon declares nothing and is scoped to nothing. Only the consuming app
+can widen it, with one of three fields:
+
+```typescript
+wireAddon({
+  name: 'graph',
+  package: '@pikku/addon-graph',
+
+  secretGrants: ['STRIPE_KEY'], // lend these, unrenamed
+  secretOverrides: { MAILGUN_KEY: 'PROD_EMAIL_KEY' }, // lend + rename
+  // globalSecrets: 'why no static list can cover it' // lend everything
+})
+```
+
+| field             | meaning                                 |
+| ----------------- | --------------------------------------- |
+| `secretOverrides` | grant **and** rename                    |
+| `secretGrants`    | grant as-is                             |
+| `globalSecrets`   | grant everything, with a written reason |
+
+**Grants name the secret as the addon reads it**, not as your project stores it.
+Scoping is checked _before_ the override map renames anything, so an overridden
+secret is granted by its addon-side key — which is also why an override's key
+grants and its value does not. With no rename in play the two names coincide.
+
+`globalSecrets` / `globalCredentials` take the _reason_ for the grant, not a
+boolean, because every grant is enumerated in the deploy manifest
+(`unscopedSecretAddons`, `grantedSecretAddons`). Prefer `secretGrants` — reach
+for `globalSecrets` only when no static list can exist, and never for an addon
+that performs outbound requests, where an unrestricted secret read is an
+exfiltration primitive.
+
+A grant naming a secret your project does not declare is a build error from
+`pikku all`, resolved through the override map first:
+
+```
+Secret grant 'STIRPE_KEY' in addon 'graph' (@pikku/addon-graph) targets a secret
+that does not exist. Available secrets: BETTER_AUTH_SECRET, GITHUB_OAUTH
+```
+
 ### `ref(name)`
 
 Type-safe reference to a function — local or addon — for use in any wiring. It
@@ -94,7 +150,8 @@ import { pikkuAddonServices } from '#pikku'
 
 export const createSingletonServices = pikkuAddonServices(
   async (config, { secrets, logger }) => {
-    const creds = await secrets.getSecret<GithubCredentials>('GITHUB_CREDENTIALS')
+    const creds =
+      await secrets.getSecret<GithubCredentials>('GITHUB_CREDENTIALS')
     return { github: new GithubService(creds.reveal()) }
   }
 )
@@ -184,11 +241,24 @@ approvalDescription: async (_services, { title }) => `Add a todo called "${title
 ### Build
 
 ```bash
-npx pikku all    # Generate types
-yarn tsc         # Compile TypeScript
-cp -r .pikku dist/  # Include generated files in dist
+yarn pikku all          # Generate types
+yarn tsc                # Compile TypeScript
+cp -r .pikku types dist/  # Ship the generated files and the types they import
+yarn pikku validate     # Check the published file set holds together
 ```
 
+`yarn pikku`, not `npx pikku`: a scaffolded addon carries `@pikku/cli` as a
+devDependency, and building it against a different CLI than it declares is how
+generated output ends up disagreeing with the packaged one. `npx pikku new
+addon` above is the exception — it runs before the addon, and its CLI, exist.
+
+`types/` has to be copied alongside `.pikku`: the generated files import
+`SingletonServices`, `Services`, `Config` and `UserSession` from
+`../../types/application-types.d.js`, and `tsc` never emits a hand-written
+`.d.ts` to `outDir`, so nothing else puts it in `dist`. Leave it out and the
+addon installs fine and fails to typecheck in every app that depends on it —
+which is what `pikku validate` is there to catch before you publish.
+
 ## Consuming an Addon
 
 ### Install & Register
@@ -204,7 +274,7 @@ import { wireAddon } from '#pikku'
 wireAddon({ name: 'todos', package: '@my-org/addon-todos' })
 ```
 
-After registration, run `npx pikku all` to generate types for the addon's functions.
+After registration, run `yarn pikku all` to generate types for the addon's functions.
 
 ### Call via RPC
 

package/skills/pikku-concepts/SKILL.md

@@ -230,7 +230,7 @@ await server.start()
 
 **Lifecycle hooks do not run on this path** — only `pikku dev` and `pikku serve` invoke them. Do your startup work directly in the entrypoint instead.
 
-`pikku workspace validate` warns when a project starts a server by hand *and* depends on no runtime adapter, since that combination means path 1 was available and unused. Silence it with `"lint": { "customServerBootstrap": "off" }` in `pikku.config.json`.
+`pikku validate` warns when a project starts a server by hand *and* depends on no runtime adapter, since that combination means path 1 was available and unused. Silence it with `"lint": { "customServerBootstrap": "off" }` in `pikku.config.json`.
 
 ## Code Generation
 

package/skills/pikku-config/SKILL.md

@@ -243,7 +243,7 @@ const apiKey = services.variables.get('API_KEY')
 }
 ```
 
-`customServerBootstrap` is the one evaluated by `pikku workspace validate` rather than codegen: it warns when the root `start`/`dev` script boots a server without `pikku dev` / `pikku serve` and no runtime adapter is installed. Set it to `"off"` to keep a hand-rolled entrypoint, or `"error"` to enforce the hooks.
+`customServerBootstrap` is the one evaluated by `pikku validate` rather than codegen: it warns when the root `start`/`dev` script boots a server without `pikku dev` / `pikku serve` and no runtime adapter is installed. Set it to `"off"` to keep a hand-rolled entrypoint, or `"error"` to enforce the hooks.
 
 ## Complete Example
 

package/skills/pikku-knowledge/SKILL.md

@@ -5,13 +5,14 @@ description: >-
   notes that say what the app is, in the language its users use. Covers the Open Knowledge Format
   note (path-as-identity markdown, YAML frontmatter, only `type` required), the sections of the
   app-project profile (slices, entities, decisions, questions, wishlist) and the one question each
-  answers, slice status/entities/gherkin rules, the `resource:` URI scheme that ties a note to the
+  answers, slice status/entities/gherkin rules, the `resource:` URI scheme tying a note to the
   code it is about, the shapes that are NOT a knowledge base, and the `pikku knowledge
-  validate|index` commands. TRIGGER when: user asks to write down a decision, a requirement, an
-  entity or an open question; asks what the app does or is; asks about knowledge/, notes, slices,
-  or an index.md; or hands over a product brief to record. DO NOT TRIGGER when: user asks what
+  validate|index` commands. TRIGGER when: user asks to write down a decision, requirement, entity
+  or open question; asks what the app does or is; asks about knowledge/, notes, slices,
+  an index.md, or a diagram, callout or decision block; or hands over a product
+  brief to record. DO NOT TRIGGER when: user asks what
   functions, routes, tables or permissions exist (that is `pikku meta` / `pikku info`, never a
-  note), or asks to write a scenario test (use pikku-scenario).
+  note), or to write a scenario test (use pikku-scenario).
 installGroups: [core]
 ---
 
@@ -142,7 +143,49 @@ And writing again replaces it rather than adding a second
 
 - **`status`** is `proposed` → `dispatched` → `built`. Nothing else. Every gate compares it literally.
 - **`entities`** lists what the slice touches, **at most three**. Past three it is not one buildable piece — split it.
-- **The scenario is a fenced `gherkin` block, in the third person.** `Given 'owner' has no entry` — never `Given I have no entry`. A quoted word _means a persona_, which is what lets a reader (and a test) tell who is acting. First person hides that, so it is rejected.
+- **The scenario is a fenced `gherkin` block, in the third person.** `Given 'owner' has no entry` — never `Given I have no entry`. A quoted word _means a persona_, which is what lets a reader (and a test) tell who is acting. First person hides that, so it is rejected. The console draws the keywords as a column and each quoted persona as a chip, so a first-person scenario is visibly a block with no personas in it.
+
+## Showing it
+
+A note is markdown, and four kinds of block are **drawn** rather than printed. Every one of them degrades to something readable — a diagram falls back to its source, a callout to a blockquote, a decision to a code block — so writing one costs nothing where it is not rendered.
+
+None of this changes the governing rule. A diagram of the schema is still a copy of `pikku meta` that drifts, and it drifts while looking more authoritative than prose would. These are for the part no generator can derive.
+
+**```mermaid — when the relationship is the point.** Prose is bad at graphs: "an entry belongs to a day, a day belongs to an owner, and a grant lets another owner read a day" is a sentence a reader has to re-read twice and draw themselves. Reach for one when a note is about how several things relate, an order of steps across time, or a state machine. Do not draw one thing, or two things and an arrow — that is a sentence.
+
+````markdown
+```mermaid
+flowchart LR
+  owner -->|writes| entry
+  entry -->|belongs to| day
+  owner -->|grants read on| day
+```
+````
+
+**`> [!NOTE]` — when a line must survive skimming.** Five kinds: `NOTE`, `TIP`, `IMPORTANT`, `WARNING`, `CAUTION`. Use one for the thing a reader who skips the paragraph must still not miss — a trap, a constraint that is easy to violate, an assumption the rest of the note rests on. Two callouts in a note is normal; six means the note has no prose left and nothing stands out.
+
+```markdown
+> [!WARNING]
+> A grant is checked on every request, not cached. A permission change is
+> immediate everywhere, and there is no invalidation step to forget.
+```
+
+**```decision — the answer a decision note owes.** `decisions/` answers "what was chosen, and what does that rule out?", and the second half is the half that gets dropped. The fence makes it checkable: `pikku knowledge validate` warns when a fence says what was chosen and never says what it closes off.
+
+````markdown
+```decision
+chosen: A revoked grant stops working immediately, everywhere.
+rules-out:
+  - A "revoked but valid until midnight" state
+  - A scheduled cleanup job
+because: Two people disagreeing about who can see today is worse than one of
+  them losing access mid-session.
+```
+````
+
+It is a **summary, not the note** — the argument continues in prose underneath. `rules-out:` takes one line or a `- item` block, and any value too long for one line wraps onto indented lines under it, as `because:` does above. A decision genuinely argued in prose needs no fence, and validate never asks for one; what it does ask is that a fence you did write is complete.
+
+**Fences of any other language are code** — highlighted and copyable, which is right for a snippet and wrong for a scenario or a decision, so do not put either in a bare fence.
 
 ## `resource:` — tying a note to the code
 
@@ -196,7 +239,7 @@ pikku knowledge index           # refresh every index.md
 pikku knowledge index --check   # report stale indexes without writing (CI gate)
 ```
 
-`validate` reports: notes with no `type`, a missing `knowledge/index.md`, a section with no `index.md`, notes flat at the root, sections that duplicate what the project already declares, slices with a bad or missing `status`, slices over three entities, slices with no gherkin block or a first-person one, and every `resource:` that no longer resolves. Errors fail the command; warnings do not.
+`validate` reports: notes with no `type`, a missing `knowledge/index.md`, a section with no `index.md`, notes flat at the root, sections that duplicate what the project already declares, slices with a bad or missing `status`, slices over three entities, slices with no gherkin block or a first-person one, `decision` fences that state no `chosen:` or rule nothing out, and every `resource:` that no longer resolves. Errors fail the command; warnings do not.
 
 `index` rewrites only the block between `<!-- pikku:knowledge-index -->` markers, creating a scaffolded `index.md` for a section that has none. It is idempotent — running it twice changes nothing.
 

package/skills/pikku-scenario/SKILL.md

@@ -5,7 +5,7 @@ description: >-
   test coverage. A scenario (pikkuScenario) drives the app the way users do — steps run as actors
   over the real transport against a running server — so a flow doubles as an e2e test and a
   staged/production health check. Covers scenario.do / expectEventually / expectError /
-  expectService, declared steps via pikkuScenarioStep (including browser steps driven by
+  expectService / expectScore, declared steps via pikkuScenarioStep (including browser steps driven by
   @pikku/playwright) written as intent rather than as clicks, with the actions factored into
   shared browser utilities, actors and environments in pikku.config.json, SCENARIO_ACTOR_SECRET, the
   `pikku scenario list|run` commands, live function coverage via `pikku dev --coverage`, and
@@ -91,6 +91,7 @@ A scenario takes the same config fields as a workflow (`title`, `description`, `
 | `scenario.expectEventually(step, rpc, data, predicate, { actor, within, interval })` | Poll until `predicate(out)` passes or `within` elapses. For anything asynchronous — queues, workers, eventual state.   |
 | `scenario.expectError(step, rpc, data, { actor, matches })`                          | Assert the call **fails**. For fault injection and negative paths.                                                     |
 | `scenario.expectService(step, 'service.method', { actor, calledWith })`              | Assert a stubbed service was called. Requires the server to run with `--test`.                                         |
+| `scenario.expectScore(step, runId, scorer, { atLeast, atMost, reference })`          | Grade a finished agent run with a declared scorer and assert the score. See below.                                     |
 | `scenario.given(stepName, step, data, { actor })`                                    | Run a declared `pikkuScenarioStep` as setup. `when` is the same call; `then` also makes the step's bindings witnesses. |
 | `scenario.runScheduledTask(name)`                                                    | Fire a wired scheduler on the target now, rather than waiting for its cron.                                            |
 
@@ -98,6 +99,37 @@ A scenario takes the same config fields as a workflow (`title`, `description`, `
 
 Prefer `expectEventually` over sleeping.
 
+### Asserting on an agent's answer (`expectScore`)
+
+An agent's output is not comparable to a fixed string, so it is graded rather
+than matched. Declare the rubric with `pikkuAIScorer` (grades in code) or
+`pikkuAIJudge` (grades with a model) in a `*.scorer.ts` file, name it on the
+agent's `scorers`, then assert on the run the scenario just triggered:
+
+```typescript
+const { runId } = await scenario.when('asks for a summary', 'runAssistant', {
+  prompt: data.prompt,
+}, { actor: actors.user })
+
+await scenario.expectScore('answered briefly', runId, 'brevity', { atLeast: 0.8 })
+```
+
+The default bound is `atLeast: 0.5`, so an unqualified `expectScore` still fails
+a run the scorer graded zero. `atMost` is for a rubric where high is the failure
+(sycophancy, verbosity). `reference` supplies the answer key a
+`requiresReference` judge grades against — live traffic has none, so such a
+judge is only ever reachable from a scenario.
+
+Grading goes through the `pikkuScenarioGradeRun` instrumentation RPC on the
+server under test, which grades from the snapshot the runtime kept at the end of
+the run. Two consequences: the run must have happened on **that** server and be
+recent, and the grade is returned to the scenario rather than recorded — a
+test's score never lands among the production figures. Sampling is ignored, so a
+scorer set to grade 1% of live traffic still grades every scenario run.
+
+Tag any scenario whose scorer is a judge `ai-live`: it costs a model call, and
+the default suite excludes it.
+
 ### Setup and teardown (`before` / `after`)
 
 A scenario config takes `before` and `after`. Both have the **same signature as `func`** — `(services, data, wire)` — with the return value discarded:

package/skills/pikku-workflow/SKILL.md

@@ -29,11 +29,11 @@ Build durable, multi-step workflows with automatic retry, sleep, suspend/resume,
 
 ## Choosing the right factory
 
-| Factory | When to use | Step-graph view? |
-|---|---|---|
-| `pikkuWorkflowFunc` | **Default for all new workflows.** Sequential + conditional logic; DSL mode (serialisable, replay-safe). ALL `const`/`let` declarations must be at the top level of the function body (not inside blocks). | ✅ Yes |
-| `pikkuWorkflowGraph` | DAG / fan-out with nodes and typed refs between them. | ✅ Yes |
-| `pikkuWorkflowComplexFunc` | Escape hatch only — arbitrary TypeScript, no top-level restriction (e.g. dynamic inline functions the DSL extractor cannot handle). | ❌ No (loses step-graph view) |
+| Factory                    | When to use                                                                                                                                                                                                | Step-graph view?              |
+| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
+| `pikkuWorkflowFunc`        | **Default for all new workflows.** Sequential + conditional logic; DSL mode (serialisable, replay-safe). ALL `const`/`let` declarations must be at the top level of the function body (not inside blocks). | ✅ Yes                        |
+| `pikkuWorkflowGraph`       | DAG / fan-out with nodes and typed refs between them.                                                                                                                                                      | ✅ Yes                        |
+| `pikkuWorkflowComplexFunc` | Escape hatch only — arbitrary TypeScript, no top-level restriction (e.g. dynamic inline functions the DSL extractor cannot handle).                                                                        | ❌ No (loses step-graph view) |
 
 **Default to `pikkuWorkflowFunc`.** Use `pikkuWorkflowGraph` ONLY with explicit user approval AND only for a genuine cyclic dependency or Node.js-only import DSL cannot express. Use `pikkuWorkflowComplexFunc` ONLY with explicit user approval — a last-resort escape hatch. Never switch to either just to dodge a PKU641 error; restructure the code instead.
 
@@ -58,7 +58,11 @@ if (priority === 'high') {
 
 ```typescript
 // CORRECT — workflow factories come from the generated types file
-import { pikkuWorkflowFunc, pikkuWorkflowGraph, pikkuWorkflowComplexFunc } from '#pikku/workflow/pikku-workflow-types.gen.js'
+import {
+  pikkuWorkflowFunc,
+  pikkuWorkflowGraph,
+  pikkuWorkflowComplexFunc,
+} from '#pikku/workflow/pikku-workflow-types.gen.js'
 
 // WRONG — '#pikku' does not re-export them (TS2305)
 import { pikkuWorkflowFunc } from '#pikku'
@@ -73,7 +77,10 @@ import { z } from 'zod'
 import { pikkuWorkflowFunc } from '#pikku/workflow/pikku-workflow-types.gen.js'
 
 const ProcessOrderInput = z.object({ orderId: z.string(), amount: z.number() })
-const ProcessOrderOutput = z.object({ status: z.string(), discount: z.number().optional() })
+const ProcessOrderOutput = z.object({
+  status: z.string(),
+  discount: z.number().optional(),
+})
 
 export const processOrder = pikkuWorkflowFunc({
   description: 'Process an order through payment and fulfillment',
@@ -86,7 +93,9 @@ export const processOrder = pikkuWorkflowFunc({
     let status: string
 
     if (data.amount > 1000) {
-      const d = await workflow.do('Apply bulk discount', 'calcDiscount', { amount: data.amount })
+      const d = await workflow.do('Apply bulk discount', 'calcDiscount', {
+        amount: data.amount,
+      })
       discount = d.discountPercent
     }
 
@@ -129,6 +138,65 @@ await workflow.approval('Manager sign-off', { ... })
 `workflow.name`, `workflow.runId` and `await workflow.getRun()` identify the
 current run if a step needs to reference it.
 
+### Approval gates: who may answer
+
+`workflow.approval(reason, options)` takes a `schema` (a runtime value — the
+payload arrives from an untrusted caller, so a type generic would validate
+nothing), an optional `expiry`, and an optional policy for **who** may answer:
+
+```typescript
+const signOff = await workflow.approval('Manager sign-off', {
+  schema: SignOffSchema,
+  expiry: '3d',
+  approvers: 'not-initiator',      // four-eyes: anyone but whoever started the run
+  approverScope: 'payments:approve', // and they must hold this scope
+})
+if (signOff.status === 'expired') { ... }
+```
+
+`approvers` is one of:
+
+| value             | who may answer                                                                                           |
+| ----------------- | -------------------------------------------------------------------------------------------------------- |
+| `any` _(default)_ | anyone the approve entrypoint admits — the gate is a pause for a decision, not an authorization boundary |
+| `owner`           | only the user who started the run                                                                        |
+| `not-initiator`   | anyone **except** the user who started the run                                                           |
+
+Both options are enforced in two phases, because a decision can legitimately
+arrive before the run has reached the gate:
+
+- **At submission**, if the run has already reached the gate. Reaching it
+  publishes the policy into the run state, so the approve entrypoint can judge
+  the caller against it and refuse with a **403**.
+- **On replay**, for a decision that arrived before the gate — there was no
+  policy to judge it against yet, so it is accepted and judged when the workflow
+  reaches the gate. Failing there discards the decision and leaves the gate
+  closed, exactly as a decision that fails the schema does.
+
+So the same rejected decision surfaces as an HTTP error or as a silently
+re-closed gate depending on timing. Both are audited.
+
+A gate declaring neither option accepts a decision from anyone the approve
+route lets through; gate the route with `auth`/`permissions` to narrow that.
+
+#### What survives the run
+
+A settled decision carries `decidedBy` and `decidedAt`, so the answer keeps its
+provenance in the step result:
+
+```typescript
+if (signOff.status === 'decided') {
+  logger.info(`signed by ${signOff.decidedBy?.userId} at ${signOff.decidedAt}`)
+}
+```
+
+That record is deleted with the run, though — `deleteRun` cascades to steps and
+history — and an attempt that was _refused_ never reaches a step at all. So
+every answer is also written to the audit sink as `workflow.approval.decided`,
+with `outcome: 'success' | 'denied'`, the decider under `userIdentity`, and the
+run, reason and refusal in `metadata`. Wire an `audit` service to keep it; a
+project without one records nothing and is otherwise unaffected.
+
 ### Error handling: `onError`, never try/catch
 
 **Do not wrap steps in try/catch.** The DSL extractor serialises the body into a
@@ -137,14 +205,19 @@ graph would no longer describe what actually runs, which is the whole point of
 the DSL mode. This is a settled design decision, not a temporary limitation.
 
 Use the `onError` step option instead: it names an RPC to invoke when the step
-has failed *after* exhausting its retries.
+has failed _after_ exhausting its retries.
 
 ```typescript
-await workflow.do('Charge', 'chargePayment', { orderId }, {
-  retries: 3,
-  retryDelay: '1s',
-  onError: 'refundReservation',   // compensation RPC
-})
+await workflow.do(
+  'Charge',
+  'chargePayment',
+  { orderId },
+  {
+    retries: 3,
+    retryDelay: '1s',
+    onError: 'refundReservation', // compensation RPC
+  }
+)
 ```
 
 The handler receives `{ error: { message } }`, and the original error is still
@@ -161,7 +234,9 @@ Full step options: `description`, `retries`, `retryDelay`, `onError` (plus
 
 ```typescript
 const users = await Promise.all(
-  data.userIds.map((userId) => workflow.do(`Fetch user ${userId}`, 'getUser', { userId }))
+  data.userIds.map((userId) =>
+    workflow.do(`Fetch user ${userId}`, 'getUser', { userId })
+  )
 )
 ```
 
@@ -182,7 +257,10 @@ export const userOnboarding = pikkuWorkflowGraph({
   config: {
     createProfile: { next: ['sendWelcome', 'setupDefaults'] }, // run in parallel
     sendWelcome: {
-      input: (ref) => ({ to: ref('createProfile', 'email'), subject: 'Welcome!' }),
+      input: (ref) => ({
+        to: ref('createProfile', 'email'),
+        subject: 'Welcome!',
+      }),
     },
   },
 })