@hotmeshio/long-tail 0.27.0 → 0.28.1

package/dashboard/dist/assets/{yaml-workflows-B0_JxRYQ.js.map → yaml-workflows-BgY1XHJx.js.map}

@@ -1 +1 @@
-{"version":3,"file":"yaml-workflows-B0_JxRYQ.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-BgY1XHJx.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-Dz6R8-Dw.js"></script>
+    <script type="module" crossorigin src="./assets/index-CkMHS-hG.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-DUYcKTjP.js">
-    <link rel="stylesheet" crossorigin href="./assets/index-CnU7Jjz3.css">
+    <link rel="modulepreload" crossorigin href="./assets/vendor-icons-fxBvvHBi.js">
+    <link rel="stylesheet" crossorigin href="./assets/index-B9uv-euR.css">
   </head>
   <body>
     <div id="root"></div>

package/docs/architecture.md

@@ -173,6 +173,7 @@ Long Tail ships with the following built-in servers:
 |--------|---------|
 | `long-tail-db-query` | Query tasks, escalations, process summaries, system health |
 | `long-tail-human-queue` | Route work to humans, check resolution, claim/resolve, escalate-and-wait |
+| `long-tail-machines` | The lines index with health, a line as its leader sees it, a wire dry run, machine-command rows, declare and retire lines |
 | `mcp-workflows-longtail` | Discover and invoke compiled workflow tools |
 | `long-tail-workflow-compiler` | Convert executions to YAML, deploy, list |
 | `long-tail-translation` | Translate content between languages |

package/docs/code-owned-configuration.md

@@ -66,6 +66,7 @@ The domain dictionary's override lives beside its declaration:
 | Scan schemes | `scanSchemes[]` | whole scheme + its rules (one ownership unit; `enabled` is declarative here) | — |
 | Domain dictionary | `mcp.domainDictionary` (inline) or `mcp.domainDictionaryPath` | whole document (version bumps once per change) | — |
 | Graph workflows | `graphWorkflows[]` | always compare-and-apply: description/schema sync, redeploy on YAML version bump | run history |
+| Machine lines | `machines.lines[]` | the whole line definition (`lt_machine_lines`; version bumps once per change) | lines declared through the API, their bot accounts, their rows |
 
 `certified` on a workflow profile is explicit-only under code ownership: an
 omitted flag registers the workflow as **not** certified. (The db-owned seed
@@ -133,6 +134,10 @@ declaration are reported as `version/category` orphans. The pass runs whether
 or not the dashboard scan affordances (`features.scanCodes`) are enabled —
 declaring schemes states intent.
 
+## Machine lines
+
+Lines ([machines](machines.md#declaration)) follow the dial too. Each row of `lt_machine_lines` keeps the line's definition, who declared it (`source`: `code` from `start({ machines })`, `api` from `PUT /api/machines/lines/:siteId/:lineId`), and a `version` that advances once per change. Db-owned, a code line is inserted when absent and left as it is afterwards, with a drift warning when the declaration differs. Code-owned, a code line is written whenever its declaration differs, advancing the version once, and dashboard or API edits to it are replaced at the next deploy. Boot then runs every enabled line the registry holds, code and API lines alike, and never deletes one: a line declared in code before and not now is reported and left standing, and a line leaves the registry only through `DELETE /api/machines/lines/:siteId/:lineId`.
+
 ## The boot report
 
 Each surface logs one line summarizing its pass:
@@ -140,6 +145,7 @@ Each surface logs one line summarizing its pass:
 ```
 [long-tail] config apply (workflows): applied 2, unchanged 31, db-owned 0
 [long-tail] config apply (roles): applied 1, unchanged 11, db-owned 0, orphans: [old-station]
+[lt-machines] lines: applied 2, unchanged 0, db-owned 0
 ```
 
 Orphans — database records of a declared surface with no matching declaration

package/docs/dashboard.md

@@ -14,6 +14,7 @@ The reactive, event-driven surface — where operations watch the floor and buil
 |------|-------|------|---------|
 | **Pace Board** | `/pace` | Gauge | Actual-vs-target flow across a segment of roles — a pace chart over the sequence, a live role table, and a role detail panel. Readable by every login (aggregate counts and trends) while `features.publicPaceBoard`, default on, stands. |
 | **Trend Board** | `/trends` | TrendingUp | Where the time went — the entity lens over a metadata facet (`serialNumber`, `orderId`): a state-mix summary, dwell rankings, and per-entity cross-queue timelines. Shares the combined board selector with the Pace Board. |
+| **Lines** | `/lines` | Factory | The index of every machine line with its health, searched and paged on the server, grouped by site, lines needing attention first, with a panel to declare, edit and retire lines. A line shows its machines as tiles or rows above a boxed wire tape with its own filters, pause and full screen, and a panel per machine with its snapshot, open rows, timeline, command and inspect tools. Present when `start({ machines })` runs a surface; see [Machines](machines.md#lines-view). Readable by the ops tier (superadmin, admin type, engineer); declaring and retiring takes an administrator. |
 | **Event Topics** | `/topics` | Radio | Topic catalog — browse all known event topics with descriptions, schemas, and subscriber counts. |
 | **Agents** | `/agents` | Bot | Autonomous event-driven automations (labeled **Automations** when AI is not configured). Configure subscriptions, schedules, and knowledge domains. |
 | **Capabilities** | `/capabilities` | Zap | Browse MCP tools grouped by capability category, with a live run panel. |
@@ -494,7 +495,7 @@ Accessible at `/files` (builder-only: superadmin or the `engineer` role). Browse
 
 The backend is selected by the `LT_STORAGE_BACKEND` env var — `local` (filesystem) or `s3` (S3-compatible, including MinIO). The same interface serves every backend; only env changes.
 
-**API:** `GET /api/file-browser/browse?prefix=<path>` lists. `POST /api/file-browser/upload?path=<path>` uploads raw bytes. `GET /api/file-browser/download/<path>` downloads; `DELETE /api/file-browser/delete/<path>` removes; `POST /api/file-browser/signed-url` mints a link. Token-scoped serving is at `GET /api/files/<path>?token=<jwt>`.
+**API:** `GET /api/file-browser/browse?prefix=<path>` lists. `POST /api/file-browser/upload?path=<path>[&sha256=<hex>]` uploads raw bytes; the stored object keeps the bytes' SHA-256, the response carries it, and a `sha256` the caller names is checked first, 422 when the bytes differ and nothing stored. `GET /api/file-browser/metadata/<path>` reports the digest beside size and type. `GET /api/file-browser/download/<path>` downloads; `DELETE /api/file-browser/delete/<path>` removes; `POST /api/file-browser/signed-url` mints a link. Token-scoped serving is at `GET /api/files/<path>?token=<jwt>`.
 
 ### Knowledge
 

package/docs/events.md

@@ -216,7 +216,7 @@ Events are published to `{subjectPrefix}.{event.type}`. Every built-in type star
 | Knowledge | `lt.events.system.knowledge.<domain>.<action>` |
 | File | `lt.events.system.file.<action>` |
 
-A role is written as one subject token: each run of characters other than letters, digits, `_` and `-` becomes `-`. Subscribe to `lt.events.system.escalation.<role>.>` for one role's escalations.
+A role is written as one subject token: each run of characters other than letters, digits, `_` and `-` becomes `-`. Subscribe to `lt.events.system.escalation.<role>.>` for one role's escalations. The machine surface publishes under `lt.events.machine.` ([machine surface events](#machine-surface-events)).
 
 ### Usage
 
@@ -360,6 +360,39 @@ class WebhookEventAdapter implements LTEventAdapter {
 }
 ```
 
+## Machine surface events
+
+A deployment that declares lines ([machines](machines.md)) publishes three event families under `machine.`, with the site, line and machine written as subject tokens the way roles are.
+
+| Event | Subject | Carries |
+|---|---|---|
+| Wire | `lt.events.machine.wire.<site>.<line>.<machine\|unknown>.<in\|out>` | One record per message a line's gateway reads (`in`) and per command, snapshot request or receipt it sends (`out`) |
+| Log | `lt.events.machine.log.<site>.<line>.<event>` | One per gateway log entry: its level, the event name and its context; `<event>` is the log event without its `machine_gateway.` prefix as one token |
+| Line | `lt.events.machine.line.<site>.<line>.<declared\|retired>` | A change to the line registry: the site, line, `source` (`code` or `api`), `version` and `action` |
+
+The wire record is the event's `data`:
+
+```typescript
+interface WireEvent {
+  type: 'machine.wire'; siteId: string; lineId: string; machineId: string | null; address: string | null;
+  direction: 'in' | 'out'; channel: string; topic: string; id: string | null; at: string; retained: boolean;
+  kind: 'presence' | 'snapshot' | 'job' | 'alarm' | 'telemetry' | 'report' | 'cmd' | 'reply' | 'receipt' | 'unknown';
+  event: string | null;    // job event, alarm action, command op, reply status
+  summary: string;         // one line from the kind, the event and the ids the body names
+  violations: string[];    // what the contract check found
+  actions: { verb: 'claim' | 'accumulate' | 'resolve' | 'create-row' | 'refuse' | 'hold' | 'unmatched' | 'unreadable' | 'ack' | 'none'; rowId?: string; itemKey?: string; detail?: string }[];
+  payload?: unknown;       // the raw wire payload
+}
+```
+
+`actions` is what the gateway did with the message: the verbs it performed on rows with their row ids (`claim`, `accumulate` with its `itemKey`, `resolve`, `create-row`), a verb Long Tail refused (`refuse`), a message held for a person under a strict codec (`hold`), one no row claimed (`unmatched`), one the codec or the planner could not read (`unreadable`), one admitted with nothing to do (`ack`), and `none` with a `detail` for everything else. Telemetry messages are many and join the wire record only with `MACHINE_WIRE_TELEMETRY=on`.
+
+A line event names a line and nothing more: each replica reads the registry row back and follows what the row says, so the row, never the event, decides whether a line runs.
+
+In a browser, builders receive every event whole. Anyone else receives `machine.wire` without `payload`, and `machine.log` and `machine.line` with their type and routing fields only, the same filter escalation events pass through on both the Socket.IO path and the NATS WebSocket proxy. A browser connected straight to a NATS WebSocket listener bypasses that filter, so production runs the proxy.
+
+The dashboard's line page subscribes to `lt.events.machine.wire.<site>.<line>.>`; the Lines index refreshes on `lt.events.machine.line.>` and `lt.events.machine.log.>`. A subscriber on `lt.events.>` sees all three families.
+
 ## When Events Fire
 
 Regardless of which adapter receives them, all events originate from three places in the system.

package/docs/hitl/lookups.md

@@ -15,13 +15,15 @@ An escalation can reference **versioned knowledge lookups** — enumerated lists
 |-------|----------|---------|
 | `domain` | yes | Knowledge domain |
 | `key` | yes | Entry key within the domain |
-| `version` | no | An edition to pin. Absent or `"current"`, the ref follows the newest edition |
+| `version` | no | An edition to pin, by its number or by the label it carries. Absent or `"current"`, the ref follows the newest edition |
 | `as` | no | The ref's form-context address, when the key alone is ambiguous |
 
 **Current refs** (no `version`, or `"current"`) read the entry's newest edition. A pending row reads the edition in force when its form renders, so a row that stays open for days shows today's list. A resolved or cancelled row reads the edition that was current when it closed, so its history shows the list its work was done against. Form schemas stay pinned (`schemaVersion`); the lists they read follow the knowledge entry.
 
 **Pinned refs** (`version: N`) name an immutable edition: every escalation created against edition 2 renders edition 2 forever, however the entry evolves afterward. Pin when the form must read one exact edition.
 
+**Labelled refs** (`version: "rev-b"`) name an edition by the label the write that minted it gave (`label` on `storeEntry`, `store_knowledge` and `append_knowledge`). A label names one edition of an entry for good, so a ref that carries the label a machine or a document quotes, such as a catalog revision, reads the right edition without knowing its number. A whole-number label no edition carries, `"2"`, reads edition 2. A label nothing carries resolves to nothing: the row is created all the same and its lookup answers `missing: true` until an edition with that label exists.
+
 A value picked from a current list is validated against the edition in force at submit, so an option removed while the form was open is refused with the canonical 422 and the person picks again.
 
 Refs live under the reserved `envelope.lookups` key — the unindexed, render-only bag beside `formDefaults`. They ride the engine's atomic write but never touch the GIN-indexed metadata surface: refs are form plumbing, not facets.
@@ -42,7 +44,7 @@ const decision = await conditional<CascadeResolverV1>(signalId, {
 });
 ```
 
-The refs fold into `envelope.lookups` as a pure transform — a wait with refs costs exactly what one without does. A malformed ref (missing field, a version that is not a positive integer or `"current"`) throws before the row is written; over the HTTP create surface the same validation answers with a 400.
+The refs fold into `envelope.lookups` as a pure transform — a wait with refs costs exactly what one without does. A malformed ref (missing field, a version that is neither a positive integer, a non-empty label nor `"current"`) throws before the row is written; over the HTTP create surface the same validation answers with a 400.
 
 ## Pinning on a Workflow Config
 
@@ -63,7 +65,7 @@ const fleetToolsConfig: LTWorkerConfig = {
 
 The Invoke Tool page fetches `GET /api/workflows/:type/input-lookups` each time the form opens; the grant is the invoke predicate, so whoever may start the workflow reads exactly the entries the config names. The invoke API resolves the same refs into the gate, so a value outside the edition is refused with the canonical 422. The registry detail page edits the refs under **Lookups** in its Invocation column; the preview renders against the resolved editions.
 
-The refs are checked twice on save. Shape first: a missing `domain` or `key`, a `version` that is not a positive integer or `"current"`, or an empty `as` answers `400` with the field named. Existence second: a ref with no edition behind it answers `400` naming the editions that do (`Lookup ref fleet/serial-numbers v3 names no edition (editions: v1, v2)`; a current ref to an entry with no editions says `current`), from `PUT /api/workflows/:type/config` and from the MCP `upsert_workflow_config` tool alike. On the worker boot path a malformed ref fails the boot; a ref whose edition is not yet written logs a warning, since seeds commonly run after registration. At run time the resolver holds each edition in memory once read (editions are immutable; a current ref first looks up which edition is newest), a missing edition answers `missing: true` for that ref without failing the batch, the Invoke Tool page shows which editions are unavailable, and the fields that read them follow the `x-lt-options` rules: a plain path falls back to the typed input, an interpolated path stays a disabled select and fails closed.
+The refs are checked twice on save. Shape first: a missing `domain` or `key`, a `version` that is neither a positive integer, a label nor `"current"`, or an empty `as` answers `400` with the field named. Existence second: a ref with no edition behind it answers `400` naming the editions that do (`Lookup ref fleet/serial-numbers v3 names no edition (editions: v1, v2)`; a current ref to an entry with no editions says `current`), from `PUT /api/workflows/:type/config` and from the MCP `upsert_workflow_config` tool alike. On the worker boot path a malformed ref fails the boot; a ref whose edition is not yet written logs a warning, since seeds commonly run after registration. At run time the resolver holds each edition in memory once read (editions are immutable; a current ref first looks up which edition is newest), a missing edition answers `missing: true` for that ref without failing the batch, the Invoke Tool page shows which editions are unavailable, and the fields that read them follow the `x-lt-options` rules: a plain path falls back to the typed input, an interpolated path stays a disabled select and fails closed.
 
 ## Versioning
 
@@ -73,7 +75,7 @@ Every knowledge entry carries a `current_version`, and every write that changes
 2. **Current refs follow** — every pending row with a current ref shows the new edition on its next render. Nothing to repin.
 3. **Pinned rows keep their edition** — an escalation pinned to v1 renders v1's list even after v5 exists. Repin the literal (and evolve the resolver payload type) when a pinned form should move.
 
-Inspect the lineage with `GET /api/knowledge/entry/versions?domain=catalog&key=materials`, `ltc kb versions catalog materials`, or the `list_knowledge_versions` MCP tool. Fetch a specific edition with `?version=N` on the entry endpoint.
+A write may name the edition it leaves current with `label` (`storeEntry`, `store_knowledge`, `append_knowledge`); the label stays with that edition, and a second edition of the entry cannot take it. Inspect the lineage with `GET /api/knowledge/entry/versions?domain=catalog&key=materials`, `ltc kb versions catalog materials`, or the `list_knowledge_versions` MCP tool; each edition lists its label. Fetch a specific edition with `?version=N` or `?version=<label>` on the entry endpoint, or `version` on `get_knowledge`.
 
 ## The Grant
 

package/docs/machines.md

@@ -6,20 +6,32 @@ This page is the contract for a host. A runnable factory lives in [examples/work
 
 ## Declaration
 
+Lines are declared two ways, and both land in one registry (`lt_machine_lines`) that every replica reads: in code, through `start({ machines })`, and through the API, `PUT /api/machines/lines/:siteId/:lineId`.
+
 ```typescript
 import { start, Machines } from '@hotmeshio/long-tail';
 
 await start({
   // ...database, workers, roles
   machines: {
-    lines: [Machines.loadLine('/etc/line.json')],
+    lines: [Machines.loadLine('/etc/line.json')],   // code lines; [] when every line comes through the API
     codec: myCodec,     // optional: the machines' wire protocol (default: the generic line protocol)
+    codecs: { 'site-1/line-2': otherCodec },   // optional: a codec of its own for one line
     rows: myRows,       // optional: how your rows read as handoffs (default: the standard handoff facets)
   },
 });
 ```
 
-Transports come from the environment (see [Configuration](#configuration)). `mqtt` is an optional peer dependency; install it in the host when a line runs.
+`codec` is the protocol every line speaks; `codecs` gives one line a protocol of its own, keyed `<siteId>/<lineId>`, so a print farm and a finishing line on different protocols run on one surface. A line declared through the API runs on `codec` unless `codecs` names it. Transports come from the environment (see [Configuration](#configuration)). `mqtt` is an optional peer dependency; install it in the host when a line runs. Declaring `machines` opens the dashboard's [Lines view](#lines-view), with or without code lines.
+
+The registry keeps each line's definition, who declared it (`source`: `code` or `api`), and a `version` that advances once per change. Ownership follows `configSource`, as roles do:
+
+- `db` (the default): a code line is inserted when absent and left as it is afterwards; a declaration that differs from the row is logged as drift and the row stands.
+- `code`: a code line is written whenever its declaration differs, advancing the version once; the row then matches the code again.
+
+Boot applies the code lines under these rules, logs one report (applied, unchanged, db-owned, and code lines the registry still holds that code no longer declares), then runs every enabled line the registry holds, code and API alike. Boot never deletes a line: a line leaves the registry only through `DELETE /api/machines/lines/:siteId/:lineId`. An API declaration applies the line's station, exit and operator roles where none exist (the host's own role declarations win), runs the line on the replica that took the request, and publishes `machine.line.<site>.<line>.declared`; every other replica reads the row back and runs it too. Retiring a line publishes `machine.line.<site>.<line>.retired` and each replica stops it; the line's roles and bot accounts stay.
+
+The registry is Long Tail's side of a line. The site's side, its broker's certificates and ACL and its NATS permissions, is rendered from the lines it serves (see [Topology and identity](#topology-and-identity)); a line declared through the API leads only once the site knows it too. Until then the replica stands by and logs `machine_gateway.line.leadership_lost` with the broker's refusal, and the registry row waits.
 
 For each line, one replica leads (a Postgres advisory lock held on its own connection), makes sure the line's bot accounts exist, and runs the gateway. Other replicas wait on the lock and take over when the leader's session ends. A replica whose connection drops or is refused, as while Postgres restarts, contends again every 5 seconds.
 
@@ -44,6 +56,7 @@ For each line, one replica leads (a Postgres advisory lock held on its own conne
 | `addressing` | `declared` (default): each address is `machines[].address`, or the station's id. `learned`: a station with no `address` learns it from the machine that claims it. See [Learned addresses](#learned-addresses) |
 | `roles.exit` | The role of the person who receives units at the end of a route. Default `line-exit` |
 | `roles.operator` | The role that gets failed handoffs, stopping alarms, and offline or quiet machines. Default `line-operator` |
+| `roles.quality` | The role that decides units a machine finished on hold: release, rework or scrap. Default `line-quality` |
 | `roles.receivers` | Other roles of people who take units straight from a machine. Machine bots join these roles and the exit role, so they can record their releases on those rows |
 | `machines[].allowedSoftware` | Versions the line accepts. A machine reporting another version is refused before any dispatch |
 | `machines[].queueDepth` | Most jobs the machine is sent or holds at once. Unset: no limit. See [Pacing](#pacing) |
@@ -58,12 +71,13 @@ A machine handoff is a row on the receiving machine's role (a handoff to a perso
 | Facet | Meaning |
 |---|---|
 | `siteId`, `lineId` | The line; a gateway acts only on its own line's rows |
-| `units` | `[{ unitId, carrierId, artifact?, artifacts?, parameters? }]`: the units that move together; any of a route's units, all or some. A unit's `artifact` is its own file, such as a per-unit model, and `artifacts` its files when it has several; each is `{ url, sha256, id?, contentType?, sizeBytes? }`. Its `parameters` are its own settings |
+| `units` | `[{ unitId, carrierId, artifact?, artifacts?, parameters?, refs? }]`: the units that move together; any of a route's units, all or some. A unit's `artifact` is its own file, such as a per-unit model, and `artifacts` its files when it has several; each is `{ url, sha256, id?, contentType?, sizeBytes? }`. Its `parameters` are its own settings and its `refs` its own references |
 | `jobId`, `senderJobId` | The receiver's job and the sender's. Each open handoff into a machine names its own job; a second open row naming the same job there resolves `dispatch-refused`. A row for some of a sender job's units still receives their releases, however the codec split that job |
 | `fromMachine`, `toMachine` | Machine ids, or null for line entry and for a person |
 | `recipeId`, `recipeVersion`, `process` | What the receiver runs |
 | `artifactUrl`, `artifactSha256` | The job file, by reference |
 | `parameters` | Settings for the job, sent to the machine as given. Long Tail does not read them; what they mean is between the host and its codec |
+| `refs` | The host's references for the job by name, `{ orderId: 'ORD-9', batch: 'B-2' }`: string values only, others are dropped. Sent with the dispatch as `refs` (and each unit's as `units[].refs`) and containment-searchable on the row: `GET /escalations?facets={"refs":{"orderId":"ORD-9"}}` |
 | `attempt` | Retry number |
 
 The gateway dispatches to `toMachine` when the row is created, or, under a codec that dispatches on arrival, once every unit has arrived there. It claims the row as that machine once the machine accepts. It records each unit's release by the sender and each arrival at the receiver as items. It resolves the row as the receiver once every unit has arrived:
@@ -72,21 +86,21 @@ The gateway dispatches to `toMachine` when the row is created, or, under a codec
 { received: true, receiver: 'cut-01', units: ['U1', 'U2'] }
 ```
 
-When a handoff ends without every unit (a failure, a timeout, a cancel), the gateway withdraws only the jobs none of whose units reached the receiver, so nothing queued for an absent unit runs later. A job some of whose units already arrived is under way: it stays, and what happens to it is the workflow's next decision. A workflow that wants it stopped parks a `cancel` command row (see Commands).
+When a handoff ends without every unit (a failure, a timeout, a cancel), the gateway withdraws only the jobs it sent whose units never reached the receiver, so nothing queued for an absent unit runs later; a job that never went out, because the row was waiting for room or for its units to arrive, leaves the receiver nothing to withdraw. A job some of whose units already arrived is under way: it stays, and what happens to it is the workflow's next decision. A workflow that wants it stopped parks a `cancel` command row (see Commands).
 
 `Machines.handoffProgress(units, items)` reads where a handoff's units stand from its items (a row's items, or `$accumulated` on a finished wait): `{ released, arrived, missing }`. A workflow reads it to decide what a split means for its own process.
 
-On arrival dispatch, the units are already at the receiver, so its acceptance resolves the row the same way.
+On arrival dispatch, the units are already at the receiver, so the row resolves `received` once the machine has the job: at its acceptance, or, when the acceptance says `preparing: true`, at the `completed` reply that follows; a `failed` reply meanwhile ends the row `dispatch-failed`. A gateway taking the line over resolves such a row at once if the machine's snapshot holds the job, since the reply it waited for may have passed. The job then runs with its row ended; the gateway that sent it remembers the row for as long as the machine holds the job's units, so a machine that restarts with the job unfinished is sent it again from that row (the same command id and issue time while the validity round lasts, flagged as a retry), with no verb on the row. A gateway that took the line after the row ended remembers nothing of the job: a restart then logs `machine_gateway.dispatch.unrecoverable` with the jobs the machine lost, and the next hop's row times out as its route decides.
 
-When the handoff ends without a receipt, the row resolves `{ received: false, errorCode, unitId?, reason?, detail }`:
+When the handoff ends without a receipt, the row resolves `{ received: false, errorCode, unitId?, result?, reason?, detail, code? }`. `detail` is text for a person; `code` is the machine's structured code when its reply carried one, so a workflow can branch on it:
 
 | `errorCode` | Cause |
 |---|---|
-| `dispatch-refused` | The machine refused or failed the dispatch (mode, recipe, queue, artifact), or the machine requires an artifact and the row has none. The reason is in `detail` |
-| `dispatch-failed` | The machine accepted the job, then could not prepare it (artifact, recipe). The reason is in `detail` |
+| `dispatch-refused` | The machine refused or failed the dispatch (mode, recipe, queue, artifact), or the machine requires an artifact and the row has none. The reason is in `detail`, and `code` is the reply's code when it had one |
+| `dispatch-failed` | The machine accepted the job, then could not prepare it (artifact, recipe). The reason is in `detail`, and `code` is the reply's code when it had one |
 | `no-reply` | No reply after every attempt with the same command id, and the machine's snapshot does not list the job, or it sent none (`detail` then says the state is unknown). A job the snapshot lists counts as accepted. The dispatch is cancelled, so a copy still queued for an absent machine never runs |
 | `software-unsupported` | The machine runs a version the line does not allow |
-| `sender-rejected` | The sender finished a unit as reject, hold, scrap or rework. Its reason is in `reason` and `detail` |
+| `sender-rejected` | The sender finished a unit as reject, hold, scrap or rework; `result` says which. Its reason is in `reason` and `detail` |
 | `jam`, `incomplete-handshake`, `carrier-mismatch`, `unreadable-id` | The move between machines failed |
 | `withdrawn` | The receiver gave the job back |
 
@@ -121,7 +135,7 @@ Every other progress message stays in the stream, so an hour-long job leaves a h
 
 ### Decisions on a failed handoff
 
-`Machines.handoffDecisions(errorCode)` gives a default set of decisions for a failed handoff. A failure in the move leaves the units on the line, so `retry`, `manual` and `scrap` all fit. Units the sender finished as not ok (`sender-rejected`) leave the line and never re-enter it, so only `manual` and `scrap` fit. After a `partial-arrival` (a timeout once only some units arrived) the units are split between two stations, and a retry of the same hop would ask the sender for units it no longer holds, so the default offers `manual` and `scrap`. A workflow is free to offer its own decisions instead, such as moving only the missing units on; the platform reports the facts and does not choose.
+`Machines.handoffDecisions(errorCode)` gives a default set of decisions for a failed handoff. A failure in the move leaves the units on the line, so `retry`, `manual` and `scrap` all fit. Units the sender finished as not ok (`sender-rejected`) leave the line and never re-enter it, so only `manual` and `scrap` fit; units finished on hold (`result: hold`) are the exception, and the example route asks the quality role instead (`Machines.HOLD_DECISIONS`: `release`, `rework`, `scrap`), sending the decision to the holding machine as the command the codec declares for it (`dispositionOp`) when it declares one. After a `partial-arrival` (a timeout once only some units arrived) the units are split between two stations, and a retry of the same hop would ask the sender for units it no longer holds, so the default offers `manual` and `scrap`. A workflow is free to offer its own decisions instead, such as moving only the missing units on; the platform reports the facts and does not choose.
 
 The example route's policy for a split: it stops the receiver's job with a `cancel` command row, then a person collects each group of units where it stopped.
 
@@ -143,11 +157,11 @@ A machine's load is every job it has been sent or still holds:
 - rows whose units still wait on it to move on;
 - units that arrived and have not left.
 
-A unit leaves when the machine releases it, when it arrives at the next machine, or when the machine's snapshot no longer lists its job. A replica taking the line reads every open row back before it sends anything, so pacing survives a restart.
+A unit leaves when the machine releases it, when it arrives at the next machine, or when the machine's snapshot no longer lists its job. A replica taking the line reads every open row back before it sends anything, so pacing survives a restart; a handoff row that was never given items, one parked by hand on a machine's role, reads as holding none.
 
 ## Commands
 
-A host asks a machine to start, stop, pause, resume, change over or cancel a job (`cancel` needs `args.jobId`) by parking a `machine-command` row on the machine's role, from a workflow step or through the API, the way it asks a person for anything:
+A host asks a machine to start, stop, pause, resume, change over, cancel a job (`cancel` needs `args.jobId`), report a `snapshot`, or do anything its codec declares (`rowOps`, see [The wire](#the-wire)) by parking a `machine-command` row on the machine's role, from a workflow step or through the API, the way it asks a person for anything. `stop` with `args.jobId` stops that job at a safe point and holds its units; without it, the machine finishes the current unit and takes no more:
 
 ```typescript
 const reply = await conditional<Machines.CommandResolution>(`changeover-${orderId}`, {
@@ -167,9 +181,11 @@ The gateway sends the command and resolves the row with the reply, as the machin
 | `status` | Meaning |
 |---|---|
 | `accepted` | The machine took the command |
-| `refused`, `failed` | The machine said no; its reason is in `reason` (a changeover to a version it does not hold is refused) |
+| `refused`, `failed` | The machine said no; its reason is in `reason` (a changeover to a version it does not hold is refused), and `code` is the reply's structured code when it carried one |
 | `no-reply` | No reply after every attempt. The command expired at the end of the asking, so a copy that reaches the machine later is refused, never run |
-| `unsupported` | Not a command a row may ask for, not a machine on this line, or a command the line's codec has no message for; nothing was sent |
+| `unsupported` | Not a command a row may ask for (a control op, `snapshot`, or one the codec declares), not a machine on this line, or a command the line's codec has no message for; nothing was sent |
+
+A `snapshot` row resolves with the reply like any command, and the machine's snapshot follows on its own channel; a dashboard or a workflow asks for a machine's state this way.
 
 A command is sent again, under the same `cmdId` and with the same arguments, by a gateway that takes over the line while its row is open. Its `expiresAt` counts in rounds of the asking from the row's creation, and a round begins only once the one before it has expired; a command sent in a later round goes out as a new one, `<row>:command:r<n>`, never as an old one with changed arguments. Dispatches work the same way with `MACHINE_DISPATCH_TTL_MS`, counted from the row's creation, or for `dispatchOn: 'arrival'` from the last unit's arrival, so a machine never holds two valid commands for one row.
 
@@ -189,6 +205,7 @@ interface LineCodec {
   strict?: boolean;                                       // broken messages go to a person, never acted on
   snapshotOnStart?: boolean;                              // ask every machine for a snapshot on taking the line
   retainedAlarms?: boolean;                               // active alarms stay retained on the broker until they clear
+  rowOps?: readonly string[];                             // the machines' own commands a machine-command row may ask for
   decode(topic: string, payload: string, retained?: boolean): Inspection[];
   encode(ident: MachineIdent, command: MachineCommand): WireMessage[];      // [] when the machines lack the command
   receipt?(ident: MachineIdent, messageIds: string[]): WireMessage[];       // for machines that keep an outbox
@@ -199,40 +216,106 @@ interface LineCodec {
 - With `unitsPerDispatch: 1` the gateway sends one job per unit, claims the row once every job is accepted, and cancels the accepted jobs if any is refused.
 - `topicFor` lays out the topics, for a protocol with its own levels (a direction before the machine, say). The layout begins with `{root}/{site}/{line}/`. The broker ACL and the stream subjects follow it. Without it the layout is `{root}/{site}/{line}/{address}/{channel}`.
 - `dispatchOn: 'arrival'` is for machines that take work only for units they have scanned in. The job goes out once every unit of the row has arrived, and each unit carries the arrival event its receiver reported (`units[].arrival`), so `encode` can echo the receiver's own visit id.
-- A reply is `accepted` (recorded), and a machine that prepares its jobs may later reply `completed` (ready) or `failed` under the same `cmdId`. A failure after acceptance ends the handoff as `dispatch-failed`. When no reply comes, the gateway asks the machine for its snapshot before deciding.
+- A reply is `accepted` (recorded), and a machine that prepares its jobs says so with `preparing: true` and later replies `completed` (ready) or `failed` under the same `cmdId`. A failure after acceptance ends the handoff as `dispatch-failed`. When no reply comes, the gateway asks the machine for its snapshot before deciding.
 - `receipt` confirms the messages the gateway is done with, for machines that resend an event until it is confirmed. `decode` marks each such message with a `receiptId`. The ids go out per machine in batches of up to 100 after `MACHINE_RECEIPT_DELAY_MS`, including messages already applied. A message still waiting for its row is confirmed once it lands.
-- `strict: true` holds a message with contract violations: it is confirmed, never acted on, and one `contract-violation` row shows it to the operator role. Without it, known fields are acted on and the violations are logged.
-- An alarm body may name the catalog edition its code comes from, `catalog: { domain, key, version }`. The alarm row then carries it as a lookup ref, so the row reads the code's meaning as of that edition.
+- `strict: true` holds a message with contract violations: it is confirmed, never acted on, and one `contract-violation` row shows it to the operator role. Without it, known fields are acted on and the violations are logged. A receiver's report that it read no id (`transfer-failed`, `failure: unreadable-id`, neither `unitId` nor `carrierId`) keeps the contract, so under a strict codec it reaches the operator as a `handoff-error` row rather than a violation.
+- An alarm body may say `needsPerson: true`: the row is raised whatever the level, and the row's level stays the machine's. Stopping levels raise a row on their own.
+- A snapshot needs only `mode`, `enabled`, `jobs` and `alarms`; `bootId`, `software`, `recipe` and `cycles` are read when present. A job event needs no `orderRef`; the row already knows its order. A codec for machines that spread these over several messages fills in what it has.
+- An alarm body may name the catalog edition its code comes from, `catalog: { domain, key, version }`, with `version` an edition number or the label an edition carries (a catalog revision, say). The alarm row then carries it as a lookup ref, so the row reads the code's meaning as of that edition; a label no edition carries yet leaves the row's lookup unresolved, never the row uncreated.
 - Event channels go to the durable stream and telemetry channels are read live. A machine reads its commands on the command channels. The broker ACL is rendered from these channels, so a codec with its own topics gets its own ACL. Unknown body fields are allowed and known ones are checked. Payloads may be up to 256 KB.
 - `snapshotOnStart: true` is for machines that keep no retained state and report only what changes. The gateway asks each machine for a snapshot once it takes the line, so it learns every machine's current job before it acts on a change.
 - `retainedAlarms: true` says active alarms stay retained on the broker until they clear, as in the line protocol. A gateway taking the line then reads every active alarm back, and an alarm row whose alarm is missing has cleared. Without it, a machine's snapshot lists its active alarms (`alarms`), and an alarm row whose alarm a snapshot the machine sends no longer lists resolves `cleared`; a snapshot read back from the broker is never used for this, since it may be older than the alarms.
 - A receiver that reads only the carrier may report `arrived`, or `transfer-failed` with `unreadable-id`, with `carrierId` and no `unitId` or `jobId`. The gateway finds the unit an open handoff into that machine carries on that carrier.
-- Each command reaches `encode` with `attempt`, how many times this gateway has sent that `cmdId`, and `retry`, true when the machine may already have it: sent earlier, or its row existed before this gateway took the line. A protocol with a retransmission flag sets it from `retry`.
+- Each command reaches `encode` with `attempt`, how many times this gateway has sent that `cmdId`, `retry`, true when the machine may already have it (sent earlier, or its row existed before this gateway took the line), and `issuedAt`, when it was issued. `issuedAt` is the same on every send of a `cmdId`, by this gateway or the next: a dispatch or a command row takes the start of its validity round, any other command the time of its first send. A protocol with a retransmission flag sets it from `retry` and stamps its time from `issuedAt`, so a resend repeats the first attempt with only the flag changed; the generic envelope's `at` is `issuedAt`.
 - When `encode` returns no messages, the machines have no such command. The gateway sends nothing and waits for nothing: a machine-command row resolves `unsupported`, and a cancel or snapshot the machines lack is logged as unsupported.
+- `rowOps` names the machines' own commands, beyond the line protocol's control ops and `snapshot`, that a machine-command row may ask for. Each goes through `encode` with the row's `args` and the row resolves with the reply. Every entry is a non-empty string; the gateway refuses to start on a codec whose entries are not.
+- A reply may carry `code`, a string the machine chooses, beside its `reason` text. The gateway puts it on the row as `code`, on a command row's resolution and on a `dispatch-refused` or `dispatch-failed` handoff, so a workflow branches on the code and a person reads the reason.
+- Presence may carry `sessionId`, one per connection, and `reason` on a goodbye. A presence with a new `sessionId` while the machine is online is a reconnect whose offline presence was never heard: the gateway asks for a snapshot, as it does when a machine comes back. An offline row records the `reason` the machine gave.
 
 The generic protocol's topics are `{root}/{site}/{line}/{machine}/{channel}`. Every message is wrapped in `{ v, id, at, source, body }`.
 
 | Channel | Purpose |
 |---|---|
-| `presence` (retained) | Birth and will, with the software version |
-| `snapshot` (retained) | Mode, recipe, jobs, alarms, counters, boot id |
+| `presence` (retained) | Birth and will, with the software version, a `sessionId` per connection, and on a goodbye the `reason` |
+| `snapshot` (retained) | Mode, enabled, jobs and alarms; recipe, counters, software and boot id when the machine keeps them |
 | `job` | Per unit: `queued`, `ready`, `arrived`, `bound`, `started`, `progress`, `finished`, `released`, `transfer-failed`, `withdrawn` |
-| `alarm/<id>` (retained while active) | Raise, acknowledgement, clear (with who cleared it) |
+| `alarm/<id>` (retained while active) | Raise, acknowledgement, clear (with who cleared it); `needsPerson: true` on an alarm of any level asks for a person |
 | `telemetry` | Readings |
 | `report/<name>` | Production, availability, inventory and other reporting, kept in the stream |
-| `cmd` / `cmd/reply` | `dispatch`, `cancel`, `start`, `stop`, `pause`, `resume`, `changeover`, `ack-alarm`, `snapshot`; replies `accepted`, `completed`, `refused`, `failed`. Every command carries a `cmdId` (a repeat is answered, never run twice) and an expiry |
+| `cmd` / `cmd/reply` | `dispatch`, `cancel`, `start`, `stop` (with `jobId`: that job, at a safe point), `pause`, `resume`, `changeover`, `ack-alarm`, `snapshot`; replies `accepted`, `completed`, `refused`, `failed`, with a `reason` and an optional `code`. Every command carries a `cmdId` (a repeat is answered, never run twice) and an expiry |
 
 ## Rows for people
 
 | Row | Raised when | Resolved when |
 |---|---|---|
-| `line-alarm` | A stopping alarm (critical or emergency) is raised | The machine clears it (with who cleared it). If a person resolves it first, the gateway sends `ack-alarm` |
-| `machine-offline` | Presence goes offline past a debounce | The machine is heard again |
+| `line-alarm` | A stopping alarm (critical or emergency) is raised, or one the machine flags `needsPerson`, at the level the machine said | The machine clears it (with who cleared it). If a person resolves it first, the gateway sends `ack-alarm` |
+| `machine-offline` | Presence goes offline past a debounce; the row's `reason` is the machine's, when its goodbye gave one | The machine is heard again |
 | `machine-quiet` | A connected machine sends nothing for `MACHINE_QUIET_MS` | It is heard again |
 | `contract-violation` | A strict codec decodes a message that breaks the contract. The row holds the raw message and the violations | A person resolves it |
+| `handoff-error` (`unmatched-arrival`) | A machine reports an arrival no open handoff into it expects: a carrier no row carries, once every delivery has passed, or a read that found no id at all (`transfer-failed` with `failure: unreadable-id`, no unit, no carrier), at once. One row per machine and carrier, holding the raw arrival, so the unit is re-scanned or routed | A person resolves it; the next such arrival raises a row again |
+| `quality-hold` | The example route's row for units a machine finished on hold (`sender-rejected` with `result: hold`), on the quality role | A person answers `release` (the hop runs again from the holding machine), `rework` with an optional `station` (the route runs again from that station), or `scrap` |
 | `machine-registration` | On a line that learns addresses, an address claims a station bound to another address, or an address bound to one station claims another | A person resolves it with `{ decision: 'approve' }`, which binds the station to the claimant, or `reject` |
 
-A replica taking a line reads back its learned addresses, its open handoff, command, alarm, offline, quiet and registration rows, and each open handoff's arrivals, so the receiver holds those units again. It then reads the machines' retained state, so a clear or a return that happened while no gateway was listening still resolves its row. A machine that restarts with a new boot id gets its accepted jobs dispatched again under the same command ids. An alarm id reused with a new raise time counts as a new alarm.
+A replica taking a line reads back its learned addresses, its open handoff, command, alarm, offline, quiet and registration rows, and each open handoff's arrivals, so the receiver holds those units again. It then reads the machines' retained state, so a clear or a return that happened while no gateway was listening still resolves its row. A machine that restarts with a new boot id gets its accepted jobs dispatched again under the same command ids, and, from the gateway that sent them, the ready jobs of rows that already ended whose units it still holds; jobs it lost that no row and no memory covers are logged as unrecoverable. An alarm id reused with a new raise time counts as a new alarm.
+
+## Lines view
+
+The dashboard shows the lines under Monitor. The view exists only when `start({ machines })` runs a surface: `GET /api/settings`, which is public, then carries `machines: { declared: n }`, the number of lines this replica runs, and names no line; without a surface the key is absent and the dashboard shows no Lines entry. Reading the view takes the ops tier (superadmin, admin type, or engineer); declaring and retiring a line takes an administrator.
+
+**The index** (`/lines`) lists every line in the registry with how it is right now, searched and paged on the server. Each row carries the site and line, the machines with any offline or quiet in the warning tone, active alarms, rows waiting on a person, work in flight (handoff and command rows), whether this replica leads it, and at wide widths the machine chain and the source with its version. Lines needing attention sort first; the order can also be site and line, or recently changed. The filter band searches site, line, machine ids, processes, roles and addresses, narrows to one site (the sites give the index its facet, each with its lines and how many need attention), and keeps only lines that need attention. Until a search or a site narrows the page, rows group under a heading per site. On a narrow container the table folds into console cards. A panel declares a line from a JSON definition, edits and saves one already declared (the version you edited is sent, and a newer one on the server refuses the save), and retires it after a confirmation inside the panel.
+
+**A line** (`/lines/:siteId/:lineId`) shows its machines above and the wire beneath. The machines region lists the machines as tiles (presence ring, id, process and address, software, held units, open rows by kind, active alarms) or as rows (one dense line per machine in a list that scrolls within the region, with a search over id, process, role and address). The view picks itself by count, tiles up to twelve machines and rows beyond, and the choice can be overridden per line from the two icon buttons; "Needs attention" keeps only machines that are offline, quiet, alarmed or holding open rows. The wire is a boxed section beneath: its own filter band (machine, channel, direction, kind, violations only; folded behind one Filters button on a narrow container), the count shown and on the tape, pause (new arrivals wait while you read), clear, full screen, and "Watch on the event stream", which adds the line's wire to the shell's bottom event feed so the line stays watchable anywhere in the app. The tape keeps the newest two thousand events and scrolls inside its box; a row opens the event's record. Selecting a machine opens its panel and follows it on the tape until the chip beneath the band releases the filter. The panel holds the machine's last snapshot (address, software, since and last seen, boot and session ids, jobs, alarms, held units), its open rows with links, a timeline over a window of the rows that moved work to or from it, and three tools: ask for a snapshot (a `snapshot` command row), send a command (a control op, `snapshot`, or one the codec declares, with JSON args), and inspect a message (a dry run of a topic and payload, nothing applied). A replica standing by says so and keeps the tape live from the leader.
+
+### The wire record
+
+Every message a line's gateway reads, and every command, snapshot request and receipt it sends, is published as one event, `machine.wire.<site>.<line>.<machineId|unknown>.<in|out>` (on NATS `lt.events.machine.wire...`, tokens sanitized as escalation subjects are). The dashboard subscribes to `lt.events.machine.wire.<site>.<line>.>`. The event's `data` is the record:
+
+```typescript
+interface WireEvent {
+  type: 'machine.wire'; siteId: string; lineId: string; machineId: string | null; address: string | null;
+  direction: 'in' | 'out'; channel: string; topic: string; id: string | null; at: string; retained: boolean;
+  kind: 'presence' | 'snapshot' | 'job' | 'alarm' | 'telemetry' | 'report' | 'cmd' | 'reply' | 'receipt' | 'unknown';
+  event: string | null;    // job event, alarm raised/acked/cleared, command op, reply status, presence online/offline, snapshot mode
+  summary: string;         // one line from the kind, the event and the ids the body names
+  violations: string[];    // what the contract check found
+  actions: { verb: 'claim' | 'accumulate' | 'resolve' | 'create-row' | 'refuse' | 'hold' | 'unmatched' | 'unreadable' | 'ack' | 'none'; rowId?: string; itemKey?: string; detail?: string }[];
+  payload?: unknown;       // the raw wire payload; builders only, stripped before it reaches anyone else's browser
+}
+```
+
+`actions` is what the gateway did with the message: the verbs it performed on rows, with the row ids (`claim`, `accumulate` with its `itemKey`, `resolve`, `create-row`), a verb Long Tail refused (`refuse`), a message held for a person under a strict codec (`hold`), one no row claimed after every delivery (`unmatched`; an arrival then goes to a person as a `handoff-error` row), one the codec or the planner could not read (`unreadable`), one admitted with nothing to do (`ack`), and `none` with a `detail` for everything else: a message waiting for its row, a dispatch or command that went out because of it (the send is its own `out` record), an address no station claims. A record of a message read back from the broker on taking the line says `retained: true`.
+
+Telemetry messages are read live and are many: they join the wire record only with `MACHINE_WIRE_TELEMETRY=on`. The leader also keeps the line's last wire events in memory, readable over HTTP (`GET .../wire`, below), so a client outside the browser follows the tape without the event stream.
+
+The gateway log is published the same way, `machine.log.<site>.<line>.<event>` with the entry's level and context, where `<event>` is the log event without its `machine_gateway.` prefix as one token (`dispatch-accepted`, `verb-row_not_visible`). The console log keeps every entry as before.
+
+### Routes
+
+| Route | Answer |
+|---|---|
+| `GET /api/machines/lines?q=&site=&attention=&sort=&limit=&offset=` | The index, `LineIndex`: one page of `LineIndexRow` (the `LineSummary` with its machines, process, role, address and the codec's `rowOps`; `source`, `version`, `enabled`, `updatedAt`; `leading` on this replica; and `health`: machines, and the pending rows counted as `offline`, `quiet`, `alarms`, `people` (handoff errors, contract violations, registrations), `handoff`, `command`, with `attention` when a machine is offline, an alarm is active or a person is needed), `total`, `sites` (every site with its lines and how many need attention), `limit`, `offset`. `q` searches site, line, machine ids, processes, roles and addresses (the first 200 characters count); `attention=true` keeps only lines that need it; `sort` is `attention` (default), `site` or `updated`, anything else 400; `limit` is 50 by default and 200 at most. 404 when `machines` is not declared at all |
+| `PUT /api/machines/lines/:siteId/:lineId` `{ definition: LineDef, version? }` | Declares the line through the API (administrators): the definition is validated as `loadLine` validates a file and must name the site and line in the path, stored with `source: api`, its roles applied, and the line run on every replica. A `version` names the version the caller last read; a different one is 409. Answers `{ line: LineIndexRow }`; 400 names what the definition lacks, a version that is not a whole number, or a site or line that is not a topic level |
+| `DELETE /api/machines/lines/:siteId/:lineId` | Retires the line (administrators): the registry row goes, every replica stops it, its roles and bot accounts stay. 204, or 404 when there is no such line or the path is not a site and line |
+| `GET /api/machines/lines/:siteId/:lineId` | `LineViewResponse`: the `LineView` from the replica leading the line (`takenAt`, each machine's link with online, since, last seen, software, boot and session ids, held units with the rows they came in on, open row counts by kind with the offline and quiet row ids, alarms with their rows, the last snapshot's jobs, and the contested claims waiting for a person), or `{ siteId, lineId, leading: false }` from a replica standing by. Both carry `summary`, the `LineSummary` (machines, roles, addresses and the codec's ops), so the Lines view reads the line from any replica |
+| `GET /api/machines/lines/:siteId/:lineId/wire?limit=&machine=&direction=&kind=&since=` | `LineWireResponse`: the line's last wire events from the replica leading it, newest first (`MACHINE_WIRE_WINDOW` of them kept, 500 by default and at most 500 per read), narrowed by machine, direction (`in`, `out`), kind and `since` (ISO 8601); builders read each event's `payload`, everyone else the record without it, as on the event stream. A replica standing by answers `leading: false` and no events. A test harness or a vendor's driver reads the tape here with a token and nothing else |
+| `POST /api/machines/lines/:siteId/:lineId/inspect` `{ topic, payload, retained? }` | A dry run on the leader: what the codec reads (`kind`, `event`, `summary`, `inspections`, `violations`) and the actions the gateway would take, planned on a copy of its state. Nothing is applied and no row is created; 409 on a replica that is not leading |
+| `POST /api/machines/lines/:siteId/:lineId/machines/:machineId/commands` `{ op, args }` | Parks a `machine-command` row on the machine's role as the caller, so that role's write access decides, and answers `{ rowId }`. `op` is a control op, `snapshot`, or one the codec declares (400 otherwise); an unknown machine is 404 |
+
+Declaring a line from a shell:
+
+```bash
+curl -X PUT http://localhost:3000/api/machines/lines/site-2/line-1 \
+  -H "authorization: Bearer $TOKEN" -H 'content-type: application/json' \
+  -d "{\"definition\": $(cat line.json)}"
+curl "http://localhost:3000/api/machines/lines?q=press&attention=true" -H "authorization: Bearer $TOKEN"
+curl -X DELETE http://localhost:3000/api/machines/lines/site-2/line-1 -H "authorization: Bearer $TOKEN"
+```
+
+Each replica answers the index and the line's summary; only the leader of a line holds its state. A request-reply to the leader, so any replica can serve the live view and the dry run, and a per-line runtime switch for telemetry on the wire are the next steps.
+
+### MCP
+
+The built-in `long-tail-machines` server offers the same surface to agents, gated as the routes are: `list_machine_lines` (the index with health, search, site and attention filters, sort and paging; `declared: false` without a surface), `get_machine_line` (one line as its leader sees it or standing by, with its summary and command ops), `inspect_machine_message` (the dry run), `send_machine_command` (parks a `machine-command` row on the machine's role as the caller), and for administrators `declare_machine_line` (versioned; a stale version is a conflict) and `retire_machine_line`. Read-scoped callers see the three reads only. See [MCP](mcp.md#machines-server).
 
 ## Topology and identity
 
@@ -245,13 +328,14 @@ A replica taking a line reads back its learned addresses, its open handoff, comm
 
 - **Machines:** each machine logs in over MQTT 3.1.1 or 5 with its own certificate; the CN (`{site}-{line}-{address}`) is its username. The broker ACL lets it write only its own channels and read only its own commands. The line controller may command every machine on the line.
 - **Durable streams:** the bridge carries the line's topics one way into NATS, where only the bridge may publish them. JetStream keeps `LINE_EVENTS` (30 days) and `LINE_TELEMETRY` (3 days). The gateway reads through a durable consumer, `<controller>-events`, and may publish only JetStream requests and acks for its own streams and consumer; it cannot delete or purge them.
+- **One site, several codecs:** the streams are ensured with the subjects of every codec the surface runs on the site, so lines on different roots share `LINE_EVENTS` and `LINE_TELEMETRY` whichever line starts last; a gateway whose consumer the stream would feed nothing refuses to start and says which subjects are missing.
 - **Where the streams live:** by default in Long Tail's messaging ([events](events.md#messaging)), whose NATS server must run JetStream. The bridge then logs in to that server's edge account for the line (`Machines.edgeAccountFor`), which may publish only the line's subjects, so the edge reaches nothing of Long Tail's. With `MACHINE_SITE_NATS_URL`, the streams live instead in a NATS server of the site's own (`Machines.renderSiteConf`), and Long Tail's NATS stays inside Long Tail. Either way the gateway reads the same streams under the same consumer name.
 - **Escalation events:** the gateway inside Long Tail reads them in process. A standalone gateway subscribes to them over Long Tail's messaging.
 - **Commands:** the gateway publishes commands to the machine broker at QoS 1, so they queue for a machine that is away.
 - **Bot accounts:** in Long Tail each machine is a bot account on its station and receiver roles, so `claimed_by` and `resolved_by` name the machine. The controller bot holds those roles and the operator role, and raises the operator rows. The bots are member accounts with no password, under names the line derives; the line will not start while a person's account holds one of those names.
 - **Rows are the authority:** an escalation event only tells the gateway which row to look at. It reads the row back as the controller and acts on the stored role, status and metadata. A row on a role the controller does not hold, or an event its stored row contradicts, does nothing.
 - **Roles carry the access:** dispatching to a machine or commanding one means parking a row on that machine's role, so Long Tail's role access decides who can. The gateway acts on a handoff into a machine only on that machine's role, and on a handoff to a person only on a receiver role. A row commands only the machine whose role it is on: cancelling a handoff withdraws the receiver's dispatch, and the sender's job is stopped only by a `cancel` command row on the sender's role.
-- **Rendering:** `Machines.renderSiteConf`, `renderMosquittoConf` and `renderMosquittoAcl(line, codec)` render the configuration from the line; the ACL takes its topics from the codec's channels.
+- **Rendering:** `Machines.renderSiteConf`, `renderMosquittoConf` and `renderMosquittoAcl(lines, codec)` render the configuration from one line or several on the same broker and site NATS: one bridge identity per line, one gateway user allowed every line's streams, and each line's stations and controller in the ACL. The ACL takes its topics from the codec's channels. Lines on different protocols pass a resolver instead of one codec, `renderMosquittoAcl(lines, (line) => codecOf(line))`, and a `root` resolver to `renderSiteConf` and `renderMosquittoConf`, so each line's bridge, subjects and ACL follow its own codec.
 - **Machines that host their own broker:** the machine broker connects out to each machine's broker with a Mosquitto bridge, carrying the machine's messages in and its commands out under the machine's level of the line's topics, and its codec reads them there. The bridge's notification topic, kept on the machine broker, is the machine's presence. `examples/workflows/bambu-printer` does this for 3D printers.
 
 ### Learned addresses
@@ -272,7 +356,7 @@ A line with `addressing: 'learned'` names its stations and lets each machine tel
 | `MACHINE_TRANSPORT` | | `nats` (durable streams) or `mqtt` (any MQTT broker, no replay beyond the session) |
 | `MACHINE_ESCALATION_FEED` | `in-process` inside Long Tail, `core` for a standalone gateway | Where escalation events come from; `core` subscribes over Long Tail's messaging, or to `NATS_URL` with `NATS_TOKEN` when the gateway has none |
 | `MACHINE_TOPIC_ROOT` | `line/v1` | The generic codec's root |
-| `MACHINE_LINE_CONFIG` | | Path of the line JSON |
+| `MACHINE_LINE_CONFIG` | | The line JSON files, one path or several separated by commas; each site and line once |
 | `MACHINE_SITE_NATS_URL`, `_USER`, `_PASSWORD` | | A site NATS of its own for the streams; unset, `nats` keeps them in Long Tail's messaging |
 | `MACHINE_MQTT_URL`, `_PROTOCOL` | `_PROTOCOL` 5 | Machine broker, for commands and retained reads; 4 for a broker that speaks only MQTT 3.1.1 |
 | `MACHINE_MQTT_CA`, `_CERT`, `_KEY` | | TLS files; `{clientId}` in a path picks each identity's certificate |
@@ -284,7 +368,9 @@ A line with `addressing: 'learned'` names its stations and lets each machine tel
 | `MACHINE_RECEIPT_DELAY_MS` | `250` | How long confirmed message ids gather before a receipt goes out |
 | `MACHINE_LIFECYCLE` | `off` | `on` notes each job's start, progress steps and pauses on the row that holds it |
 | `MACHINE_PROGRESS_STEP` | `25` | With lifecycle notes on, progress is noted each time it crosses this many percent; `0` notes none |
-| `MACHINE_CODEC_MODULE` | | Development server only: a module whose `createCodec(line)` speaks the machines' protocol |
+| `MACHINE_WIRE_TELEMETRY` | `off` | `on` publishes telemetry messages on the wire record too ([Lines view](#lines-view)) |
+| `MACHINE_WIRE_WINDOW` | `500` | How many of a line's last wire events its leader keeps for `GET .../wire` |
+| `MACHINE_CODEC_MODULE` | | Development server only: a module whose `createCodec(line)` speaks the machines' protocol, for a single line |
 
 ## Testing a codec or adapter