@pikku/core 0.12.71 → 0.12.74

package/knowledge/decisions/security/queue-jobs-carry-the-producers-pikku-user-id.md

@@ -0,0 +1,39 @@
+---
+type: decision
+title: Queue jobs carry the producer's pikku user id
+description: A job's pikkuUserId is trusted as identity by the worker, so enqueue rights are effectively act-as-user rights
+tags: queue
+---
+
+# Queue jobs carry the producer's pikku user id
+
+`JobOptions.pikkuUserId` (`packages/core/src/wirings/queue/queue.types.ts`) is
+set by whoever enqueues the job. The adapter surfaces it as
+`QueueJob.pikkuUserId`, `runQueueJob` in
+`packages/core/src/wirings/queue/queue-runner.ts` copies it onto the wire as
+`PikkuQueue.pikkuUserId`, and `resolveSession` in
+`packages/core/src/function/function-runner.ts` then resolves it through
+`defaultPikkuUserIdResolver` and loads that user's session out of the
+`sessionStore`. The worker function runs with that session.
+
+The claim is now HMAC-signed at enqueue and verified in `runQueueJob` — see
+[[queue-job-identities-are-signed-at-enqueue]], which supersedes the "any
+producer may name any user" reading below. Everything here still holds for the
+*authorization* question: signing proves the producer held the deployment
+secret, not that it was entitled to name that user.
+
+There is no re-authentication at the worker boundary — the queue payload *is* the
+credential. Workers run with `auth: false`, so nothing downstream re-checks that
+the producer was entitled to name that user. This is deliberate: the whole point
+is to let a background job resolve the same per-user credentials the original
+request had, without persisting a token in the queue. The cost is that write
+access to the queue is equivalent to being able to act as any user whose session
+is in the store.
+
+**What this rules out:** exposing job enqueue to untrusted callers, or letting a
+client-supplied field flow into `JobOptions.pikkuUserId` without an authorization
+check first. It also rules out treating the queue as an authorization boundary —
+do not add a "the worker validated the producer's rights" assumption anywhere
+downstream, and do not drop the id from the wire on the theory that workers are
+unauthenticated anyway. Dropping an id that fails *signature* verification is a
+different matter and is what the worker now does.

package/knowledge/decisions/security/remote-addon-tokens-are-client-credentials-not-mesh-trust.md

@@ -0,0 +1,34 @@
+---
+type: decision
+title: Remote addon tokens are client credentials, not mesh trust
+description: wireRemoteAddon authenticates as a client to a hosted library and fails closed on an empty token; it never uses PIKKU_REMOTE_SECRET
+tags: rpc
+---
+
+# Remote addon tokens are client credentials, not mesh trust
+
+`resolveRemoteAddonToken` in
+`packages/core/src/wirings/rpc/remote-addon-auth.ts` resolves the bearer token a
+`wireRemoteAddon` consumer sends to the host. This is a **client** authenticating
+to a hosted library — it is not pikku's trusted machine-to-machine mesh, which
+uses `PIKKU_REMOTE_SECRET`. Conflating the two would hand a third-party addon
+host a credential that grants mesh-level trust inside the consumer's own
+deployment.
+
+The consumer binds the addon's declared auth requirement to one of three local
+sources: `credentialId`, a per-user credential read through `wire.getCredential`
+and therefore scoped to `pikkuUserId`; `secretId`, a platform key from the
+secrets service; or `resolve`, a custom escape hatch. The resolved token is never
+logged or traced. Binding a `credentialId` without a wire that supports
+credentials throws rather than falling back to a shared secret.
+
+Resolution fails closed. `null` is returned only when no auth is bound at all,
+which is the addon declaring its remote surface public. Once auth *is* bound, a
+resolved value of `null`, `undefined` or `''` raises `RemoteAddonAuthError` (401)
+instead of dispatching an unauthenticated request that the host might accept as
+anonymous.
+
+**What this rules out:** defaulting to `PIKKU_REMOTE_SECRET` or any ambient
+credential when the bound source comes up empty, treating an empty token as
+"public", and adding the token to log lines, trace headers or error messages for
+debugging.

