@c4a/context-cli 0.6.1-beta.1 → 0.6.1-beta.2

package/docs/quickstart.md

@@ -44,8 +44,8 @@ After initialization, read the workspace guidance:
 AGENTS.md
 ```
 
-`AGENTS.md` explains the current project, SDK references, plugin Skills, and
-the safe workflow for agents. It is the project-local starting point after
+`AGENTS.md` explains the current project, SDK references, installed Agent
+entry, and safe workflow contract. It is the project-local starting point after
 `context init`.
 
 ## 3. Work Through an Agent
@@ -54,9 +54,14 @@ Inside the workspace, ask the installed agent plugin to continue the workflow.
 The agent should:
 
 1. read `AGENTS.md`;
-2. run `context status`;
-3. follow the status `next` hint and CLI diagnostics;
-4. stop at human gates such as source scope, structure confirmation, review,
+2. run `context status --format json`;
+3. treat `workflow.current` as the current-step authority, read each
+   `resources.required` item, and execute only the returned command or
+   configuration action;
+4. at a Gate, load an `inspection_action` Skill or Schema only for
+   pre-decision inspection and a `resolution_action` Skill or Schema only
+   after confirmation;
+5. stop at human gates such as source scope, structure confirmation, review,
    and package decisions.
 
 The CLI performs mechanical work such as source registration, capture,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@c4a/context-cli",
-  "version": "0.6.1-beta.1",
+  "version": "0.6.1-beta.2",
   "type": "module",
   "description": "Local CLI for capturing, compiling, and governing knowledge workspaces",
   "license": "MIT",
@@ -20,7 +20,8 @@
     "context": "cli.js"
   },
   "dependencies": {
-    "@c4a/context": "0.6.1-beta.1",
+    "@c4a/agent-graph": "0.2.2",
+    "@c4a/context": "0.6.1-beta.2",
     "commander": "^11.0.0",
     "handlebars": "^4.7.8",
     "ink": "^5.0.0",

package/plugins/README.md

@@ -4,155 +4,81 @@
 
 <p align="center"><img src="./assets/logo.svg" alt="C4A Context" width="180"/></p>
 
-Context provides agent commands for maintaining a project-local knowledge workspace. The plugin is installed globally for the agent, while each workspace keeps its own sources, pending review state, approved knowledge, and build output. Public agent entrypoints are intentionally small: initialize once, then use next-step guidance.
-
-Agent dialogue should follow the user's current conversation language. CLI
-commands, flags, ids, status values, JSONL keys, and `source_ref` tokens are
-protocol text and stay unchanged.
+Context provides a thin Agent entry for project-local knowledge workspaces. The
+plugin does not embed the whole workflow in one prompt. It starts from current
+workspace facts, then Context CLI selects the legal route, commands, gates, and
+Markdown/schema resources for that step.
 
 ## Install
 
-Install the CLI first:
-
 ```bash
 npm i -g @c4a/context-cli
-# or
-bun add -g @c4a/context-cli
-```
-
-Then install the bundled plugin marketplace globally:
-
-```bash
 context plugin install
 ```
 
-The installer resolves the plugin marketplace from the installed CLI package. Published packages use `dist/plugins`; source checkouts use the same generated tree after `bun run --filter @c4a/context-cli build`. For Codex, it materializes the bundled plugin into `~/.codex/plugins/cache/c4a/context/local/`, matching Codex's local-plugin cache convention.
-
-For a dry run:
+For a source checkout, build the CLI and plugin first:
 
 ```bash
