OPS 0.4.0 架构与方案设计：Native 与 PTC 再次平权

RT。在0.3.0版本中，Native 和 PTC 共用同一套工具，跑同一套优化思路——这在PTC 模式下确实有token节省，但是同时又要照顾 Native 导致优化不够激进；而 Native 被塞入了过重的工具，导致有时候反而是负优化。鉴于ops团队的扩展，Native 与 PTC分别走各自的优化方案成为可能。

在任何设计之前，首先明确我们项目的基本原则：

OPS 的设计目的是节省ai在 DSH 使用的token，遏制上下文膨胀，节省任务时间，同时尽可能提高模型能力
OPS 代码原则是 DSH 的工具增强插件，仅提供额外的附加工具（包括windows的basn本身封装成具有持久化运行能力的ops_bash工具，代码上copy复用原版的bash实现），以及对部分原版工具的覆盖。联动代码另算。
节省token的方式是降低tools的心智负担，降低tools输入输出，给靠谱的反馈以遏制循环，使用渐进式纰漏获得高级能力

0.4.0当然也会继续遵循轻量化，低侵入性的原则。

所以，我要开始认真了！

打卡

在之前的版本里，我们犯了一个错误，试图用一种数据结构来让两类截然不同工作情况共用。

在 Native 模式下，直接看工具输出的是 LLM，它需要的是清晰、一眼能看懂、带有行号、排版规整的返回，灌一个几千行的严格 JSON Array，反而更吃token；而在 PTC 模式下，接收工具输出的是一段运行在沙盒里的 JS 代码，如果为了省 token 吐出一堆排版好看的纯文本，程序就得写正则表达式去扣文本，一旦稍微改个换行，正则匹配失败，脚本直接崩掉。程序要的是严格、强类型、不可篡改、字段分明的标准数据结构。

所以，这次架构重构，Native 与 PTC 分别优化，底层能力共享，上层投影彻底分离。

这是哈基米画的架构图。你们不要再嘲笑哈基米了好吗，她真的很可爱啊！

                            DSH 宿主环境
         tools/scope · session · workingDirectory · 权限沙箱
         subprocess · approvals · PTC runtime · LLM Provider
                               │
                 ┌─────────────┴─────────────┐
                 │                           │
        Native 普通模式适配器          PTC 代码模式适配器
        - 常驻核心基础工具面           - 纯净 typed SDK
        - 针对模型优化的紧凑排版       - 机器友好的 Canonical 数据
        - 单一工具短回执/去重          - 异常状态机 (Error State Machine)
        - Native 渐进式发现入口        - PTC 渐进式 SDK 按需装载
                 │                           │
                 └─────────────┬─────────────┘
                               │
                       OPS 共享内核中台
           能力清单 (Registry) · 统一参数校验 · 宿主权限桥接
           版本观察账本 · 结果临时存储 · Rust 高性能文件/搜索核心
           跨平台进程治理 · 操作回滚与审计
                               │
                底层支持：操作系统文件系统 / Windows 私有 Bash

她真的很可爱啊！

所以我们的OPS 0.4.0主要逻辑部分会有5个主要组件：

组件名称	内部组件 ID	默认状态	开启后做什么	关闭后怎样
Bash 替换	`dsh-ops/shell`	Windows 开；其他平台默认关	Windows 注册独立工具 `ops_bash`，提供 Bash	不再提供 OPS 的 Bash 工具
普通模式ops工具	`dsh-ops/file`	开	为普通模式模型直调提供更好的文件、搜索、批量操作能力；针对模型排版优化，高级工具默认按需隐藏。	普通模式不提供这组 OPS 专属增强工具，宿主原版工具照常使用。
PTC 模式ops工具	`dsh-ops/ptc`	开	为 PTC 模式提供专门优化的 typed API、批量数据操作、结果稳定引用与局部恢复机制。	PTC 仍可正常使用宿主原生机制，只是不启用这组 OPS 专用 SDK 增强。
扩展高级工具	`dsh-ops/discovery` (新增)	开	注册一个极简发现入口（`ops_discover`），仅在模型需要时动态加载多文件、PDF、DOC 等具体能力。	不向模型提供自主发现能力；用户在配置中显式设为“始终加载”的高级工具仍可用。
替换原版文件工具	`dsh-ops/hide-official` (迁移升级)	关→开	用已通过严格兼容验收的 OPS 工具替换所选的原版工具，模型只看到一套干净的接口。	宿主原版工具完全恢复可见；OPS 的高阶能力（如批量读写）仍可按需独立使用。

