Standardize run and assignment identity for workflow attribution; release staged-implementation 0.2.0-alpha.3

plugins/staged-implementation/skills/coordinator/SKILL.md

@@ -16,7 +16,7 @@ Before dispatch, read the shared [Execution Contract](references/execution-contr
 ## Establish the Run
 
 1. Read project instructions and identify the authoritative plan, checklist, prompt map, readiness audit and current execution handoff. Verify actual Git/worktree state and protected pre-existing changes. Confirm planning checkpoint or explicit uncommitted disposition. If missing and no planning-commit authority exists, finish applicable document checks, identify the exact proposed files/commit and ask before execution. Planning and implementation commit authority remain separate.
-2. Record the authorized run boundary, allowed targets/operations, model/effort, stop conditions and commit policy with their sources. Normalize existing instructions to `authorized-for-accepted-chunks`, `ask-before-each-commit` or `do-not-commit`; ask only when unresolved. General implementation permission does not authorize commits, pushing, deployment or hardware operations.
+2. Record the authorized run boundary, allowed targets/operations, model/effort, stop conditions and commit policy with their sources. Establish or recover the stable run ID under the shared contract's assignment-label rules; resume retains it. Normalize existing instructions to `authorized-for-accepted-chunks`, `ask-before-each-commit` or `do-not-commit`; ask only when unresolved. General implementation permission does not authorize commits, pushing, deployment or hardware operations.
 3. Reuse a current readiness audit. If absent, assess the full intended run once; subsequently update affected dependencies/scope only. Classify ready, contract-blocked, dependency-blocked, environment-blocked and required pre-implementation freezes. Unrelated unresolved contract decisions require explicit ready-subset authorization. Major feasibility risks are investigated early; later engineering freezes precede dependent work, not every independent chunk.
 4. Verify persistent source/backing Git/evidence locations, resource ownership and receiving-filesystem headroom. Establish one run resource ledger in the existing handoff. Allocate resources and shared targets to the active orchestrator; do not duplicate its child allocations in the run total.
 5. Qualify the runtime for this architecture before consequential execution. Verify nested delegation, scoped context, preservation of authorized model/effort, inspectable child edits, pause/notification routing and enough agent capacity. Demonstrate that retiring a completed subtree permits a fresh orchestrator and its workers to launch; an idle/interrupted worker may still occupy a slot. Reuse applicable recorded qualification, not unsupported assumptions. Use the bounded [Pilot Validation](references/pilot-validation.md) when this runtime/model arrangement is unqualified. If unavailable or unsafe, hold coordinated execution and propose direct/manual operation; do not silently flatten the hierarchy, bypass independent validation or restart active work.
@@ -26,8 +26,8 @@ Start with one active orchestrator assignment at a time. Coordinator + orchestra
 ## Dispatch and Continue
 
 1. Select the next eligible chunk or validation gate from written dependencies and actual accepted state. Do not treat a committed candidate as accepted without its acceptance evidence. Do not use held work as a dependency. Verify uncommitted accepted inputs explicitly when permitted by policy. If grouping is useful, enumerate the approved chunk IDs and order; preserve every acceptance/rollback boundary.
-2. Assign the bounded work using the shared execution contract. Save or reference the assignment in existing prompt/handoff locations; no separate dispatch journal. Give a fresh orchestrator scoped context without full parent-history inheritance when supported, explicit authorized model/effort if needed, and the correct experimental skill path/version. It writes the detailed implementer prompt after verifying scoped readiness. Do not send it the entire historical run narrative.
-3. Record the assignment/worker mapping and ownership before it may mutate shared resources. Delegate chunk review, acceptance and scoped commits under existing user authority. Reserve the candidate/index/integration target for that orchestrator; neither coordinator nor another worker may edit or stage there concurrently. Coordinator-owned scheduling records must be separate from the candidate's validated inputs, or updated only after its hold is released.
+2. Assign the bounded work using the shared execution contract, including the run ID, unit scope/ID, role and attempt to propagate through delegation. Use its supported task-label encoding. Save or reference the assignment in existing prompt/handoff locations; no separate dispatch journal. Give a fresh orchestrator scoped context without full parent-history inheritance when supported, explicit authorized model/effort if needed, and the correct experimental skill path/version. It writes the detailed implementer prompt after verifying scoped readiness. Do not send it the entire historical run narrative.
+3. Record the logical assignment/tool-label/actual-worker mapping, immediate parent and ownership before it may mutate shared resources. Delegate chunk review, acceptance and scoped commits under existing user authority. Reserve the candidate/index/integration target for that orchestrator; neither coordinator nor another worker may edit or stage there concurrently. Coordinator-owned scheduling records must be separate from the candidate's validated inputs, or updated only after its hold is released.
 4. Wait for completion or material events using supported notifications/interruptible waits. Do not send routine acknowledgement prompts, poll continuously, or absorb raw logs merely to remain busy. Check liveness when expected progress, tool failure or other evidence warrants it; a wait timeout alone is insufficient. Prefer available status information before prompting. Required user updates use information already received, with uncertainty stated honestly; do not initiate inspections or descendant status requests solely to refresh a progress message. Follow the shared contract's communication boundary while preserving timely intervention, pause routing and required safety/resource checks. Do not let the orchestrator dispatch beyond its assignment.
 5. Check the returned acceptance record and actual repository state under **Completion Verification**. Route concrete omissions or discrepancies back to the same orchestrator when continuity is useful. Do not start a new full review for every clerical correction. New contract or cross-chunk risk can require a scoped independent challenge; no required review may be skipped.
 6. Transfer outstanding resources/holds, retire the complete worker subtree and verify capacity for the next assignment. Closing a parent does not prove its children/processes stopped. Preserve held source, failed evidence and future gate/rollback consumers. Reconcile eligible cleanup and allocations before further work.

plugins/staged-implementation/skills/coordinator/references/execution-contract.md

@@ -15,6 +15,18 @@ Shared by Coordinator and Orchestrator. Use existing prompt, handoff and chunk-e
 
 In coordinated mode, the orchestrator owns its chunk prompt, review, evidence and acceptance record; the coordinator owns global scheduling/readiness/status records. The orchestrator returns proposed global updates rather than editing them concurrently. If a shared contract must change, hold affected work and route it for authoritative reconciliation. Direct mode folds run duties into the orchestrator only for the explicitly bounded assignment.
 
+### Assignment labels
+
+Establish one non-secret run ID in the existing handoff before dispatch. Preserve it across session restarts/resume and pass it unchanged to descendants; distinct runs use distinct IDs. The logical assignment is run ID + scope (`chunk` or `group`) + exact chunk/gate or named-group ID + role + attempt. A group names its members explicitly; its workers use their actual assigned chunk or group, not an inferred allocation. Same-worker correction/revalidation retains identity; a fresh replacement increments the attempt for that run/scope/unit/role, including after resume. Do not reuse an assignment ID for a different worker.
+
+For supported spawn task names, encode this identity as:
+
+`si1_<hex run ID>_<c|g>_<hex unit ID>_<role>_<attempt>`
+
+Use lowercase hexadecimal of the exact UTF-8 run/unit IDs (no slugification), `c` for one chunk or gate, `g` for a named group, the lowercase role name, and a positive decimal attempt without leading zeros. IDs must be nonempty, at most 96 UTF-8 bytes each and contain no characters below U+0020; keep the encoded label within 512 characters and the tool's actual limits. For example, run `run-a`, chunk `O-03`, role `implementer`, attempt `1` becomes `si1_72756e2d61_c_4f2d3033_implementer_1`. Hex is reversible, not anonymization; never put credentials or private content in identifiers.
+
+Record logical assignment → submitted tool label → returned worker ID and immediate parent in the existing handoff/assignment record once. Check uniqueness in the tool's naming scope. If the tool cannot accept the encoding or has no label field, retain the logical identity and explicitly map the supported unique label (or absence of one) to the actual worker; never silently truncate, rename canonical IDs or assume an audit can infer the mapping. Labels identify assignments, not acceptance, completion or resource release. No extra status messages or telemetry journal are required.
+
 ## Execution and Acceptance
 
 The orchestrator reads the actual candidate and contracts, writes/reuses the scoped implementer prompt, reviews the actual diff and affected behavior, obtains independent validation where required, reconciles findings and decides chunk acceptance. No implementer self-acceptance or validator acceptance authority. Independence requires a separate validator assignment with authoritative requirements and candidate evidence, not adoption of the implementer's verdict. Required fresh challenges remain mandatory.

plugins/staged-implementation/skills/coordinator/references/pilot-validation.md

@@ -14,6 +14,8 @@ Before consequential unattended work, qualify a small disposable fixture project
 6. **Integration discrepancy:** change a fixture input after validation or return an inconsistent candidate/commit identity. Verify completion is held for reconciliation. Test uncommitted accepted work under `do-not-commit` without forcing a commit or allowing unsafe subsequent overlap.
 7. **Resources:** simulate low-space/admission outcomes without filling the disk. Check allocation accounting across layers, persistence verification before edits, retained future consumers and bounded cleanup authority. Retirement must not delete held work or imply a process/resource release.
 
+During these trials, verify the [assignment-label mapping](execution-contract.md#assignment-labels) against actual submitted task names and returned worker/parent identities. Same-worker repairs retain identity; replacement increments the attempt; restart preserves the run ID; a separate run uses a distinct ID. Check chunk versus named-group scope and any tool-limit mapping explicitly. Record this in existing trial evidence; successful label generation alone does not prove logs expose enough information for audit correlation.
+
 During ordinary execution and the correction cycle, observe whether user updates trigger status-only polling chains or parents duplicate active workers' investigations. Check that required updates use known state, ordinary repairs stay with the orchestrator, and material blockers/pauses still propagate promptly. Record deviations in the existing trial evidence; no separate report or rigid message quota is needed.
 
 Hold unattended qualification on any unresolved authority, candidate, recovery or capacity failure. Propose direct/manual execution only as an explicit alternative, not an automatic fallback. Additional nested reviews require available capacity; do not drop a required review or change models to fit.

plugins/staged-implementation/skills/orchestrator/SKILL.md

@@ -123,7 +123,7 @@ For each authorized ready unit within the assignment (validation-only gates need
 
 Keep the existing chunk record sufficient for recovery: candidate/baseline, worker ownership, findings, evidence, authority and retained consumers. Return these to the coordinator's one live run handoff; do not create a competing global status record. Direct mode uses the existing bounded handoff. Preserve future gates, dependencies and recovery obligations through authoritative links. Do not load accepted-chunk narratives or full logs unless applicable to current work.
 
-Attribute every worker assignment to a stable chunk and role with a canonical ID such as `<chunk-id>:<role>:<attempt>`. Use implementer modes `new-chunk | correction | replacement` and validator modes `validation | revalidation | replacement`. Same-worker corrections/revalidation retain the assignment ID; a fresh replacement increments the attempt. A next-chunk worker uses the new chunk's ID. Where task labels are supported, use the canonical ID only if valid for that tool; otherwise choose a supported unique label (for example, `o_03_implementer_1` for `O-03:implementer:1`). Record the assignment-to-label/worker mapping once in the handoff; check label collisions and do not assume telemetry can decode an unsupported format.
+Attribute workers using the [shared assignment-label contract](../coordinator/references/execution-contract.md#assignment-labels): propagate the coordinator's run ID, or establish/recover it in the direct-mode handoff. Encode the exact unit scope/ID, role and attempt for supported task names; record the mapping to actual workers and immediate parents. Use implementer modes `new-chunk | correction | replacement` and validator modes `validation | revalidation | replacement`. Same-worker corrections/revalidation retain identity; a fresh replacement increments the attempt, including after resume. A next-chunk worker uses the new chunk's ID. Tool limitations require an explicit mapping, not guessed truncation or a new run ID.
 
 The implementer may remain available as the same-chunk repair agent during validation, but must not write until the parent releases the validation hold and assigns a correction. Before a replacement edits, establish that the prior worker and its owned operations have stopped writing; verify the actual candidate, transfer relevant findings/resources, retire the superseded assignment and designate the replacement as sole writer. A recorded transfer alone does not establish that writes stopped. An unresolved validation hold still prevents replacement edits.
 

plugins/staged-implementation/skills/planner/SKILL.md

@@ -305,7 +305,7 @@ For a direct orchestrator launch, name the chunk/gate IDs and stop boundary. It
 
 State the lifecycle: retain same-chunk repair continuity without writes during validation; verify writer cessation and ownership transfer before replacement. Retire the complete subtree after the bounded result and transfer resources/holds. Runtime inactivity does not prove capacity or process release. Route coordinated approvals through Coordinator, propagate user pauses promptly, and preserve recovery evidence. Keep future gates, dependencies, recovery obligations and authority restrictions accessible in the existing handoff.
 
-Use canonical assignment IDs such as `<chunk-id>:<role>:<attempt>`; same-worker corrections/revalidation retain the ID and fresh replacements increment the attempt. If task labels are supported, use the ID only when valid for that tool; otherwise use a supported unique encoding and record its mapping to the assignment/worker in the handoff. Do not require unsupported label syntax or assume telemetry recognizes the encoding.
+Use the [shared assignment-label contract](../coordinator/references/execution-contract.md#assignment-labels) for both execution entry points. Establish/recover one stable run ID, preserve it on resume and propagate it to descendants. Same-worker corrections/revalidation retain identity; fresh replacements increment the attempt. Require the shared encoding for supported task names and the logical-assignment/tool-label/actual-worker mapping with immediate parent in the existing handoff. Tool limitations require an explicit mapping, not silent truncation or assumed telemetry attribution.
 
 State in the handoff that authorization to run orchestration includes routine cleanup of that run's tracked, disposable temporary resources after ownership, retention and consumer-release checks pass. No separate cleanup approval question is needed within those bounds. Carry this scope into worker assignments and honor explicit retention/no-deletion instructions and higher-priority restrictions. On resuming the same run, accumulated resources qualify only after their run ownership and release conditions are verified and recorded. Unknown ownership, shared caches, files predating the run, unrelated resources and anything still needed remain excluded. Standalone planning/implementation/validation or commit permission does not grant this orchestration cleanup scope; ask for concrete additional authority only when needed outside it. Never propose blanket clearing of `/tmp`.