-context plugin install --dry-run
-context plugin path
+bun run --filter @c4a/context-cli build
+context plugin install --dev
 ```
 
-## Workflow
+Use `context plugin install --dry-run` to inspect installation and
+`context plugin path` to locate the bundled marketplace.
 
-Run commands from the context project root.
+## Agent entry
 
-1. Initialize a workspace:
+The public host surface stays small:
 
-   ```bash
-   context init context
-   cd context
-   bun install
-   ```
+- `init` creates a Context workspace;
+- `continue` observes and advances an existing workspace.
 
-2. Continue through the installed agent entry:
+Continuation starts with:
 
-   ```bash
-   <host-specific Context continuation command or skill>
-   ```
+```bash
+context status --format json
+```
 
-The continuation entry first runs `context status`, then follows CLI diagnostics. It
-executes safe mechanical `next:` steps instead of only reporting them, and stops
-at `Human gate:` / placeholder next steps, source registration, source scope
-selection, review, package output choice, or source-repo operations that require
-user approval. It must not infer repo sources or extraction scope from the
-surrounding monorepo.
-It uses lower-level CLI primitives only when the workspace state requires them:
+`workflow.current` is the current-step authority. The Agent reads every required
+resource, executes only returned commands, preserves revision and authority
+flags, and reevaluates status after each action. Long procedures and semantic
+judgment rules are published in the Context workflow bundle and loaded only
+when the current route or operation selects them.
 
-- `context source ...`
-- `context run ...`
-- `context review ...`
-- `context close`
-- `context build`
-- `context verify`
+Gate inspection and resolution Actions keep their own Skill and Schema
+locators. The Agent loads those conditional resources only when it enters that
+phase; they are not preloaded with the Route's ordinary required resources.
 
-When the user explicitly requests fully managed operation in the current
-conversation, continuation uses `context status --managed --format json` and
-follows its managed commands. Eligible classification, extraction-scope,
-structure-confirmation, Review, and package-output gates proceed automatically;
-source boundaries, unread source permission, external operations, and
-validation failures remain gated. No managed policy is written to the project,
-and a new conversation returns to ordinary gates.
+The two entry documents are also the source for hosts that expose Agent Skills
+instead of commands. There are no stage-specific skills: source, alignment,
+compile, review, and package guidance comes from the route-selected workflow
+resources.
 
-## SDK Manual For Agents
+## Human gates and managed sessions
 
-After `bun install`, the project has a local SDK manual under:
+Ordinary mode preserves source, read-permission, scope, structure, Review, and
+package decisions as explicit gates. Fully managed mode is available only when
+the user explicitly requests it in the current conversation:
 
-```text
-node_modules/@c4a/context/docs/
+```bash
+context status --managed --format json
 ```
 
-Recommended files:
+That session authority is not stored. It cannot choose source boundaries,
+authorize unread external content, perform external repository operations, or
+bypass validation and verification.
 
-- `node_modules/@c4a/context/docs/guides/agent-dialogue.md`
-- `node_modules/@c4a/context/docs/guides/agent-guide.md`
-- `node_modules/@c4a/context/docs/reference/project-api.md`
-- `node_modules/@c4a/context/docs/reference/package-templates.md`
+## Workspace and SDK
 
-Template examples are installed at:
+Run the plugin from the initialized Context project root. Project declarations
+live in `src/index.ts`; source state, draft state, approved knowledge, generated
+packages, and disposable runtime state remain owned by Context CLI.
+
+After workspace dependency installation, the SDK manual starts at:
 
 ```text
-node_modules/@c4a/context/templates/package-templates/
+node_modules/@c4a/context/docs/README.md
 ```
 
-Agents should read these files instead of probing `node_modules/@c4a/context/dist`
-with ad-hoc scripts.
-
-## Workspace Shape
-
-Committed project state lives in:
-
-- `src/` — project flow and custom code;
-- `sources/repo/index.yaml`, `sources/file/index.yaml`, and
-  `sources/lark/index.yaml` — source registries;
-- `unapproved/entities.jsonl` — draft/rejected/deprecated metadata;
-- `unapproved/structure.yaml` — unconfirmed or confirmed prose structure draft;
-- `knowledge/` — approved Markdown;
-- `knowledge/structure.yaml` — closed structure/edge projection derived from
-  approved knowledge;
-- `dist/` — built packages;
-- `README.md`, `AGENTS.md`, `package.json`.
-
-Runtime scratch lives in `.tmp/context-runtime/` and is ignored.
-
-## Agent Entry Points
-
-The global plugin exposes only the user-facing Context commands for the current workspace:
-
-- `init`
-- `continue`
-
-The CLI still provides lower-level primitives, but they are not public slash
-commands. The continuation entry chooses them based on CLI output and user intent.
-
-Current source registration, document capture discipline, structure planning,
-node classification, reading density, candidate resolution, edge gates,
-source-bound section drafting, refresh/update judgment, semantic conflict
-judgment, and close guidance live in internal procedures under
-`skill-source-scope`, `skill-prose-align`, and `skill-prose-compile`.
-
-Package-time querying is generated into each built package as the
-`knowledge-query` skill. Package output decisions live in `skill-package-output`.
-The current workflow does not expose source deletion, purge, or retraction
-commands. If a user asks for that kind of lifecycle change, stop and explain
-that the current plugin has no approved gate for it; do not recreate
-file-mutating operations outside the current workflow.
-
-Agents should follow the current status route and internal procedures. Do not
-call or reconstruct command shapes or payload protocols that are absent from the
-current CLI/schema views.
-
-The CLI performs mechanical work only. It does not clone, checkout, reset, fetch, or call an LLM silently. When source repos are missing or at the wrong commit, it reports diagnostics and expects the agent to ask the user before running external repo operations.
-
-## Current Workflow Surface
-
-This plugin exposes the current workflow through `init` and `continue`.
-`continue` starts from `context status`, follows the status route, and delegates
-to current source/capture phases, prose align evidence views, source-bound prose
-compile, review, close, verify/build/status guidance, OKF indexes, generated
-knowledge-query skills, and declared project phase previews.
-
-Agents must not simulate lifecycle or retraction work by deleting workspace
-files. Source deletion, purge, and retraction are not current plugin operations.
+The plugin does not expose source deletion, purge, or retraction. It also does
+not silently clone, fetch, checkout, install, build, test, or call an LLM.