这两个和节省Token无关的存放代码的组件暂时不变，未来会调整来让用户理解起来更方便：

组件名称	内部组件 ID	默认状态	开启后做什么	关闭后怎样
会话数据检测	`dsh-ops/panel`	关	真实记录会话内的本地执行耗时、调用链路与 Token 消耗，生成本地轻量可视化面板。	物理停止一切监控逻辑，不记录数据、不落盘生成多余文件。
OPS 只读侧栏	`dsh-ops/tui`	关	在支持的 TUI 终端界面中展示当前 OPS 运行状态与配额消耗，纯本地渲染，绝不调用模型。	不注册侧栏渲染钩子，释放终端渲染资源。

普通模式ops工具只管普通模式，PTC 模式ops工具只管PTC 模式，互不影响，而扩展高级工具则是渐进式纰漏的高级工具的入口——裸dsh对 PDF 解析、Word 解析、表格分析、其他各种日常工作需要自己编写脚本或者下载运行库，堆叠在工具层的话会占用大量固定系统prompt。ops_discover即为工具发现入口，模型发现哪个就用哪个，用不着就加载。

依旧哈基米的图：

┌─────────────────────────────────────────────────────────────┐
│ 组件配置：按需工具入口 (dsh-ops/discovery)                  │
├─────────────────────────────────────────────────────────────┤
│ 基础行为：                                                  │
│   [✔] 启用动态发现入口 (向模型暴露 ops_discover)            │
│   单次最大挂载工具数: [ 3 ] (建议 1-3，硬上限 5)            │
│                                                             │
│ 允许被发现的能力池 (按需沉睡，触发时挂载)：                 │
│   [✔] 多文件范围读取 (ops_read_many)                        │
│   [✔] 高级多模式搜索 (ops_search)                           │
│   [✔] 单文件多段原子编辑 (ops_edit_many)                   │
│   [✔] 批量跨文件替换 (ops_replace)                          │
│   [✔] PDF 文档结构化阅读 (ops_pdf_read)                     │
│   [✔] Word 文档阅读 (ops_doc_read)                          │
│   [✔] CSV/TSV 表格解析与编码转换 (ops_table_read)           │
│                                                             │
│ 始终常驻加载 (跳过 discover 流程，首轮即进模型上下文)：     │
│   [ ] 多文件范围读取 (针对高强度工程重构任务)               │
│   [ ] 高级多模式搜索                                        │
│   [ ] PDF 文档结构化阅读                                    │
│                                                             │
│ [说明] 尚未通过兼容验收的格式能力将以灰色显示，不可勾选。   │
└─────────────────────────────────────────────────────────────┘

【ops_discover 统一 Schema 规范】

{
  "name": "ops_discover",
  "description": "按需动态能力检索入口。当前会话缺少处理特定任务（如多文件批处理、PDF/Word阅读、高级搜索）的工具时调用。激活后的真实工具将在下一轮交互中挂载可用。禁止用于执行具体业务动作。",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "所需能力的自然语言描述（如 'read pdf pages'）或精确指定（如 'select:ops_read_many'）。"
      },
      "max_results": {
        "type": "integer",
        "minimum": 1,
        "maximum": 5,
        "default": 3,
        "description": "本次期望激活的能力数量上限。"
      }
    },
    "required": ["query"]
  }
}

关闭入口后，会话上下文完全不暴露 ops_discover 工具声明，其余组件完全不受影响

对ops 2.0 的老本行ops_bash其实也写的非常不优雅，真正优雅的写法是：

fork走原版的bash-local并夺舍并开启，以完全适应dsh原生的bash运行时和托管逻辑
原版bash-local是指向环境中的bash.exe，很容易跑wsl那，对ops_bash fork走的bash-local，提供
- 可以选择指向git bash而不用下载二进制包
- 使用特殊的二进制管理逻辑来单独下载插件自己的bash。二进制不再是必含项。

这样的话：

   ops_bash 工具
     ├─ 保持 DSH tool-bash 的输入输出契约
     ├─ 复用宿主审批、jobs、subprocess
     └─ OPS Bash 执行器
          ├─ 解析 OPS 私有 Bash 的绝对路径 + 单独二进制文件下载与移除管理器
          ├─ 按宿主当前权限准备执行
          └─ 调用 <绝对路径>/bash.exe -c <command>