package/knowledge/decisions/security/scaffold-features-are-authenticated-unless-opted-out.md

@@ -0,0 +1,49 @@
+---
+type: decision
+title: A scaffolded surface is authenticated unless the config opts out in writing
+description: scaffold.<feature> became boolean | { auth, path }, where true means authenticated — going public requires typing { auth: false }, and the legacy 'auth' | 'no-auth' strings are refused rather than coerced
+tags: config, authorization, codegen, scaffold
+---
+
+# A scaffolded surface is authenticated unless the config opts out in writing
+
+`scaffold.<feature>` was `'auth' | 'no-auth' | false`. Two things were wrong
+with it, and they compounded.
+
+The auth dimension asked the wrong question of some features and the right one
+of others. For `rpc` it is a blanket "no anonymous RPC in this app", set on a
+dispatcher that cannot know what it dispatches to — wrong the moment one
+legitimately public sessionless function exists. For `userAdmin` it was
+redundant: the generated functions are `pikkuFunc` with `scopes:
+['admin:users:list']`, gated twice over already. But for `agent`, `workflow`,
+`events` and `scenarios` it was the *only* gate, because those generate real
+endpoints the app never authors and has nowhere else to declare a gate for.
+A uniform collapse to boolean would have silently opened four surfaces.
+
+And the value read like a preference. `"rpc": "no-auth"` looks like a
+starter-file setting; it was a live authorization decision, three directories
+from the functions it governed. That is the shape the console incident took.
+
+The type is now `boolean | { auth?: boolean; path?: string }`. `true` means
+enabled **and authenticated**; a surface becomes public only by writing
+`{ auth: false }`. Omitting a field can then never open anything — the failure
+mode of a forgotten flag is a locked door. Features with no auth dimension
+(`webhook`, `remoteRpc`, whose generator hardcodes `auth: false`) simply ignore
+it.
+
+The object form is also what makes the legacy strings safe to remove. An
+earlier design used `string` for the output path, under which `"no-auth"` would
+have parsed as *a file named `no-auth`* — every unmigrated config silently
+producing nonsense instead of failing. With `boolean | object`, a string is
+never valid, so `resolveScaffoldFeature` refuses `'auth'` and `'no-auth'` by
+name and prints the replacement. Coercing them was rejected outright: the value
+it would coerce to is the one that caused the incident.
+
+Reading happens once, in `pikku-cli-config.ts`, so a legacy value fails at load
+with the migration named rather than downstream where it has already become
+something plausible.
+
+**What this rules out:** a bare `true` that means "public"; inferring a
+feature's auth posture from its default; using `string` for the output path
+while the legacy string values still exist in the wild; and collapsing the auth
+dimension uniformly across features that do not all have one.

package/knowledge/decisions/security/scenario-step-functions-are-never-externally-invocable.md

@@ -0,0 +1,30 @@
+---
+type: decision
+title: Scenario-step functions are never externally invocable over RPC
+description: rpcExposed requires expose and rejects scenarioStep, so test steps stay reachable only from inside a scenario run
+tags: rpc
+---
+
+# Scenario-step functions are never externally invocable over RPC
+
+`ContextAwareRPCService.rpcExposed` in
+`packages/core/src/wirings/rpc/rpc-runner.ts` is the entry point for RPCs that
+arrive from outside the process. It resolves the function's meta and throws
+`RPCNotFoundError` unless `functionMeta.expose` is set **and**
+`functionMeta.scenarioStep` is falsy — the same 404 an unknown name gets, so the
+existence of a hidden function is not disclosed.
+
+A scenario step is a piece of a test scenario: it may drive a browser, assert
+against fixtures, or reach for privileged setup helpers. Steps are dispatched by
+name from inside a scenario run through the internal `rpc` path, which does not
+consult `expose`. If a step were also reachable from the outside, any caller who
+guessed its name would get an unauthenticated handle on test tooling in whatever
+environment the scenario code shipped to.
+
+The two conditions are independent and both required: `expose` opts a function
+into the external surface, `scenarioStep` opts it back out regardless.
+
+**What this rules out:** collapsing the check to `!functionMeta.expose`,
+returning a distinct "forbidden" error that confirms the name exists, and routing
+external traffic through `rpc` instead of `rpcExposed` for convenience — `rpc`
+performs no exposure check at all.