package/plugins/README_CN.md

@@ -4,139 +4,74 @@
 
 <p align="center"><img src="./assets/logo.svg" alt="C4A Context" width="180"/></p>
 
-Context 提供面向 Agent 的知识工作区命令。Plugin 安装到全局 Agent 环境;每个知识工作区只保存自己的源声明、待审状态、已批准知识和构建产物。公开入口刻意收口:初始化一次,之后通过 next-step guidance 推进。
-
-Agent 与用户对话时应使用当前对话语言;CLI 命令、参数、id、状态枚举、JSONL key 和 `source_ref` 属于协议文本,保持英文或原样。
+Context 为项目内知识工作区提供轻量 Agent 入口。Plugin 不会把完整工作流塞进
+一份提示词，而是先观察当前工作区事实，再由 Context CLI 选择当前步骤允许的
+路线、命令、门禁以及 Markdown/schema 资源。
 
 ## 安装
 
-先安装 CLI:
-
 ```bash
 npm i -g @c4a/context-cli
-# 或
-bun add -g @c4a/context-cli
-```
-
-再把随 CLI 包发布的 plugin marketplace 安装到全局:
-
-```bash
 context plugin install
 ```
 
-安装器会从当前 CLI 包动态解析 marketplace 目录。发布包使用 `dist/plugins`;源码 checkout 在执行 `bun run --filter @c4a/context-cli build` 后也使用同样的生成目录。对 Codex,安装器会把随包生成的插件复制到 `~/.codex/plugins/cache/c4a/context/local/`,符合 Codex 本地插件的 cache 约定。
-
-只查看将执行的操作:
+源码开发模式需要先构建：
 
 ```bash
-context plugin install --dry-run
-context plugin path
+bun run --filter @c4a/context-cli build
+context plugin install --dev
 ```
 
-## 工作流
+可用 `context plugin install --dry-run` 查看安装动作，用
+`context plugin path` 定位随 CLI 发布的 marketplace。
 
-在 context 项目根目录执行命令。
+## Agent 入口
 
-1. 初始化工作区:
+公开入口保持精简：
 
-   ```bash
-   context init context
-   cd context
-   bun install
-   ```
+- `init`：创建 Context 工作区；
+- `continue`：观察并推进已有工作区。
 
-2. 通过已安装的 Agent 入口继续推进:
+Continuation 从以下命令开始：
 
-   ```bash
-   <当前宿主暴露的 Context continuation command 或 skill>
-   ```
+```bash
+context status --format json
+```
 
-Continuation 入口会先运行 `context status`,然后跟随 CLI 诊断。安全的机械 `next:` 步骤会直接执行,不会只把命令复述给用户;遇到 `Human gate:`、带占位符的 next、source 注册、source 范围选择、审阅、package 输出选择或需要用户授权的 source repo 操作才会停下来确认。它不能根据周边 monorepo 自行推断 repo source 或提取范围,只在工作区状态需要时调用底层 CLI 能力:
+`workflow.current` 是当前步骤的权威协议。Agent 读取全部 required 资源，只执行
+返回的命令，完整保留 revision 与 authority 参数，并在每次动作后重新求值。
+长篇流程与语义判断规则发布在 Context workflow bundle 中，仅在当前路线或操作
+选中时加载。
 
-- `context source ...`
-- `context run ...`
-- `context review ...`
-- `context close`
-- `context build`
-- `context verify`
+Gate 的检查动作与决议动作分别保留自己的 Skill 和 Schema 位置。Agent 只在进入
+相应阶段时加载这些条件资源，不会把它们提前混入 Route 的普通 required 资源。
 