不过注意ops_bash，对windowx下的read-only和workspace-write原本的权限必须完全对齐（如果dsh 原版的 bash-local 在windows做的不好就改改）

pwsh7则提供一建升级宿主pwsh的选项，不再携带二进制包。npm装二进制什么的，不需要啦！

在在普通模式下，工具的返回值是返回大模型的阅读材料。在旧版本里，哪怕读一个 10 行的文件，工具也会吐出一个 JSON 结构：

{ "file_path": "...", "lines": [ { "number": 1, "text": "..." }, ... ] }。

而在 Native 模式下，工具其实应该使用紧凑扁平化排版来节省Token。

此外， ops_read_many可以把相关的 3 个文件各自前 50 行一次性端上来，避免来回跑 3 趟；以及 ops_edit_many 返回不要把整个文件又打印一遍给它。

Native 紧凑排版格式化标准：

=== FILE: src/server.ts (Lines 1-8 of 120) ===
1 | import { createServer } from 'http';
2 | import { handleRequest } from './router';
...
8 | const PORT = process.env.PORT || 8080;
=== FILE: src/router.ts (Lines 20-25 of 60) ===
20| export function handleRequest(req, res) {
...
25| }
[Notice: Total 14 lines displayed. TruncatedBy: none.]

ops_edit_many Schema：

{
  "name": "ops_edit_many",
  "description": "针对单个文件的原子化多段替换。所有编辑基于同一文件初始快照校验，全部匹配成功后一次性发布，彻底规避中间脏状态。",
  "parameters": {
    "type": "object",
    "properties": {
      "file_path": { "type": "string", "description": "目标文件相对或绝对路径" },
      "expected_revision": { "type": "string", "description": "可选的文件版本标识，防止基于陈旧内容写入" },
      "edits": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "old_text": { "type": "string", "description": "待替换的精确文本块（必须全局唯一）" },
            "new_text": { "type": "string", "description": "替换后的新文本" }
          },
          "required": ["old_text", "new_text"]
        },
        "minItems": 1,
        "maxItems": 100
      }
    },
    "required": ["file_path", "edits"]
  }
}

上下文感知重读去重：相同文件、相同行号区间、文件mtime 与size 未发生任何改变，且宿主证实前一次读取的正文仍处于当前上下文窗口中。返回标准模板：

[Notice: Content for 'src/server.ts' (Lines 1-8) unchanged. Visible in previous message. Re-read suppressed.]

触发会话压缩或上下文截断，该去重策略立即静默失效，恢复拉取全量物理文本。

在 PTC 模式下，如果工具返回纯文本，编写脚本的模型就必须写一大堆 split('\n') 去拆文本。所以

在 PTC 里，数据应该是严谨、结构化的，模型写的脚本拿到数据后，可以在沙盒里做各种高阶筛选，最后只向外 return 一个最终统计数字。这样既能保证程序执行可靠稳定，又能实现模型上下文节省。

PTC 统一 Outcome 状态信封

/**
 * PTC 模式下所有工具调用的唯一下游信封
 */
export type Outcome<T> =
  | {
      status: 'completed';
      data: T;
      coverage?: CoverageMeta;
    }
  | {
      status: 'partial';
      data: T;
      coverage: CoverageMeta;
      continuation: string; // 显式翻页/续取 Token
    }
  | {
      status: 'rejected' | 'conflict' | 'error' | 'unknown';
      error: OpsErrorPayload;
      data?: T; // 发生部分应用时，保留现场脏数据供排查
    };

export type OpsErrorPayload = {
  code: string;               // 稳定机器错误码，如 'ERR_FILE_NOT_FOUND'
  effectState: 'none' | 'applied' | 'partial' | 'unknown'; // 物理副作用状态
  retry: 'never' | 'after-input-change' | 'after-state-change' | 'bounded-transient';
  message: string;
  nextAction?: string;        // 提示修复参数的明确指引
};

export type CoverageMeta = {
  scannedFiles: number;
  matchedCount: number;
  isComplete: boolean;
  truncatedBy?: 'scan-budget' | 'output-budget' | 'time-limit' | 'row-limit';
};

PTC 典型安全调用范式

// 规范：PTC 代码必须先检查 status，坚决杜绝未捕获崩溃
const res = await tools.ops_read_many({
  files: [
    { file_path: 'lib/parser.ts', offset: 1, limit: 120 },
    { file_path: 'lib/ast.ts', offset: 1, limit: 120 }
  ]
});