package/knowledge/decisions/security/scope-resolution-happens-at-the-session-boundary-and-sync-never-deletes.md

@@ -0,0 +1,28 @@
+---
+type: decision
+title: Scope resolution happens at the session boundary and scope sync never deletes
+description: ScopeService is called when a session is built, never by the function runner, and syncScopes only ever adds — revoking is an explicit operation
+tags: services
+---
+
+# Scope resolution happens at the session boundary and scope sync never deletes
+
+Implementations of `ScopeService` (`packages/core/src/services/scope-service.ts`)
+are called at the session boundary — better-auth's `mapSession`, for instance —
+and never by the function runner. The runner reads `session.scopes` and performs
+no I/O of its own, which is what keeps it viable on Workers and Lambda. Because
+the session is rebuilt per request, a scope change takes effect on the next call:
+nothing is cached and there is nothing to invalidate.
+
+`syncScopes` is additive and never deletes. Scopes are declared in code, so a
+declaration removed in a deploy would otherwise revoke a live grant the moment
+the new build boots — silently, mid-rollout, for everyone holding it. Instead the
+row stays and goes inert: `listScopes` reports it as `declared: false`, no
+function can require it, `findStaleScopes` surfaces it for `pikku scopes audit`,
+and `pikku scopes prune` is the explicit act that removes it.
+
+**What this rules out:** having the function runner resolve scopes per call (it
+would put a store round-trip in every request path and break the Workers/Lambda
+story), caching resolved scopes anywhere, and making `syncScopes` reconcile —
+diffing declared against stored and deleting the difference. A deploy must never
+be able to revoke a grant as a side effect.

package/knowledge/decisions/security/self-authentication-is-declared-not-detected.md

@@ -0,0 +1,34 @@
+---
+type: decision
+title: Self-authentication is declared, not detected
+description: A function that authorizes callers in its own body says so with selfAuthenticated; codegen never tries to infer it
+tags: permissions, codegen
+---
+
+# Self-authentication is declared, not detected
+
+Some functions are genuinely closed while carrying no session, scope or
+permission: a webhook receiver that verifies a signature, a handler that
+redeems a signed invite, an exchange endpoint that validates a token before it
+does anything. Nothing in meta distinguishes those from a function nobody
+remembered to gate, so `validateExposedFunctionsGated` (PKU574) would warn about
+them on every build.
+
+The fix is a declaration — `selfAuthenticated: true` on the function config —
+not analysis of the body. Detection would have to recognise an open-ended set of
+authorization idioms, and it fails in the expensive direction: a body that
+*looks* like it checks something silences the warning for a function that
+checks nothing. A declaration cannot be wrong by accident. Someone typed it,
+it is greppable, and it survives into meta where an audit reads it as what it
+is — a claim by a named author, not an inference.
+
+It carries no runtime effect and grants nothing. Its entire job is to move a
+gate that codegen cannot see into a place where a human can, and to keep PKU574
+worth reading: a warning that is usually wrong stops being read, which costs
+more than the warning ever saved.
+
+**What this rules out:** inferring self-authentication from the function body or
+from what it imports; giving `selfAuthenticated` any runtime meaning (it must
+never be a way to skip a check the runtime would otherwise run); and dropping
+the PKU574 warning instead, which was the alternative that would have left every
+genuinely ungated function silent too.