-如果用户在当前对话明确要求“全托管”,Continuation 会改用 `context status
---managed --format json` 并持续跟随其命令。分类、提取范围、结构确认、审阅和
-package 输出门禁可自动完成;来源边界、尚未授权的文档读取、外部仓库/系统操作和
-校验失败仍会停下。该授权不会写入 `defineProject` 或工作区,新对话默认恢复普通
-人工门禁。
+这两个入口文档也用于生成仅支持 Agent Skills 的宿主入口。不再发布阶段型
+Skill；来源、对齐、编译、审核和构建说明均由当前路线选择的 workflow resources
+动态提供。
 
-## Agent 可读的 SDK 手册
+## 人工门禁与全托管会话
 
-执行 `bun install` 后,项目内会有 SDK 手册:
+普通模式保留来源、读取权限、提取范围、结构、审阅和包形态等显式门禁。只有用户
+在当前对话明确要求全托管时，才使用：
 
-```text
-node_modules/@c4a/context/docs/
+```bash
+context status --managed --format json
 ```
 
-推荐先读:
+该会话权限不会持久化，也不能选择来源边界、授权尚未允许读取的外部内容、执行
+外部仓库操作，或绕过校验与验证。
 
-- `node_modules/@c4a/context/docs/guides/agent-dialogue.md`
-- `node_modules/@c4a/context/docs/guides/agent-guide.md`
-- `node_modules/@c4a/context/docs/reference/project-api.md`
-- `node_modules/@c4a/context/docs/reference/package-templates.md`
+## 工作区与 SDK
 
-模板示例在:
+Plugin 应在初始化后的 Context 项目根目录运行。`src/index.ts` 保存项目声明；
+来源状态、草稿状态、已批准知识、构建产物和临时运行状态均由 Context CLI 管理。
+
+安装工作区依赖后，SDK 手册入口为：
 
 ```text
