@voltro/plugin-atlassian 0.35.0 → 0.37.0

package/CHANGELOG.md

@@ -39,6 +39,164 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.37.0] — 2026-08-13
+
+### ⚠ BREAKING
+
+- **@voltro/protocol, @voltro/runtime, @voltro/cli** — A field a procedure's input schema does not declare now REJECTS the call. It used to be discarded and the call ran with what was left.
+
+  The measurement, from a consumer's root layout:
+
+  ```ts
+  query?.('userSettings.list', { employeeId })
+  ```
+
+  That procedure declares `userId` / `userIdIn`. Effect's default `onExcessProperty: 'ignore'` decoded the payload to `{}` — not reasoned, measured:
+
+  ```ts
+  decodeUnknownSync(Struct({ userId: optional(String) }))({ employeeId: 'e' })  // → {}
+  ```
+
+  An empty input to a LIST query is not a narrower filter, it is the ABSENCE of one. Their admin, signed in as `2d0add2c…`, was served the settings row of `4410c2f8…` — another user's language and theme in the first paint, with nothing in any log to say so.
+
+  **Why refuse rather than warn.** The decoder cannot tell a projection field from a FILTER field, and that asymmetry is the whole risk: dropping an unknown `include` costs a caller some data, dropping an unknown `tenantId` hands them somebody else's. Nothing at decode time distinguishes the two, so the safe direction is the only one available — the same fail-closed reasoning as the row filter's refusal, one layer up. A warning would have to be read by someone, in a log, after the wrong rows were already served.
+
+  The typed loader query that shipped in 0.36.0 closes the same hole for callers we compile. This closes it for the ones we do not: a plain `fetch`, a curl, a still-cached bundle after a field rename, and every untyped caller.
+
+  Three things measured rather than assumed, because none follows from the annotation's name: it propagates into NESTED structs, through every member of a UNION, and leaves a non-struct payload (`Schema.Void`, a scalar) alone.
+
+  **`Schema.Struct({})` needed a filter, and only a real process showed it.** The fixture's `notes.list` declares an empty input; `POST /rpc` with `{ employeeId }` came back `200` with a snapshot, which for twenty minutes read as the whole change having failed. An empty `TypeLiteral` has no property signatures, so Effect has no expected key set for a key to be excess OF — self-consistent, and the wrong answer here, because `input: Schema.Struct({})` is the STRONGEST declaration a procedure can make and it was the one shape that accepted everything. It gets an explicit predicate now; `Schema.Record` keeps its open key set, because there the openness is declared.
+
+  **Verified against a running `voltro serve`, not only in units.** A declared input succeeds and inserts its row; an undeclared field is refused naming the key and the accepted set. The refusal arrives on the channel a payload decode failure ALREADY used — a missing required field produces the same `Die` with a `ParseError` message — so this adds no new error shape for a client to handle, it moves one case onto the channel the sibling case was always on.
+
+  `strictInput` lives in one module and every `Rpc.make` payload in `@voltro/protocol` goes through it — query, mutation, action, stream, event, plus the workflow start on both the server lifter and the browser-loaded rpc group. `strictInput.test.ts` asserts that SET by scanning the source, not the five lifters somebody remembered: a rule applied at the sites you can list is the shape that let `bootStoreCodec` be fixed twice and break a third time.
+
+  **`voltro update` carries you across this** — codemod `0.37.0/01_procedure-input-rejects-undeclared-fields`, a written note. A transform would have to guess which declared field a stray one meant, which is the same guess that produced the defect.
+
+### Added
+
+- **@voltro/plugin-audit** — `redactInput` / `redactOutcome` gained `'shape'`, and `redactSubject` gained `'metadata-shape'`: the payload's STRUCTURE survives, no value from it.
+
+  ```json
+  { "__redacted": { "jiraToken": "string(113)", "attempts": "number" } }
+  ```
+
+  Requested by the consumer who had asked for the redaction one round earlier, and both requests were right. They spent a day on a bug their own audit trail could have ended in seconds — a value arrived as 113 characters where 44 were due, and the row that would have said so read `{"__redacted":"all"}`. `'all'` remains the default on every field; this is opt-in.
+
+  The rules, and the two that are decisions rather than details:
+
+  - A string reports its LENGTH. Never a prefix, never a hash — `enc:v1:` is a prefix and so is the first byte of a private key, so there is no prefix length that is safe for every credential format. - A number, boolean or date reports its TYPE only. A number can BE the secret. - **A key can be the value.** An object keyed by user data puts a datum where a schema name belongs, so a key is reproduced only when it looks like a declared field — a short plain identifier. The first version truncated long keys and documented the weakness instead; this module's own test caught 62 characters of a secret surviving on the first run. A leak with a footnote is still a leak. - **A string's length is a real disclosure, and a small one.** Stated in the docs rather than buried: for a fixed-format credential it carries nothing, for a human-chosen password it is a weak hint. `'all'` stays the default for anyone that matters to.
+
+  The `'shape'` outcome describes the payload it REPLACES — the value on success, the error on failure — rather than the event. Describing the event would report `{ kind, value, durationMs }` and hide the field, which is the failure the option exists to end. An error's `_tag` still survives, as it does under `'all'`.
+
+### Fixed
+
+- **@voltro/cli** — `voltro db --help` listed fifteen of eighteen subcommands. `adopt`, `scan-credentials` and `encrypt-column` shipped and never joined the hand-written string.
+
+  A consumer wrote both halves of that gap into a requirements document, as separate items, neither of them about help text:
+
+  - **`voltro db encrypt-column` "does not exist"** — filed as a feature request, quoting the fifteen names they saw as evidence. It shipped in 0.33.0, and enabling `.encrypted()` on a populated column by hand is exactly the migration they were about to write themselves. - **`scan-credentials` "no longer exists"** — filed as CLOSED, a credential scanner struck off their list as removed. It had not moved.
+
+  A quoted enumeration is read as exhaustive, and the more careful the reader the more thoroughly they act on the missing entry. Same lesson a boot refusal in `procedureAccessGate` had already taught us, in a place nobody thought of as a message.
+
+  The usage line is now GENERATED from the dispatch table's key type (`Record<DbSubcommand, Handler>` in `dbCommand.ts`, names in `subcommandNames.ts`), so a handler with no name or a name with no handler fails to compile. `voltro privacy` is keyed the same way. The prose summary beside it cannot be generated — it carries per-command annotations — so a test asserts it mentions every name, because it carried the identical three omissions and it is what `voltro --help` prints first.
+
+  `subcommandHelpParity.test.ts` also NAMES the six commands whose subcommand menus have no dispatch table behind them (`webhooks`, `evolve`, `new`, `data`, `storage`, `add`). They dispatch through a switch and are unchecked; a silently-unchecked command reads exactly like a checked one.
+- **@voltro/cli** — A 401 or 403 from the inspect surface now names `VOLTRO_INSPECT_TOKEN` and says which side is missing.
+
+  `voltro db plan --against <url>` printed `remote returned 403` and stopped. A consumer read that as a DATABASE permission problem — the natural reading of a 403 from a command whose entire subject is a database — and went looking at grants. The cause is one unset environment variable, which the command reads four lines above the message.
+
+  `voltro probe access` had half of it: it named the variable on 401 and not on 403, while classifying both as `refused`. So the two commands somebody needs during an access migration were the two that would not say what was wrong, and one of them said something misleading instead.
+
+  `inspectGateHint` is shared by both call sites and distinguishes the two statuses, because they call for different actions: a 401 means no credential was sent (set the variable), a 403 means the one sent was not accepted (the two values differ). Both halves of the sentence name the server AND the calling shell — naming one side produces a second failed attempt.
+- **@voltro/cli** — `VOLTRO_TEMPLATES_DIR` is authoritative when set. It used to be a HINT: if the path it named held no `apps/` (or no `baselines/`), both resolvers fell through to the sibling-checkout walk-up and quietly used a different tree — or none.
+
+  A pointer that silently isn't followed is worse than a wrong one. A CI job aimed at the wrong path scaffolded from whatever it happened to find, and a job whose checkout had failed reported an empty template catalogue with nothing connecting that emptiness to the variable it was given. `scripts/lib/docsSite.mjs` states the same rule for `VOLTRO_DOCS_DIR`, and arrived at it the same way: you said where it is; it is not there.
+
+  Behaviourally this only changes the misconfigured case — a correct `VOLTRO_TEMPLATES_DIR` resolved to the same place before and after. What changes is that a wrong one now shows up as "not found, here is the path I was told" at the first thing that reads it, instead of as a different tree three steps later.
+
+  The unbundled resolution order is otherwise untouched: sibling `voltro-templates` → `.voltro-templates` → the bundled `templates/` a published CLI ships.
+
+### Internal (no consumer-facing effect)
+
+- **@voltro/plugin-ai-flows** — Two comments in the flow engine cited task records from a plans tracker that has since been deleted. Comment-only; no behavior, no API, nothing a consumer can observe.
+
+  Worth writing down because of HOW it surfaced. The tracker was retired in the META repo, and the gate that went red was in THIS one — `check-stale-task-comments.mjs` resolves a comment's `task #NN` against `../plans`, so deleting a plan document in one repo can only be half a change, and the other half is in a repo the deleting commit never touched.
+
+  Neither comment was WRONG, which is the part that makes the rule earn its keep. The first claims `@voltro/ai` has first-class media generation — true: `generateImage`, `generateSpeech`, `generateVideo` all ship in `packages/ai/src/media.ts`. It now names those three instead of a record number, which is checkable without the deleted document. The second only quoted the retired id inside its own account of a defect (a `"not yet wired (task #35)"` message that outlived the shipped HITL park and misled an audit into filing it as unbuilt); the quote lost the number and kept the whole lesson.
+
+  The check's own failure text is the reasoning: a plan is retired for exactly two reasons — the work shipped, or it was dropped without shipping — and a comment still citing it asserts the second while usually meaning the first.
+
+---
+
+## [0.36.0] — 2026-08-13
+
+### ⚠ BREAKING
+
+- **@voltro/integration-http, @voltro/plugin-atlassian** — A 401 from an upstream now produces `code: 'unauthorized'`, not `code: 'session_expired'`. The connection vault's own failure — where we DO know the credential is unusable — becomes `code: 'credential_unusable'`.
+
+  `session_expired` asserted a cause the status cannot support. A 401 says the credential was not accepted and says nothing about why: expired, revoked, insufficient scope and MALFORMED all produce it. A consumer's plugin sent ciphertext as a bearer token (a separate defect, fixed in the same release), the upstream answered 401, this name called it an expired session, and their health check acted on the name and deleted a valid session. Login loop, with every symptom pointing at a revoked credential.
+
+  Names get acted on, which is the whole reason to split them:
+
+  - `'unauthorized'` — the upstream refused. Non-transient, so still never retried; `status` rides along so a caller that knows more about its own upstream can decide for itself. Deciding for them is what this gives up. - `'credential_unusable'` — the connection vault could not produce a credential (no grant, revoked grant, refresh failed). Here the claim is ours to make, because the failure is ours rather than the far end's.
+
+  The 401 message stopped saying "session expired" too. It now says the credential was refused and that the reason is not in the response — which is the honest sentence and the one that would have saved the day this cost.
+
+  Its test asserts the CLAIM rather than banning the word: the first version forbade `/expired/i` and went red against the corrected message, which lists expiry as one of several things a 401 can mean. That distinction is the point of the change, so the assertion had to be about `session expired` specifically.
+
+  **`voltro update` carries you across this** — codemod `0.35.1/01_unauthorized-replaces-session-expired`.
+
+### Added
+
+- **@voltro/web** — **`apiSurface: compatible` — why the three altered golden lines cannot break a caller.** `LoaderContext` and `LoaderFn` each gained a type parameter WITH a default, so an unparameterised reference still resolves. The one that needed proving is `query?`, which went from a written-out signature to `LoaderQuery<Procedures>` — and `LoaderQuery` is a conditional whose false branch is character-for-character the previous signature. `unknown` does not extend `ProcedureTypeMap`, so the defaulted instantiation takes that branch.
+
+  Proved with `tsc` rather than by reading it: a probe asserting mutual assignability between `LoaderQuery<unknown>` and the old signature compiles, and inverting the probe fails — with tsc printing the resolved type as `<T = unknown>(tag: string, input?: Record<string, unknown> | undefined) => Promise<T>`, which is the old signature verbatim.
+
+  `LoaderContext` takes the app's procedure map, so a loader's `query` infers its input and output from the descriptor instead of returning `unknown`.
+
+  ```ts
+  import type { AppProcedures } from '<your-api>/rpcGroup'
+  
+  export const loader = async ({ query }: LoaderContext<AppProcedures>) => {
+    const rows = await query?.('bookmarks.list', { limit: 100 })
+    //    ^ inferred; an unknown tag or a wrong input shape is a compile error
+  }
+  ```
+
+  `AppProcedures` is generated already and has been for a while — it was wired to `createHooks` on the CLIENT and to nothing on the server, so every loader call site spelled its own output type by hand and a typo in a tag compiled. A consumer reported it twice.
+
+  The extraction reuses `ProcedureInput` / `ProcedureOutput` from `@voltro/client` rather than re-deriving them: a second answer to "what does this tag return" drifts the first time a descriptor field is renamed, and both answers look right in isolation.
+
+  Opt-in, and non-breaking: with no map named, the signature is the previous `<T = unknown>(tag: string, …)`. The framework cannot import an app's generated file, which is the same reason `createHooks<AppProcedures>` takes it explicitly.
+
+  Covered by a `.test-d.ts`, because the failure mode is "it compiles when it should not" and no runtime assertion can observe that. Two of its cases exist because the first version was vacuous: an `interface` fixture does not satisfy the map constraint (no implicit index signature — the codegen emits an alias for exactly this reason), so the typed branch fell back silently and every `@ts-expect-error` came back unused.
+
+### Fixed
+
+- **@voltro/cli** — The store a plugin receives through `bindDataStore` now carries the storage codec, so an `.encrypted()` column read through it decrypts.
+
+  A consumer measured both stores inside one request: `ctx.store` gave a 44-character plaintext PAT, and the store their plugin's `credentialsResolver` received gave 113 characters of `enc:v1:…`. Ciphertext is a syntactically valid bearer token, so nothing threw. Jira answered 401, `@voltro/integration-http` named that `session_expired`, their PAT health check did the reasonable thing with that name and deleted the session, and the user got login → dashboard → login forever. A configuration error in the costume of an authentication refusal, where every symptom pointed at the one explanation that was wrong.
+
+  The part worth recording is that `bootStoreCodec.ts` was written for exactly this, after it happened at two other seams, and its header predicts this consumer's symptom verbatim: "a route reading an `.encrypted()` column got the literal string `enc:v1:…` back … the failure reads as 'wrong credential'". The fix was applied per-seam. `bindDataStore` was not one of the seams anybody listed, so it happened a third time — and a per-seam test stayed green throughout, because it covered the two seams somebody remembered.
+
+  `bootStoreHandouts.test.ts` asserts the rule instead: no boot path hands a plugin the raw driver, on either boot path, with the wrapper applied before the handout. The codec needs no Subject — it is how a column is spelled on disk versus in JS — so there was never anything a boot-level store could not carry.
+
+  Also relevant to anyone who followed the 0.28.0 codemod: that codemod told apps to stop carrying a credential on the Subject and look it up in the resolver instead. Doing exactly that is what put an app on this seam, so the instruction and `.encrypted()` were not simultaneously satisfiable through it.
+- **@voltro/runtime, @voltro/cli** — The rpc/WebSocket query and stream arms now resolve row visibility before the executor sees a context. Fixes a 0.35.0 regression that made every read throw for an app with a registered row filter, and the older leak underneath it.
+
+  0.35.0 shipped two things for the row filter: the registration moved to `globalThis` (so a duplicate `@voltro/runtime` instance cannot hide it), and a scoped store built without a resolved scope started throwing instead of silently serving unfiltered rows. The first was a real fix for a real hazard. The second was correct in principle and immediately fatal in practice, because the framework itself had a path that did exactly what it now refuses.
+
+  The consumer who reported the original leak ran the two-line check we asked for and `getRowFilter()` was visible from their request path — so the instance split was NOT their cause, and our hypothesis was wrong. Their measurement is what found the real one: the refusal fired, meaning the registration was FOUND and `ctx.rowFilter` was still undefined at the store. Nothing was missing; a step was.
+
+  Four arms reach a request context. `makeOneShotQueryRunner` (REST) and `makeQuerySubscriber` (SSE) both `await withRowFilter(...)` and say so in a comment. The rpc query handler and the stream handler — each hand-copied into both boot paths — handed the raw request straight through. So a user's executor received a context whose `ctx.store` applied no row filter, on the two arms that carry the most traffic. It survived because subscriptions are refiltered per DELIVERY, which made a descriptor-returning query look correct end to end while the executor's own reads were not.
+
+  `withScopedRequest` is the seam that fixes it once: a request that already carries a scope passes through untouched (resolving twice would run the app's `load` twice per request), an app with NO filter stays fully synchronous, and an app with one gets an Effect — which every one of these call sites already accepts. A boot-path parity test pins both stream arms and the shared producer.
+
+  The refusal also stopped firing for a SYSTEM subject. That is not a softening: `resolveRowFilterScopeFor` returns `NO_ROW_FILTER` for a system subject, so the only correct value was already determined, and several legitimate paths (schedules, resumed workflows, the webhook trigger context) build a context directly with no scope. Demanding a decision there is what took the api down.
+
+---
+
 ## [0.35.0] — 2026-08-13
 
 ### ⚠ BREAKING

package/dist/connection.d.ts

@@ -20,10 +20,14 @@ declare interface AtlassianCredentials {
  * vault.
  *
  * A failure to resolve becomes a NON-transient `JiraError` carrying
- * `code: 'session_expired'` — the plugin's existing signal for "the stored
- * credential is no longer usable, re-auth rather than retry". That mapping is
- * the point of this adapter: without it, a revoked grant would surface as an
- * opaque rejection that the plugin's retry policy would happily hammer.
+ * `code: 'credential_unusable'` — "the stored credential is no longer usable,
+ * re-auth rather than retry". That mapping is the point of this adapter:
+ * without it, a revoked grant would surface as an opaque rejection that the
+ * plugin's retry policy would happily hammer.
+ *
+ * Distinct from `'unauthorized'`, which is what an upstream 401 produces. This
+ * one is a claim we can actually make — the vault knows it has no usable
+ * credential — while a 401 only says the far end refused, without a reason.
  */
 export declare const connectionCredentials: (options: ConnectionCredentialsOptions) => CredentialsResolver;
 
@@ -92,9 +96,23 @@ declare interface CredentialsStore {
 
 /**
  * Jira failure. `transient` drives retry — `true` for 408/425/429/5xx +
- * network blips (worth retrying), `false` for 4xx / config errors. A 401
- * carries `code: 'session_expired'` (the stored PAT is stale) and is
- * NON-transient — re-auth, don't retry.
+ * network blips (worth retrying), `false` for 4xx / config errors.
+ *
+ * Two non-transient credential codes, and the split is the point. Both used to
+ * be `session_expired`, which asserted a cause one of them cannot know:
+ *
+ *   - `'unauthorized'` — the UPSTREAM answered 401. It refused the credential
+ *     and did not say why: expired, revoked, insufficient scope and MALFORMED
+ *     are all this status. Do not conclude "re-auth" from it alone.
+ *   - `'credential_unusable'` — the connection VAULT could not produce a
+ *     credential (no grant, revoked grant, refresh failed). Here we do know,
+ *     because the failure is ours rather than the upstream's, and re-auth is
+ *     the right action.
+ *
+ * The rename came from a consumer whose plugin sent ciphertext as a bearer
+ * token — a configuration error that arrived as a 401, was named
+ * `session_expired`, and made their health check delete a perfectly valid
+ * session. A name that asserts a cause gets acted on.
  */
 declare class JiraError extends JiraError_base {
 }
@@ -105,7 +123,7 @@ declare const JiraError_base: Schema.TaggedErrorClass<JiraError, "JiraError", {
     message: typeof Schema.String;
     transient: typeof Schema.Boolean;
     status: Schema.optional<typeof Schema.Number>;
-    code: Schema.optional<Schema.Literal<["session_expired"]>>;
+    code: Schema.optional<Schema.Literal<["unauthorized", "credential_unusable"]>>;
 }>;
 
 /** The slice of a resolved connection this adapter needs. Structurally

package/dist/connection.js

@@ -1,5 +1,5 @@
 import "./auth-EQ6tsD4P.js";
-import { a as e } from "./types-CVyqPJzY.js";
+import { a as e } from "./types-KZkXCLg1.js";
 import { Effect as t } from "effect";
 //#region src/connection.ts
 var n = async (e, t) => (await import("@voltro/runtime")).resolveConnectionForSubject(e, t), r = (r) => {
@@ -17,7 +17,7 @@ var n = async (e, t) => (await import("@voltro/runtime")).resolveConnectionForSu
 		catch: (t) => new e({
 			message: `no usable "${r.connectionId}" connection for this user: ${t instanceof Error ? t.message : String(t)}`,
 			transient: !1,
-			code: "session_expired"
+			code: "credential_unusable"
 		})
 	});
 };

package/dist/index.d.ts

@@ -169,7 +169,7 @@ declare const ConfluenceError_base: Schema.TaggedErrorClass<ConfluenceError, "Co
     message: typeof Schema.String;
     transient: typeof Schema.Boolean;
     status: Schema.optional<typeof Schema.Number>;
-    code: Schema.optional<Schema.Literal<["session_expired"]>>;
+    code: Schema.optional<Schema.Literal<["unauthorized", "credential_unusable"]>>;
 }>;
 
 export declare class ConfluenceService extends ConfluenceService_base {
@@ -290,9 +290,23 @@ declare type J<A> = Effect.Effect<A, JiraError, SubjectService>;
 
 /**
  * Jira failure. `transient` drives retry — `true` for 408/425/429/5xx +
- * network blips (worth retrying), `false` for 4xx / config errors. A 401
- * carries `code: 'session_expired'` (the stored PAT is stale) and is
- * NON-transient — re-auth, don't retry.
+ * network blips (worth retrying), `false` for 4xx / config errors.
+ *
+ * Two non-transient credential codes, and the split is the point. Both used to
+ * be `session_expired`, which asserted a cause one of them cannot know:
+ *
+ *   - `'unauthorized'` — the UPSTREAM answered 401. It refused the credential
+ *     and did not say why: expired, revoked, insufficient scope and MALFORMED
+ *     are all this status. Do not conclude "re-auth" from it alone.
+ *   - `'credential_unusable'` — the connection VAULT could not produce a
+ *     credential (no grant, revoked grant, refresh failed). Here we do know,
+ *     because the failure is ours rather than the upstream's, and re-auth is
+ *     the right action.
+ *
+ * The rename came from a consumer whose plugin sent ciphertext as a bearer
+ * token — a configuration error that arrived as a 401, was named
+ * `session_expired`, and made their health check delete a perfectly valid
+ * session. A name that asserts a cause gets acted on.
  */
 export declare class JiraError extends JiraError_base {
 }
@@ -303,7 +317,7 @@ declare const JiraError_base: Schema.TaggedErrorClass<JiraError, "JiraError", {
     message: typeof Schema.String;
     transient: typeof Schema.Boolean;
     status: Schema.optional<typeof Schema.Number>;
-    code: Schema.optional<Schema.Literal<["session_expired"]>>;
+    code: Schema.optional<Schema.Literal<["unauthorized", "credential_unusable"]>>;
 }>;
 
 export declare class JiraService extends JiraService_base {

package/dist/index.js

@@ -1,5 +1,5 @@
 import { n as e, t } from "./auth-EQ6tsD4P.js";
-import { a as n, i as r, n as i, o as a, r as o, t as s } from "./types-CVyqPJzY.js";
+import { a as n, i as r, n as i, o as a, r as o, t as s } from "./types-KZkXCLg1.js";
 import { Effect as c, Layer as l, Option as u } from "effect";
 import { SubjectService as d, definePlugin as f, pluginInstanceName as p } from "@voltro/protocol";
 import { DEFAULT_POLICY as m, DEFAULT_POLICY as h, assertSameHost as g, request as _, requestJson as v } from "@voltro/integration-http";

package/dist/{types-CVyqPJzY.js → types-KZkXCLg1.js}

@@ -4,12 +4,12 @@ var n = class extends t.TaggedError()("JiraError", {
 	message: t.String,
 	transient: t.Boolean,
 	status: t.optional(t.Number),
-	code: t.optional(t.Literal("session_expired"))
+	code: t.optional(t.Literal("unauthorized", "credential_unusable"))
 }) {}, r = class extends t.TaggedError()("ConfluenceError", {
 	message: t.String,
 	transient: t.Boolean,
 	status: t.optional(t.Number),
-	code: t.optional(t.Literal("session_expired"))
+	code: t.optional(t.Literal("unauthorized", "credential_unusable"))
 }) {}, i = class extends t.TaggedError()("AtlassianOAuthError", {
 	message: t.String,
 	transient: t.Boolean,

package/dist/webhook.js

@@ -1,4 +1,4 @@
-import { n as e } from "./types-CVyqPJzY.js";
+import { n as e } from "./types-KZkXCLg1.js";
 import { createHmac as t, timingSafeEqual as n } from "node:crypto";
 //#region src/webhook.ts
 var r = "X-Hub-Signature", i = (e = r) => ({

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/plugin-atlassian",
-  "version": "0.35.0",
+  "version": "0.37.0",
   "description": "Jira + Confluence plugin — JiraService + ConfluenceService over the Atlassian REST/Greenhopper/Agile APIs, with a pluggable per-subject credentials resolver (PAT), transient retry + Retry-After, timeouts, an SSRF-guarded PAT-free avatar proxy, and optional response caching via @voltro/cache.",
   "keywords": [
     "voltro",
@@ -43,8 +43,8 @@
     "node": ">=24.0.0"
   },
   "dependencies": {
-    "@voltro/integration-http": "0.35.0",
-    "@voltro/protocol": "0.35.0"
+    "@voltro/integration-http": "0.37.0",
+    "@voltro/protocol": "0.37.0"
   },
   "peerDependencies": {
     "effect": "^3.22.0"