package/knowledge/decisions/security/signed-content-urls-bind-the-request-path.md

@@ -0,0 +1,37 @@
+---
+type: decision
+title: Signed content URLs bind the request path and verify fail-closed
+description: A signature that only carries timestamps authorizes every asset, and a verifier with no key must refuse rather than allow
+tags: content
+---
+
+# Signed content URLs bind the request path and verify fail-closed
+
+`LocalContent` signs a payload containing the decoded request path, and the
+verifier in `pikku-node-http-server.ts` compares it against the path actually
+requested. `LocalContent` requires a `JWTService` and throws without one; a
+verifier with no key available rejects with 403 rather than allowing the
+request, logging once per process so an attacker-triggerable path cannot flood.
+
+A signature over `{signedAt, expiresAt, notBefore}` alone proves only *when* a
+URL was issued, never *what* it was issued for. Any valid token was a skeleton
+key: swap the pathname from a public thumbnail to a private document and the
+signature still verifies. Timestamps bound the window; only the path binds the
+asset.
+
+The path is the representation both signing entry points can produce and the
+verifier can reconstruct — it sees a request line, and cannot recover the
+bucket/key split from it. `signedContentPath` normalizes both sides identically
+(pathname only, origin and query dropped, `decodeURIComponent` falling back to
+the raw pathname on a malformed escape) so a difference in encoding cannot
+become a difference in verdict.
+
+`pikku serve` and `pikku dev` mint an ephemeral per-process signing key, so
+local content serving works with no configuration without shipping a fail-open
+path. URLs signed by one dev-server process are meaningless to the next, which
+is the correct lifetime for a dev secret.
+
+**What this rules out:** signing a URL without binding it to what it grants;
+returning "valid" from a verifier that could not check anything; normalizing the
+path differently on the two sides; and constructing `LocalContent` without a
+JWT service.

package/knowledge/decisions/security/webhook-bodies-are-signed-before-they-are-enqueued.md

@@ -0,0 +1,25 @@
+---
+type: decision
+title: Webhook bodies are signed before they are enqueued
+description: QueueWebhookService computes the HMAC at enqueue time so the signing key never travels in the queue payload
+tags: services
+---
+
+# Webhook bodies are signed before they are enqueued
+
+`QueueWebhookService.prepareDelivery`
+(`packages/core/src/services/queue-webhook-service.ts`) serialises the payload,
+resolves the signing secret, computes the signature and writes it into the job's
+`headers` — all before `queueService.add` is called. The worker,
+`pikkuWebhookWorkerFunc`, POSTs headers it was handed and never sees a secret.
+
+Signing in the worker instead would mean the key has to reach the worker, and the
+only channel between the two is the queue payload: an SQS body, a Redis value, a
+`jsonb` column, all of which are at rest, replicated, and visible to anyone who
+can read the queue. The signature is not sensitive; the key is.
+
+**What this rules out:** moving signing into the worker so it can re-sign on
+retry, and putting `secret` (or a resolved key of any kind) onto `WebhookJobData`.
+Note the related consequence: because the signature is fixed at enqueue time, a
+key rotated between enqueue and delivery does not change an in-flight job's
+signature — that is intended, not a bug to fix by carrying the key.

package/knowledge/decisions/security/workflow-actor-steps-always-use-the-real-transport.md

