# pipeline_core

产线核心模块 —— 管理产线定义、步骤编排、版本控制、发布流程。

## 功能

- **产线管理**：产线 CRUD，定义产线名称与描述
- **步骤编排**：产线步骤的增删改查，支持依赖关系（DAG）
- **版本控制**：产线版本发布与回滚
- **编辑器**：可视化产线步骤编排界面

## 数据表

| 表 | 说明 |
|---|------|
| pipelines | 产线定义 |
| pipeline_steps | 产线步骤（含 deps 依赖） |
| sd_projects | 软件项目定义（2026-09-10 自 pipeline-sdlc 迁入，跨产线共享） |
| sd_project_role_models | 项目角色模型配置（同上迁入；下拉 codes 指 sd_role 字典 + llm_model(status=active)） |
| pipeline_deliverables | 产线交付物（同上迁入；主要写入方 pipeline-bidding） |
| pipeline_user_memory | 跨会话持久记忆（2026-09-10 多租户：加 org_id/user_id 归属列，key 掺租户维度，迁移 m0023） |
| pipeline_tool_policies | 工具作用域策略（2026-09-10 五级作用域 org/pipeline/role/project 的 allow/deny 微调，迁移 m0028） |

已移除（2026-09-10 孤儿表清零）：`pipeline_versions`（页面 08-28 已删、0 行，models 定义删除+DROP 见 m0027）、`llm`（模型管理收敛 pipeline-llm 后停用，8 行已确认无损迁移，DROP 见 m0027）。

## 跨产线共享资源（wwwroot/api/）

三张迁入表配套 15 个 api dspy 与手写角色模型页（`wwwroot/sd_project_role_models/`，
git 跟踪、勿被 xls2ui 覆盖）。sdlc 侧页面消费 `get_project_options.dspy` 用绝对路径
`/pipeline_core/api/**` 引用；反向本模块页面消费 sdlc 子表也用绝对路径。

### 已知表治理清单（2026-09-10 审计）

全部办结（2026-09-10 批评会决议，用户认可）：

- `pipeline_conversations`：孤儿表→已归籍 pipeline-service（models 定义 b8a2aea + collation 统一 m0022）。
- `sd_conversations`：死表→models 定义已删、project_capability 4 处引用已清、DROP 见 m0027（32 行备份后删）。
- 其余 10 张孤儿/死表一次清零：5 张归籍补定义（bid_analysis_history、bid_cost_benefit→bidding；pipeline_agent_instances、pipeline_agent_settings、pipeline_project_agents→service），4 张死表 DROP + 权限清理见 m0027（非破坏的 collation/索引收敛在 m0026），pipeline_deploy_ledger 为 dmig 自建台账豁免（table_doctor 白名单）。

## 安装

```bash
cd pkgs/pipeline_core && pip install .
```

## 集成

伞仓 (pipeline-app) 通过 wwwroot symlink 加载本模块：
```
wwwroot/pipeline_core -> ../pkgs/pipeline_core/wwwroot
```

## 通用会话产线隔离（2026-09-05）

配合 pipeline-service 的 7 层隔离（详见其 README），本模块承担：

- `agent_config.load_agent_config(generic=True)`：不挂产线能力包，
  并剔除 GENERAL_TOOLS 中 category=project/shell 的工具（schema 层防线，
  LLM 根本看不见项目管理/命令执行工具）
- `upload_tools.resolve_upload_dir(generic=True)`：通用会话上传文件落
  `_general/{uid}` 专属目录，与 AgentExecutor 的文件根一致
  （_resolve_ws_path 越界保护只认该目录）
- `wwwroot/api/agent_chat_generic.dspy`：纯通用会话入口（generic=True）

## agent 通用能力对齐 Hermes（2026-09-10）

把 Hermes Agent 的「写入侧/运行时侧」能力补齐给产线会话 agent，GENERAL_TOOLS
从 25 个扩到 29 个，新增四工具（定义在本模块 `agent_config.py`，handler 在
pipeline-service `agent_loop_v2.py`）：

| 工具 | 能力 | 隔离/门禁 |
|---|---|---|
| `memory` | add/list/remove 持久记忆（对齐 Hermes memory） | 多租户写入门禁在 handler：只能写 user/project/pipeline 域（global/org 种子域禁写），org_id/user_id 强制注入会话真实身份（忽略 LLM 传值），无身份拒写，remove 仅本人条目 |
| `manage_skill` | create/patch/write_file/remove_file/delete 技能（对齐 skill_manage） | 只落本租户 orgs/{org} 或 org 0 降级 users/{uid}；改 global 原版走 fork-on-write 继承副本；产线层拒改；子文件限 references/scripts/templates/assets |
| `process` | poll/log/wait/kill 后台任务（配套 run_command background） | 状态文件化在 workspace/.bg/，跨 worker 可见；只解析发起者 workspace |
| `subagent` | list/steer/stop/result 后台子 agent（配套 delegate_subtask background） | 同 workspace 并行上限 3、深度限制 1、子会话历史隔离 |