if (res.status !== 'completed') {
  // 程序化响应错误状态，不需要模型二次猜错
  return { ok: false, errCode: res.error.code, action: res.error.nextAction };
}

// 在沙盒本地完成提取，仅向模型返回聚合事实
return {
  ok: true,
  summary: res.data.files.map(f => ({
    path: f.path,
    exportedCount: f.lines.filter(l => l.includes('export ')).length
  }))
};

Noted

路径、编码、搜索与修改的一致性也是token节省的关键，在实际使用中，笨蛋大肥鱼经常出现：

写入文件的时候，Linux 用 LF，Windows 悄悄转成了 CRLF。下一次模型去读，行数比预期多了一行，模型以为写入被篡改了，开始疯狂执行“自我修复”，吃光几十万 token。
搜索大项目时，工具搜出了 50 条匹配项然后停了，结果直接返回一个 done。模型误以为全工程只有这 50 个地方，直接大刀阔斧重构，把没搜出来的 200 处代码全搞挂了。

so，基本功必须扎实稳定，诚实、确定、严格一致

SearchExecutionReport 结构定义：

export type SearchExecutionReport = {
  scanComplete: boolean;        // 物理遍历是否彻底完成
  pageComplete: boolean;        // 当前页输出是否完整
  scannedFiles: number;         // 实际扫过的物理文件数
  skippedFiles: number;         // 因忽略规则/权限跳过的文件数
  skipReasons: Record<string, number>;
  matchedObserved: number;      // 当前已看到的匹配项数量
  matchedTotal?: number;        // 仅在严格全量扫描时提供真实总数；早停时严禁伪造
  truncatedBy: 'scan-budget' | 'output-budget' | 'time' | 'row-limit' | 'none';
  continuation?: string;        // 稳定翻页游标
};

普通文件路径解析永远以宿主当前 workingDirectory 为绝对基准，不擅自缓存或绑定过期的启动路径
遇到非法二进制字节或未知编码，必须明确报 ERR_INVALID_ENCODING 并推荐专用文档/二进制工具，不可以替换为乱码问号字符
统一物理 LF 为行号换行边界，无论空文件还是末尾无回车的文件，物理行计算逻辑在所有 Native 与 PTC 投影中必须等价

对防循环与反馈闭环，AI它反复重试一个错误动作，根本原因在于系统给的反馈含糊其辞，根本不知道是文件被锁了、路径打错了，还是因为自己没权限，于是它只能瞎蒙，改个参数再试。

OPS 工具的防循环核心就是，给出绝对清晰的反馈，不让模型自己找。

每一个报错，必须明确界定副作用和重试指引：

如果是权限被宿主安全策略拦截了，直接告诉它 retry: "never"，明确说“你没权限，除非人类在系统侧为你提权，否则再试一万次也没用”
如果是文件在外部被改了，触发了版本冲突（CAS 校验失败），告诉它 retry: "after-state-change"，必须先重新读一遍最新代码，才能再次发起写入
还有亿些具体的反馈可以根据实际绕路情况具体调整，随时更新

OPS 统一执行状态与重试决策表

高层 Status	状态定义	副作用状态 (`effectState`)	重试策略 (`retry`)	物理反馈与模型引导动作
`completed`	动作完全成功	`applied`	`never`	仅返回极简确认短语，严禁废话，不诱导二次多余校验。
`partial`	批处理部分生效 / 触发截断	`partial`	`after-input-change`	清晰列出成功列表与未处理列表，附带继续执行的游标。
`rejected`	触发沙箱规则 / 人工审批拒绝	`none`	`never`	明确指出缺少哪项权限；严禁伪装成不存在，严禁诱导切 Shell。
`conflict`	目标内容已被他人修改 (CAS 冲突)	`none`	`after-state-change`	强制要求先执行重新读取操作，刷新观察快照后再发起修改。
`error`	参数校验失败 / 正则语法错误	`none`	`after-input-change`	精准指出哪一个字段非法，并给出一个最小合法修正示例。
`unknown`	进程崩溃 / 超时杀死 / 管道中断	`unknown`	`never` (需后验检查)	严禁自动重试！要求模型必须先发起一次只读操作核实真实磁盘状态。

在实际开发中，模型可能会干出一些在一个拥有 10 万行庞大日志的目录里执行搜索之类的事情，这时候需要预算防御。如果一个搜索结果搜出了几千条匹配项，那应该在本地受控磁盘安全区落盘，给模型返回一个引用句柄：ref://session-xxx/ops_search/chunk-1，模型如果确实需要这批数据，可以按页去读。这里注意防递归——当模型调工具去读一个引用数据时，返回的结果如果有截断，就截断报错，不能出现读一个引用结果，又生成了一个新引用结果包住旧引用导致无限套娃