@@ -0,0 +1,34 @@
+---
+type: decision
+title: A scenario actor step always goes over the real transport and never through internal dispatch
+description: Internal dispatch would bypass auth middleware and permissions, turning a scenario into a green health check that proves nothing
+tags: workflow
+---
+
+# A scenario actor step always goes over the real transport and never through internal dispatch
+
+When a workflow step carries `options.actor`, `rpcStep` in
+`pikku-workflow-service.ts` calls `actor.invoke(rpcName, data)` — the actor's
+authenticated client, over the real network transport — and never falls back to
+internal dispatch. Internal dispatch skips auth middleware and permission
+checks, so a scenario that "passed" that way would prove only that the function
+body runs, not that the persona is allowed to run it. That is a green health
+check for a system that may be wide open.
+
+For the same reason, actor steps never queue: `rpcStep` short-circuits
+`dispatchStep` to `false` whenever `options.actor` is set. An actor step is an
+outbound HTTP call made by the runner itself, and the actor's session lives in
+this process — a queued worker in another process would have no session to make
+it with. The step is still recorded durably like any RPC step, so replay and
+reporting are unaffected.
+
+Actor identity is process-local by nature. `PikkuScenarioService.runActors` maps
+run id to live authenticated clients (cookie jars), and those ride that map
+only, never the persisted run wire — a serialized session on a durable run row
+would be a credential at rest.
+
+**What this rules out:** adding an "internal dispatch is faster" fast path for
+actor steps, routing an actor step through the queue, serializing actor sessions
+onto the run wire, or letting `actor.invoke` degrade to `rpcWithWire` when the
+transport is unavailable. Each turns an end-to-end authorization test into one
+that cannot fail.

package/knowledge/decisions/security/workflow-approval-payloads-are-validated-on-replay-inside-the-workflow.md

@@ -0,0 +1,40 @@
+---
+type: decision
+title: An approval decision is stored raw and validated on replay, and an invalid one closes the gate rather than failing the run
+description: The schema only exists inside the workflow body, and letting an external payload fail the run would let any caller kill a workflow
+tags: workflow
+---
+
+# An approval decision is stored raw and validated on replay, and an invalid one closes the gate rather than failing the run
+
+`approveStep` in `pikku-workflow-service.ts` is called from outside the workflow
+— an HTTP route, an RPC — where the approval's schema value is not in scope. It
+therefore stores the decision payload raw in run state and does nothing else.
+Validation happens on replay inside `approvalStep`, in the workflow body, which
+is the only place the schema exists.
+
+When validation fails, the bad decision is dropped, the issues are recorded on
+the gate's state record, and a `WorkflowSuspendedException` re-closes the gate.
+The failure stays legible to whoever tries next, and — the security point —
+failing the run instead would let any caller kill a workflow with a malformed
+payload. A later valid decision still lands normally.
+
+`WorkflowApprovalOptions.schema` is a VALUE, not a type generic, for the same
+reason: the payload arrives from an untrusted caller over the approve wire, and
+a generic is erased at compile time, so it would validate nothing. Any
+standard-schema library (zod, valibot, arktype) satisfies it. The contract is
+the `~standard` spec and nothing more: `@pikku/core` deliberately carries no
+zod dependency, which is why `pikku-workflow-service.test.ts` hand-rolls a
+minimal `StandardSchemaV1` rather than importing a validation library.
+
+A decision arriving for a gate that has already resolved is rejected with
+`WorkflowApprovalResolvedError` (409) rather than accepted and dropped. The gate
+caches its outcome as the step result and never re-reads run state, so a
+decision recorded after resolution could not take effect — most obviously when
+it loses the race with expiry — and the approver has to be told their decision
+did not land.
+
+**What this rules out:** validating in `approveStep` (the schema is not there),
+failing the run on an invalid payload, turning `schema` into a type parameter,
+accepting a decision on a resolved gate, or making a resolved gate re-read run
+state so a late decision "wins".

package/knowledge/decisions/security/workflow-queued-steps-rehydrate-their-session-from-the-run-wire.md

