dev-flow-codex 0.5.0 → 0.5.2

package/README.md

@@ -1,196 +1,189 @@
 # dev-flow-codex
 
-`dev-flow-codex` 是 Codex CLI 的 explicit-only Dev Flow Adapter。package 包含一个 Codex
-Plugin、一个 `dev-flow` Skill、一份 local STDIO MCP 声明、method-profile reference 和一个
-`darwin-arm64` Core executable。它不保存 Task、process cursor、transition table 或 recovery
-classification。
+[中文](https://github.com/Innocent-children/dev-flow/blob/main/packages/codex/README.md) |
+[English](https://github.com/Innocent-children/dev-flow/blob/main/docs/CODEX_en.md)
 
-## 安装与发布身份
+`dev-flow-codex` 把 Dev Flow 状态图接入 Codex CLI。package 包含 Codex Plugin、显式 Skill、
+local STDIO MCP 配置和 macOS arm64 Core executable；Task、节点、流转和 Recovery 仍由 bundled
+Go Core 独自管理。
 
-当前 package、plugin 和 bundled Core 版本是 `0.4.0`。Feature 009 发布已完成的 Feature 008
-graph runtime；历史 `0.3.0` 包、Tag、Release 与证据保持冻结。
+## 支持范围
 
-标准安装和显式注册入口是：
+| 项目 | 当前支持 |
+| --- | --- |
+| Package | `dev-flow-codex@0.5.1` |
+| Bundled Core | `0.5.0` |
+| Platform | macOS arm64 |
+| Node.js | `>=24` |
+| Codex | `>=0.147.0` |
+| Release | [codex-v0.5.1](https://github.com/Innocent-children/dev-flow/releases/tag/codex-v0.5.1) |
+
+`0.5.1` 的 normal release 已通过 registry package 安装、package/Core identity、setup、Core
+handshake、remove、uninstall 和 repository-unchanged 门禁。上表记录已经验证的精确公开版本；
+下面的安装命令使用 npm `latest` dist-tag 获取当前最新稳定 package。
+
+## 安装
 
 ```bash
-npm install -g dev-flow-codex@0.4.0
+npm install -g dev-flow-codex@latest
 dev-flow-codex setup
+dev-flow-codex --version
 ```
 
-精确 npm tarball、standalone Core、manifest、checksums、实际 Codex 版本和最终 Journey 结果以
-GitHub Release `v0.4.0` 与 registry 回读证据为准。
+npm 全局安装只负责把 package 和 `dev-flow-codex` launcher 放到 `PATH`。`setup` 是独立步骤：
+它验证平台、package 内容、bundled Core 与 Codex 兼容版本，然后注册 Plugin、marketplace 与 MCP，
+并在写入后回读 ownership。`--version` 同时输出实际 package 和 bundled Core 版本。
 
-当前公开支持 native macOS arm64、Node.js `>=24` 和 Codex
-`>=0.147.0 <0.148.0`。没有 Linux、Windows、Intel Mac、Rosetta 或 DeepSeek 产品支持声明。
+## 命令参考
 
-## Closed package
+`dev-flow-codex` 的生产 CLI 只接受下表中的命令；未知参数会在执行任何注册操作前失败。
 
-生产 package 内容由 `package.json.files` 和本地 builder 共同关闭：
+| 命令 | 说明 |
+| --- | --- |
+| `npm install -g dev-flow-codex@latest` | 安装 npm `latest` 指向的 package，并把 launcher 全局加入 `PATH`；不会自动注册 Codex Plugin。 |
+| `dev-flow-codex setup` | 校验 package、Core 和 Codex 版本，注册 marketplace、Plugin 与 MCP，并回读最终状态。重复执行会验证现有 ownership，兼容 package 升级也通过该命令完成。 |
+| `dev-flow-codex setup --json` | 与 `setup` 行为相同，但只输出机器可读 JSON：`operation`、`status`、`changed` 和 `receipt_path`。 |
+| `dev-flow-codex --version` | 输出 `dev-flow-codex <package-version> (core <core-version>)`，用于确认实际安装身份。 |
+| `dev-flow-codex remove` | 删除该 package 拥有的 Plugin、marketplace 注册和 receipt；保留 Task data、未知相邻文件和目标 Git 仓库。 |
+| `dev-flow-codex remove --json` | 与 `remove` 行为相同，并输出机器可读 JSON；`next_step` 提示随后执行全局 npm 卸载。 |
+| `npm uninstall -g dev-flow-codex` | 在 `remove` 完成后卸载全局 package。单独执行不会先清理 Codex 注册。 |
+| `dev-flow-codex mcp` | **内部 Host 命令。** Plugin 的 MCP 配置调用它来设置数据目录和 admission instructions，再启动 packaged Core 的 `mcp --stdio`；正常用户不应手工运行。 |
 
-```text
-.agents/plugins/marketplace.json
-LICENSE
-README.md
-bin/dev-flow-codex.mjs
-lib/lifecycle.mjs
-lib/paths.mjs
-package.json
-plugin/.codex-plugin/plugin.json
-plugin/.mcp.json
-plugin/skills/dev-flow/SKILL.md
-plugin/skills/dev-flow/agents/openai.yaml
-plugin/skills/dev-flow/references/method-profiles.md
-plugin/skills/dev-flow/references/node-payloads.md
-runtime/darwin-arm64/dev-flow
-```
+当前 CLI 不提供 `help`、`update`、`uninstall` 或其他隐式子命令。更新到当前最新版本时执行：
 
-Artifact 不包含 tests、fixtures、specs、source tree、`.git`、`node_modules`、用户数据、构建日志
-或绝对路径。package 没有 production npm dependency 和 install/update/uninstall lifecycle hook；
-安装文件与显式 Codex 注册是两个操作。
+```bash
+npm install -g dev-flow-codex@latest
+dev-flow-codex setup
+```
 
-## Local package build
+完整的 Codex、DeepSeek、Core 和 MCP 命令目录见
+[命令参考](../../docs/COMMANDS.md)。
 
-在干净、已提交的 source commit 上，把最终验收制品构建到仓库外的空目录：
+## 开始一个 Task
 
-```bash
-ARTIFACT_ROOT="${TMPDIR:-/tmp}/dev-flow-local-artifacts"
-mkdir -p "$ARTIFACT_ROOT"
-SOURCE_COMMIT="$(git rev-parse HEAD)"
+在当前 Git 仓库中，用唯一的精确 selector 描述工作：
 
-pnpm --dir packages/codex run build:local \
-  --output "$ARTIFACT_ROOT" \
-  --final \
-  --source-commit "$SOURCE_COMMIT" \
-  --report "$ARTIFACT_ROOT/artifact-evidence.json"
+```text
+$dev-flow-codex:dev-flow Fix idempotency in the order-creation endpoint and run targeted tests.
 ```
 
-`--final` 表示 builder 的 clean-source/identity verification 模式；公开 Release 由 standalone
-一键发布命令产生。
-Builder 要求输出目录已经存在、没有 `.tgz`，source tree 干净且 HEAD 等于 `--source-commit`；
-它验证 package/Core/plugin version identity、platform、detached runtime executable 和 closed pack
-contents，并输出 SHA-256 evidence。制品与 evidence JSON 均保留在仓库外。
+这不是 shell 命令。新 Task 从 `REQUIREMENTS` 开始，默认使用 `plain` profile；也可以在同一请求
+中明确选择 `spec-kit` 或 `openspec`。Task 创建后 profile 保持不变。
 
-本地构建只生成和检查制品，不执行 setup/remove、不修改真实 Codex 配置、不启动 native Journey。
+Core 会持续返回：
 
-## Explicit invocation boundary
+- 当前 node、purpose、entry/completion conditions；
+- 当前 revision、action identity 和 repository binding；
+- `allowed_effects`、`required_evidence` 和 verification budget；
+- method profile 对应的 semantic steps；
+- 全部合法 transitions、guard、destination 与 reason rule。
 
-Skill metadata 设置 `policy.allow_implicit_invocation: false`。唯一精确 selector 是：
+Codex 完成当前节点工作后，只提交 live Action 允许的 `transition_id` 和 closed payload。
 
-```text
-$dev-flow-codex:dev-flow
-```
+## 显式调用边界
 
-Skill resource/base name 是 `dev-flow`，installed Skill full name 是 `dev-flow-codex:dev-flow`，
-only exact explicit selector 是 `$dev-flow-codex:dev-flow`。bare `$dev-flow` is not an alias and
-does not select this Skill；wrong plugin namespace、wrong Skill base name 或 missing selector 也不会
-选择它。ordinary prompt 必须产生 zero Dev Flow calls。non-exact selectors must not complete a task-bearing operation；
-This does not disable ordinary Codex repository tools. The package does not make or claim selector-bound MCP visibility or authorization。
-
-被接纳的请求必须只涉及一个现有 Git repository，并先调用 `dev_flow_server_info({})`。当前
-source-local Contract 0.2 handshake 必须返回：
+Skill metadata 设置 `policy.allow_implicit_invocation: false`，因此只有下面这个精确 selector 可以
+进入 Dev Flow：
 
 ```text
-schema_version = 2
-core_limits_version = 0.2
-process = standard-development@1
-method_profiles = plain, spec-kit, openspec
-exact six-tool catalog
+$dev-flow-codex:dev-flow
 ```
 
-不完整、不同版本或不同顺序的 catalog 会停止请求。公开工具为：
+相关名称与边界如下：
 
-```text
-dev_flow_server_info
-dev_flow_open_task
-dev_flow_get_task
-dev_flow_get_next_action
-dev_flow_apply_action
-dev_flow_cancel_task
-```
+- Skill resource/base name 是 `dev-flow`；
+- 安装后的 Skill full name 是 `dev-flow-codex:dev-flow`；
+- `$dev-flow` 不是别名，不会选择该 Skill；
+- plugin namespace 错误、Skill base name 错误或缺少 selector 都不会选择该 Skill；
+- 普通提示词必须产生零次 Dev Flow 调用；
+- 非精确 selector 不得完成任何携带 Task 的操作。
 
-## Graph task 与 method profiles
+这项边界不限制 Codex 的普通仓库工具，也不声称 MCP 的可见性或授权与 selector 绑定；它只约束
+当前 Skill 是否可以发起 Dev Flow 调用。
 
-新任务从 `REQUIREMENTS` 开始，Core 返回完整 node contract、semantic method steps 和全部合法
-transitions。Codex 只提交 Core 返回的 `transition_id` 和 closed node payload；destination、guard、
-current node 和 completion 都由 Core 决定。
+通过 admission 后，`dev_flow_server_info({})` 必须是第一次 Dev Flow 调用。安装内容、bundled
+Core、Codex 兼容性和注册 ownership 已由 `dev-flow-codex setup` 验证；每次 Task 启动只静默确认
+Core ready、`standard-development`、definition digest、method profiles 与六个工具的闭合集合，
+成功后立即打开或恢复 Task。正常启动不向用户逐项展示版本、摘要、profile 或工具目录；只有失败
+时才报告具体阻塞项和一个可执行的恢复步骤。工具和 method profile 的返回顺序不影响兼容性。
 
-Task 创建时选择一个 immutable profile：
+| MCP 工具 | 作用 |
+| --- | --- |
+| `dev_flow_server_info` | 读取 Core identity、能力、process、method profile 和工具目录；有效 admission 后必须首先调用。 |
+| `dev_flow_open_task` | 为当前 canonical repository 创建新 Task，或恢复其现有 Task。 |
+| `dev_flow_get_task` | 读取持久化 Task；可附带 operation probe 获取 Recovery assessment。 |
+| `dev_flow_get_next_action` | 读取当前节点的权威 Action、验证预算、method steps 和全部合法 transition。 |
+| `dev_flow_apply_action` | 使用当前 revision、Action identity、repository binding 和 closed payload 应用一次 Core 声明的 transition。 |
+| `dev_flow_cancel_task` | 使用当前 revision 和明确 reason 取消一个非终态 Task。 |
 
-```text
-plain
-spec-kit
-openspec
-```
+## 理解审查与 Recovery
 
-三种 profile 使用同一状态图。Adapter 按当前 Action 渲染实际存在的 capability 和预期 artifact。
-capability unavailable 或 unknown 时，它明确报告缺失，并呈现合同定义的 plain-equivalent work；
-只有等价工作实际完成时才提交 `plain_fallback` method evidence。command、checkbox、sync、archive
-或 artifact 自身不会推进 Core。
+`TEST` 通过后，Task 进入 `COMPREHENSION_REVIEW`。Codex 解释当前行为、设计与维护风险，开发者
+给出明确 verdict。复杂实现进入 `REFACTOR`；仓库发生变化后必须重新回到 `TEST`。
 
-`TEST` 成功后必须进入 `COMPREHENSION_REVIEW`。Codex 向开发者解释当前行为、复杂度和维护
-风险，并取得明确 verdict；AI/static evidence 不能替代用户确认。复杂代码进入 `REFACTOR`，
-repository-changing refactor 只能回到 `TEST`。
+每次 mutation 前，Adapter 保留 request/operation ID、source cursor、revision、action、
+repository binding 和原始 payload。结果缺失、取消、截断、损坏或 transport failure 时，Adapter
+先读取 Core，再遵循五分类 Recovery 和 advice；它不自行判断 retry safety 或 destination。
 
-## Read-before-retry
+## 数据目录
 
-每次 mutation 前，Adapter 保留完整 operation identity：request/operation ID、process、source
-cursor、revision、action、issuance binding 和原始 closed payload。结果缺失、取消、损坏、截断或
-transport failure 时不得盲目重试，也不得重建缺失的 probe。
+默认数据目录由 package lifecycle 管理，也可以设置：
 
-Adapter 使用 `dev_flow_get_task` 或 `dev_flow_get_next_action` 提交原 operation probe，并只遵循
-Core 返回的五分类 Assessment 和 advice。Probe 零写入；只有显式 recovery apply 可以完成一次
-Core-derived transition 或创建一次 blocker。Adapter 不判断 classification、retry safety、resume
-node 或 destination。
+```bash
+export DEV_FLOW_DATA_DIR="/absolute/path/to/existing-directory"
+```
 
-## Schema 1 unsupported guidance
+显式目录必须已经存在、可用且可 canonicalize。setup、remove 和 npm uninstall 都保留 Task data
+与未知相邻文件，也不会修改目标 Git 仓库。
 
-Graph package 只支持 fresh Schema 2、snapshot-v2 和精确 `standard-development@1`。遇到 Schema
-1/pre-graph data 时 Core 返回 `SCHEMA_UNSUPPORTED`，且不 decode、migrate、rename、truncate、
-delete 或 reset 旧数据。不要重复启动或自动清理。
+当前 Core 只读取当前 SQLite Schema。检测到不兼容或 pre-graph data 时返回
+`SCHEMA_UNSUPPORTED` 并保持零写入。请选择新的数据目录，或在 Core 外部手工归档、改名或删除
+旧目录。
 
-用户必须明确选择一个新的绝对、canonical、usable `DEV_FLOW_DATA_DIR`，或在 Core 外部手工
-archive/rename/delete 旧目录，再启动 graph Core。错误信息不回显私有数据库路径。
+## 移除
 
-## Setup、remove 与 retained data
+先删除 Codex 注册，再卸载全局 npm package：
 
-`0.4.0` package 文件安装仍与 Codex 注册分离：只有 `dev-flow-codex setup` 可以创建经 ownership
-和 read-back 验证的注册，只有 `dev-flow-codex remove` 可以删除该产品拥有的注册。
+```bash
+dev-flow-codex remove
+npm uninstall -g dev-flow-codex
+```
 
-setup/update/remove/uninstall 均保留 Core task data 和未知相邻文件，不会修改目标 repository 或
-Git。remove 应先证明 plugin/marketplace absence，再单独执行 package-manager uninstall。重新安装
-兼容的 graph artifact 可以从同一 Schema 2 数据目录恢复任务；没有任何 Schema 1 reader 或
-conversion path。
+需要机器可读结果时使用：
 
-## Closed node payload construction
+```bash
+dev-flow-codex remove --json
+```
 
-打包 Skill 在每次普通 apply 前同时读取 live Action、`dev_flow_apply_action` `inputSchema` 和
-`plugin/skills/dev-flow/references/node-payloads.md` 的对应标记模板。该 reference 覆盖
-REQUIREMENTS、DESIGN、TASKS、IMPLEMENT、TEST、COMPREHENSION_REVIEW 的复杂度/通过分支、
-REFACTOR、DELIVERY 和 BLOCKED resolution，并由真实 MCP validator、workflow decoder 和 payload
-validator 提取验证。它只提供构造指引，不保存游标、复制 transition authority 或替代 Core。
+重新安装兼容 package 并再次运行 `setup` 后，可以从保留的当前数据目录继续 Task。
 
-`required_evidence` 与 ArtifactReference role 不同；`repository_observation` 不得作为 artifact
-role。无真实 process artifact 时使用空 `artifacts`，同时保留完整 branch wrapper、当前 baseline/
-record/evidence identity 和精确 MethodEvidence。Core `INVALID_ARGUMENT` 会停止该 mutation，不会
-触发候选 payload 试探或自动重试。
+## Package 内容
 
-对于 apply/cancel，Result Envelope `request_id` 与 caller mutation `request_id` 相同，并与成功
-提交后的 `LastOperation.operation_id`/TaskEvent identity 对齐。没有 caller request ID 的 read/open/
-info 工具继续使用 Core 生成的本地 transport identity。
+生产 package 由 `package.json.files` 关闭，只包含 Plugin、Skill、MCP 配置、lifecycle library、
+license 和一个 darwin-arm64 Core。它不包含 source tree、tests、fixtures、specs、`.git`、
+`node_modules`、用户数据、构建日志或绝对路径，也没有 install/uninstall hook。
 
-## Deterministic validation
+## 维护者入口
 
-完整 package-local 测试入口为：
+Package-local 验证：
 
 ```bash
 pnpm --dir packages/codex test
 ```
 
-它覆盖 package contract、Skill contract、lifecycle、journey harness、parser/evidence 以及已有
-launcher/runtime tests。fixture、simulated Harness 和 static contract 证据不属于 native Codex
-evidence，也不证明 package 已公开发布。
+Source-local 最终制品构建：
+
+```bash
+ARTIFACT_ROOT="${TMPDIR:-/tmp}/dev-flow-codex-artifacts"
+mkdir -p "$ARTIFACT_ROOT"
+SOURCE_COMMIT="$(git rev-parse HEAD)"
+
+pnpm --dir packages/codex run build:local \
+  --output "$ARTIFACT_ROOT" \
+  --final \
+  --source-commit "$SOURCE_COMMIT" \
+  --report "$ARTIFACT_ROOT/artifact-evidence.json"
+```
 
-Feature 008 的 source-local acceptance 已完成。Attempt 3 提供真实 native Codex graph-flow
-evidence；独立的 no-Codex deterministic lifecycle 使用同一精确 artifact 证明 setup、remove、
-npm uninstall、data retention、相同 artifact reinstall 和同一 lifecycle Task terminal reopen。
-两类 evidence 保持不同标签，且都不构成 registry package 或公开发布证明。
+构建输出必须位于仓库外。公开发布使用根目录的 standalone release command，见
+[`release/codex/README.md`](../../release/codex/README.md)。

package/bin/dev-flow-codex.mjs

@@ -16,7 +16,7 @@ import {
 } from "../lib/paths.mjs";
 
 const FORWARDED_SIGNALS = ["SIGINT", "SIGTERM", "SIGHUP"];
-const NPM_UNINSTALL_HANDOFF = "Run npm uninstall dev-flow-codex separately after deregistration.";
+const NPM_UNINSTALL_HANDOFF = "Run npm uninstall -g dev-flow-codex separately after deregistration.";
 const CODEX_MCP_INSTRUCTIONS_ENVIRONMENT = "DEV_FLOW_CODEX_MCP_INSTRUCTIONS";
 const CODEX_MCP_INSTRUCTIONS = [
   "Dev Flow for Codex is explicit-only.",
@@ -58,9 +58,6 @@ export async function runCLI(arguments_, dependencies = {}) {
         environment,
         currentDirectory: paths.packageRoot,
       });
-      if (coreVersion !== packageVersion) {
-        throw new Error(`package version ${packageVersion} does not match Core version ${coreVersion}`);
-      }
       stdout.write(`dev-flow-codex ${packageVersion} (core ${coreVersion})\n`);
       return { code: 0, signal: null };
     }

package/lib/lifecycle.mjs

@@ -20,7 +20,7 @@ import { containedPath } from "./paths.mjs";
 
 const execFile = promisify(execFileCallback);
 
-export const CODEX_COMPATIBILITY_RANGE = ">=0.147.0 <0.148.0";
+export const CODEX_COMPATIBILITY_RANGE = ">=0.147.0";
 export const MARKETPLACE_NAME = "dev-flow-local";
 export const PLUGIN_NAME = "dev-flow-codex";
 export const PLUGIN_SELECTOR = `${PLUGIN_NAME}@${MARKETPLACE_NAME}`;
@@ -293,9 +293,6 @@ async function preflightSetup({ paths, packageVersion, codexExecutable, environm
     environment,
     currentDirectory: paths.packageRoot,
   });
-  if (coreVersion !== packageVersion) {
-    throw new Error(`packaged Core version ${coreVersion} does not match package version ${packageVersion}`);
-  }
   const codexVersion = await inspectCodexVersion(codexExecutable, {
     environment,
     currentDirectory: paths.packageRoot,
@@ -473,7 +470,6 @@ function assertRegistrationAbsent(state, paths) {
 function assertRemovalReceipt(receipt, paths, packageVersion) {
   const matches =
     receipt.product.version === packageVersion &&
-    receipt.product.core_version === packageVersion &&
     receipt.registration.marketplace_name === MARKETPLACE_NAME &&
     receipt.registration.marketplace_root === paths.marketplaceRoot &&
     receipt.registration.plugin_name === PLUGIN_NAME &&
@@ -739,7 +735,6 @@ function createReceipt({
   installedAt,
 }) {
   return validateReceipt({
-    schema_version: 3,
     product: {
       name: PLUGIN_NAME,
       version: packageVersion,
@@ -822,29 +817,26 @@ async function readJSON(path, label) {
 }
 
 export function versionSatisfiesRange(version, range = CODEX_COMPATIBILITY_RANGE) {
-  const match = /^>=(\S+)\s+<(\S+)$/.exec(range);
+  const match = /^>=(\S+)$/.exec(range);
   if (!match) throw new Error(`unsupported compatibility range ${JSON.stringify(range)}`);
   const candidate = parseSemver(version, "Codex version");
   const minimum = parseSemver(match[1], "compatibility minimum");
-  const maximum = parseSemver(match[2], "compatibility maximum");
-  return compareSemver(candidate, minimum) >= 0 && compareSemver(candidate, maximum) < 0;
+  return compareSemver(candidate, minimum) >= 0;
 }
 
 export function validateReceipt(receipt, { compatibilityRange = CODEX_COMPATIBILITY_RANGE } = {}) {
   assertObject(receipt, "registration receipt");
   assertExactKeys(
     receipt,
-    ["schema_version", "product", "host", "registration", "paths", "resource_digests", "installed_at"],
+    ["product", "host", "registration", "paths", "resource_digests", "installed_at"],
     "registration receipt",
   );
-  if (receipt.schema_version !== 3) throw new Error("registration receipt schema_version must equal 3");
 
   assertObject(receipt.product, "product");
   assertExactKeys(receipt.product, ["name", "version", "core_version", "codex_compatibility"], "product");
   assertEqual(receipt.product.name, "dev-flow-codex", "product.name");
   parseSemver(receipt.product.version, "product.version");
   parseSemver(receipt.product.core_version, "product.core_version");
-  assertEqual(receipt.product.core_version, receipt.product.version, "product Core version");
   assertEqual(receipt.product.codex_compatibility, compatibilityRange, "product compatibility range");
 
   assertObject(receipt.host, "host");
@@ -1005,7 +997,6 @@ function assertCompatibleReceiptUpgrade(previousReceipt, currentReceipt) {
 
 function upgradeOwnershipProjection(receipt) {
   return {
-    schema_version: receipt.schema_version,
     product: {
       name: receipt.product.name,
       codex_compatibility: receipt.product.codex_compatibility,
@@ -1022,7 +1013,6 @@ function upgradeOwnershipProjection(receipt) {
 
 function ownershipProjection(receipt) {
   return {
-    schema_version: receipt.schema_version,
     product: receipt.product,
     host: receipt.host,
     registration: receipt.registration,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dev-flow-codex",
-  "version": "0.5.0",
+  "version": "0.5.2",
   "private": false,
   "description": "Explicit-only Dev Flow integration for Codex CLI.",
   "license": "Apache-2.0",

package/plugin/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "dev-flow-codex",
-  "version": "0.5.0",
+  "version": "0.5.2",
   "description": "Explicit-only Dev Flow integration for Codex CLI.",
   "author": {
     "name": "Dev Flow"

package/plugin/skills/dev-flow/SKILL.md

@@ -5,10 +5,10 @@ description: "Explicit-only Dev Flow entry point for Codex. Use only when the cu
 
 # Dev Flow
 
-This Skill is the Contract 0.2 Codex adapter for the shared Dev Flow Core. Core owns task state,
+This Skill is the current Core contract Codex adapter for the shared Dev Flow Core. Core owns task state,
 current node, legal transitions, destinations, recovery, blockers, and terminal outcomes. The Skill
-admits one explicit request, presents a complete Core Action, renders method work, and forwards one
-closed result without keeping adapter state.
+admits one explicit request, silently validates normal startup results, renders method work, and
+forwards one closed result without keeping adapter state.
 
 ## Admission gate
 
@@ -38,20 +38,23 @@ If admission fails, explain the missing precondition and stop before Skill-owned
 not complete a task-bearing call or create adapter state. Host-exposed read-only or Core-rejected
 calls are not activation and must be reported honestly.
 
+Successful admission is internal startup work. Do not narrate the selector, Git-root, repository,
+profile-default, or authorization checklist; continue directly to the compatibility handshake.
+
 ## Compatibility handshake
 
 Only after admission passes, call `dev_flow_server_info({})`; it must be the first Dev Flow tool
 call. Require one complete structured result proving:
 
-- product is exactly `dev-flow`, and Core version equals the packaged product version;
-- `schema_version` is exactly `2` and `core_limits_version` is exactly `0.2`;
+- product is exactly `dev-flow`, and Core version is present and canonical. Core and the Codex
+  package are independently versioned products, so their versions are not required to be equal;
 - transport is exactly `stdio`, health is exactly `ready`, and the supported host set contains
   `codex`;
-- `supported_processes` contains exactly one closed `standard-development@1` entry:
-  `process_id` is `standard-development`, `process_version` is `1`, `definition_digest` is present
-  and canonical, and `new_task_supported` is exactly `true`;
-- `method_profiles` is exactly `plain`, `spec-kit`, `openspec` in that order;
-- the tool catalog contains exactly these six raw names, in this order:
+- `supported_processes` contains exactly one closed `standard-development` entry:
+  `process_id` is `standard-development`, `definition_digest` is present and canonical, and
+  `new_task_supported` is exactly `true`;
+- `method_profiles` contains exactly `plain`, `spec-kit`, and `openspec`, regardless of order;
+- the tool catalog contains exactly these six raw names, regardless of order:
 
 1. `dev_flow_server_info`
 2. `dev_flow_open_task`
@@ -60,10 +63,17 @@ call. Require one complete structured result proving:
 5. `dev_flow_apply_action`
 6. `dev_flow_cancel_task`
 
-Any other schema, unsupported process version, absent process digest, false new-task support,
-incomplete method-profile set, missing/additional/reordered tool, or incomplete, truncated, malformed,
-or incompatible result fails the handshake. Stop without task discovery or undocumented probing. Do
-not inspect local source or an installed binary, and do not start a second MCP server to bypass a
+Package resources, the bundled Core executable and version, Codex compatibility, and registration
+ownership are setup-time checks owned by `dev-flow-codex setup`; do not repeat them by inspecting the
+installed package or executable during each Skill invocation.
+
+An unsupported process, absent process digest, false new-task support, incomplete method-profile set,
+missing or additional tool, or incomplete, truncated, malformed, or incompatible result fails the
+handshake. On success, do not display or explain the handshake checklist, versions, process digest,
+profiles, or tool catalog; continue immediately to task discovery. On failure, report only the
+specific blocking condition and one actionable next step. For installation or compatibility failures,
+direct the user to rerun `dev-flow-codex setup`. Stop without task discovery or undocumented probing.
+Do not inspect local source or an installed binary, and do not start a second MCP server to bypass a
 failed handshake.
 
 ## Task discovery
@@ -111,12 +121,14 @@ Use this exact `new_task` JSON shape, changing only values derived from the admi
 
 Ask before opening only when a material request, initial-bound, verification, or profile choice
 cannot be derived without changing user intent. Let Core decide whether a compatible intent creates
-or resumes a task. Report an ownership or contract conflict unchanged in meaning and stop.
+or resumes a task. Report an ownership or contract conflict unchanged in meaning and stop. After a
+successful open, give at most one concise status containing the Task identity, revision, and current
+node, then begin the node's substantive repository work without reciting startup checks.
 
 ## Governed action loop
 
 The inseparable Action fields are exactly `task_id`, `revision`, `action_id`, `action_kind`,
-`process_id`, `process_version`, `process_definition_digest`, `current_node`, `node_purpose`,
+`process_id`, `process_definition_digest`, `current_node`, `node_purpose`,
 `entry_conditions`, `completion_conditions`, `allowed_effects`, `required_evidence`,
 `method_profile`, `method_steps`, `available_transitions`, `payload_contract`, `guidance`,
 `repository_binding_digest`, and `issued_at`.
@@ -130,11 +142,11 @@ For an active task, perform each iteration in this order:
    allowed effects, required evidence, method profile, method steps, available transitions, payload
    schema/contract, guidance, repository-binding digest, and issued time as one inseparable Core
    result. Stop if any field is absent, malformed, or truncated.
-3. Present the current node, purpose, entry and completion conditions, allowed effects, required
-   evidence, immutable method profile, every method step, and all `available_transitions`. For every
-   returned transition show its identifier, Core-returned destination for visibility, description or
-   `when` selection condition, guard identifier, and reason rule. Do not reduce this to one
-   recommended next step.
+3. Validate the complete Action internally. During normal work, give only a concise current-node
+   status and proceed; do not dump entry conditions, completion conditions, allowed effects, required
+   evidence, method steps, payload details, or all `available_transitions`. Surface a contract field
+   only when it requires a user decision, limits requested authority, or explains a blocker. Keep the
+   complete Action bound for transition selection and forwarding even when it is not displayed.
 4. Stop when the complete result reports a blocker or terminal outcome.
 5. Render and perform each current method operation under the allowed effects, repository
    instructions, verification budget, and current user authority.
@@ -247,7 +259,6 @@ Map every mutation top-level field from the same fresh Action:
 - `fresh_action.action_id` -> top-level `action_id`;
 - `fresh_action.action_kind` -> top-level `action_kind`;
 - `fresh_action.process_id` -> top-level `process_id`;
-- `fresh_action.process_version` -> top-level `process_version`;
 - `fresh_action.process_definition_digest` -> top-level `process_definition_digest`;
 - `fresh_action.current_node` -> top-level `source_cursor`;
 - `fresh_action.repository_binding_digest` -> top-level `repository_binding_digest`;
@@ -262,7 +273,6 @@ apply_arguments = {
   "action_id": fresh_action.action_id,
   "action_kind": fresh_action.action_kind,
   "process_id": fresh_action.process_id,
-  "process_version": fresh_action.process_version,
   "process_definition_digest": fresh_action.process_definition_digest,
   "source_cursor": fresh_action.current_node,
   "repository_binding_digest": fresh_action.repository_binding_digest,
@@ -312,7 +322,7 @@ transport-failed instead of returning one complete structured result. Do not imm
 `dev_flow_apply_action` and do not infer the result from repository state or worktree contents.
 
 Before calling `dev_flow_apply_action`, retain the original `request_id`, `task_id`, `process_id`,
-`process_version`, `process_definition_digest`, `source_cursor`, `revision`, `action_id`,
+`process_definition_digest`, `source_cursor`, `revision`, `action_id`,
 `action_kind`, `repository_binding_digest`, and exact closed `payload` from the same fresh action and
 the same apply dispatch. Never derive or reconstruct them from an incomplete response or partial
 output.
@@ -324,7 +334,6 @@ When all required original identity values are retained, construct exactly this
 {
   "operation_id": "<original apply request_id>",
   "process_id": "standard-development",
-  "process_version": 1,
   "process_definition_digest": "<original process definition digest>",
   "source_cursor": "<original source cursor>",
   "expected_revision": 3,

package/plugin/skills/dev-flow/references/method-profiles.md

@@ -1,6 +1,6 @@
 # Codex Method Profile Rendering Reference
 
-This is the closed Codex Host-rendering reference for Core Contract 0.2 semantic method steps. Read
+This is the closed Codex Host-rendering reference for current Core contract semantic method steps. Read
 it only after Core returns a complete current Action. It explains how Codex may perform the work; it
 is not a process definition or a second task cursor.
 

package/plugin/skills/dev-flow/references/node-payloads.md

@@ -1,4 +1,4 @@
-# Core Contract 0.2 Node Payload Construction
+# current Core contract Node Payload Construction
 
 This reference helps the Codex Adapter construct the one closed payload branch returned by the
 current Core Action. It is not a process definition, transition table, cursor, or authority. The