预算控制：

预算层级	监控指标与边界	默认安全硬上限	越界治理与防护措施
第一级：执行预算	物理进程耗时、磁盘扫描文件数、IO 吞吐	单次操作 30 秒 / 10,000 文件	立即触发流式早停，保留现场并标记 `truncatedBy: "scan-budget"`。
第二级：存储预算	引用缓存磁盘空间、单会话总配额	单个结果 10 MB / 会话总配额 100 MB	超限直接抛出配额耗尽异常，采用 LRU 淘汰旧引用，未知效果审计数据永不自动淘汰。
第三级：输出预算	传给模型的单次报文字节大小	默认 64 KB (强转义后)	超出部分自动截断，保留头部高置信内容，生成稳定持久化引用供分段提取。
第四级：聚合预算	并发调用多工具时的总上下文积聚	依宿主全局上下文窗口策略为准	OPS 自有工具维护并发流量阀门，避免多个大输出工具同时冲击上下文。

StorageReference 数据结构：

export type StorageReference = {
  refId: string;           // 格式：ref://<session_id>/<tool_name>/<uuid>
  createdAt: number;       // 创建时间戳
  ttlMs: number;           // 生存期（默认会话退出即销毁）
  schemaVersion: string;   // 结构版本
  producerTool: string;    // 产出该引用的工具名
  totalItems: number;      // 包含记录总数
  totalBytes: number;      // 物理字节数
  preview: string;         // 首部前 10 行短预览
};

PDF、DOC，各种奇怪的日常格式读取这个——应该大概不用详细说，总之，常见格式文件，ocr，文字抓取，去重之类的高级工具塞渐进式发现里，这一块可以几乎无限制的增加，又不咋挤占系统token，还有各种常用用法对应的快速工具，一点一点补上

以及TypeScript 胶水代码和 Rust 底层代码分层：

- TypeScript 宿主胶水层：负责和 DSH 宿主的所有 API 对接，负责区分 Native 文本渲染和 PTC SDK 编译，负责实现那 7 个组件的用户配置界面。
Rust 执行内核：纯粹作为高性能二进制存在，提供极简、无锁、带长度前缀的跨进程 IPC 协议，专心致志做最底层的流式文件读取、原子写入发布与 Ripgrep 搜索。

暂定代码目录与 IPC 协议：

ops-workspace/
├── package.json
├── lib/                             # TypeScript 宿主胶水层
│   ├── components/                  # 0.4.0 对应的 7 大用户组件实现
│   │   ├── shell-component.ts       # Bash 与 PowerShell 7
│   │   ├── native-file-component.ts # 普通模式工具增强
│   │   ├── ptc-file-component.ts    # PTC 模式工具增强
│   │   ├── discovery-component.ts   # 按需工具入口 (新增)
│   │   ├── replace-component.ts     # 替换原版文件工具 (迁移升级)
│   │   ├── panel-component.ts       # 会话数据检测
│   │   └── tui-component.ts         # OPS 只读侧栏
│   ├── capabilities/                # 能力统一定义清单 (单一事实源)
│   ├── modes/
│   │   ├── native/                  # Native 专用呈现、排版、防回显 Stub
│   │   └── ptc/                     # PTC 专用 SDK 生成器、Canonical 序列化
│   ├── results/                     # 稳定引用与 LRU 淘汰
│   └── authority/                   # 宿主权限桥与 workingDirectory 同步
│
└── native/                          # 底层 Rust 独立工程
    ├── Cargo.toml
    └── crates/
        ├── ops-protocol/            # 跨进程二进制/JSON 序列化标准
        ├── ops-files/               # 零拷贝流式读取、原子 CAS 写入发布
        ├── ops-search/              # 基于 Ripgrep 栈的高性能搜索
        ├── ops-batch/               # Plan 与 Resume 批处理状态机
        ├── ops-results/             # 本地安全结果分卷缓存
        └── ops-documents/           # 纯净沙箱文档解析核心

宿主 Node 进程与 Rust Worker 间采用带 4 字节大端序长度前缀的 IPC 帧传输：

[4-Byte Big-Endian Length][JSON-RPC / Binary Frame Payload]