@@ -0,0 +1,32 @@
+---
+type: decision
+title: A queued workflow step rehydrates its session from the persisted run wire
+description: The queue job payload is just `{ runId }`, so without threading `pikkuUserId` an authed step sees no session and throws
+tags: workflow
+---
+
+# A queued workflow step rehydrates its session from the persisted run wire
+
+A queued workflow step is executed with the bare job wire — the payload is just
+`{ runId }` (or `{ runId, stepName, rpcName, data, fromStepName }`) — so it
+carries no `pikkuUserId`. `invokeStepRpc` in `pikku-workflow-service.ts`
+therefore merges the run's own `wire.pikkuUserId` into the step wire override
+before calling `rpcWithWire`. Without it, a step written as an authed
+`pikkuFunc` sees no session and fails with "Authentication required" on the
+queued path while passing inline, which is the worst possible split: it looks
+like a transport bug rather than an auth one.
+
+`invokeStepRpc` is shared by the queue executor and the inline executor
+precisely so the two cannot drift. The only thing that differs between
+transports is who calls it, not the call itself. `createWorkflowWire` and
+`runWorkflowJobInner` propagate the same `pikkuUserId` onto the workflow wire
+for the workflow body.
+
+The user id is the only identity carried. It is a reference for credential
+resolution, not a serialized session — the session itself is rehydrated on the
+far side.
+
+**What this rules out:** giving the queued path its own invocation helper,
+dropping the `pikkuUserId` merge because "the wire already has a session"
+inline, or widening the run wire to persist session tokens instead of a user id
+reference.

package/knowledge/decisions/security/workflow-scenario-sessions-are-isolated-per-actor-and-per-scenario.md

@@ -0,0 +1,32 @@
+---
+type: decision
+title: Scenario sessions are isolated per actor and reset between scenarios
+description: One jar per actor keeps two personas from sharing a session; a browser reset keeps one scenario from leaving the next signed in as somebody else
+tags: workflow
+---
+
+# Scenario sessions are isolated per actor and reset between scenarios
+
+`createCookieJar` in `scenario-cookie-jar.ts` holds its `Map` as a closure
+local, so two jars can never share a session. That is precisely what lets one
+scenario sign in as several people without one of them inheriting another's
+session. Every response is read, not just the sign-in, so a cookie the target
+rotates mid-session is followed rather than dropped, and an empty `Set-Cookie`
+value is treated as a deletion — the name is dropped rather than held as a
+cookie whose value says it is gone. The jar also stamps `Origin`, because Better
+Auth rejects a state-changing POST whose Origin does not match its baseURL.
+
+`ScenarioCookieJar.empty` reports a fact about the jar, not about the session: a
+target that sets a CSRF or locale cookie before anyone signs in fills the jar
+without establishing a session. Anything needing to know whether a sign-in
+happened has to track the sign-in itself.
+
+The browser side has the same requirement. `ScenarioBrowserProvider.reset`
+discards every actor's per-scenario state — cookies, storage, open pages — while
+keeping the browser, and is called between scenarios so one scenario cannot
+leave the next signed in as somebody else.
+
+**What this rules out:** hoisting the jar to a module-level or per-service map,
+sharing one jar across actors, reading `Set-Cookie` only from the sign-in
+response, treating `empty === false` as "signed in", or skipping `reset` between
+scenarios as an optimisation.

package/knowledge/decisions/security/workflow-scenario-steps-are-never-network-invocable.md

@@ -0,0 +1,31 @@
+---
+type: decision
+title: A scenario step is never registered as a callable RPC and never dispatched on the queue
+description: A step drives a browser and holds an actor's session, so exposing it as an RPC would put that reach on the network
+tags: workflow
+---
+
+# A scenario step is never registered as a callable RPC and never dispatched on the queue
+
+`ScenarioStepMeta` in `dsl/workflow-dsl.types.ts` is a distinct meta type from
+`RpcStepMeta` on purpose. A scenario step runs locally through `runPikkuFunc`
+and must never be treated as dispatchable on the queue or replay path, nor
+registered as a callable RPC — a browser-driving step must not be
+network-invocable. It executes with a browser handle and an actor's
+authenticated session in hand; exposed as an RPC it would hand a remote caller
+that reach.
+
+`PikkuScenarioService.scenarioStep` reflects this at runtime: it always runs
+through `engine.inlineStep` with `runPikkuFunc`, never through `rpcStep`, so no
+transport is involved. A step declaring `browser: true` is refused outright
+unless both a browser provider is registered and an actor was supplied, with an
+error saying which is missing.
+
+Scenario steps are also modelled as sessionless pikku functions (see
+`scenario-step.test.ts`) because a step is driven by an actor, not by a wire
+session.
+
+**What this rules out:** collapsing `ScenarioStepMeta` into `RpcStepMeta`,
+registering step functions in the RPC map so they "can be tested directly",
+routing a scenario step through `rpcStep`/`dispatchStep`, or defaulting a
+`browser: true` step to run without an actor.

