feat(workflow): preserve worker succession across conversations

CHANGELOG.md

@@ -2,6 +2,19 @@
 
 ## Unreleased
 
+## 3.0.0 - 2026-09-07
+
+- Replace predecessor-acknowledged ownership transfer with explicit user-approved succession,
+  preserved checkpoints and project assignment lineage independent of disposable chats.
+- Allocate collision-checked worker IDs while retaining existing IDs and v1 work-state records;
+  record successor/model verification without implying independent review or merge authority.
+- Define OPS-attributed ownership, commit/PR receipts and synchronized managed labels while
+  retaining personal development authorship and existing repository permissions.
+- Name conversations through available official client tools, with verified results and
+  a capability-based fallback that never edits internal conversation storage.
+- This major version changes the coordination and handoff contract. Existing records remain
+  readable; label provisioning, tags, releases and account activation are not implicit.
+
 ## 2.9.0 - 2026-09-07
 
 - Add explicitly assigned conflict resolution, a durable merge sequence, exact review

README.md

@@ -114,6 +114,23 @@ Read [worker coordination](references/worker-coordination.md) for named workers
 [PR review](references/pr-review.md) for review work. Reload the real source when another
 conversation may have updated it; existing context is not rewritten by filesystem changes.
 
+### Worker succession in 3.0.0
+
+Workers are replaceable execution owners. Project assignments, commits, PRs and tested
+checkpoints preserve continuity when chats disappear or a later model takes over.
+Explicit user approval transfers named work without waiting for a predecessor response;
+existing IDs and v1 records remain valid. The changed transfer contract is the reason
+for the major version, not an incompatible storage migration.
+
+The coordination reference defines collision-checked IDs, assignment lineage, OPS
+ownership/commit receipts, and `DEV`/`OPS` plus `OCCUPIED`/`REVIEW_READY` label synchronization.
+Personal accounts still author development commits and create PRs when the repository
+separates those actions from OPS records. Labels do not grant ownership or merge authority.
+
+Conversation names follow `<short scope> | <project summary> | <short worker id>`.
+Use supported official tools and verify the new title; otherwise provide the suggested
+title without blocking development. Chat titles and IDs are optional lookup aids.
+
 For an explicitly assigned resolver of a named PR set, read
 [conflict resolution](references/conflict-resolution.md). Ordinary worker authority is unchanged.
 

SKILL.md

@@ -2,7 +2,7 @@
 name: commit-it
 description: Track requested features, fixes and GitHub delivery, prepare authorized issue-linked commits, perform scoped PR reviews, and resolve an explicitly assigned PR set through verified integration and authorized ordered merges.
 metadata:
-  version: "2.9.0"
+  version: "3.0.0"
 ---
 
 # Commit It
@@ -51,6 +51,11 @@ permission for scoped issue/PR tracking. Without that permission or a direct req
 prepare the proposed external update and obtain the missing authorization. Tracking
 permission alone never implies commit, push, PR publication, merge or branch deletion.
 An explicitly approved delivery sequence should proceed without repeated approval.
+Where operational writes use a configured OPS account or guarded command, route
+claims, labels, progress, commit receipts and review comments through that interface.
+The `gh` examples below describe operations, not permission to bypass account routing
+or worker restrictions on issue-body edits. Development commits and PR creation keep
+the repository's personal author identity, including both commit author and committer.
 
 1. **Start:** use `gh issue list/view` and `gh pr list/view` for the current task only.
    Reuse the related issue/PR. When creation is authorized and no match exists, create
@@ -175,16 +180,30 @@ work; intake alone does not start implementation or create a background service.
 
 ### Coordinator and worker ownership
 
-When the user adopts a coordinator with named workers, read
-[worker coordination](references/worker-coordination.md). Use the user-assigned IDs,
-Draft/Ready PR stages, an authoritative PR work-state block and issue status mirrors.
-Separate ownership from verification and authenticate messages with the intended
-account/App; a commit email does not set the issue/PR author. This opt-in mode does
-not expand repository permissions or create accounts, labels, Projects or background jobs.
-
-When a repository separates development authorship from operational records,
-follow its repository or global identity policy. Keep personal account mappings,
-local paths, credentials and deployment configuration outside this reusable skill.
+When the user assigns workers or requests succession, read
+[worker coordination](references/worker-coordination.md). Workers are replaceable
+execution owners, not permanent conversations. Preserve continuity through project
+assignments, issues, PRs, commits and reproducible verification. Later models improve
+inherited work through tests; a model change alone is neither new evidence nor a reason
+to discard valid work. Archived or deleted chats must not prevent approved succession.
+
+Preserve supplied worker IDs. Otherwise allocate `<client>-<UTC timestamp>-<8 hex digits>`
+and check project records for collisions. Keep assignment lineage and handoff revisions;
+explicit user approval is sufficient to transfer named work without predecessor acknowledgement.
+Preserve checkpoints, reconcile current ownership and stop only actual conflicting writers.
+This does not expand merge, deployment, credential or published-history authority.
+
+Use the reference's Draft/Ready stages, authoritative work-state record, issue mirrors,
+OPS commit/PR receipts and managed `DEV`/`OPS`, `OCCUPIED`/`REVIEW_READY` labels. Provision
+missing labels only within setup authorization. Separate personal development commits
+and PR creation from configured OPS ownership/status/review writes; authenticate each
+operation independently. Keep personal mappings, host paths and credentials outside this
+package. No account, App, Project or background job creation is implied.
+
+At assignment or handoff, use available official tools to name the current conversation
+`<short scope> | <project summary> | <short worker id>`. Verify the result; capability
+absence only requires a suggested title, not blocked implementation. See the reference
+for platform-specific paths and fallback rules.
 
 ### Explicit conflict-resolution mode
 
