@hotmeshio/long-tail 0.20.0 → 0.21.1

package/dashboard/dist/assets/{yaml-workflows-CiWwx5rM.js → yaml-workflows-BHAOOGvn.js}

@@ -1,2 +1,2 @@
-import{u as l,b as a,c as s}from"./vendor-query-DvWWuNIB.js";import{m as r}from"./index-CIwlVfvV.js";function f(e={}){const o=new URLSearchParams;return e.status&&o.set("status",e.status),e.graph_topic&&o.set("graph_topic",e.graph_topic),e.app_id&&o.set("app_id",e.app_id),e.search&&o.set("search",e.search),e.set_id&&o.set("set_id",e.set_id),e.limit&&o.set("limit",String(e.limit)),e.offset!==void 0&&o.set("offset",String(e.offset)),l({queryKey:["yamlWorkflows",e],queryFn:()=>r(`/yaml-workflows?${o}`)})}function m(){return l({queryKey:["yamlWorkflowAppIds"],queryFn:()=>r("/yaml-workflows/app-ids")})}function c(e){return l({queryKey:["yamlWorkflows",e],queryFn:()=>r(`/yaml-workflows/${e}`),enabled:!!e})}function w(){const e=a();return s({mutationFn:o=>r("/yaml-workflows",{method:"POST",body:JSON.stringify(o)}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function k(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}/deploy`,{method:"POST"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function p(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}/activate`,{method:"POST"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function d(){const e=a();return s({mutationFn:({id:o,data:t,sync:n,execute_as:u})=>r(`/yaml-workflows/${o}/invoke`,{method:"POST",body:JSON.stringify({data:t,sync:n,...u?{execute_as:u}:{}})}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function h(){const e=a();return s({mutationFn:({id:o,task_queue:t,compilation_feedback:n})=>r(`/yaml-workflows/${o}/regenerate`,{method:"POST",body:JSON.stringify({task_queue:t,compilation_feedback:n})}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function q(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}/archive`,{method:"POST"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function W(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}/restore`,{method:"POST"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"}),e.invalidateQueries({queryKey:["yamlWorkflow"],refetchType:"all"})}})}function S(){const e=a();return s({mutationFn:({id:o,...t})=>r(`/yaml-workflows/${o}`,{method:"PUT",body:JSON.stringify(t)}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function v(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}`,{method:"DELETE"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function T(e){return l({queryKey:["yamlWorkflows",e,"versions"],queryFn:()=>r(`/yaml-workflows/${e}/versions`),enabled:!!e})}function F(e,o){return l({queryKey:["yamlWorkflows",e,"versions",o],queryFn:()=>r(`/yaml-workflows/${e}/versions/${o}`),enabled:!!e&&o!==null})}export{m as a,S as b,c,T as d,k as e,p as f,q as g,W as h,v as i,h as j,F as k,d as l,w as m,f as u};
-//# sourceMappingURL=yaml-workflows-CiWwx5rM.js.map
+import{u as l,b as a,c as s}from"./vendor-query-DvWWuNIB.js";import{m as r}from"./index-CgUcYveM.js";function f(e={}){const o=new URLSearchParams;return e.status&&o.set("status",e.status),e.graph_topic&&o.set("graph_topic",e.graph_topic),e.app_id&&o.set("app_id",e.app_id),e.search&&o.set("search",e.search),e.set_id&&o.set("set_id",e.set_id),e.limit&&o.set("limit",String(e.limit)),e.offset!==void 0&&o.set("offset",String(e.offset)),l({queryKey:["yamlWorkflows",e],queryFn:()=>r(`/yaml-workflows?${o}`)})}function m(){return l({queryKey:["yamlWorkflowAppIds"],queryFn:()=>r("/yaml-workflows/app-ids")})}function c(e){return l({queryKey:["yamlWorkflows",e],queryFn:()=>r(`/yaml-workflows/${e}`),enabled:!!e})}function w(){const e=a();return s({mutationFn:o=>r("/yaml-workflows",{method:"POST",body:JSON.stringify(o)}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function k(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}/deploy`,{method:"POST"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function p(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}/activate`,{method:"POST"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function d(){const e=a();return s({mutationFn:({id:o,data:t,sync:n,execute_as:u})=>r(`/yaml-workflows/${o}/invoke`,{method:"POST",body:JSON.stringify({data:t,sync:n,...u?{execute_as:u}:{}})}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function h(){const e=a();return s({mutationFn:({id:o,task_queue:t,compilation_feedback:n})=>r(`/yaml-workflows/${o}/regenerate`,{method:"POST",body:JSON.stringify({task_queue:t,compilation_feedback:n})}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function q(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}/archive`,{method:"POST"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function W(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}/restore`,{method:"POST"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"}),e.invalidateQueries({queryKey:["yamlWorkflow"],refetchType:"all"})}})}function S(){const e=a();return s({mutationFn:({id:o,...t})=>r(`/yaml-workflows/${o}`,{method:"PUT",body:JSON.stringify(t)}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function v(){const e=a();return s({mutationFn:o=>r(`/yaml-workflows/${o}`,{method:"DELETE"}),onSuccess:()=>{e.invalidateQueries({queryKey:["yamlWorkflows"],refetchType:"all"})}})}function T(e){return l({queryKey:["yamlWorkflows",e,"versions"],queryFn:()=>r(`/yaml-workflows/${e}/versions`),enabled:!!e})}function F(e,o){return l({queryKey:["yamlWorkflows",e,"versions",o],queryFn:()=>r(`/yaml-workflows/${e}/versions/${o}`),enabled:!!e&&o!==null})}export{m as a,S as b,c,T as d,k as e,p as f,q as g,W as h,v as i,h as j,F as k,d as l,w as m,f as u};
+//# sourceMappingURL=yaml-workflows-BHAOOGvn.js.map

package/dashboard/dist/assets/{yaml-workflows-CiWwx5rM.js.map → yaml-workflows-BHAOOGvn.js.map}

@@ -1 +1 @@
-{"version":3,"file":"yaml-workflows-CiWwx5rM.js","sources":["../../src/api/yaml-workflows.ts"],"sourcesContent":["import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';\nimport { apiFetch } from './client';\nimport type { LTYamlWorkflowRecord, LTYamlWorkflowStatus, LTYamlWorkflowVersion } from './types';\n\ninterface YamlWorkflowListResponse {\n  workflows: LTYamlWorkflowRecord[];\n  total: number;\n}\n\ninterface YamlWorkflowFilters {\n  status?: LTYamlWorkflowStatus;\n  graph_topic?: string;\n  app_id?: string;\n  search?: string;\n  set_id?: string;\n  limit?: number;\n  offset?: number;\n}\n\nexport function useYamlWorkflows(filters: YamlWorkflowFilters = {}) {\n  const params = new URLSearchParams();\n  if (filters.status) params.set('status', filters.status);\n  if (filters.graph_topic) params.set('graph_topic', filters.graph_topic);\n  if (filters.app_id) params.set('app_id', filters.app_id);\n  if (filters.search) params.set('search', filters.search);\n  if (filters.set_id) params.set('set_id', filters.set_id);\n  if (filters.limit) params.set('limit', String(filters.limit));\n  if (filters.offset !== undefined) params.set('offset', String(filters.offset));\n\n  return useQuery<YamlWorkflowListResponse>({\n    queryKey: ['yamlWorkflows', filters],\n    queryFn: () => apiFetch(`/yaml-workflows?${params}`),\n  });\n}\n\nexport function useYamlWorkflowAppIds() {\n  return useQuery<{ app_ids: string[] }>({\n    queryKey: ['yamlWorkflowAppIds'],\n    queryFn: () => apiFetch('/yaml-workflows/app-ids'),\n  });\n}\n\nexport function useYamlWorkflowByTopic(graphTopic: string | undefined, appId?: string) {\n  return useQuery<YamlWorkflowListResponse>({\n    queryKey: ['yamlWorkflows', 'byTopic', graphTopic, appId],\n    queryFn: () => {\n      const params = new URLSearchParams({ graph_topic: graphTopic!, limit: '1' });\n      if (appId) params.set('app_id', appId);\n      return apiFetch(`/yaml-workflows?${params}`);\n    },\n    enabled: !!graphTopic,\n  });\n}\n\nexport function useYamlWorkflow(id: string) {\n  return useQuery<LTYamlWorkflowRecord>({\n    queryKey: ['yamlWorkflows', id],\n    queryFn: () => apiFetch(`/yaml-workflows/${id}`),\n    enabled: !!id,\n  });\n}\n\nexport function useCreateYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (input: {\n      workflow_id: string;\n      task_queue: string;\n      workflow_name: string;\n      name: string;\n      description?: string;\n      app_id?: string;\n      subscribes?: string;\n      tags?: string[];\n      compilation_feedback?: string;\n    }) =>\n      apiFetch<LTYamlWorkflowRecord>('/yaml-workflows', {\n        method: 'POST',\n        body: JSON.stringify(input),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useDeployYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/deploy`, {\n        method: 'POST',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useActivateYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/activate`, {\n        method: 'POST',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useInvokeYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: ({ id, data, sync, execute_as }: { id: string; data: Record<string, unknown>; sync?: boolean; execute_as?: string }) =>\n      apiFetch<{ result?: unknown; job_id?: string }>(`/yaml-workflows/${id}/invoke`, {\n        method: 'POST',\n        body: JSON.stringify({ data, sync, ...(execute_as ? { execute_as } : {}) }),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useRegenerateYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: ({ id, task_queue, compilation_feedback }: { id: string; task_queue?: string; compilation_feedback?: string }) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/regenerate`, {\n        method: 'POST',\n        body: JSON.stringify({ task_queue, compilation_feedback }),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useArchiveYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/archive`, {\n        method: 'POST',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useRestoreYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/restore`, {\n        method: 'POST',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflow'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useUpdateYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: ({ id, ...updates }: { id: string; yaml_content?: string; name?: string; description?: string; input_schema?: Record<string, unknown>; output_schema?: Record<string, unknown>; tags?: string[]; app_id?: string; graph_topic?: string }) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}`, {\n        method: 'PUT',\n        body: JSON.stringify(updates),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useDeleteYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<{ deleted: boolean }>(`/yaml-workflows/${id}`, {\n        method: 'DELETE',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\n// ── Cron scheduling ─────────────────────────────────────────────\n\nexport function useSetYamlCron() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: ({ id, cron_schedule, cron_envelope, execute_as }: {\n      id: string;\n      cron_schedule: string;\n      cron_envelope?: Record<string, unknown> | null;\n      execute_as?: string | null;\n    }) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/cron`, {\n        method: 'PUT',\n        body: JSON.stringify({ cron_schedule, cron_envelope, execute_as }),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useClearYamlCron() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/cron`, {\n        method: 'DELETE',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\n// ── Version history ─────────────────────────────────────────────\n\nexport function useYamlWorkflowVersions(id: string) {\n  return useQuery<{ versions: LTYamlWorkflowVersion[]; total: number }>({\n    queryKey: ['yamlWorkflows', id, 'versions'],\n    queryFn: () => apiFetch(`/yaml-workflows/${id}/versions`),\n    enabled: !!id,\n  });\n}\n\nexport function useYamlWorkflowVersion(id: string, version: number | null) {\n  return useQuery<LTYamlWorkflowVersion>({\n    queryKey: ['yamlWorkflows', id, 'versions', version],\n    queryFn: () => apiFetch(`/yaml-workflows/${id}/versions/${version}`),\n    enabled: !!id && version !== null,\n  });\n}\n"],"names":["useYamlWorkflows","filters","params","useQuery","apiFetch","useYamlWorkflowAppIds","useYamlWorkflow","id","useCreateYamlWorkflow","queryClient","useQueryClient","useMutation","input","useDeployYamlWorkflow","useActivateYamlWorkflow","useInvokeYamlWorkflow","data","sync","execute_as","useRegenerateYamlWorkflow","task_queue","compilation_feedback","useArchiveYamlWorkflow","useRestoreYamlWorkflow","useUpdateYamlWorkflow","updates","useDeleteYamlWorkflow","useYamlWorkflowVersions","useYamlWorkflowVersion","version"],"mappings":"qGAmBO,SAASA,EAAiBC,EAA+B,GAAI,CAClE,MAAMC,EAAS,IAAI,gBACnB,OAAID,EAAQ,QAAQC,EAAO,IAAI,SAAUD,EAAQ,MAAM,EACnDA,EAAQ,aAAaC,EAAO,IAAI,cAAeD,EAAQ,WAAW,EAClEA,EAAQ,QAAQC,EAAO,IAAI,SAAUD,EAAQ,MAAM,EACnDA,EAAQ,QAAQC,EAAO,IAAI,SAAUD,EAAQ,MAAM,EACnDA,EAAQ,QAAQC,EAAO,IAAI,SAAUD,EAAQ,MAAM,EACnDA,EAAQ,OAAOC,EAAO,IAAI,QAAS,OAAOD,EAAQ,KAAK,CAAC,EACxDA,EAAQ,SAAW,QAAWC,EAAO,IAAI,SAAU,OAAOD,EAAQ,MAAM,CAAC,EAEtEE,EAAmC,CACxC,SAAU,CAAC,gBAAiBF,CAAO,EACnC,QAAS,IAAMG,EAAS,mBAAmBF,CAAM,EAAE,CAAA,CACpD,CACH,CAEO,SAASG,GAAwB,CACtC,OAAOF,EAAgC,CACrC,SAAU,CAAC,oBAAoB,EAC/B,QAAS,IAAMC,EAAS,yBAAyB,CAAA,CAClD,CACH,CAcO,SAASE,EAAgBC,EAAY,CAC1C,OAAOJ,EAA+B,CACpC,SAAU,CAAC,gBAAiBI,CAAE,EAC9B,QAAS,IAAMH,EAAS,mBAAmBG,CAAE,EAAE,EAC/C,QAAS,CAAC,CAACA,CAAA,CACZ,CACH,CAEO,SAASC,GAAwB,CACtC,MAAMC,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaC,GAWXR,EAA+B,kBAAmB,CAChD,OAAQ,OACR,KAAM,KAAK,UAAUQ,CAAK,CAAA,CAC3B,EACH,UAAW,IAAM,CACfH,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASI,GAAwB,CACtC,MAAMJ,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,UAAW,CAC7D,OAAQ,MAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASK,GAA0B,CACxC,MAAML,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,YAAa,CAC/D,OAAQ,MAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASM,GAAwB,CACtC,MAAMN,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAY,CAAC,CAAE,GAAAJ,EAAI,KAAAS,EAAM,KAAAC,EAAM,WAAAC,KAC7Bd,EAAgD,mBAAmBG,CAAE,UAAW,CAC9E,OAAQ,OACR,KAAM,KAAK,UAAU,CAAE,KAAAS,EAAM,KAAAC,EAAM,GAAIC,EAAa,CAAE,WAAAA,CAAA,EAAe,GAAK,CAAA,CAC3E,EACH,UAAW,IAAM,CACfT,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASU,GAA4B,CAC1C,MAAMV,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAY,CAAC,CAAE,GAAAJ,EAAI,WAAAa,EAAY,qBAAAC,KAC7BjB,EAA+B,mBAAmBG,CAAE,cAAe,CACjE,OAAQ,OACR,KAAM,KAAK,UAAU,CAAE,WAAAa,EAAY,qBAAAC,EAAsB,CAAA,CAC1D,EACH,UAAW,IAAM,CACfZ,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASa,GAAyB,CACvC,MAAMb,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,WAAY,CAC9D,OAAQ,MAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASc,GAAyB,CACvC,MAAMd,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,WAAY,CAC9D,OAAQ,MAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,EACjFA,EAAY,kBAAkB,CAAE,SAAU,CAAC,cAAc,EAAG,YAAa,MAAO,CAClF,CAAA,CACD,CACH,CAEO,SAASe,GAAwB,CACtC,MAAMf,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAY,CAAC,CAAE,GAAAJ,EAAI,GAAGkB,KACpBrB,EAA+B,mBAAmBG,CAAE,GAAI,CACtD,OAAQ,MACR,KAAM,KAAK,UAAUkB,CAAO,CAAA,CAC7B,EACH,UAAW,IAAM,CACfhB,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASiB,GAAwB,CACtC,MAAMjB,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,GAAI,CACtD,OAAQ,QAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAsCO,SAASkB,EAAwBpB,EAAY,CAClD,OAAOJ,EAA+D,CACpE,SAAU,CAAC,gBAAiBI,EAAI,UAAU,EAC1C,QAAS,IAAMH,EAAS,mBAAmBG,CAAE,WAAW,EACxD,QAAS,CAAC,CAACA,CAAA,CACZ,CACH,CAEO,SAASqB,EAAuBrB,EAAYsB,EAAwB,CACzE,OAAO1B,EAAgC,CACrC,SAAU,CAAC,gBAAiBI,EAAI,WAAYsB,CAAO,EACnD,QAAS,IAAMzB,EAAS,mBAAmBG,CAAE,aAAasB,CAAO,EAAE,EACnE,QAAS,CAAC,CAACtB,GAAMsB,IAAY,IAAA,CAC9B,CACH"}
+{"version":3,"file":"yaml-workflows-BHAOOGvn.js","sources":["../../src/api/yaml-workflows.ts"],"sourcesContent":["import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';\nimport { apiFetch } from './client';\nimport type { LTYamlWorkflowRecord, LTYamlWorkflowStatus, LTYamlWorkflowVersion } from './types';\n\ninterface YamlWorkflowListResponse {\n  workflows: LTYamlWorkflowRecord[];\n  total: number;\n}\n\ninterface YamlWorkflowFilters {\n  status?: LTYamlWorkflowStatus;\n  graph_topic?: string;\n  app_id?: string;\n  search?: string;\n  set_id?: string;\n  limit?: number;\n  offset?: number;\n}\n\nexport function useYamlWorkflows(filters: YamlWorkflowFilters = {}) {\n  const params = new URLSearchParams();\n  if (filters.status) params.set('status', filters.status);\n  if (filters.graph_topic) params.set('graph_topic', filters.graph_topic);\n  if (filters.app_id) params.set('app_id', filters.app_id);\n  if (filters.search) params.set('search', filters.search);\n  if (filters.set_id) params.set('set_id', filters.set_id);\n  if (filters.limit) params.set('limit', String(filters.limit));\n  if (filters.offset !== undefined) params.set('offset', String(filters.offset));\n\n  return useQuery<YamlWorkflowListResponse>({\n    queryKey: ['yamlWorkflows', filters],\n    queryFn: () => apiFetch(`/yaml-workflows?${params}`),\n  });\n}\n\nexport function useYamlWorkflowAppIds() {\n  return useQuery<{ app_ids: string[] }>({\n    queryKey: ['yamlWorkflowAppIds'],\n    queryFn: () => apiFetch('/yaml-workflows/app-ids'),\n  });\n}\n\nexport function useYamlWorkflowByTopic(graphTopic: string | undefined, appId?: string) {\n  return useQuery<YamlWorkflowListResponse>({\n    queryKey: ['yamlWorkflows', 'byTopic', graphTopic, appId],\n    queryFn: () => {\n      const params = new URLSearchParams({ graph_topic: graphTopic!, limit: '1' });\n      if (appId) params.set('app_id', appId);\n      return apiFetch(`/yaml-workflows?${params}`);\n    },\n    enabled: !!graphTopic,\n  });\n}\n\nexport function useYamlWorkflow(id: string) {\n  return useQuery<LTYamlWorkflowRecord>({\n    queryKey: ['yamlWorkflows', id],\n    queryFn: () => apiFetch(`/yaml-workflows/${id}`),\n    enabled: !!id,\n  });\n}\n\nexport function useCreateYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (input: {\n      workflow_id: string;\n      task_queue: string;\n      workflow_name: string;\n      name: string;\n      description?: string;\n      app_id?: string;\n      subscribes?: string;\n      tags?: string[];\n      compilation_feedback?: string;\n    }) =>\n      apiFetch<LTYamlWorkflowRecord>('/yaml-workflows', {\n        method: 'POST',\n        body: JSON.stringify(input),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useDeployYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/deploy`, {\n        method: 'POST',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useActivateYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/activate`, {\n        method: 'POST',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useInvokeYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: ({ id, data, sync, execute_as }: { id: string; data: Record<string, unknown>; sync?: boolean; execute_as?: string }) =>\n      apiFetch<{ result?: unknown; job_id?: string }>(`/yaml-workflows/${id}/invoke`, {\n        method: 'POST',\n        body: JSON.stringify({ data, sync, ...(execute_as ? { execute_as } : {}) }),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useRegenerateYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: ({ id, task_queue, compilation_feedback }: { id: string; task_queue?: string; compilation_feedback?: string }) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/regenerate`, {\n        method: 'POST',\n        body: JSON.stringify({ task_queue, compilation_feedback }),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useArchiveYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/archive`, {\n        method: 'POST',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useRestoreYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/restore`, {\n        method: 'POST',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflow'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useUpdateYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: ({ id, ...updates }: { id: string; yaml_content?: string; name?: string; description?: string; input_schema?: Record<string, unknown>; output_schema?: Record<string, unknown>; tags?: string[]; app_id?: string; graph_topic?: string }) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}`, {\n        method: 'PUT',\n        body: JSON.stringify(updates),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useDeleteYamlWorkflow() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<{ deleted: boolean }>(`/yaml-workflows/${id}`, {\n        method: 'DELETE',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\n// ── Cron scheduling ─────────────────────────────────────────────\n\nexport function useSetYamlCron() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: ({ id, cron_schedule, cron_envelope, execute_as }: {\n      id: string;\n      cron_schedule: string;\n      cron_envelope?: Record<string, unknown> | null;\n      execute_as?: string | null;\n    }) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/cron`, {\n        method: 'PUT',\n        body: JSON.stringify({ cron_schedule, cron_envelope, execute_as }),\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\nexport function useClearYamlCron() {\n  const queryClient = useQueryClient();\n  return useMutation({\n    mutationFn: (id: string) =>\n      apiFetch<LTYamlWorkflowRecord>(`/yaml-workflows/${id}/cron`, {\n        method: 'DELETE',\n      }),\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['yamlWorkflows'], refetchType: 'all' });\n    },\n  });\n}\n\n// ── Version history ─────────────────────────────────────────────\n\nexport function useYamlWorkflowVersions(id: string) {\n  return useQuery<{ versions: LTYamlWorkflowVersion[]; total: number }>({\n    queryKey: ['yamlWorkflows', id, 'versions'],\n    queryFn: () => apiFetch(`/yaml-workflows/${id}/versions`),\n    enabled: !!id,\n  });\n}\n\nexport function useYamlWorkflowVersion(id: string, version: number | null) {\n  return useQuery<LTYamlWorkflowVersion>({\n    queryKey: ['yamlWorkflows', id, 'versions', version],\n    queryFn: () => apiFetch(`/yaml-workflows/${id}/versions/${version}`),\n    enabled: !!id && version !== null,\n  });\n}\n"],"names":["useYamlWorkflows","filters","params","useQuery","apiFetch","useYamlWorkflowAppIds","useYamlWorkflow","id","useCreateYamlWorkflow","queryClient","useQueryClient","useMutation","input","useDeployYamlWorkflow","useActivateYamlWorkflow","useInvokeYamlWorkflow","data","sync","execute_as","useRegenerateYamlWorkflow","task_queue","compilation_feedback","useArchiveYamlWorkflow","useRestoreYamlWorkflow","useUpdateYamlWorkflow","updates","useDeleteYamlWorkflow","useYamlWorkflowVersions","useYamlWorkflowVersion","version"],"mappings":"qGAmBO,SAASA,EAAiBC,EAA+B,GAAI,CAClE,MAAMC,EAAS,IAAI,gBACnB,OAAID,EAAQ,QAAQC,EAAO,IAAI,SAAUD,EAAQ,MAAM,EACnDA,EAAQ,aAAaC,EAAO,IAAI,cAAeD,EAAQ,WAAW,EAClEA,EAAQ,QAAQC,EAAO,IAAI,SAAUD,EAAQ,MAAM,EACnDA,EAAQ,QAAQC,EAAO,IAAI,SAAUD,EAAQ,MAAM,EACnDA,EAAQ,QAAQC,EAAO,IAAI,SAAUD,EAAQ,MAAM,EACnDA,EAAQ,OAAOC,EAAO,IAAI,QAAS,OAAOD,EAAQ,KAAK,CAAC,EACxDA,EAAQ,SAAW,QAAWC,EAAO,IAAI,SAAU,OAAOD,EAAQ,MAAM,CAAC,EAEtEE,EAAmC,CACxC,SAAU,CAAC,gBAAiBF,CAAO,EACnC,QAAS,IAAMG,EAAS,mBAAmBF,CAAM,EAAE,CAAA,CACpD,CACH,CAEO,SAASG,GAAwB,CACtC,OAAOF,EAAgC,CACrC,SAAU,CAAC,oBAAoB,EAC/B,QAAS,IAAMC,EAAS,yBAAyB,CAAA,CAClD,CACH,CAcO,SAASE,EAAgBC,EAAY,CAC1C,OAAOJ,EAA+B,CACpC,SAAU,CAAC,gBAAiBI,CAAE,EAC9B,QAAS,IAAMH,EAAS,mBAAmBG,CAAE,EAAE,EAC/C,QAAS,CAAC,CAACA,CAAA,CACZ,CACH,CAEO,SAASC,GAAwB,CACtC,MAAMC,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaC,GAWXR,EAA+B,kBAAmB,CAChD,OAAQ,OACR,KAAM,KAAK,UAAUQ,CAAK,CAAA,CAC3B,EACH,UAAW,IAAM,CACfH,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASI,GAAwB,CACtC,MAAMJ,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,UAAW,CAC7D,OAAQ,MAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASK,GAA0B,CACxC,MAAML,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,YAAa,CAC/D,OAAQ,MAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASM,GAAwB,CACtC,MAAMN,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAY,CAAC,CAAE,GAAAJ,EAAI,KAAAS,EAAM,KAAAC,EAAM,WAAAC,KAC7Bd,EAAgD,mBAAmBG,CAAE,UAAW,CAC9E,OAAQ,OACR,KAAM,KAAK,UAAU,CAAE,KAAAS,EAAM,KAAAC,EAAM,GAAIC,EAAa,CAAE,WAAAA,CAAA,EAAe,GAAK,CAAA,CAC3E,EACH,UAAW,IAAM,CACfT,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASU,GAA4B,CAC1C,MAAMV,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAY,CAAC,CAAE,GAAAJ,EAAI,WAAAa,EAAY,qBAAAC,KAC7BjB,EAA+B,mBAAmBG,CAAE,cAAe,CACjE,OAAQ,OACR,KAAM,KAAK,UAAU,CAAE,WAAAa,EAAY,qBAAAC,EAAsB,CAAA,CAC1D,EACH,UAAW,IAAM,CACfZ,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASa,GAAyB,CACvC,MAAMb,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,WAAY,CAC9D,OAAQ,MAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASc,GAAyB,CACvC,MAAMd,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,WAAY,CAC9D,OAAQ,MAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,EACjFA,EAAY,kBAAkB,CAAE,SAAU,CAAC,cAAc,EAAG,YAAa,MAAO,CAClF,CAAA,CACD,CACH,CAEO,SAASe,GAAwB,CACtC,MAAMf,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAY,CAAC,CAAE,GAAAJ,EAAI,GAAGkB,KACpBrB,EAA+B,mBAAmBG,CAAE,GAAI,CACtD,OAAQ,MACR,KAAM,KAAK,UAAUkB,CAAO,CAAA,CAC7B,EACH,UAAW,IAAM,CACfhB,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAEO,SAASiB,GAAwB,CACtC,MAAMjB,EAAcC,EAAA,EACpB,OAAOC,EAAY,CACjB,WAAaJ,GACXH,EAA+B,mBAAmBG,CAAE,GAAI,CACtD,OAAQ,QAAA,CACT,EACH,UAAW,IAAM,CACfE,EAAY,kBAAkB,CAAE,SAAU,CAAC,eAAe,EAAG,YAAa,MAAO,CACnF,CAAA,CACD,CACH,CAsCO,SAASkB,EAAwBpB,EAAY,CAClD,OAAOJ,EAA+D,CACpE,SAAU,CAAC,gBAAiBI,EAAI,UAAU,EAC1C,QAAS,IAAMH,EAAS,mBAAmBG,CAAE,WAAW,EACxD,QAAS,CAAC,CAACA,CAAA,CACZ,CACH,CAEO,SAASqB,EAAuBrB,EAAYsB,EAAwB,CACzE,OAAO1B,EAAgC,CACrC,SAAU,CAAC,gBAAiBI,EAAI,WAAYsB,CAAO,EACnD,QAAS,IAAMzB,EAAS,mBAAmBG,CAAE,aAAasB,CAAO,EAAE,EACnE,QAAS,CAAC,CAACtB,GAAMsB,IAAY,IAAA,CAC9B,CACH"}

package/dashboard/dist/index.html

@@ -8,11 +8,11 @@
     <link rel="preconnect" href="https://fonts.googleapis.com" />
     <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
     <link href="https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:wght@300;400;500;600;700&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet" />
-    <script type="module" crossorigin src="./assets/index-CIwlVfvV.js"></script>
+    <script type="module" crossorigin src="./assets/index-CgUcYveM.js"></script>
     <link rel="modulepreload" crossorigin href="./assets/vendor-query-DvWWuNIB.js">
     <link rel="modulepreload" crossorigin href="./assets/vendor-react-_9U4mKFr.js">
-    <link rel="modulepreload" crossorigin href="./assets/vendor-icons-DeBdvyKJ.js">
-    <link rel="stylesheet" crossorigin href="./assets/index-Bpvfr4OW.css">
+    <link rel="modulepreload" crossorigin href="./assets/vendor-icons-B7OcUM6b.js">
+    <link rel="stylesheet" crossorigin href="./assets/index-Dh8MJl3L.css">
   </head>
   <body>
     <div id="root"></div>

package/docs/accumulator.md

@@ -0,0 +1,113 @@
+# Open accumulator
+
+One escalation row is a container that fills over time. Items join it one at a time, the row stays pending while they do, and the waiting workflow resumes with the ordered collection when the container is full, when its window closes, or when someone closes it by hand. Every terminal path except cancel delivers the collection, so a timeout is a delivery window, never a failure.
+
+This page is the contract. The narrative lives in [Creating Escalations](hitl/escalation.md#open-accumulation--items-arrive-over-time) and [Resolution](hitl/resolution.md#accumulator-items); the endpoints in the [HTTP](api/http/escalations.md#accumulate-items) and [SDK](api/sdk/escalations.md#accumulate--accumulatebysignalkey--accumulatebymetadata) references.
+
+## Declaration
+
+```typescript
+const bin = await conditionalAccumulator<ItemPayload, ResolverPayload>(signalId, {
+  role: 'bin',
+  metadata: { binKey },
+  timeout: '4h',
+  accumulate: {
+    max?: number;            // count trigger; absent = unbounded
+    resolveAtMax?: boolean;  // default true; false makes max a cap only
+    unique?: boolean;        // default true; false replaces a repeated key in place
+  },
+});
+// AccumulatorResult<P, R> | null
+```
+
+`conditional` accepts the same `accumulate` field and returns `T | false | null`; `conditionalAccumulator` removes the `false` branch from the type because an accumulator never resumes with it. `accumulate` and `batch` are mutually exclusive on one wait.
+
+## Delivered value
+
+```typescript
+type AccumulatorResult<P, R> = R & {
+  $accumulated: Array<{ itemKey: string; payload?: P; at: string; actor?: string; reciprocalId?: string }>;
+  $trigger: 'count' | 'timeout' | 'resolve';
+  $resolution?: EscalationResolution;
+};
+```
+
+`$accumulated` is ordered by each entry's `at` (the database clock at the add), then by key. `R` is present only when `$trigger` is `'resolve'`.
+
+| Path | `$trigger` | Row status | `resolver_payload` stored | Wait resumes with |
+|------|------------|------------|---------------------------|-------------------|
+| The add that reaches `max` (with `resolveAtMax`) | `count` | `resolved` | `{ $accumulated, $trigger }` | the same, plus `$resolution` when the adder carried identity |
+| The `timeout` timer fires first | `timeout` | `expired` | `{ $accumulated, $trigger }` | the same |
+| `resolve` / `resolveByMetadata` / `resolveAllOrNone` | `resolve` | `resolved` | `{ $accumulated, $trigger, ...resolverPayload }` | the same, plus `$resolution` |
+| `cancel` | none | `cancelled` | untouched | `null` (items stay on the row) |
+
+## Reserved keys
+
+Written by the fold at creation, inside the row's Leg1 commit, and maintained by every add and remove:
+
+| Surface | Key | Meaning |
+|---------|-----|---------|
+| `metadata` (GIN-indexed) | `accumulate_count` | items held right now |
+| `metadata` | `accumulate_max` | the count trigger, or `null` when unbounded |
+| `metadata` | `accumulate_keys` | held item keys; `metadata @> '{"accumulate_keys":["ORD-9"]}'` finds the container holding that order |
+| `envelope` | `accumulate_items` | `Record<itemKey, { payload?, at, actor?, reciprocalId? }>` |
+| `envelope` | `accumulate_config` | the folded `{ unique, resolveAtMax }` |
+
+A batch wait may add `partialOnTimeout: true`; it stores `envelope.batch_partial_on_timeout` and its timer delivers `{ ...filledItems, $trigger: 'timeout' }` instead of `false`.
+
+## Operations
+
+| Operation | HTTP | SDK | MCP |
+|-----------|------|-----|-----|
+| Add by id | `POST /api/escalations/:id/accumulate` | `lt.escalations.accumulate` | `accumulate_item` |
+| Add by signal key | `POST /api/escalations/accumulate-by-signal-key` | `accumulateBySignalKey` | |
+| Add by facet | `POST /api/escalations/accumulate-by-metadata` | `accumulateByMetadata` | |
+| Remove by id | `POST /api/escalations/:id/remove-item` | `removeItem` | `remove_item` |
+| Remove by signal key / facet | `POST /api/escalations/remove-item-by-signal-key`, `/remove-item-by-metadata` | `removeItemBySignalKey`, `removeItemByMetadata` | |
+| Read the collection | `GET /api/escalations/:id/items`, `GET /api/escalations/items-by-signal-key` | `getItems`, `getItemsBySignalKey` | `get_escalation_items` (admin; `id` or `signalKey`) |
+| Scan | the `accumulate` verb; item mode answers `no_open_container` when the container closed; templates read `{claim.<facet>}` and `{item.<facet>}` | | |
+
+An add takes `itemKey` (1 to 128 characters), an optional `payload` (validated against the container role's versioned form when present), an optional `metadata` patch (reserved keys rejected), `assertClaim` (by id), and an optional `reciprocal`.
+
+### Outcomes
+
+| Outcome | HTTP | Meaning |
+|---------|------|---------|
+| `accepted` | 200 | the item landed; `count`, `remaining` (`null` when unbounded) |
+| `completed` | 200 | this add reached `max`; the row resolved and the waiter woke, `signaled`, `workflowId` |
+| `duplicate-item` | 409 | the key is already held (`unique`), row untouched |
+| `full` | 409 | `max` held and the key is new (`resolveAtMax: false`, or a race with the completing add) |
+| `not-accumulator` | 400 | the row carries no `accumulate` declaration |
+| `not-found` | 404 | unknown row, or outside the caller's scope on the ingress forms |
+| `already-resolved`, `already-expired`, `already-cancelled` | 409 | the row is terminal |
+| `claimed-by-other`, `claim-expired` | 409 | the `assertClaim` assertion failed |
+| `reciprocal-not-found` | 404 | the reciprocal selector matched nothing the caller may act on |
+| `reciprocal-not-accumulator` | 400 | the reciprocal row carries no declaration |
+| `reciprocal-duplicate`, `reciprocal-full`, `reciprocal-terminal` | 409 | the reciprocal blocked the add; the container is untouched |
+
+Removals answer `removed` (200, with the new `count`), `item-absent` (404), `reciprocal-absent` (404), and the row and reciprocal states above.
+
+## Reciprocal adds
+
+A reciprocal names a second accumulator row (`id`, `signalKey`, or `key` + `value`), typically the item's own escalation declared `accumulate: { max: 1 }`. Both rows are locked in one ordered statement, both guards are evaluated before either write, and both rows change or neither. The container gains the item under `itemKey`; the reciprocal gains the container's id as its item key; each entry carries the other row's id as `reciprocalId`. A side that reaches its `max` resolves and wakes in that same statement. Removal with a reciprocal removes from both rows or neither.
+
+## Guarantees
+
+- **One statement per write.** An add or a removal is a single guarded UPDATE; the resolve-at-max and the wake enqueue ride inside it. There is no read-then-write anywhere on the path; the escalation layer's lookups only pick rows and gate access, and the statement re-checks every predicate under lock.
+- **Exactly one completion.** Two adds racing for the last slot yield one `completed` and one terminal answer.
+- **Row truth equals delivered value.** Whatever the workflow receives is what the row stores as `resolver_payload`, on every path.
+- **Timeout is settled once.** The expiry statement and every resolve lock the row and re-check `pending`; if a resolve won, the timer path skips the resume entirely.
+- **Facets are recomputed, never patched.** `accumulate_count` is derived from `accumulate_keys` in the same statement, so the two never drift.
+- **Additive.** Existing `conditional`, `batch`, `resolve`, and `cancel` callers are unchanged; `partialOnTimeout` is opt-in.
+
+## Events
+
+Every accepted add and removal publishes `escalation.updated` for the container (and for the reciprocal) with `item_key`, `count`, `remaining`, `actor`, `reciprocal_id`, and `removed: true` on a removal. A completing add publishes `escalation.resolved`. The rows are the ledger: entries carry `at`, `actor`, and `reciprocalId`; `accumulate_keys` answers membership from the GIN index; `accumulate_count` and `accumulate_max` are numeric facets for aggregates and range queries.
+
+## Deferred
+
+`idleTimeoutSeconds` (the window re-arms on each add) and `armTimeoutOnFirst` (the window starts at the first add) need a re-armable engine timer; today the window is a fixed delayed message written at park. A cross-row item event table is also deferred; the rows carry the per-item history. Neither changes the contract above.
+
+## Versions
+
+HotMesh 0.29.0 (`accumulate`, `partialOnTimeout`, timeout delivery, reciprocal statement) and long-tail 0.21.1 (root export of `conditionalAccumulator`, `no_open_container`, claim and item template tokens, items by signal key).

package/docs/api/http/escalations.md

@@ -1122,6 +1122,96 @@ Single atomic query finds the pending escalation by metadata, auto-claims if unc
 }
 ```
 
+## Batch items
+
+```
+POST /api/escalations/:id/resolve-batch-item
+POST /api/escalations/resolve-batch-item-by-signal-key
+POST /api/escalations/resolve-batch-item-by-metadata
+```
+
+Submit ONE declared item of a batch escalation (a `conditional` wait created with `batch: [...]`). Interim items answer `{ outcome: 'accepted', remaining }`; the LAST item answers `{ outcome: 'completed', remaining: 0, signaled, escalationId, workflowId }` and the waiting workflow resumes with the full collection, in the same statement. Each item validates against the row's versioned role form (canonical 422). Duplicates answer 409 (`Batch item already submitted`), undeclared keys 400, a non-batch row 400.
+
+**Body (by id):** `{ itemKey, resolverPayload, metadata?, assertClaim? }`. **By signal key:** `{ signalKey, itemKey, resolverPayload, metadata? }`. **By metadata:** `{ key, value, itemKey, resolverPayload, metadata?, restrictRoles? }`.
+
+Claim semantics: claim-agnostic by default; `assertClaim: true` (by id) requires the caller's own live claim, asserted atomically. RBAC mirrors the single-resolve forms: the by-id form answers 404 for rows outside the caller's read scope and 403 inside it but outside write scope; the ingress forms collapse a write denial to 404.
+
+## Accumulate items
+
+```
+POST /api/escalations/:id/accumulate
+POST /api/escalations/accumulate-by-signal-key
+POST /api/escalations/accumulate-by-metadata
+```
+
+Add ONE item to an open accumulator escalation (a `conditionalAccumulator` wait declared with `accumulate: {...}`). Interim adds are atomic row appends; the add that reaches `max` completes the escalation and the waiting workflow resumes with the ordered collection, in the same statement.
+
+**Body (by id):**
+
+```json
+{
+  "itemKey": "ORD-9",
+  "payload": { "weight": 2 },
+  "metadata": { "lane": "A" },
+  "assertClaim": false,
+  "reciprocal": { "id": "…" }
+}
+```
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `itemKey` | `string` | **Required.** The key the item is held under (1 to 128 characters) |
+| `payload` | `object` | Stored on the entry and delivered inside `$accumulated`; validates against the row's versioned role form when present (canonical 422) |
+| `metadata` | `object` | Merge patch for the container's GIN-indexed metadata, same statement; reserved `accumulate_*` keys are rejected |
+| `assertClaim` | `boolean` | By id only. Require the caller's own live claim, asserted atomically |
+| `reciprocal` | `object` | A second accumulator row written in the same statement, both or neither. Exactly one of `id`, `signalKey`, or `key` + `value`; optional `payload` stored on its entry |
+
+**By signal key:** `{ signalKey, itemKey, payload?, metadata?, reciprocal? }`. **By metadata:** `{ key, value, itemKey, payload?, metadata?, restrictRoles?, reciprocal? }` selects the highest priority pending accumulator whose metadata contains the key/value, within the caller's write scope intersected with `restrictRoles`.
+
+**Response 200 (interim):**
+
+```json
+{ "outcome": "accepted", "count": 3, "remaining": 9, "escalationId": "…",
+  "reciprocal": { "outcome": "completed", "count": 1, "remaining": 0, "escalationId": "…", "signaled": true } }
+```
+
+`remaining` is `null` on an unbounded accumulator. `reciprocal` is present only when one was named.
+
+**Response 200 (completed):**
+
+```json
+{ "outcome": "completed", "count": 12, "remaining": 0, "signaled": true, "escalationId": "…", "workflowId": "…" }
+```
+
+**Errors:** 400 `itemKey is required`, `Escalation is not an accumulator`, `payload must be an object`, `reciprocal requires exactly one of id, signalKey, or key/value`; 404 `Escalation not found` (unknown, or outside the caller's scope on the ingress forms), `Reciprocal escalation not found`; 409 `Item already held` (`{ itemKey }`), `Accumulator is full`, `Escalation is claimed by another user`, `Your claim has expired`, `Escalation not available for accumulation` (resolved, cancelled, or expired), and the reciprocal blocks `Reciprocal escalation already holds this container`, `Reciprocal accumulator is full`, `Reciprocal escalation is no longer pending` (each with `outcome`); 422 payload violations.
+
+```
+POST /api/escalations/:id/remove-item
+POST /api/escalations/remove-item-by-signal-key
+POST /api/escalations/remove-item-by-metadata
+```
+
+Remove ONE held item from a pending accumulator in one guarded statement. The row stays pending and the waiter never wakes. **Body:** `{ itemKey, reciprocal? }` (plus the selector fields of the ingress forms). **Response 200:** `{ "outcome": "removed", "count": 2, "escalationId": "…", "reciprocal"?: { "count", "escalationId" } }`. **Errors:** 404 `Item not held by this escalation` (`{ itemKey }`), `Reciprocal escalation does not hold this container`; 400 and 409 as above.
+
+```
+GET /api/escalations/:id/items
+GET /api/escalations/items-by-signal-key?signalKey=…
+```
+
+The held items of an accumulator or batch row in arrival order, by row id or by the `signal_key` a workflow already knows. Read access; 404 non-disclosure.
+
+```json
+{
+  "escalationId": "…", "kind": "accumulate", "status": "pending", "count": 2, "max": 12,
+  "items": [
+    { "itemKey": "ORD-9", "payload": { "weight": 2 }, "at": "2026-09-18T14:02:11.402Z", "actor": "…", "reciprocalId": "…" },
+    { "itemKey": "ORD-12", "at": "2026-09-18T14:03:40.118Z", "actor": "…" }
+  ]
+}
+```
+
+A batch row answers `kind: "batch"`, `max` = the declared size, and `pending` = the keys still awaiting submission. A row that holds no items answers 400 `Escalation holds no items`.
+
 ## Resolve a set of escalations
 
 ```

package/docs/api/http/roles.md

@@ -383,6 +383,7 @@ When the update changes `form_schema` or `metadata_schema`, the new pair is snap
 | `upstream_roles` | `string[] \| null` | Replace the set of roles this station draws input from across other Operations sequences (omitted = preserve; `null` or `[]` = clear). Every entry must name an existing role other than this one. Distinct from `parent_role`, which places the role in its own sequence. |
 | `list_schema` | `object \| null` | Rich formatting (x-lt-* markup) for this role's escalation LIST page. Versions independently of `form_schema`; the list always renders the latest |
 | `default_pins` | `array \| null` | Pinned-view seeds for members: `[{ label, url, badge? }]` with dashboard-relative `url`s. Members promote, hide, or reorder them via their own preferences (`/api/me/preferences`). `null` clears |
+| `portals` | `array \| null` | The role's named portals: `[{ key, label, rows, counts? }]`, `key` a slug unique within the role, `rows` 1..4 rows of 1..6 pin cells `{ label, url, badge? }`, `counts` up to 8 tiles `{ label, url, blurb? }` shown above the panels, each portal rendered as one page at `/portal/<role>/<key>`. Up to 12. `null` clears |
 | `change_summary` | `string` | Label recorded on the schema version snapshot when this update changes a schema field |
 
 **Example request** — configure a role as a station in the ops view:

package/docs/api/sdk/escalations.md

@@ -436,6 +436,25 @@ fires first resumes the workflow with `false` and expires the row in a guarded
 UPDATE, so operators can never resolve into a workflow that already moved on.
 `expiresAt`, by contrast, is display metadata on the row — it arms nothing.
 
+### Open accumulation (`accumulate`)
+
+`conditionalAccumulator<P, R>(signalId, config)` is `conditional` typed for an open accumulator: the config carries `accumulate: { max?, resolveAtMax?, unique? }`, and the wait resolves with `AccumulatorResult<P, R>` (`{ $accumulated: AccumulatedItem<P>[], $trigger: 'count' | 'timeout' | 'resolve', ...R }`) on every terminal path except cancel (`null`). `false` is not in the return type because a timeout delivers the collection. `P` types each item's payload; `R` types the resolver payload merged in when a person closes the container by hand.
+
+```typescript
+import { conditionalAccumulator } from '@hotmeshio/long-tail';
+
+const bin = await conditionalAccumulator<BagV1, { shippedBy?: string }>(signalId, {
+  role: 'bin',
+  metadata: { binKey },
+  accumulate: { max: 12 },
+  timeout: '4h',
+});
+if (bin === null) return cancelled();
+ship(bin.$accumulated.map((item) => item.itemKey), bin.$trigger);
+```
+
+Requires hotmesh 0.29.0+. `conditional` accepts the same `accumulate` field and returns `T | false | null`; `partialOnTimeout: true` on a `batch` wait likewise makes the timer deliver the filled items with `$trigger: 'timeout'`. See [Creating Escalations](../../hitl/escalation.md#open-accumulation--items-arrive-over-time).
+
 ### Two-step form
 
 Create the escalation first (e.g. to enrich routing metadata), then wait:
@@ -826,6 +845,79 @@ const result = await lt.escalations.resolveByMetadata({
 
 **Auth:** Required
 
+## resolveBatchItem / resolveBatchItemBySignalKey / resolveBatchItemByMetadata
+
+Submit ONE declared item of a batch escalation (`conditional` with `batch: [...]`). Interim items return `{ outcome: 'accepted', remaining, escalationId }`; the LAST item returns `{ outcome: 'completed', remaining: 0, signaled, escalationId, workflowId }` and the waiting workflow resumes with the full collection. See [Resolution — Batch items](../../hitl/resolution.md#batch-items).
+
+```typescript
+await lt.escalations.resolveBatchItem({ id, itemKey: 'weld', resolverPayload: { ok: true }, metadata?, assertClaim? });
+await lt.escalations.resolveBatchItemBySignalKey({ signalKey, itemKey, resolverPayload, metadata? });
+await lt.escalations.resolveBatchItemByMetadata({ key, value, itemKey, resolverPayload, metadata?, restrictRoles? });
+```
+
+**Returns:** `LTApiResult<{ outcome, remaining, escalationId, signaled?, workflowId? }>`. 409 on a duplicate item, 400 on an undeclared key or a non-batch row.
+
+**Auth:** Required
+
+## accumulate / accumulateBySignalKey / accumulateByMetadata
+
+Add ONE item to an open accumulator escalation (`conditionalAccumulator` with `accumulate: {...}`). Interim adds return `accepted` with the count held and slots remaining; the add that reaches `max` returns `completed` and the waiting workflow resumes with the ordered collection, in the same statement. See [Resolution — Accumulator items](../../hitl/resolution.md#accumulator-items).
+
+```typescript
+const added = await lt.escalations.accumulate({
+  id: binId,
+  itemKey: orderId,
+  payload: { weight: 2 },
+  reciprocal: { id: bagEscalationId },
+});
+// added.data → { outcome: 'accepted', count: 1, remaining: 11, escalationId,
+//                reciprocal: { outcome: 'completed', count: 1, remaining: 0, escalationId, signaled: true } }
+
+await lt.escalations.accumulateBySignalKey({ signalKey, itemKey });
+await lt.escalations.accumulateByMetadata({ key: 'binKey', value: binKey, itemKey, restrictRoles: ['bin'] });
+```
+
+**Parameters:**
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `id` / `signalKey` / `key` + `value` | `string` | Yes | The container selector, one per method |
+| `itemKey` | `string` | Yes | The key the item is held under (1 to 128 characters) |
+| `payload` | `object` | No | Stored on the entry and delivered inside `$accumulated`; validates against the container's versioned role form |
+| `metadata` | `object` | No | Merge patch for the container metadata, same statement; reserved `accumulate_*` keys rejected |
+| `assertClaim` | `boolean` | No | By id only: require the caller's own live claim |
+| `reciprocal` | `object` | No | `{ id \| signalKey \| key + value, payload? }`: a second accumulator row written in the same statement, both or neither |
+| `restrictRoles` | `string[]` | No | By metadata only: expected queues, intersected with the caller's write scope |
+
+**Returns:** `LTApiResult<{ outcome: 'accepted' \| 'completed', count, remaining, escalationId, signaled?, workflowId?, reciprocal? }>`. `remaining` is `null` on an unbounded accumulator. 409 on `Item already held`, `Accumulator is full`, claim blocks, terminal rows, and reciprocal blocks; 400 on a non-accumulator; 404 non-disclosure.
+
+**Auth:** Required
+
+## removeItem / removeItemBySignalKey / removeItemByMetadata
+
+Remove ONE held item from a pending accumulator in one guarded statement. The row stays pending and the waiter never wakes.
+
+```typescript
+await lt.escalations.removeItem({ id: binId, itemKey: orderId, reciprocal: { id: bagEscalationId } });
+// → { outcome: 'removed', count: 11, escalationId, reciprocal?: { count, escalationId } }
+```
+
+**Returns:** `LTApiResult<{ outcome: 'removed', count, escalationId, reciprocal? }>`. 404 `Item not held by this escalation`.
+
+**Auth:** Required
+
+## getItems / getItemsBySignalKey
+
+The held items of an accumulator or batch row in arrival order, by row id or by the `signal_key` the parked workflow knows.
+
+```typescript
+const { data } = await lt.escalations.getItems({ id: binId });
+const same = await lt.escalations.getItemsBySignalKey({ signalKey: `bin-${binKey}` });
+// data → { escalationId, kind: 'accumulate' | 'batch', status, count, max, items: [{ itemKey, payload?, at, actor?, reciprocalId? }], pending? }
+```
+
+**Auth:** Required (read access; 404 non-disclosure)
+
 ## resolveByIds
 
 Resolve a set of escalations by id in one guarded statement (the set-based sibling of `resolve`). For bookkeeping rows woken collectively — it does not deliver a per-row signal, and the store enforces that: rows backing a live `condition()` waiter (`signal_key` set) stay `pending` and are excluded from the result. Settle waiter rows individually with `resolve`, which carries the wake. RBAC: a scoped caller may only resolve rows whose role they hold.

package/docs/api/sdk/roles.md

@@ -34,6 +34,7 @@ interface RoleDetail {
   priority_facet: string | null;
   list_schema: Record<string, any> | null;
   default_pins: { label: string; url: string; badge?: boolean }[] | null;
+  portals: { key: string; label: string; rows: { label: string; url: string; badge?: boolean }[][]; counts?: { label: string; url: string; blurb?: string }[] }[] | null;
   upstream_roles: string[];
   user_count: number;
   chain_count: number;
@@ -281,6 +282,7 @@ const result = await lt.roles.update({
 | `upstream_roles` | `string[] \| null` | No | Replace the set of roles this station draws input from across other Operations sequences (omitted = preserve; `null` or `[]` = clear). Distinct from `parent_role`, which places the role in its own sequence |
 | `list_schema` | `object \| null` | No | Rich formatting (x-lt-* markup) for this role's escalation LIST page; versions independently of `form_schema` |
 | `default_pins` | `array \| null` | No | Pinned-view seeds for members: `[{ label, url, badge? }]` with dashboard-relative `url`s. Members promote, hide, or reorder via their own preferences (`lt.me`) |
+| `portals` | `array \| null` | No | The role's named portals `[{ key, label, rows, counts? }]`, each 1..4 rows of 1..6 pin cells rendered as one page at `/portal/<role>/<key>`, with up to 8 count tiles above |
 | `change_summary` | `string` | No | Label recorded on the schema version snapshot when this update changes a schema field |
 
 When the update changes `form_schema` or `metadata_schema`, the new pair is snapshotted into the role's version history and `current_schema_version` advances.

package/docs/architecture.md

@@ -132,7 +132,7 @@ A pipeline workflow is a compiled deterministic workflow generated from a succes
 
 Pipeline workflows are stored in `lt_yaml_workflows` with status lifecycle: `draft` → `deployed` → `active` → `archived`. In the dashboard, pipeline workflows display a **Wand2** (magic wand) icon in purple.
 
-See the [Compilation Pipeline](compilation.md) guide for the full lifecycle and the [Workflows Guide](workflows.md) for detailed coverage of all three types.
+See the [Compilation Pipeline](https://github.com/hotmeshio/long-tail/blob/main/docs/donotpublish/compilation.md) guide for the full lifecycle and the [Workflows Guide](workflows.md) for detailed coverage of all three types.
 
 ## System Capabilities
 

package/docs/code-owned-configuration.md

@@ -75,7 +75,8 @@ they always have.)
 ## Roles: first-class declarations
 
 `roles[]` registers roles with titles, versioned form/metadata/list schemas,
-escalation targets, upstream inputs, dials, and pins:
+escalation targets, upstream inputs, dials, pins, and portals
+(`portals`, named matrices of pin cells, each rendered as one page):
 
 ```typescript
 roles: [

package/docs/dashboard.md

@@ -166,7 +166,7 @@ The MCP Tool Designer page lists previous tool design sessions and provides entr
 
 **Composer mode** — manual tool design for building tools from scratch using the visual DAG editor.
 
-Steps unlock sequentially in each wizard. Compiled tools appear in **Graph Workflows** and **Graph Executions**. See the [Compilation Pipeline](compilation.md) guide for details.
+Steps unlock sequentially in each wizard. Compiled tools appear in **Graph Workflows** and **Graph Executions**. See the [Compilation Pipeline](https://github.com/hotmeshio/long-tail/blob/main/docs/donotpublish/compilation.md) guide for details.
 
 ### MCP Server Tools
 
@@ -278,7 +278,9 @@ Accessible at `/admin/roles/:role`. One page per role — a quiet header carryin
 
 **Pins** — two live-save groups. **Link Variables** leads: the facet names members bind per device (`properties.link_variables` — name, optional label, optional default). A pin below may reference a variable as a facet value, `facets={"facility":"{lt:facility}"}`; each member device opens it scoped to its own binding (set from the user menu → Link variables), falling back to the declared default or, unbound, applying no filter. A caption under each templated pin previews the binding on the viewing device (`facility = 'soleful'` / `facility = <empty>`). **Default Pins** follows — the pinned-view seeds this role hands its members (`default_pins`): label, dashboard-relative URL, optional badge. Members see them in their Pinned nav section from first login (marked role-provided) and may promote, hide, or reorder them via preferences; promoting a templated pin copies the template, so it keeps following the device's bindings. See [Faceted Routing — Link variables](faceted-routing.md#link-variables).
 
-**API:** `PATCH /api/roles/:role` updates identity, Pace Board dials, placement, schemas, and pins.
+**Portal** — the role's named portals, each its pinned views laid out as one page. The editor mirrors the page: sheets, title bands, cell panels, dashed slots for adding. Name a portal and start it from a pin; then rows of cells, each cell a pin picked from the role's default pins or the admin's own pins, or typed as a label and URL, with editable panel titles (`portals`, up to 12 portals of 4 rows by 6). Edits join the page draft and **Save** writes them. A sketch shows each shape; **Open** opens `/portal/<role>/<key>`. See [Portal](hitl/portal.md).
+
+**API:** `PATCH /api/roles/:role` updates identity, Pace Board dials, placement, schemas, pins, and the portal.
 
 ### Escalation Schema
 
@@ -377,7 +379,7 @@ Accessible at `/escalations/available`. The central queue for escalation activit
 - **Columns:** a **Summary** cell (status dot + description or type), **Assignee** (claimant, or `—`), **Role** pill, **Priority**, and **Created**. The status dot distinguishes pending, claimed, resolved, cancelled, and expired; notification escalations show a bell.
 - **Faceted query** — beyond the filter bar, the queue takes a structured metadata query, all URL-backed so a query copy-pastes: `?facets={"orderId":"..."}` (equality, AND-ed), `?block=` (exclude), `?range=` (numeric bounds), `?exists=` (key present), `?roles=` (union of role queues), and `?orderBy=` (JSON sort). `?jeopardy=1` narrows to rows past the role's age threshold. List rows omit the envelope by default; `?include=envelope` pulls the full envelope and payload columns for rich views.
 - **Metadata value affordances** — each metadata key/value row carries a three-icon triad on hover: **filter** (scope the current role's queue to `key = value`), **search** (the same facet match across all roles), and **history** (open the entity's cross-queue interval timeline in the right panel — every role this value moved through, with durations and gaps). Filter-present, search-present, history-past. History renders for string values, since the timeline's GIN containment match serves JSON-string facets.
-- **View modes** (`?view=`) — `table` (the columns above), `timeline` (100 rows per page of cross-queue movement), and `rich`. When a role owns a [list schema](#escalations-list-schema), the list defaults to the role-authored `rich` view (the live item as a card, plus a load-on-demand history) with a **Table view** toggle back.
+- **View modes** (`?view=`) — `table` (the columns above), `timeline` (100 rows per page of cross-queue movement), and `rich`. A `?layout=` hint shapes the table: `compact` stays a tight table however narrow, holding non-identity columns until the container clears the split width; `cards` folds into console cards on purpose; absent, the table folds on its own below the card threshold (the same hint a portal pin carries, see [Portal](hitl/portal.md)). When a role owns a [list schema](#escalations-list-schema), the list defaults to the role-authored `rich` view (the live item as a card, plus a load-on-demand history) with a **Table view** toggle back.
 - **Claim** — the claim action locks an item to your user for a claim window (default 30 min). Only members of the role see its pending items; a member scoped `read_self` lands directly on their own assigned item rather than browsing the queue. Re-claiming your own expired item extends it rather than failing.
 - **Bulk actions (admin)** — row checkboxes surface a selection bar: **Claim**, **Assign**, **Unassign**, **Escalate** (move to another role), and **Cancel**. Assign opens a modal for the target user and claim duration; rows under a live claim are skipped unless the modal's takeover checkbox (shown when the selection includes live claims) reassigns them — admin/superadmin only. Unassign returns claimed rows to the pool. Each response reports how many rows were skipped and why. Scoped to a single role, the Cancel verb and its confirmation speak the role form's `x-lt-labels.cancel` vocabulary (`false` hides it). Assign also accepts a faceted query instead of an id list, so "claim everything matching this facet" is one call.
 
@@ -387,6 +389,10 @@ Accessible at `/escalations/available`. The central queue for escalation activit
 
 Accessible at `/escalations/queue`. The personal inbox — the items currently assigned to you across your roles. It carries the same title-as-role-selector, the same rich/table views, and the same metadata affordances as All Escalations, minus the bulk selection bar (every row is already yours). A **Claim expiry** column counts down each item's remaining window. The shell also auto-navigates here on hand-off: when a workflow assigns a follow-on escalation to you (`assigned_to = you`), the dashboard opens that item's detail directly.
 
+### Portal
+
+Accessible at `/portal/<role>/<key>` to any signed-in user, from the **Portals** section of the user menu, and from the rows that lead the role's group in the nav. Each of the role's `portals` renders as a grid: one row per declared row, each dividing its width among its cells, every cell a bounded panel of a pinned list view drawn with the same rich, table, and timeline components as All Escalations; the left nav steps aside on portal pages as it does in kiosk mode. Panels show the pin label, the live count, a view toggle and sort direction for the visit, a refresh, and a link to the full view; rows open the item detail. A kiosk role lands on its first portal as home. See [Portal](hitl/portal.md).
+
 ### Escalation Detail & Resolve Form
 
 Accessible at `/escalations/detail/:id`. Where a person completes the work the workflow is waiting on. The main column is the resolve form; a switchable side panel carries context.
@@ -399,7 +405,7 @@ Accessible at `/escalations/detail/:id`. Where a person completes the work the w
 - **Submit guard** — `x-lt-submit-guard` gates a parent on a child query (e.g. "every item in this batch must resolve first"): the dashboard disables Submit with a live count while rows remain, and the server re-checks the guard atomically inside the resolving `UPDATE` so no race slips through. `autoResolveWhenEmpty` submits the parent the moment the query empties.
 - **Transition hand-off** — `x-lt-transition` replaces the return-to-previous-page jump with a short wait screen: the workflow assigns a follow-on escalation back to the submitter, the screen detects it and navigates onward (or falls back to `x-lt-transition-done` after a bounded wait). This is the submit → side-effect → next-step chain (submit, a label prints, the harvest task opens).
 - **Batch resolution** — a `conditional({ batch })` escalation accumulates N items on one row; `POST /api/escalations/:id/resolve-batch-item` submits each (claim-agnostic by default, `assertClaim` to require your own live claim), and the last item wakes the workflow with the full collection.
-- **Side panel** — switchable views selected by the icon strip: **Help** (the form's `x-lt-help` markdown, `{{domain.path}}`-interpolated against the live record — escalation, metadata, envelope, payload, resolver, and `lookup.*` — or a state-aware hint like "Claim this escalation to enable the form"), **Details** (status, role, priority, claim provenance, timestamps, and for builders the identifier links), **AI Analysis** (what triage diagnosed and corrected, when AI is on), **Metadata** (the row's facets, with the same triad), **Context** (input envelope, escalation context, resolver payload), **Record** (the raw JSON, builders only), and **Errors** (the last submit's validation failures). The panel and form share the width as a flex set; it opens expanded on Help when the form carries `x-lt-help`.
+- **Side panel** — switchable views selected by the icon strip: **Help** (the form's `x-lt-help` markdown, `{{domain.path}}`-interpolated against the live record — escalation, metadata, envelope, payload, resolver, and `lookup.*` — or a state-aware hint like "Claim this escalation to enable the form"), **Details** (status, role, priority, claim provenance, timestamps, and for builders the identifier links), **AI Analysis** (what triage diagnosed and corrected, when AI is on), **Metadata** (the row's facets, with the same triad), **Items** (on an accumulator or batch row: the held items in arrival order with the count against max, each with its payload summary, arrival time, actor, and a link to its reciprocal row; on a pending accumulator the actor adds an item by key with an optional JSON payload or removes one, each through the same guarded statement the API runs), **Context** (input envelope, escalation context, resolver payload), **Record** (the raw JSON, builders only), and **Errors** (the last submit's validation failures). The panel and form share the width as a flex set; it opens expanded on Help when the form carries `x-lt-help`.
 - **Admin claim override** — when an item is held by someone else, admins and superadmins see **Reassign…** (hand the claim to another user, takeover implied) and **Return to queue** (unassign) in the action bar.
 
 **API:** `POST /api/escalations/:id/claim` claims, `/release` releases, `/resolve` resolves; `/resolve-batch-item` submits one batch item; `/escalate` moves; `/cancel` cancels. The role's form and its versions come from `GET /api/roles/:role/schema`.

package/docs/hitl/design.md

@@ -8,7 +8,7 @@ author schemas and copy, the rules the renderer applies to errors, and how a
 deployment plugs its own stylesheet in through static config.
 
 The full internal doctrine lives in
-[`docs/design-principles.md`](../design-principles.md); the reference form
+[`docs/donotpublish/design-principles.md`](https://github.com/hotmeshio/long-tail/blob/main/docs/donotpublish/design-principles.md); the reference form
 implementation is `examples/workflows/acme-stations`.
 
 ---

package/docs/hitl/escalation.md

@@ -103,7 +103,43 @@ The declaration folds into the row at creation, inside the same Leg1 commit:
 
 Items are submitted via `POST /api/escalations/:id/resolve-batch-item`, `POST /api/escalations/resolve-batch-item-by-signal-key` (the deterministic home signal id — no UUID lookup, no facet duplication), or `POST /api/escalations/resolve-batch-item-by-metadata` (see [Resolution — Batch items](resolution.md)). Each item validates against the same versioned role form a single-item resolver gets, `schemaVersion` pins included. Each fill is one guarded statement: the payload lands only while its key is still pending (duplicates return `duplicate-item` untouched), and the LAST fill resolves the row, stores the assembled collection as `resolver_payload`, and wakes this wait — atomically. The completing submission's `$resolution` rides the delivered collection.
 
-`timeout` and cancellation keep their standard semantics (`false` / `null`); a plain resolve on a batch row remains an admin override that resolves the whole row with the payload given.
+`timeout` and cancellation keep their standard semantics (`false` / `null`); a plain resolve on a batch row remains an admin override that resolves the whole row with the payload given. Add `partialOnTimeout: true` (hotmesh 0.29.0+) and the timer instead resumes the wait with the items filled so far plus `$trigger: 'timeout'`, the same value the expired row stores as `resolver_payload`.
+
+### Open accumulation — items arrive over time
+
+Declare `accumulate` and the escalation becomes an open container: items join it one at a time through `accumulateItem` while the row stays pending, and the wait resumes with the ordered collection when the container is full, when its window closes, or when someone resolves it by hand. A timeout is a delivery, never a failure, so the wait has no `false` branch; `conditionalAccumulator` types that contract.
+
+```typescript
+import { conditionalAccumulator } from '@hotmeshio/long-tail';
+
+const bin = await conditionalAccumulator<BagV1, { shippedBy?: string }>(signalId, {
+  role: 'bin',
+  description: 'Scan each bag into the bin',
+  metadata: { binKey },
+  accumulate: { max: 12 },   // count trigger; omit for an unbounded window
+  timeout: '4h',             // the window
+});
+if (bin === null) { /* cancelled */ }
+bin.$trigger;      // 'count' | 'timeout' | 'resolve'
+bin.$accumulated;  // [{ itemKey, payload?, at, actor?, reciprocalId? }, ...] in arrival order
+bin.shippedBy;     // present only when $trigger is 'resolve' (the resolver's payload merges in)
+```
+
+`accumulate` takes three dials. `max` is the count trigger; absent, only the timer or a manual resolve ends the wait. `resolveAtMax: false` makes `max` a cap: the last slot answers `accepted`, further adds answer `full`, and the wait still ends by timer or resolve. `unique: false` lets a repeated item key replace its entry in place; the default answers `duplicate-item` and leaves the row untouched.
+
+The declaration folds into the row at creation, inside the same Leg1 commit:
+
+- `metadata.accumulate_count` — items held right now, recomputed in every add and remove
+- `metadata.accumulate_max` — the count trigger, or `null` when unbounded
+- `metadata.accumulate_keys` — the held item keys (`@>`-queryable: `{"accumulate_keys":["ORD-9"]}` finds the container holding that order)
+- `envelope.accumulate_items` — `Record<itemKey, { payload?, at, actor?, reciprocalId? }>`, with `at` stamped by the database clock in the add statement
+- `envelope.accumulate_config` — the folded `{ unique, resolveAtMax }`
+
+Items are added via `POST /api/escalations/:id/accumulate`, `POST /api/escalations/accumulate-by-signal-key`, or `POST /api/escalations/accumulate-by-metadata`, removed via the matching `remove-item` forms, and read in arrival order via `GET /api/escalations/:id/items` (see [Resolution — Accumulator items](resolution.md#accumulator-items)). Each add is one guarded statement: the entry lands only while the row is pending and the key is not already held, the facets recompute, and the add that reaches `max` resolves the row, stores `{ $accumulated, $trigger: 'count' }` as `resolver_payload`, and wakes this wait, atomically. When the timer fires first the expiry statement stores and delivers `{ $accumulated, $trigger: 'timeout' }` and the row is `expired`; a manual `resolve` stores and delivers the collection merged with the resolver's payload under `$trigger: 'resolve'`. Cancellation still yields `null` with the held items preserved on the row.
+
+A **reciprocal** add writes two accumulator rows in that same statement, both or neither: the container gains the item, and a second row (the item's own escalation, declared `accumulate: { max: 1 }`) gains the container's id as its item key. Each entry carries the other row's id as `reciprocalId`, so "which bin holds this bag" reads from the bag's row and "which bags are in this bin" from the bin's, both as row truth. A blocked reciprocal (already resolved, full, already holding this container) answers `reciprocal-*` and the container is untouched. The `rollupBin` and `rollupMember` examples show both sides.
+
+`accumulate` and `batch` are mutually exclusive on one wait. The full contract, guarantees, and what is deferred are collected in [Open accumulator](../accumulator.md).
 
 ### Row completeness guarantee
 

package/docs/hitl/invoke-form.md

@@ -70,6 +70,10 @@ An array of conditions requires every one, so the prompt belongs to its tool and
 
 `x-lt-help` on the schema root is the longer reference for the side panel: markdown, tables, and `{{input.*}}` tokens that re-interpolate as the operator types.
 
+## From an escalation form
+
+A role's `form_schema` can offer the same invoke from inside the work item: an `x-lt-invoke` field names the workflow and maps the escalation's values into its payload, then either posts directly or opens this form in a dialog with those values in place. Visibility follows the same per-caller list, the payload meets the same gate, and the run reports over the same events. See [x-lt-invoke.md](x-lt-invoke.md).
+
 ## The Invoke Tool page
 
 The page is open to anyone the server lists an invokable workflow for. Builders reach **Invoke Tool** under Orchestrate; every other persona gets a **Tools** section in the nav that appears only when there is something to invoke. Each invokable workflow is a tool; the list sits on the left, grouped by task queue, with the first workflow preselected; the form takes the rest of the row. Below 1280px the list folds into a select and the form takes the full width.