package/knowledge/index.md

@@ -0,0 +1,24 @@
+---
+type: overview
+title: Knowledge
+description: Why @pikku/core is built the way it is — the reasoning that used to live in comments
+---
+
+# Knowledge
+
+Pikku's source says *what* it does. These notes say *why*, for the handful of
+choices where the code alone reads as arbitrary or, worse, reads as a mistake.
+
+The rule that produced this directory: **reasoning never lives in code.** A
+comment that restates the line below it is deleted. A comment that records a
+decision — a constraint, a trade-off, a thing that was tried and failed — moves
+here and gets a name, so it can be linked to and argued with.
+
+Everything mechanical is generated or inspectable: the wirings, the schemas, the
+meta files, the export surface. A note that repeats them is a copy that will
+drift.
+
+<!-- pikku:knowledge-index -->
+- [decisions](decisions/index.md) — a rule that was chosen, and what it rules out
+- [questions](questions/index.md) — something asked and not yet answered
+<!-- /pikku:knowledge-index -->

package/knowledge/questions/index.md

@@ -0,0 +1,15 @@
+---
+type: overview
+title: Questions
+description: Things asked of core and not yet answered
+---
+
+# Questions
+
+Something asked and not yet answered. A question earns a note when the code
+currently makes a choice that nobody has defended — the choice stays, the doubt
+gets recorded.
+
+<!-- pikku:knowledge-index -->
+_Nothing here yet._
+<!-- /pikku:knowledge-index -->

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pikku/core",
-  "version": "0.12.71",
+  "version": "0.12.74",
   "description": "The Pikku runtime — functions, wirings, services, middleware and types",
   "author": "yasser.fadl@gmail.com",
   "license": "MIT",
@@ -27,6 +27,7 @@
     "./workflow/timeline": "./dist/wirings/workflow/run-timeline.js",
     "./workflow/types": "./dist/wirings/workflow/workflow.types.js",
     "./actor-flow": "./dist/wirings/actor-flow/index.js",
+    "./virtual-user": "./dist/wirings/virtual-user/index.js",
     "./channel/local": "./dist/wirings/channel/local/index.js",
     "./channel/serverless": "./dist/wirings/channel/serverless/index.js",
     "./http": "./dist/wirings/http/index.js",
@@ -45,6 +46,8 @@
     "./node": "./dist/wirings/node/index.js",
     "./credential": "./dist/wirings/credential/index.js",
     "./scope": "./dist/wirings/scope/index.js",
+    "./role": "./dist/wirings/role/index.js",
+    "./persona": "./dist/wirings/persona/index.js",
     "./secret": "./dist/wirings/secret/index.js",
     "./variable": "./dist/wirings/variable/index.js",
     "./oauth2": "./dist/wirings/oauth2/index.js",
@@ -55,7 +58,6 @@
     "./services/istanbul-coverage": "./dist/services/istanbul-coverage-service.js",
     "./services/local-content": "./dist/services/local-content.js",
     "./services/temporary-file-service": "./dist/services/temporary-file-service.js",
-    "./services/gopass-secrets": "./dist/services/gopass-secrets.js",
     "./crypto-utils": "./dist/crypto-utils.js",
     "./hmac": "./dist/utils/hmac.js",
     "./internal": "./dist/internal.js",