-node_modules/@c4a/context/templates/package-templates/
+node_modules/@c4a/context/docs/README.md
 ```
 
-Agent 应读取这些文件,不要通过临时脚本反查 `node_modules/@c4a/context/dist`
-来猜 SDK API。
-
-## 工作区形态
-
-需要提交的项目状态在:
-
-- `src/`:项目流程和定制代码;
-- `sources/repo/index.yaml`、`sources/file/index.yaml`、`sources/lark/index.yaml`:源 registry;
-- `unapproved/entities.jsonl`:draft/rejected/deprecated 元信息;
-- `unapproved/structure.yaml`:未确认或已确认的文档结构草稿;
-- `knowledge/`:approved Markdown;
-- `knowledge/structure.yaml`:由 approved knowledge 派生的结构与关系投影;
-- `dist/`:构建产物;
-- `README.md`、`AGENTS.md`、`package.json`。
-
-运行缓存放在 `.tmp/context-runtime/`,并被忽略。
-
-## Agent 入口
-
-全局 plugin 只暴露面向用户的 Context 命令:
-
-- `init`
-- `continue`
-
-CLI 仍保留底层能力,但它们不是公开 slash command。Continuation 入口根据 CLI 输出和用户意图选择要调用的底层命令。
-
-当前 source 注册、文档 capture 纪律、structure planning、Node 分类、阅读密度、
-候选处理、edge gates、source-bound section drafting、refresh/update 判断、
-语义冲突判断和 close 指引都在 `skill-source-scope`、`skill-prose-align`、
-`skill-prose-compile` 下面的内部 procedure。
-
-包内查询能力在构建包时生成到 `knowledge-query` skill。package 输出决策在
-`skill-package-output`。当前工作流不暴露 source 删除、purge 或撤回命令。
-如果用户要求这类生命周期变更,先停下来说明当前 plugin 没有已批准门禁;
-Agent 不得在当前工作流之外重建文件变更类操作。
-
-Agent 应按当前 status route 和内部 procedure 推进。不要调用或重建当前
-CLI/schema views 没有暴露的命令形态或 payload 协议。
-
-CLI 只做机械操作。它不会静默 clone、checkout、reset、fetch,也不会调用 LLM。源仓库缺失或 commit 不匹配时,CLI 只返回诊断;Agent 需要先征询用户,再决定是否执行外部 repo 操作。
-
-## 当前工作流入口
-
-本 plugin 只暴露当前工作流入口: `init` 和 `continue`。`continue` 从
-`context status` 开始,按 status route 分发到 source/capture phase、prose
-align evidence views、source-bound prose compile、review、close、
-verify/build/status guidance、OKF indexes、生成包里的 knowledge-query skill,
-以及已声明 project phase 的只读预览。
-
-Agent 不得通过直接删除 `sources/`、`knowledge/`、`unapproved/`、`dist/`
-或 `.tmp` 来模拟生命周期或撤回操作。source 删除、purge 和撤回不是当前
-plugin 操作。
+当前 Plugin 不暴露 source 删除、purge 或 retraction，也不会静默执行 clone、
+fetch、checkout、install、build、test 或调用 LLM。

package/plugins/VERSION

@@ -1 +1 @@
-0.6.1-beta.1
+0.6.1-beta.2

package/plugins/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "context",
   "description": "Maintain a project-local knowledge workspace through init and next-step agent guidance.",
-  "version": "0.6.1-beta.1",
+  "version": "0.6.1-beta.2",
   "author": {
     "name": "c4a"
   },

package/plugins/claude/commands/continue.md

@@ -6,27 +6,44 @@ allowed-tools: Bash(context:*), Bash(bun:*), Bash(cd *)
 
 ## Your Task
 
-Use this as the conversational entry for an existing Context workspace. There is
-no `context continue` CLI primitive; the command runs lower-level `context ...`
-commands only when the workspace state requires them.
+Use this as the conversational entry for an existing Context workspace. There
+is no `context continue` CLI primitive. Start with:
+
+```bash
+context status --format json
+```
+
+Use `context status --managed --format json` only when the user explicitly
+requested fully managed operation in this conversation. Never persist or reuse
+that authority in another conversation. While the request remains active, use
+`--managed` for every status evaluation; stop using it when the conversation
+ends or the user revokes it.
 
 If the user is starting a new workspace or a new batch from a raw repository
 root, do not run `context status` first. Use the public Context init entry or
 `context init` to create the workspace, complete the init setup command, then
 return here from the initialized workspace.
 
-If `context status` reports `workspace-not-found` and points at a configured
-`context.workspaceDir`, do not keep working from the host repository root. Enter
-that workspace when it exists, or initialize it through the init workflow after
-confirming with the user.
-
 Language policy: explain, ask, confirm, and summarize in the user's current
 conversation language. Keep CLI commands, flags, paths, ids, status enum values,
 JSONL payload keys, `source_ref` values, and copied CLI output tokens unchanged.
 
-Use the internal `context:skill-continue-workflow` procedure end to end. It owns the
-status loop, safe mechanical next steps, source/scope gate, review gate, package
-gate, and final report rules.
+Treat `workflow.current` as the current-step authority:
+
+1. Read every `resources.required` item. Read a `path` directly; for a resource
+   with `command`, execute that command and read the returned file.
+2. At a Gate, keep conditional context phase-local. An `inspection_action`
+   Skill or Schema is read only when performing that pre-decision inspection;
+   a `resolution_action` Skill or Schema is read only after the user confirms
+   the Gate. Neither replaces ordinary `resources.required`.
+3. Execute only `commands` returned by the Route, preserving revision and
+   authority flags exactly. A command marked `after-human-confirmation` must
+   wait for the current Gate decision.
+4. If `configuration` is present, edit only the named project file using the
+   selected resources as its contract.
+5. After every action or configuration change, run status again. A phase-local
+   `next_action` can continue that operation but never replaces the workspace
+   Route.
 
 Do not infer repo sources, extraction scope, review decisions, or package output
 choices from surrounding files. Do not call source-repo operations such as

package/plugins/claude/commands/init.md

@@ -6,16 +6,25 @@ allowed-tools: Bash(context:*), Bash(bun:*), Bash(cd *)
 
 ## Your Task
 
-Initialize a Context workspace with the global CLI, then continue only through
-safe mechanical setup steps until the first human decision gate.
+Initialize a Context workspace with the global CLI, complete the returned setup
+step, then hand control to the current workflow route.
 
 Language policy: explain, ask, confirm, and summarize in the user's current
 conversation language. Keep CLI commands, flags, file paths, package names,
 enum values, payload keys, and copied CLI output tokens unchanged.
 
-Use the internal `context:skill-init-workspace` procedure end to end. It owns
-the `context init` invocation, dependency install follow-up, generated
-`AGENTS.md` handoff, status handoff, and stop conditions.
+Run `context init [project-dir] [--name <name>]` with only the arguments the
+user supplied. Execute the setup command returned by init, enter the project
+root, and read its generated `AGENTS.md`. Use `--dev` only when the user
+explicitly asked to test a locally linked Context SDK.
+
+Then run `context status --format json`, or `context status --managed --format
+json` only when the user explicitly requested fully managed operation in this
+conversation. While that request remains active, use `--managed` for every
+status evaluation; never persist it into another conversation. Treat
+`workflow.current` as the current-step authority: read every required resource,
+execute only its exact commands, stop before any unresolved command marked
+`after-human-confirmation`, and rerun status after each action.
 
 Do not add extra project-local agent setup. Do not infer repo sources or
 extraction scope from the surrounding monorepo after setup.

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

@@ -1,6 +1,6 @@
 {
   "name": "context",
-  "version": "0.6.1-beta.1",
+  "version": "0.6.1-beta.2",
   "description": "Maintain a project-local knowledge workspace through init and next-step agent guidance.",
   "author": {
     "name": "c4a"
@@ -18,7 +18,7 @@
   "skills": "./skills/",
   "interface": {
     "displayName": "C4A Context",
-    "shortDescription": "Initialize and advance a local, source-linked project knowledge workspace.\nv0.6.1-beta.1",
+    "shortDescription": "Initialize and advance a local, source-linked project knowledge workspace.\nv0.6.1-beta.2",
     "longDescription": "Create a Context workspace and use agent-guided next steps to register sources, run extraction, review candidates, build package outputs, and verify health without silently mutating source repositories.",
     "developerName": "c4a",
     "category": "Productivity",

package/plugins/codex/skills/continue/SKILL.md

@@ -13,33 +13,49 @@ Public Context entry for agents that expose skills instead of slash commands.
 - Public entry: `continue`
 - Host command names are installation-specific; use the command or skill surfaced by the current host instead of deriving a filesystem path from an example name.
 - CLI primitive prefix: `context ...`
-- Internal procedures live under `references/internal-procedures/`; read each referenced file in full before following that step.
 
 ---
 
 ## Workflow
 
-Use this as the conversational entry for an existing Context workspace. There is
-no `context continue` CLI primitive; the command runs lower-level `context ...`
-commands only when the workspace state requires them.
+Use this as the conversational entry for an existing Context workspace. There
+is no `context continue` CLI primitive. Start with:
+
+```bash
+context status --format json
+```
+
+Use `context status --managed --format json` only when the user explicitly
+requested fully managed operation in this conversation. Never persist or reuse
+that authority in another conversation. While the request remains active, use
+`--managed` for every status evaluation; stop using it when the conversation
+ends or the user revokes it.
 
 If the user is starting a new workspace or a new batch from a raw repository
 root, do not run `context status` first. Use the public Context init entry or
 `context init` to create the workspace, complete the init setup command, then
 return here from the initialized workspace.
 
-If `context status` reports `workspace-not-found` and points at a configured
-`context.workspaceDir`, do not keep working from the host repository root. Enter
-that workspace when it exists, or initialize it through the init workflow after
-confirming with the user.
-
 Language policy: explain, ask, confirm, and summarize in the user's current
 conversation language. Keep CLI commands, flags, paths, ids, status enum values,
 JSONL payload keys, `source_ref` values, and copied CLI output tokens unchanged.
 
-Use the procedure in `references/internal-procedures/skill-continue-workflow.md` end to end. It owns the
-status loop, safe mechanical next steps, source/scope gate, review gate, package
-gate, and final report rules.
+Treat `workflow.current` as the current-step authority:
+
+1. Read every `resources.required` item. Read a `path` directly; for a resource
+   with `command`, execute that command and read the returned file.
+2. At a Gate, keep conditional context phase-local. An `inspection_action`
+   Skill or Schema is read only when performing that pre-decision inspection;
+   a `resolution_action` Skill or Schema is read only after the user confirms
+   the Gate. Neither replaces ordinary `resources.required`.
+3. Execute only `commands` returned by the Route, preserving revision and
+   authority flags exactly. A command marked `after-human-confirmation` must
+   wait for the current Gate decision.
+4. If `configuration` is present, edit only the named project file using the
+   selected resources as its contract.
+5. After every action or configuration change, run status again. A phase-local
+   `next_action` can continue that operation but never replaces the workspace
+   Route.
 
 Do not infer repo sources, extraction scope, review decisions, or package output
 choices from surrounding files. Do not call source-repo operations such as