[P2-018] Re-pin the delivery model to the repaired claim and handoff rules

AGENTS.md

@@ -26,13 +26,13 @@
 
 ## Delivery model (P2-018)
 
-Work is scheduled as delivery tasks in the [delivery graph](https://github.com/ArcForges/ArcForges-Design-B/blob/fd16c5f285de0bda2d0320cdff4d52c34c9098ed/docs/planning/delivery/README.md) and executed through the [Plan execution entry](https://github.com/ArcForges/Plan-B/blob/0cb637d1bfbf64d7db22a96a2b7370a409a25d8e/arcforges-implementation.md). There is no Current task, numbered substep order or single main context.
+Work is scheduled as delivery tasks in the [delivery graph](https://github.com/ArcForges/ArcForges-Design-B/blob/f8dff2d0144c7db020d35711d606334639dd078b/docs/planning/delivery/README.md) and executed through the [Plan execution entry](https://github.com/ArcForges/Plan-B/blob/ec8820732486464e92df89788edb89eafac86afb/arcforges-implementation.md). There is no Current task, numbered substep order or single main context.
 
-- Baseline: WP03.00–WP03.02 are accepted and WP03.03 has not started. Its closures and every later contract area are open tasks in the [contracts lane](https://github.com/ArcForges/ArcForges-Design-B/blob/fd16c5f285de0bda2d0320cdff4d52c34c9098ed/docs/planning/delivery/lanes/contracts.md); this repository also owns tasks in the extensions, governance and release lanes.
-- Start only a task that Plan-B's `python tools/delivery.py ready --claims` lists and whose `claims/<task-id>` branch you hold. No task here is ready until its adoption slice (`ADOPT.03.contracts`, `ADOPT.03.extensions`, `ADOPT.03.governance` or `ADOPT.03.release`) is recorded.
-- Several workers may work here at once, each on a different claimed task in its own retained worktree and `task/<task-id>` branch, inside the task's write scope. Closures are authored concurrently in their own domain proto or HTTP-schema, constraint and fixture files.
-- Shared files follow their [declared protocols](https://github.com/ArcForges/ArcForges-Design-B/blob/fd16c5f285de0bda2d0320cdff4d52c34c9098ed/docs/planning/delivery/shared-resources.md): the package inventory, foundation inventory and constraint aggregate are append-only per closure; a proto file with several contributing tasks has one designated author task; generated sources and descriptor baselines are regenerated after rebase, never hand-edited or hand-merged. The Contracts integration owner merges closure pull requests one at a time, and each merge to main publishes all packages at one candidate version.
-- Title pull requests `[<TASK-ID>] <summary>`; a bundle of compatible ready tasks lists each ID, and planning alignment uses `[P2-018]`. The integration owner merges only pull requests of the claimant at the current claim epoch.
+- Baseline: WP03.00–WP03.02 are accepted and WP03.03 has not started. Its closures and every later contract area are open tasks in the [contracts lane](https://github.com/ArcForges/ArcForges-Design-B/blob/f8dff2d0144c7db020d35711d606334639dd078b/docs/planning/delivery/lanes/contracts.md); this repository also owns tasks in the extensions, governance and release lanes.
+- Start only a task that Plan-B's `python tools/delivery.py ready` lists and whose claim you hold (`python tools/delivery.py claim <TASK-ID> --worker <name>`, recorded as `claims/<key>`, the ID in lower case with dots replaced by hyphens, such as `claims/con-02`); continue interrupted work from its handoff record (`python tools/delivery.py show <TASK-ID>`) rather than restarting it. No task here is ready until its adoption slice (`ADOPT.03.contracts`, `ADOPT.03.extensions`, `ADOPT.03.governance` or `ADOPT.03.release`) is recorded.
+- Several workers may work here at once, each on a different claimed task in its own retained worktree and `task/<key>` branch, inside the task's write scope. Closures are authored concurrently in their own domain proto or HTTP-schema, constraint and fixture files.
+- Shared files follow their [declared protocols](https://github.com/ArcForges/ArcForges-Design-B/blob/f8dff2d0144c7db020d35711d606334639dd078b/docs/planning/delivery/shared-resources.md): the package inventory, foundation inventory and constraint aggregate are append-only per closure; a proto file with several contributing tasks has one designated author task; generated sources and descriptor baselines are regenerated after rebase, never hand-edited or hand-merged. The Contracts integration owner merges closure pull requests one at a time, and each merge to main publishes all packages at one candidate version.
+- Title pull requests `[<TASK-ID>] <summary>`; a bundle of compatible ready tasks lists each ID, and planning alignment uses `[P2-018]`. The integration owner (the holder of `roles/integration-contracts`) merges only at the head commit reviewed for the claimant at the current claim epoch, keeping the task IDs in the merge title.
 - Dated `docs/wp03-*` and `docs/implementation/wp00-*` records describe their original scope; they are evidence, not execution instructions.
 
 ## Validation policy (P2-017)

README.md

@@ -14,7 +14,7 @@ operator and extension records, HTTP definitions, validators and an offline inve
 [WP03.02](docs/wp03-02-serialization.md) the generated-only serialization posture. Hello
 compatibility remains. Capability and resource descriptors (WP03.03), the complete business
 operation registries and the package-level gates are open delivery tasks in the
-[contracts lane](https://github.com/ArcForges/ArcForges-Design-B/blob/fd16c5f285de0bda2d0320cdff4d52c34c9098ed/docs/planning/delivery/lanes/contracts.md). The exact producer inventory is
+[contracts lane](https://github.com/ArcForges/ArcForges-Design-B/blob/f8dff2d0144c7db020d35711d606334639dd078b/docs/planning/delivery/lanes/contracts.md). The exact producer inventory is
 [`eng/contract-packages.json`](eng/contract-packages.json).
 
 | Package family                                                                             | Contents                                                                                          |