@neetru/sdk 3.6.0 → 3.8.0

package/dist/support.d.cts

@@ -1,7 +1,33 @@
-import { ag as ResolvedConfig, al as SupportNamespace } from './types-Du_iioJ7.cjs';
+import { ah as ResolvedConfig, am as SupportNamespace } from './types-D-9bjlM0.cjs';
 import 'drizzle-orm/node-postgres';
 import './errors.cjs';
 
-declare function createSupportNamespace(config: ResolvedConfig): SupportNamespace;
+/**
+ * 3.7.0 (Core HIGH-2, auditoria 2026-09-29): header com o id_token OIDC do
+ * usuário final. A chave `nrt_` identifica o PRODUTO (é a mesma pra todos os
+ * usuários); o Core usa este token pra amarrar o ticket ao `endUserId`
+ * (= `sub`) e só deixa o próprio dono listar/contestar/avaliar.
+ *
+ * 3.8.0: a chave `nrt_` é SÓ DE SERVIDOR (ver `server-only-key.ts`). O fluxo
+ * canônico é o backend do produto chamar o support com a chave e repassar o
+ * id_token que o app/site mandou — via `createNeetruClient({ endUserAuth })`.
+ */
+declare const END_USER_TOKEN_HEADER = "X-Neetru-End-User-Token";
+/** Dependências opcionais do namespace (injetadas pelo `createNeetruClient`). */
+interface SupportNamespaceDeps {
+    /**
+     * Devolve o **id_token** OIDC do usuário final logado, ou `null` se não houver.
+     * O `createNeetruClient` liga isto a `client.auth.getIdToken()`. NUNCA o
+     * access token: o Core recusa token com `jti` (401 `invalid_end_user_token`).
+     */
+    getEndUserToken?: () => string | null | undefined | Promise<string | null | undefined>;
+    /**
+     * Renova a sessão do usuário final (refresh_token → id_token novo). Resolve
+     * `true` se renovou. O `createNeetruClient` liga a `client.auth.refreshTokens()`
+     * quando o namespace de auth expõe o método. Usado 1x antes de desistir.
+     */
+    refreshEndUserToken?: () => Promise<boolean>;
+}
+declare function createSupportNamespace(config: ResolvedConfig, deps?: SupportNamespaceDeps): SupportNamespace;
 
-export { createSupportNamespace };
+export { END_USER_TOKEN_HEADER, type SupportNamespaceDeps, createSupportNamespace };

package/dist/support.d.ts

@@ -1,7 +1,33 @@
-import { ag as ResolvedConfig, al as SupportNamespace } from './types-BPATkXYu.js';
+import { ah as ResolvedConfig, am as SupportNamespace } from './types-bVztFQTI.js';
 import 'drizzle-orm/node-postgres';
 import './errors.js';
 
-declare function createSupportNamespace(config: ResolvedConfig): SupportNamespace;
+/**
+ * 3.7.0 (Core HIGH-2, auditoria 2026-09-29): header com o id_token OIDC do
+ * usuário final. A chave `nrt_` identifica o PRODUTO (é a mesma pra todos os
+ * usuários); o Core usa este token pra amarrar o ticket ao `endUserId`
+ * (= `sub`) e só deixa o próprio dono listar/contestar/avaliar.
+ *
+ * 3.8.0: a chave `nrt_` é SÓ DE SERVIDOR (ver `server-only-key.ts`). O fluxo
+ * canônico é o backend do produto chamar o support com a chave e repassar o
+ * id_token que o app/site mandou — via `createNeetruClient({ endUserAuth })`.
+ */
+declare const END_USER_TOKEN_HEADER = "X-Neetru-End-User-Token";
+/** Dependências opcionais do namespace (injetadas pelo `createNeetruClient`). */
+interface SupportNamespaceDeps {
+    /**
+     * Devolve o **id_token** OIDC do usuário final logado, ou `null` se não houver.
+     * O `createNeetruClient` liga isto a `client.auth.getIdToken()`. NUNCA o
+     * access token: o Core recusa token com `jti` (401 `invalid_end_user_token`).
+     */
+    getEndUserToken?: () => string | null | undefined | Promise<string | null | undefined>;
+    /**
+     * Renova a sessão do usuário final (refresh_token → id_token novo). Resolve
+     * `true` se renovou. O `createNeetruClient` liga a `client.auth.refreshTokens()`
+     * quando o namespace de auth expõe o método. Usado 1x antes de desistir.
+     */
+    refreshEndUserToken?: () => Promise<boolean>;
+}
+declare function createSupportNamespace(config: ResolvedConfig, deps?: SupportNamespaceDeps): SupportNamespace;
 
-export { createSupportNamespace };
+export { END_USER_TOKEN_HEADER, type SupportNamespaceDeps, createSupportNamespace };