`run_command` 加 `background`/`timeout` 参数；`delegate_subtask` 加 `background`。

**记忆多租户（memory_store.py）**：每条记忆带 org_id/user_id 归属列；
`visible_to()` 是唯一可见性权威（平台种子 org_id='' 全员只读 + org 归属本机构共享 +
user 归属仅本人 + pipeline/project 域带机构匹配）；`memory_key` = hash(content+org+
user+scope+scope_id)，同内容跨租户 key 不同、唯一索引永不碰撞；`_evict_partition`
按 org+user 分区淘汰，agent 写入绝不删种子或他租户记忆；写后失效缓存保多 worker
一致。`get()` 是无过滤底层查询（管理用），agent 读取一律走 `get_visible()`。

**ToolDefinition.required 字段（2026-09-10）**：None=旧行为（全参数必填），含可选
参数的工具须显式声明 required 列表，否则 `to_openai_schema()` 把可选参数标成
required、LLM 被迫为每个参数编值。GENERAL_TOOLS 全部带可选参数的工具已补 required。

## 第二批能力对齐：五级工具作用域 + patch_file + 原生视觉（2026-09-10）

### 五级作用域工具解析（tool_sources.py，GENERAL_TOOLS 30 个）

用户要求：全局/机构/产线/角色/项目五级各注册不同工具，产线特有工具按产线区分。

| 级 | 工具来源 | 隔离机制 |
|---|---|---|
| global | GENERAL_TOOLS | generic 会话剔除 project/data 类 |
| org | 机构技能包 capability 工具 + 策略表 allow/deny | 技能 get_merged 按 orgs/{org}/ 物理目录隔离 |
| pipeline | PipelineAbility.tools + 产线技能 capability 工具 | 注册表按 pipeline_id；generic 不挂 |
| role | RoleSpec.tools 白名单（过滤器非添加器）+ 角色策略 | get_role_spec(pipeline_id, role) 按产线隔离 |
| project | 策略表 allow/deny 微调 | 策略行 scope_id=project_id |

- **策略表 pipeline_tool_policies**（scope/scope_id/tool_name/effect/reason/status，
  uk(scope,scope_id,tool_name)）：CRUD 管理页 `/pipeline_core/pipeline_tool_policies/`；
  表缺失/查询失败按无策略降级（WARN 日志，不阻断会话）。
- **capability 两层语义**（别简化成一层）：①「capability 含哪些工具」映射从全部
  可见技能收集（all/ 概念规范技能=映射手册）；②「本会话需要哪些 capability」只认
  org/pipeline/role/project/user 层技能的声明——global 层声明不作为注入依据，
  否则 generic 会话经 all/ 概念技能拿到 ~70 个产线工具、击穿七层隔离（单测有回归用例）。
- **role 白名单收窄顺序**：capability 工具必须先并入再收窄（白名单作用于全集），
  且白名单是过滤器不是添加器；ask_user/todo/memory/read_file/write_file 等基础工具始终保留。
- 执行层强制门禁（service `_execute_tool`）：LLM 幻觉调用作用域外工具名直接拒绝
  并回可行动提示——schema 防线挡不住幻觉。
- 测试机实测：服务端直调 17/17（真实策略表读写/产线区分 sdlc 72 个 vs bidding 17 个
  capability 工具/门禁三态）+ HTTP 门禁确认（generic 会话 schema 无 create_project，
  LLM 如实告知未挂载拒绝伪造调用）。

### patch_file 工具（文件定点替换）

old_string 唯一性校验（0 次/多次拒绝，replace_all 显式放行）+ 原子写 + 越界防护
+ 二进制拒绝。HTTP 实测：agent 真实完成 write_file→patch_file→read_file 三步链并回读验证。

### 原生视觉（上传图片直接进对话）

- upload_tools：`is_image` + `build_image_parts`（OpenAI 多模态 data URL；8MB/张、
  4 张/条上限，超限显式告知绝不静默丢）。
- 三个 dspy 入口图片分流：不进文本上下文（避免「二进制无法读取」矛盾提示），
  仍落盘工作空间（i2t 可再处理）。
- gateway.run_message(image_paths) → executor.run(image_parts)：首条用户消息构造
  多模态 content 数组；llm_bridge→llm_v1 端点→inference 全链原样透传 messages。
- 降级兜底 `_degrade_images_if_needed`：模型不支持视觉时剥离图片重试一次 + 注入
  系统说明让 LLM 如实告知「当前模型看不了图」，绝不假装看过。token 估算/压缩摘要
  兼容 list content（`_content_as_text`）。
- HTTP 严格实测：中性文件名（img_001/img_002，无颜色词）红蓝两图一条消息，
  agent 答「第一张红色、第二张蓝色」映射正确，degrade 日志 0 条（模型原生支持）。