@@ -353,7 +372,8 @@ implementation, issue management, merging, or unrelated cleanup.
 - Default to a brief review of the exact diff, direct contracts/callers, and relevant
   verification. Expand only for a concrete risk or finding. Reuse valid test evidence.
 - When assigned to review PRs made by others, identify work this agent actually created;
-  account authorship alone cannot distinguish workers sharing one GitHub account.
+  account authorship alone cannot distinguish workers sharing one GitHub account. A successor
+  who modifies inherited code uses `Self-review: LGTM`; changing workers is not independent review.
 - If review publication is authorized and the scope has no blockers, the first line must
   be exactly `Self-review: LGTM` for work this agent authored or `Review: LGTM` for
   another worker's work. Only an explicitly assigned conflict resolver may instead use
@@ -365,7 +385,8 @@ implementation, issue management, merging, or unrelated cleanup.
 - A shared author account cannot formally approve or request changes on its own PR.
   Publish the result as a comment review in that case and describe its actual state.
 - For an ordinary worker's own completed PRs, reuse the implementation and tester's passing
-  evidence, briefly review the final diff, and post `Self-review: LGTM` immediately if unblocked.
+  evidence, briefly review the final diff, and post `Self-review: LGTM` after required
+  record, label and Draft/Ready synchronization succeeds and no blocker remains.
   Do not add another audit or repeat valid tests. Recheck only a relevant change or failure.
   Do not present self-review as independent or human approval. Unfinished work and pending
   required checks must not receive any approval heading.

references/conflict-resolution.md

@@ -8,8 +8,10 @@ this mode. User and repository authority still govern every action.
 
 - Record role `conflict-resolver` with the resolver's actual worker ID, named input
   PRs, base branch and allowed actions. A role is not a new identity. Preserve source
-  authorship, earlier worker records, unrelated changes and active worktrees. Confirm
-  affected writers have stopped before editing their branches; do not take over an
+  authorship, earlier worker records, unrelated changes and active worktrees. Follow
+  [user-approved succession](worker-coordination.md#user-approved-succession) for a
+  transfer: explicit user approval suffices without predecessor acknowledgement.
+  Preserve checkpoints and pause actual conflicting writes; do not take over an
   unassigned PR or infer authority from a shared account.
 - Resolve the named PRs' accepted requirements, defects and cross-PR interactions.
   Ordinary workers retain their existing PR-only boundaries. Resolver assignment

references/pr-review.md

@@ -30,8 +30,8 @@ unpublished personal design. A further improvement is blocking only when necessa
 the authorized outcome; otherwise keep it explicitly optional.
 
 For an ordinary worker's completed PR, reuse the implementation and tester's passing evidence.
-Briefly inspect the final diff and immediately post `Self-review: LGTM` if it has no
-blocker; do not add a second audit or rerun valid tests. Recheck only a relevant new
+After required record, label and Draft/Ready synchronization succeeds, briefly inspect
+the final diff and post `Self-review: LGTM` if it has no blocker; do not add a second audit or rerun valid tests. Recheck only a relevant new
 change or failure and name the reviewed head. An unfinished scope, known blocker or
 pending required check must not receive any approval heading.
 
@@ -47,6 +47,12 @@ These are the only approval headings; never use bare `OK`, bare `LGTM`, or anoth
 variant. All require the same completed scope and verified evidence for the recorded
 head/base; none claims independent human approval or guarantees that every behavior
 was tested. Determine authorship from actual work, not the shared GitHub account.
+A successor who edits inherited code uses `Self-review: LGTM`, preserves earlier
+worker attribution and links the reused verification. A new worker/model/account is
+not independent review by itself. A separate review-only assignment may use `Review: LGTM` only
+without taking implementation ownership or implementing the reviewed work. A successor
+accepting implementation ownership reports completion as self-review, including inherited work. Publish through the configured OPS review
+identity when required; the record still identifies the actual reviewing worker.
 A review never grants permission to merge or deploy. A conflict resolver preserves
 original authorship and follows the additional tree/sequence requirements in
 [conflict resolution](conflict-resolution.md); ordinary reviews do not activate it.