{
  "version": "1.0",
  "requestId": "req-20261018-01",
  "sessionId": "session-e842",
  "component": "native-file",
  "action": "read_range",
  "authRoot": "/workspaces/my-project",
  "params": {
    "file_path": "src/index.ts",
    "offset": 1,
    "limit": 100
  },
  "budget": {
    "timeoutMs": 10000,
    "maxBytes": 65536
  }
}

对于 0.3.x 到 0.4.0 的升级部分，原来 6 个组件的配置必须通过自动化平滑映射。替换原版文件工具”在新版本中默认保持关闭——一直等到ops完全稳定。

老版本 6 组件到 0.4.0 7 组件平滑映射表：

0.3.x 旧组件 ID / 表现	0.4.0 官方去向	自动迁移处理规则
`dsh-ops/shell`	Bash 与 PowerShell 7	保留组件 ID 与开启状态；Windows 默认开启 `ops_bash`。
`dsh-ops/file`	普通模式工具增强	保留组件 ID；原版增强逻辑平移，剔除所有笨重的高级常驻 Schema。
`dsh-ops/ptc`	PTC 模式工具增强	保留组件 ID；剥离与普通模式耦合的代码，升级为独立 typed SDK 注入。
(无对应实现)	按需工具入口	全新独立组件（`dsh-ops/discovery`），默认开启，初始包含已就绪的高阶能力。
`dsh-ops/hide-official`	替换原版文件工具	保留原 ID；语义升级。取消全量粗暴屏蔽，迁移为细粒度多选；默认保持关闭。
`dsh-ops/panel`	会话数据检测	保留 ID；修复“空转”Bug，组件开关直接绑定物理采集开关，不搞假运行。
`dsh-ops/tui`	OPS 只读侧栏	保留 ID 与轻量只读渲染逻辑，不作破坏性改动。

GPT龙娘最喜欢的测试门禁：

任务标识	真实测试场景	预期硬门禁指标
BM-01	普通模式下，使用 `ops_read_many` 读取 3 个文件的局部片段。	外层请求轮次必须为 1 轮；输出文本字节数较原版分别调用降低 $\ge 40%$。
BM-02	普通模式下，使用 `ops_edit_many` 对单个文件执行 5 处多段修改。	一次提交完成，中途 CAS 冲突检测准确率 100%；严禁输出完整文件复读。
BM-03	初始启动会话（未触发高级功能）。	初始系统提示词中新增 Schema 占用 token 数严格 $\le 400$ tokens。
BM-04	触发 `ops_discover` 激活 PDF 解析能力。	挂载后下一轮精准暴露 `ops_pdf_read`；初始未激活前 Schema 泄露为 0。
BM-05	在非授权工作区外路径执行读写探测。	宿主安全拦截率 100%；返回 `rejected` 且绝对不泄露系统上层真实路径。

打卡

Wow, impressive!

0.4.0版本已发布，接下来的小版本迭代是修bug，优化/添加新的渐进式纰漏工具~

期待

Closing the 0.4.0 architecture/design tracker following the maintainer's release confirmation in this discussion. The dual Native/PTC projections, shared kernel, discovery, result references, typed source and release documentation are implemented in the merged 0.4 series; current main is 0.4.1.

This does not mark later regression reports as fixed. Session performance and lifecycle work remains separately tracked in #333/#359/#369/#382/#386/#387, and Windows execution defects in #363/#373/#374. Keeping those concrete defects separate avoids treating completion of the design plan as proof of later runtime acceptance.

Navigation Menu

Repository navigation

OPS 0.4.0 架构与方案设计：Native 与 PTC 再次平权 #261

【ops_discover 统一 Schema 规范】

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

OPS 0.4.0 架构与方案设计：Native 与 PTC 再次平权 #261

Description

Activity

Thatgfsj commented on Oct 18, 2026

T-Auto commented on Oct 18, 2026

T-Auto commented on Oct 18, 2026

【ops_discover 统一 Schema 规范】

T-Auto commented on Oct 18, 2026

T-Auto commented on Oct 18, 2026

T-Auto commented on Oct 18, 2026

Haoming9527 commented on Oct 18, 2026

T-Auto commented on Oct 18, 2026

T-Auto commented on Oct 18, 2026

T-Auto commented on Oct 18, 2026

T-Auto commented on Oct 18, 2026

Nicholas023 commented on Oct 18, 2026

Richeir commented on Oct 18, 2026

T-Auto commented on Oct 20, 2026

zhenxian-1 commented on Oct 20, 2026

Haoming9527 commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions