engineering-process 1.2.5__tar.gz → 2.0.0__tar.gz

{engineering_process-1.2.5 → engineering_process-2.0.0}/MANIFEST.in

@@ -1,4 +1,4 @@
 include process-graph.json
 recursive-include process_assets/skills SKILL.md *.json
 recursive-include schemas *.json
-recursive-include templates *.md *.py
+recursive-include templates *.md *.py *.json

{engineering_process-1.2.5/engineering_process.egg-info → engineering_process-2.0.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: engineering-process
-Version: 1.2.5
+Version: 2.0.0
 Summary: A small agent-neutral engineering lifecycle with managed adoption
 License-Expression: MIT
 Project-URL: Homepage, https://github.com/phuongnse/engineering-process
@@ -33,11 +33,27 @@ Portable skills explain what to do. processctl owns state transitions and curren
 evidence. Each consumer owns its product rules, exact commands, merge policy, and
 release decisions.
 
+Start delivery work with [deliver-change](process_assets/skills/deliver-change/SKILL.md).
+It selects the current phase from lifecycle state; callers do not select a phase skill:
+
+    deliver-change
+      change-start -> change-plan -> change-implement -> change-verify
+        -> change-review -> change-complete
+
+[process-improve](process_assets/skills/process-improve/SKILL.md) handles a reusable
+process problem, then returns delivery to the same lifecycle.
+[production-engineering](process_assets/skills/production-engineering/SKILL.md) supplies
+the invariant floor consulted from planning through independent review. Both are
+reachable specializations; neither advances lifecycle state. `change-complete` calls
+the existing `processctl change finish` command.
+
+For migration from the previous skill identifiers, see [Versioning](VERSIONING.md#skill-namespace-migration).
+
 ## Architecture
 
 The distribution has four live parts:
 
-1. Managed skills under process_assets/skills, all reachable from run-change.
+1. Managed skills under process_assets/skills, all reachable from deliver-change.
 2. One processctl state machine under engineering_process/lifecycle.py.
 3. JSON Schemas that are loaded directly by the runtime.
 4. One adoption transaction that synchronizes managed skills and configuration from
@@ -175,7 +191,7 @@ This assessment is not a production certificate. Production still requires the
 consumer's immutable readiness pack, every required capability in `enforced` state,
 fresh consumer-owned verification on the exact candidate, and independent review.
 
-For each ordinary change, `run-change` first surfaces this readiness view. The accepted
+For each ordinary change, `deliver-change` first surfaces this readiness view. The accepted
 request and consumer rules determine which capabilities are affected. Every change
 retains the project's baseline `requiredProfiles`; start and plan add any conditional
 evidence profiles needed by affected capabilities and include a planned gap only when
@@ -184,7 +200,7 @@ floor. A planned-to-enforced promotion is a reviewed consumer source diff with f
 evidence. Unrelated planned gaps remain visible but do not block development, and no
 skill chooses product priorities or changes readiness automatically.
 
-When a consumer incident exposes a reusable process gap, `improve-process` first keeps
+When a consumer incident exposes a reusable process gap, `process-improve` first keeps
 the consumer safe, then prepares a sanitized GitHub issue draft from that checkout.
 It deduplicates by consumer/process-version/invariant, requires owner authorization
 before `gh issue create`, and uses an accepted issue as the later process change source
@@ -352,7 +368,7 @@ URL; without it, the review remains pending. Earlier plan and review documents r
 readable, and their runs remain registrable or finishable with the version selected by
 the authority that started the relevant phase.
 
-The [finding priority definitions](process_assets/skills/review-change/SKILL.md#finding-priority)
+The [finding priority definitions](process_assets/skills/change-review/SKILL.md#finding-priority)
 are the canonical P0-P3 impact convention for this process, including examples and
 their relationship to blocking decisions.
 
@@ -471,6 +487,39 @@ authorizes that merge.
 This repository opts in through .github/renovate.json, so it receives the same
 adoption PR as every other consumer. See SELF_HOSTING.md and RELEASING.md.
 
+The optional [Renovate preset](templates/renovate.json) is generated from the
+canonical public template. It supplies only `prHeader` and `prBodyTemplate`;
+dependency selection, supported platforms, schedules, major-update approval,
+commands, draft policy, and merge authority remain consumer-owned. Regenerate it
+with `python verification/generate_renovate_preset.py`; `--check` rejects drift.
+
+Consumers add `github>phuongnse/engineering-process//templates/renovate#COMMIT_SHA`
+to their existing `extends` array, replacing `COMMIT_SHA` with the full source
+commit of a verified release that contains the preset. Remove obsolete inline
+`prHeader` and `prBodyTemplate` overrides, including matching package-rule overrides.
+The preset targets the canonical draft grammar used by 1.2.4 and this distribution;
+it does not claim compatibility with earlier publication contracts. A future
+grammar change must preserve this adapter or ship an explicit consumer migration.
+
+Renovate resolves presets from the protected base configuration before dependency
+updates and post-upgrade tasks. Bootstrap the compatible preset in that base before
+relying on its generated drafts; changing the candidate configuration alone cannot
+repair the same run's body. Verify the native rendered body against both the base
+and candidate process authority during adoption. Pending fields and unchecked
+Completion gate items are proposals, never evidence or approval.
+
+Before collecting lifecycle evidence for a bot PR, apply its configured
+`stopUpdatingLabel` (Renovate's default is `stop-updating`) and confirm the head is
+unchanged after any in-flight bot run finishes. Keep the label through verification,
+independent review, receipt and the consumer-owned merge. Do not request a native
+rebase or dashboard retry while reviewing: an explicit retry can resume updates.
+If the candidate changes, open a new implementation cycle and collect fresh
+evidence. Remove the pause label only when returning the PR to automation.
+
+These are native [shared preset](https://docs.renovatebot.com/config-presets/) and
+[review pause](https://docs.renovatebot.com/configuration-options/#stopupdatinglabel)
+boundaries; the control plane does not become a second PR publisher.
+
 ## Compatibility
 
 Version 1.x retains a few small pre-1.0 command shapes so existing consumers can

{engineering_process-1.2.5 → engineering_process-2.0.0}/README.md

@@ -9,11 +9,27 @@ Portable skills explain what to do. processctl owns state transitions and curren
 evidence. Each consumer owns its product rules, exact commands, merge policy, and
 release decisions.
 
+Start delivery work with [deliver-change](process_assets/skills/deliver-change/SKILL.md).
+It selects the current phase from lifecycle state; callers do not select a phase skill:
+
+    deliver-change
+      change-start -> change-plan -> change-implement -> change-verify
+        -> change-review -> change-complete
+
+[process-improve](process_assets/skills/process-improve/SKILL.md) handles a reusable
+process problem, then returns delivery to the same lifecycle.
+[production-engineering](process_assets/skills/production-engineering/SKILL.md) supplies
+the invariant floor consulted from planning through independent review. Both are
+reachable specializations; neither advances lifecycle state. `change-complete` calls
+the existing `processctl change finish` command.
+
+For migration from the previous skill identifiers, see [Versioning](VERSIONING.md#skill-namespace-migration).
+
 ## Architecture
 
 The distribution has four live parts:
 
-1. Managed skills under process_assets/skills, all reachable from run-change.
+1. Managed skills under process_assets/skills, all reachable from deliver-change.
 2. One processctl state machine under engineering_process/lifecycle.py.
 3. JSON Schemas that are loaded directly by the runtime.
 4. One adoption transaction that synchronizes managed skills and configuration from
@@ -151,7 +167,7 @@ This assessment is not a production certificate. Production still requires the
 consumer's immutable readiness pack, every required capability in `enforced` state,
 fresh consumer-owned verification on the exact candidate, and independent review.
 
-For each ordinary change, `run-change` first surfaces this readiness view. The accepted
+For each ordinary change, `deliver-change` first surfaces this readiness view. The accepted
 request and consumer rules determine which capabilities are affected. Every change
 retains the project's baseline `requiredProfiles`; start and plan add any conditional
 evidence profiles needed by affected capabilities and include a planned gap only when
@@ -160,7 +176,7 @@ floor. A planned-to-enforced promotion is a reviewed consumer source diff with f
 evidence. Unrelated planned gaps remain visible but do not block development, and no
 skill chooses product priorities or changes readiness automatically.
 
-When a consumer incident exposes a reusable process gap, `improve-process` first keeps
+When a consumer incident exposes a reusable process gap, `process-improve` first keeps
 the consumer safe, then prepares a sanitized GitHub issue draft from that checkout.
 It deduplicates by consumer/process-version/invariant, requires owner authorization
 before `gh issue create`, and uses an accepted issue as the later process change source
@@ -328,7 +344,7 @@ URL; without it, the review remains pending. Earlier plan and review documents r
 readable, and their runs remain registrable or finishable with the version selected by
 the authority that started the relevant phase.
 
-The [finding priority definitions](process_assets/skills/review-change/SKILL.md#finding-priority)
+The [finding priority definitions](process_assets/skills/change-review/SKILL.md#finding-priority)
 are the canonical P0-P3 impact convention for this process, including examples and
 their relationship to blocking decisions.
 
@@ -447,6 +463,39 @@ authorizes that merge.
 This repository opts in through .github/renovate.json, so it receives the same
 adoption PR as every other consumer. See SELF_HOSTING.md and RELEASING.md.
 
+The optional [Renovate preset](templates/renovate.json) is generated from the
+canonical public template. It supplies only `prHeader` and `prBodyTemplate`;
+dependency selection, supported platforms, schedules, major-update approval,
+commands, draft policy, and merge authority remain consumer-owned. Regenerate it
+with `python verification/generate_renovate_preset.py`; `--check` rejects drift.
+
+Consumers add `github>phuongnse/engineering-process//templates/renovate#COMMIT_SHA`
+to their existing `extends` array, replacing `COMMIT_SHA` with the full source
+commit of a verified release that contains the preset. Remove obsolete inline
+`prHeader` and `prBodyTemplate` overrides, including matching package-rule overrides.
+The preset targets the canonical draft grammar used by 1.2.4 and this distribution;
+it does not claim compatibility with earlier publication contracts. A future
+grammar change must preserve this adapter or ship an explicit consumer migration.
+
+Renovate resolves presets from the protected base configuration before dependency
+updates and post-upgrade tasks. Bootstrap the compatible preset in that base before
+relying on its generated drafts; changing the candidate configuration alone cannot
+repair the same run's body. Verify the native rendered body against both the base
+and candidate process authority during adoption. Pending fields and unchecked
+Completion gate items are proposals, never evidence or approval.
+
+Before collecting lifecycle evidence for a bot PR, apply its configured
+`stopUpdatingLabel` (Renovate's default is `stop-updating`) and confirm the head is
+unchanged after any in-flight bot run finishes. Keep the label through verification,
+independent review, receipt and the consumer-owned merge. Do not request a native
+rebase or dashboard retry while reviewing: an explicit retry can resume updates.
+If the candidate changes, open a new implementation cycle and collect fresh
+evidence. Remove the pause label only when returning the PR to automation.
+
+These are native [shared preset](https://docs.renovatebot.com/config-presets/) and
+[review pause](https://docs.renovatebot.com/configuration-options/#stopupdatinglabel)
+boundaries; the control plane does not become a second PR publisher.
+
 ## Compatibility
 
 Version 1.x retains a few small pre-1.0 command shapes so existing consumers can

{engineering_process-1.2.5 → engineering_process-2.0.0}/engineering_process/__init__.py

@@ -1,3 +1,3 @@
 """Agent-neutral engineering process."""
 
-VERSION = "1.2.5"
+VERSION = "2.0.0"

{engineering_process-1.2.5 → engineering_process-2.0.0}/engineering_process/contracts.py

@@ -67,9 +67,9 @@ def digest_json(value: Any) -> str:
     return "sha256:" + hashlib.sha256(canonical_bytes(value)).hexdigest()
 
 
-def write_json_atomic(path: Path, value: Any) -> None:
-    """Write canonical human-readable JSON without exposing a partial file."""
-    data = (
+def formatted_json_bytes(value: Any) -> bytes:
+    """Serialize human-readable JSON as UTF-8 without BOM, using LF."""
+    return (
         json.dumps(
             value,
             ensure_ascii=False,
@@ -79,6 +79,11 @@ def write_json_atomic(path: Path, value: Any) -> None:
         )
         + "\n"
     ).encode("utf-8")
+
+
+def write_json_atomic(path: Path, value: Any) -> None:
+    """Write canonical human-readable JSON without exposing a partial file."""
+    data = formatted_json_bytes(value)
     path.parent.mkdir(parents=True, exist_ok=True)
     temporary = path.with_name(f".{path.name}.tmp")
     try:

{engineering_process-1.2.5 → engineering_process-2.0.0}/engineering_process/skills.py

@@ -90,6 +90,21 @@ def validate_skills(
     graph = load_and_validate(
         graph_path, "process-graph", schema_root=schemas_root(process_root)
     )
+    owners = {state["id"]: state["ownerSkill"] for state in graph["states"]}
+    if len(owners) != len(graph["states"]):
+        raise ProcessError("process graph state ids must be unique")
+    for state in graph["states"]:
+        for transition in state["transitions"]:
+            destination = transition["nextState"]
+            skill = transition["nextSkill"]
+            if (destination is None) != (skill is None):
+                raise ProcessError("process graph terminal transitions must have both targets null")
+            if destination is not None and destination not in owners:
+                raise ProcessError(f"process graph references missing state: {destination}")
+            if skill is not None and skill not in names:
+                raise ProcessError(
+                    f"process graph transition from {state['id']} references missing skill: {skill}"
+                )
     routed = {graph["entrySkill"]}
     routed.update(state["ownerSkill"] for state in graph["states"])
     routed.update(graph.get("specializations", {}).values())

{engineering_process-1.2.5 → engineering_process-2.0.0/engineering_process.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: engineering-process
-Version: 1.2.5
+Version: 2.0.0
 Summary: A small agent-neutral engineering lifecycle with managed adoption
 License-Expression: MIT
 Project-URL: Homepage, https://github.com/phuongnse/engineering-process
@@ -33,11 +33,27 @@ Portable skills explain what to do. processctl owns state transitions and curren
 evidence. Each consumer owns its product rules, exact commands, merge policy, and
 release decisions.
 
+Start delivery work with [deliver-change](process_assets/skills/deliver-change/SKILL.md).
+It selects the current phase from lifecycle state; callers do not select a phase skill:
+
+    deliver-change
+      change-start -> change-plan -> change-implement -> change-verify
+        -> change-review -> change-complete
+
+[process-improve](process_assets/skills/process-improve/SKILL.md) handles a reusable
+process problem, then returns delivery to the same lifecycle.
+[production-engineering](process_assets/skills/production-engineering/SKILL.md) supplies
+the invariant floor consulted from planning through independent review. Both are
+reachable specializations; neither advances lifecycle state. `change-complete` calls
+the existing `processctl change finish` command.
+
+For migration from the previous skill identifiers, see [Versioning](VERSIONING.md#skill-namespace-migration).
+
 ## Architecture
 
 The distribution has four live parts:
 
-1. Managed skills under process_assets/skills, all reachable from run-change.
+1. Managed skills under process_assets/skills, all reachable from deliver-change.
 2. One processctl state machine under engineering_process/lifecycle.py.
 3. JSON Schemas that are loaded directly by the runtime.
 4. One adoption transaction that synchronizes managed skills and configuration from
@@ -175,7 +191,7 @@ This assessment is not a production certificate. Production still requires the
 consumer's immutable readiness pack, every required capability in `enforced` state,
 fresh consumer-owned verification on the exact candidate, and independent review.
 
-For each ordinary change, `run-change` first surfaces this readiness view. The accepted
+For each ordinary change, `deliver-change` first surfaces this readiness view. The accepted
 request and consumer rules determine which capabilities are affected. Every change
 retains the project's baseline `requiredProfiles`; start and plan add any conditional
 evidence profiles needed by affected capabilities and include a planned gap only when
@@ -184,7 +200,7 @@ floor. A planned-to-enforced promotion is a reviewed consumer source diff with f
 evidence. Unrelated planned gaps remain visible but do not block development, and no
 skill chooses product priorities or changes readiness automatically.
 
-When a consumer incident exposes a reusable process gap, `improve-process` first keeps
+When a consumer incident exposes a reusable process gap, `process-improve` first keeps
 the consumer safe, then prepares a sanitized GitHub issue draft from that checkout.
 It deduplicates by consumer/process-version/invariant, requires owner authorization
 before `gh issue create`, and uses an accepted issue as the later process change source
@@ -352,7 +368,7 @@ URL; without it, the review remains pending. Earlier plan and review documents r
 readable, and their runs remain registrable or finishable with the version selected by
 the authority that started the relevant phase.
 
-The [finding priority definitions](process_assets/skills/review-change/SKILL.md#finding-priority)
+The [finding priority definitions](process_assets/skills/change-review/SKILL.md#finding-priority)
 are the canonical P0-P3 impact convention for this process, including examples and
 their relationship to blocking decisions.
 
@@ -471,6 +487,39 @@ authorizes that merge.
 This repository opts in through .github/renovate.json, so it receives the same
 adoption PR as every other consumer. See SELF_HOSTING.md and RELEASING.md.
 
+The optional [Renovate preset](templates/renovate.json) is generated from the
+canonical public template. It supplies only `prHeader` and `prBodyTemplate`;
+dependency selection, supported platforms, schedules, major-update approval,
+commands, draft policy, and merge authority remain consumer-owned. Regenerate it
+with `python verification/generate_renovate_preset.py`; `--check` rejects drift.
+
+Consumers add `github>phuongnse/engineering-process//templates/renovate#COMMIT_SHA`
+to their existing `extends` array, replacing `COMMIT_SHA` with the full source
+commit of a verified release that contains the preset. Remove obsolete inline
+`prHeader` and `prBodyTemplate` overrides, including matching package-rule overrides.
+The preset targets the canonical draft grammar used by 1.2.4 and this distribution;
+it does not claim compatibility with earlier publication contracts. A future
+grammar change must preserve this adapter or ship an explicit consumer migration.
+
+Renovate resolves presets from the protected base configuration before dependency
+updates and post-upgrade tasks. Bootstrap the compatible preset in that base before
+relying on its generated drafts; changing the candidate configuration alone cannot
+repair the same run's body. Verify the native rendered body against both the base
+and candidate process authority during adoption. Pending fields and unchecked
+Completion gate items are proposals, never evidence or approval.
+
+Before collecting lifecycle evidence for a bot PR, apply its configured
+`stopUpdatingLabel` (Renovate's default is `stop-updating`) and confirm the head is
+unchanged after any in-flight bot run finishes. Keep the label through verification,
+independent review, receipt and the consumer-owned merge. Do not request a native
+rebase or dashboard retry while reviewing: an explicit retry can resume updates.
+If the candidate changes, open a new implementation cycle and collect fresh
+evidence. Remove the pause label only when returning the PR to automation.
+
+These are native [shared preset](https://docs.renovatebot.com/config-presets/) and
+[review pause](https://docs.renovatebot.com/configuration-options/#stopupdatinglabel)
+boundaries; the control plane does not become a second PR publisher.
+
 ## Compatibility
 
 Version 1.x retains a few small pre-1.0 command shapes so existing consumers can

{engineering_process-1.2.5 → engineering_process-2.0.0}/engineering_process.egg-info/SOURCES.txt

@@ -31,16 +31,16 @@ engineering_process.egg-info/dependency_links.txt
 engineering_process.egg-info/entry_points.txt
 engineering_process.egg-info/requires.txt
 engineering_process.egg-info/top_level.txt
-process_assets/skills/finish-change/SKILL.md
-process_assets/skills/implement-change/SKILL.md
-process_assets/skills/improve-process/SKILL.md
-process_assets/skills/plan-change/SKILL.md
+process_assets/skills/change-complete/SKILL.md
+process_assets/skills/change-implement/SKILL.md
+process_assets/skills/change-plan/SKILL.md
+process_assets/skills/change-review/SKILL.md
+process_assets/skills/change-start/SKILL.md
+process_assets/skills/change-verify/SKILL.md
+process_assets/skills/deliver-change/SKILL.md
+process_assets/skills/process-improve/SKILL.md
 process_assets/skills/production-engineering/SKILL.md
 process_assets/skills/production-engineering/invariants.json
-process_assets/skills/review-change/SKILL.md
-process_assets/skills/run-change/SKILL.md
-process_assets/skills/start-change/SKILL.md
-process_assets/skills/verify-change/SKILL.md
 schemas/change.schema.json
 schemas/plan.schema.json
 schemas/process-graph.schema.json
@@ -57,6 +57,7 @@ templates/AGENTS.process.md
 templates/PULL_REQUEST_TEMPLATE.md
 templates/adopt-process-windows-job.py
 templates/adopt-process.py
+templates/renovate.json
 tests/test_adoption.py
 tests/test_architecture.py
 tests/test_automation.py

{engineering_process-1.2.5 → engineering_process-2.0.0}/process-graph.json

@@ -1,83 +1,83 @@
 {
   "schemaVersion": 2,
-  "entrySkill": "run-change",
+  "entrySkill": "deliver-change",
   "specializations": {
-    "processChange": "improve-process",
+    "processChange": "process-improve",
     "productionEngineering": "production-engineering"
   },
   "states": [
     {
       "id": "unregistered",
-      "ownerSkill": "start-change",
+      "ownerSkill": "change-start",
       "commands": ["change start"],
       "transitions": [
-        {"result": "success", "nextState": "specified", "nextSkill": "plan-change"}
+        {"result": "success", "nextState": "specified", "nextSkill": "change-plan"}
       ]
     },
     {
       "id": "specified",
-      "ownerSkill": "plan-change",
+      "ownerSkill": "change-plan",
       "commands": ["change plan"],
       "transitions": [
-        {"result": "success", "nextState": "planned", "nextSkill": "implement-change"}
+        {"result": "success", "nextState": "planned", "nextSkill": "change-implement"}
       ]
     },
     {
       "id": "planned",
-      "ownerSkill": "implement-change",
+      "ownerSkill": "change-implement",
       "commands": ["change implement"],
       "transitions": [
-        {"result": "success", "nextState": "implementing", "nextSkill": "verify-change"}
+        {"result": "success", "nextState": "implementing", "nextSkill": "change-verify"}
       ]
     },
     {
       "id": "implementing",
-      "ownerSkill": "verify-change",
+      "ownerSkill": "change-verify",
       "commands": ["change implement", "change verify"],
       "transitions": [
-        {"result": "profile-passed", "nextState": "implementing", "nextSkill": "verify-change"},
-        {"result": "all-passed", "nextState": "verified", "nextSkill": "review-change"}
+        {"result": "profile-passed", "nextState": "implementing", "nextSkill": "change-verify"},
+        {"result": "all-passed", "nextState": "verified", "nextSkill": "change-review"}
       ]
     },
     {
       "id": "verified",
-      "ownerSkill": "review-change",
+      "ownerSkill": "change-review",
       "commands": ["change implement", "change review start"],
       "transitions": [
-        {"result": "assigned", "nextState": "review-pending", "nextSkill": "review-change"},
-        {"result": "source-changed", "nextState": "implementing", "nextSkill": "implement-change"}
+        {"result": "assigned", "nextState": "review-pending", "nextSkill": "change-review"},
+        {"result": "source-changed", "nextState": "implementing", "nextSkill": "change-implement"}
       ]
     },
     {
       "id": "review-pending",
-      "ownerSkill": "review-change",
+      "ownerSkill": "change-review",
       "commands": ["change implement", "change review submit"],
       "transitions": [
-        {"result": "approved", "nextState": "approved", "nextSkill": "finish-change"},
-        {"result": "changes-requested", "nextState": "changes-requested", "nextSkill": "implement-change"},
-        {"result": "source-changed", "nextState": "implementing", "nextSkill": "implement-change"}
+        {"result": "approved", "nextState": "approved", "nextSkill": "change-complete"},
+        {"result": "changes-requested", "nextState": "changes-requested", "nextSkill": "change-implement"},
+        {"result": "source-changed", "nextState": "implementing", "nextSkill": "change-implement"}
       ]
     },
     {
       "id": "changes-requested",
-      "ownerSkill": "implement-change",
+      "ownerSkill": "change-implement",
       "commands": ["change implement"],
       "transitions": [
-        {"result": "success", "nextState": "implementing", "nextSkill": "verify-change"}
+        {"result": "success", "nextState": "implementing", "nextSkill": "change-verify"}
       ]
     },
     {
       "id": "approved",
-      "ownerSkill": "finish-change",
+      "ownerSkill": "change-complete",
       "commands": ["change finish", "change implement"],
       "transitions": [
         {"result": "success", "nextState": null, "nextSkill": null},
-        {"result": "source-changed", "nextState": "implementing", "nextSkill": "implement-change"}
+        {"result": "source-changed", "nextState": "implementing", "nextSkill": "change-implement"}
       ]
     },
     {
       "id": "blocked",
-      "ownerSkill": "run-change",
+      "ownerSkill": "deliver-change",
       "commands": [],
       "transitions": []
     }

{engineering_process-1.2.5/process_assets/skills/finish-change → engineering_process-2.0.0/process_assets/skills/change-complete}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: finish-change
-description: Complete an approved change only while its verification and independent review still match the current repository snapshot.
+name: change-complete
+description: Complete an approved change when routed by deliver-change, only while verification and independent review still match the repository snapshot.
 ---
 
-# Finish a change
+# Complete a change
 
 Confirm the lifecycle is approved, every required profile passed, every blocking
 finding is closed, every non-blocking finding has its required disposition, and the
@@ -11,7 +11,8 @@ repository still matches the reviewed snapshot. Then run:
 
     processctl change finish --change-id ID --actor ACTOR --context CONTEXT
 
-The command writes one bounded completion receipt and marks the run completed.
+The existing `change finish` CLI operation writes one bounded completion receipt and
+marks the run completed.
 Completion does not itself grant merge, deployment, or release authority; those
 remain project-owned operations. Never report completion from prose alone.
 

{engineering_process-1.2.5/process_assets/skills/implement-change → engineering_process-2.0.0/process_assets/skills/change-implement}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: implement-change
-description: Implement the accepted plan or resolve blocking review findings without changing the contract implicitly.
+name: change-implement
+description: Implement the accepted plan or resolve blocking review findings when routed by deliver-change, without changing the contract implicitly.
 ---
 
 # Implement a change
@@ -29,4 +29,4 @@ gaps merely because they are listed.
 
 When evidence exposes a contract gap, stop and ask the project owner to supersede the
 contract. Do not make review prose into new scope. When implementation is ready,
-route to **verify-change**.
+route to **change-verify**.

{engineering_process-1.2.5/process_assets/skills/plan-change → engineering_process-2.0.0/process_assets/skills/change-plan}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: plan-change
-description: Produce the smallest implementation plan that covers every accepted outcome and its verification boundary.
+name: change-plan
+description: Plan the registered change and its verification boundary when deliver-change routes a specified change.
 ---
 
 # Plan a change

{engineering_process-1.2.5/process_assets/skills/review-change → engineering_process-2.0.0/process_assets/skills/change-review}/SKILL.md

@@ -1,15 +1,24 @@
 ---
-name: review-change
-description: Review the exact verified snapshot from an actor and context independent of its implementation.
+name: change-review
+description: Review the exact verified snapshot from an independent actor and context when routed by deliver-change.
 ---
 
 # Review a change
 
 The reviewer must not share either actor identity or execution context with an
-implementer in the current cycle. Start the assignment:
+implementer in the current cycle. Read `processctl change status --change-id ID`.
+When the phase is `verified`, start the assignment:
 
     processctl change review start --change-id ID --actor REVIEWER --context REVIEW_CONTEXT
 
+When the phase is `review-pending`, resume the existing assignment; do not run
+`change review start` again. Read `.process/runs/ID/run.json` for its `cycle` and
+`reviewAssignment`, including the assigned reviewer, checkpoint, and
+`reportSchemaVersion`. Continue with the assigned independent actor/context and the
+existing report path, `.process/runs/ID/review-CYCLE.json`. If that reviewer is
+unavailable, report the pending assignment as a blocker; never impersonate its
+identity or create a replacement assignment from another context.
+
 Review the accepted contract, plan, complete diff, focused tests, and verification
 evidence. The first pass is comprehensive within that frozen contract. Every finding
 maps to one accepted criterion and records priority, origin, severity, and location.
@@ -41,7 +50,7 @@ consider consumer evidence that the lifecycle cannot observe. Every schema-versi
 report classifies `processImprovement` as `none`, `consumer-specific`, or
 `shared-process` and gives a concrete rationale. Consumer-specific behavior stays in
 the consumer. For `shared-process`, keep the assignment `review-pending` and route the
-candidate through **improve-process**. Submit only after an existing or owner-authorized
+candidate through **process-improve**. Submit only after an existing or owner-authorized
 issue supplies the stable HTTPS `recordUrl`; the review itself remains read-only.
 
 Read the consumer readiness result and repository rules. Check the complete diff for
@@ -56,8 +65,8 @@ Validate and submit the report:
     processctl contract validate --kind review REPORT_PATH
     processctl change review submit --change-id ID --review REPORT_PATH
 
-Review is read-only. Requested changes route back to **implement-change**; approval
-routes to **finish-change**. Keep the same independent reviewer for corrections.
+Review is read-only. Requested changes route back to **change-implement**; approval
+routes to **change-complete**. Keep the same independent reviewer for corrections.
 Follow-up scope is only carried findings, remediation diffs, and regressions against
 the frozen contract. A new blocker must be either remediation-caused or a P0/P1 late
 violation with a rationale. After two correction cycles, another changes-requested

{engineering_process-1.2.5/process_assets/skills/start-change → engineering_process-2.0.0/process_assets/skills/change-start}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: start-change
-description: Turn an accepted request into a bounded change contract before planning or implementation begins.
+name: change-start
+description: Turn an accepted request into a bounded change contract when deliver-change routes a new change to lifecycle start.
 ---
 
 # Start a change

{engineering_process-1.2.5/process_assets/skills/verify-change → engineering_process-2.0.0/process_assets/skills/change-verify}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: verify-change
-description: Run the project-owned verification profiles and bind their results to one unchanged repository snapshot.
+name: change-verify
+description: Run the project-owned verification profiles on one unchanged repository snapshot when routed by deliver-change.
 ---
 
 # Verify a change
@@ -23,4 +23,4 @@ planned capability whose gap remains open. A readiness promotion is valid only w
 all evidence named by that capability passes on this same snapshot.
 
 When all required profiles pass on the same snapshot, the lifecycle becomes verified;
-route to **review-change**.
+route to **change-review**.