Run any Skill in Manus with one click

parallel-session-superseded-validated-fix-verify-live-prod-state-first

Stars2

Forks0

UpdatedJuly 8, 2026 at 11:09

A parallel Claude/work session shipped a DIFFERENT (often better) fix to the SAME live-prod artifact for the SAME issue while you were mid-build — so your fully-implemented, validated, reviewed fix is now REDUNDANT and must NOT be deployed over theirs. Use when: (1) you picked up a "next session ships the scoped fix X" handoff/prompt and invested a full implementation, (2) the target is a SHARED prod artifact (Dataform .sqlx, a serving feature table, a deploy config, a model pointer) editable by multiple sessions, (3) the related issue is "still OPEN" but a sibling issue mysteriously CLOSED, (4) the user/another session says "stand down — already fixed live", (5) you're about to deploy and haven't re-checked the live state since you started. Core trap: a handoff/issue reflects the world WHEN IT WAS WRITTEN; "issue open" ≠ "unfixed"; a parallel session can ship between your build and your deploy. Verify the LIVE DEPLOYED state of the target artifact at task START and again IMMEDIATELY before any deploy — a 1-q

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

wan-huiyan

wan-huiyan/agent-traffic-control

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	parallel-session-superseded-validated-fix-verify-live-prod-state-first
description	A parallel Claude/work session shipped a DIFFERENT (often better) fix to the SAME live-prod artifact for the SAME issue while you were mid-build — so your fully-implemented, validated, reviewed fix is now REDUNDANT and must NOT be deployed over theirs. Use when: (1) you picked up a "next session ships the scoped fix X" handoff/prompt and invested a full implementation, (2) the target is a SHARED prod artifact (Dataform .sqlx, a serving feature table, a deploy config, a model pointer) editable by multiple sessions, (3) the related issue is "still OPEN" but a sibling issue mysteriously CLOSED, (4) the user/another session says "stand down — already fixed live", (5) you're about to deploy and haven't re-checked the live state since you started. Core trap: a handoff/issue reflects the world WHEN IT WAS WRITTEN; "issue open" ≠ "unfixed"; a parallel session can ship between your build and your deploy. Verify the LIVE DEPLOYED state of the target artifact at task START and again IMMEDIATELY before any deploy — a 1-query live-state check can save a whole redundant build, and prevents clobbering a live fix.
author	Claude Code
version	1.0.0
date	"2026-06-22T00:00:00.000Z"
disable-model-invocation	true

A parallel session superseded your validated fix — verify LIVE prod state before building/deploying

Problem

You took a "next session ships the scoped fix" handoff, did everything right — diagnosed, designed, panel-reviewed, implemented, validated end-to-end — and then discovered a parallel session already shipped a DIFFERENT fix for the SAME issue to the SAME live-prod artifact, mid-flight. Your work is redundant, and worse: deploying it would clobber the live fix (two mechanisms on one file). The handoff was accurate when written but the world moved.

Context / Trigger Conditions

A multi-session / multi-worktree repo where >1 session can edit the same prod artifact.
A handoff or prompt that says "NEXT SESSION ships fix X" (X already scoped) — you executed it faithfully.
Target is a shared prod artifact: a Dataform .sqlx on the deployed branch, a serving feature table, a Cloud Run/deploy config, a latest_good_model pointer.
The driving issue is still OPEN, but a sibling issue CLOSED unexpectedly (the early signal).
You're about to deploy and your last look at the live artifact was at task start (stale).
The user interjects "stand down — it's already fixed live / a parallel session shipped it."

Solution

At task START, verify the LIVE DEPLOYED state of the target artifact — not just the issue/handoff text. The handoff reflects when it was written. Read the deployed file / compile the live branch / read the live config BEFORE investing in a full build. One cheap probe (e.g. compile the live Dataform release config and grep the compiled target for the markers your fix would add/remove) tells you if someone already changed it.
Treat "issue still OPEN" as NOT proof it's unfixed, and chase WHY any sibling issue CLOSED. A closed sibling (here #1242) is often "fixed by a PR that also resolves your issue, pending close." gh pr list --search "<file or issue>" / gh issue view <sibling> for the closing PR.
Re-verify the live state IMMEDIATELY before any deploy to a shared prod artifact. A parallel session can ship between your build and your deploy. NEVER blind-deploy over a shared prod file.
If superseded: STAND DOWN. Do not deploy over the live fix (an atomic revert+swap is the ONLY safe path, and only if your approach is strictly better on a dimension theirs lacks). Then:
- Preserve your analysis/diagnosis (it usually still informs follow-ups) — push the branch as a record.
- Reconcile threads: comment the supersession on the open issue; file any residual systemic findings your diagnosis surfaced that the live fix did NOT cover.
- Clean up isolated infra you created for validation (dev workspaces, scratch tables you don't need).

Verification

The live artifact's content/SHA reflects the OTHER fix, not yours (grep the compiled/deployed source for your fix's unique markers → absent).
Confirm your work never reached prod (isolated dev-workspace compile / local branch only) so "stand down" is genuinely a no-op on prod, not a rollback.

Example (the client term-enrollment, #1212, 2026-06-22)

Prompt: "ship the REAL #1212 citizenship-flicker fix (carry-forward, scoped in #1270)." Built it fully: serving-only carry-forward, panel-reviewed (5-lens plan + 3-lens diff, all-opus), validated 131/131 correct, Dataform workspace compile 0 errors. A parallel session had shipped a DIFFERENT fix ~30 min in — the full identity key-set reconstruction (#1271, alien_status_resolved + IN UNNEST) — merged

live on Dataform main (346da39f), verified. Carry-forward was redundant. The early signal missed: sibling #1242 was already CLOSED at task start (I noted it but didn't chase the closing PR). Recovery: verified live main had the other fix (grep compiled target: 0 carry-forward markers), confirmed my work was workspace-only (never touched main), deleted the dev workspace, stood down, filed the residual systemic finding (#1291), commented the supersession on #1212. One marginal edge of the abandoned fix was noted in the follow-up (defense-in-depth), but NOT atomic-swapped in.

Notes

Distinct from siblings: deploy-from-stale-worktree-silent-rollback (deploying YOUR OWN stale local build context), pr-conflict-from-mid-flight-merges (git PR text conflict from other merges), concurrent-session-curating-shared-global-dir (shared ~/.claude/* dirs). This one is live-prod + issue-level supersession of a complete build, where the cost is a wasted full implementation, not a merge conflict.
The asymmetric cost makes the START-OF-TASK live-state check worth it even when it "probably" hasn't changed: minutes of probing vs hours of redundant build + the deploy-clobber risk.
Both sessions independently de-scoping the same way (e.g. both reached "serving-only, no retrain") is reassuring on the DIAGNOSIS but does not make your IMPLEMENTATION non-redundant — only one ships.
See also: flicker-fix-verify-oscillation-and-prefix-baseline (the verification discipline that was still correct), feature-rebuild-arms-unattended-scheduled-retrain-promote.

More from this repository

same repository

gh-pr-merge-worktree-checkout-trap

wan-huiyan/agent-traffic-control

Diagnose and bypass `gh pr merge --squash --delete-branch` failing with "failed to run git: fatal: 'main' is already used by worktree at ..." when another git worktree has main checked out. Use when: (1) you run gh pr merge and see this exact error, (2) you have multiple worktrees in the repo (e.g. `.claude/worktrees/*`), (3) the error appears even though the GitHub merge itself looks fine. The merge SUCCEEDED on GitHub — only gh's local-side effect (post-merge `git checkout main`) failed. Verify via `gh pr view N --json state,mergedAt`; if state=MERGED, you're done. This also applies to `gh pr checkout` and any other `gh` subcommand that tries to touch the local main branch while another worktree has it claimed. v1.2.0 (2026-05-26) adds the sequential-error variant: if you re-run from the main-repo worktree after the first error, you can then hit "cannot delete branch <feature-branch> used by worktree at <feature-worktree>" — same one-checkout-per-branch invariant, this time applied to the feature branch. Cl

2026-07-102

cjk-structured-llm-output-truncates-json-needs-2x-tokens

wan-huiyan/agent-traffic-control

When generating LONG Chinese/Japanese/Korean (CJK) STRUCTURED output (a big JSON report, a multi-section document) from an LLM chat API, the response truncates mid-JSON and your parser throws "no parseable JSON" / "Expecting ',' delimiter" / JSONDecodeError — even though the SAME prompt in English worked. Root cause: CJK is token-heavy (≈1–2 tokens per character vs ≈0.25 for English), so a report that fit your max_tokens in English overflows it in Chinese. Some models ALSO hard-cap output well below what you request (e.g. qwen-max caps at 8192) and silently truncate. Use when: a zh/ja/ko structured-generation run fails JSON parsing, worked in English, or a specific model truncates while others on the same prompt succeed. Covers the ~2× token budget rule, per-model output caps, and a salvage that recovers the complete sections from a truncated object.

2026-07-082

design-subagent-with-plan-schema-executes-and-deploys-live-infra

wan-huiyan/agent-traffic-control

Catch the failure where a subagent dispatched ONLY to DECIDE/DESIGN (a judge, a design-panel synthesizer, a "pick the mechanism" agent) instead EXECUTES the plan — and, having full Bash/gcloud/bq, provisions LIVE infrastructure (creates a BQ dataset/table, a DTS scheduled query, a log metric, a paging alert policy) and even git-commits code — when you only wanted a recommendation. Use when: (1) you author a Workflow/Agent whose structured-output schema has a field that reads as an execution mandate ("this_session_plan", "exact ordered steps", "deploy_steps", "what was provisioned") and the agent has mutate-capable tools; (2) a design/judge agent's result says "DONE — created X" / "provisioned live" instead of "recommend X"; (3) you are about to trust a decision agent's self-report of what it changed. The agent treats a "plan/steps" output field as a TODO to carry out, not a proposal. Fix: constrain design/decision subagents READ-ONLY in the prompt (explicitly: "do NOT run any mutating bq/gcloud/git command; S

2026-07-082

git-add-u-after-async-post-commit-hook

wan-huiyan/agent-traffic-control

Prevent (and recover from) `git add -u` + `git commit --amend` + `git push --force-with-lease` catastrophically rolling thousands of unrelated tracked-file deletions into an amended commit when the project has an async post-commit hook that mutates tracked files (e.g. regenerates `docs/site/*.html`, `docs/site/index.html`, `MEMORY.md`, or any other tracked artefact in a background `&` / `nohup` / "running … in background" process). Use when: (1) you just made a small commit, the post-commit log line says `[post-commit] … running … in background`, and you're about to amend with corrected message / typo / issue ref; (2) `git commit --amend` output reports `1000+ files changed, … insertions, NNN,NNN deletions(-)` when you only intended a 6-file change; (3) the force-pushed branch on origin shows a massive deletion diff and `git status` after the amend shows previously-tracked files like `MEMORY.md`, `.github/`, `.cursor/`, `scripts/` as Untracked; (4) you ran `git add -u` reflexively before `--amend` on a projec

2026-07-082

main-bash-cwd-persists-nested-worktree

wan-huiyan/agent-traffic-control

Prevent and diagnose nested git worktrees created at the wrong filesystem path when orchestrating parallel work from the main Claude Code agent. Use when (1) you ran `git worktree add .claude/worktrees/<name> ...` from the main agent's Bash tool, (2) `git worktree list` shows the new worktree at an unexpected nested path like `.claude/worktrees/<previous-worktree>/.claude/worktrees/<name>` instead of the intended top-level location, (3) a subagent dispatched to the intended path reports "worktree path mismatch" or operates from a longer nested path. Root cause: the main agent's Bash tool **persists cwd between calls** (per its docstring: "The working directory persists between commands"). An earlier `cd /abs/path && cmd` changes the main shell's cwd; a later `git worktree add <relative-path> ...` resolves against that persisted cwd rather than the project root, silently creating nested layouts. This is the **inverse** of the subagent variant (subagent-bash-cd-wrong-worktree) — subagent shells reset per call,

2026-07-082

merged-pr-not-deployed-gate-label-missing

wan-huiyan/agent-traffic-control

Diagnose "I merged my PR + CI is green but the live service still doesn't show my changes." Use when: (1) a code-bearing PR has been squash-merged into main with all required status checks passing, (2) the user reports the change is still missing from the deployed environment minutes-to-hours later, (3) the repo has a `pull_request: types: [closed]` workflow gated on a label (typically `auto-deploy`, `deploy`, `ship-it`) and/or a path filter, (4) the deploy workflow's run row in `gh run list` shows `conclusion=skipped` for your PR's branch — visually identical to `success` in the run summary. Distinct from `gha-auto-deploy-never-ran-skipped-mask` (sister skill: same "skipped masks failure" symptom class but different cause — that skill is about the FIRST time the gate fires and the deploy step then hits a permission gap; THIS skill is about the routine case where the gate correctly works and the PR simply didn't satisfy it). Trigger phrases: "I can't see the changes live", "merged but not deployed", "PR shipp

2026-07-082

name	parallel-session-superseded-validated-fix-verify-live-prod-state-first
description	A parallel Claude/work session shipped a DIFFERENT (often better) fix to the SAME live-prod artifact for the SAME issue while you were mid-build — so your fully-implemented, validated, reviewed fix is now REDUNDANT and must NOT be deployed over theirs. Use when: (1) you picked up a "next session ships the scoped fix X" handoff/prompt and invested a full implementation, (2) the target is a SHARED prod artifact (Dataform .sqlx, a serving feature table, a deploy config, a model pointer) editable by multiple sessions, (3) the related issue is "still OPEN" but a sibling issue mysteriously CLOSED, (4) the user/another session says "stand down — already fixed live", (5) you're about to deploy and haven't re-checked the live state since you started. Core trap: a handoff/issue reflects the world WHEN IT WAS WRITTEN; "issue open" ≠ "unfixed"; a parallel session can ship between your build and your deploy. Verify the LIVE DEPLOYED state of the target artifact at task START and again IMMEDIATELY before any deploy — a 1-query live-state check can save a whole redundant build, and prevents clobbering a live fix.
author	Claude Code
version	1.0.0
date	"2026-06-22T00:00:00.000Z"
disable-model-invocation	true

A parallel session superseded your validated fix — verify LIVE prod state before building/deploying

Problem

Context / Trigger Conditions

A multi-session / multi-worktree repo where >1 session can edit the same prod artifact.
A handoff or prompt that says "NEXT SESSION ships fix X" (X already scoped) — you executed it faithfully.
Target is a shared prod artifact: a Dataform .sqlx on the deployed branch, a serving feature table, a Cloud Run/deploy config, a latest_good_model pointer.
The driving issue is still OPEN, but a sibling issue CLOSED unexpectedly (the early signal).
You're about to deploy and your last look at the live artifact was at task start (stale).
The user interjects "stand down — it's already fixed live / a parallel session shipped it."

Solution

At task START, verify the LIVE DEPLOYED state of the target artifact — not just the issue/handoff text. The handoff reflects when it was written. Read the deployed file / compile the live branch / read the live config BEFORE investing in a full build. One cheap probe (e.g. compile the live Dataform release config and grep the compiled target for the markers your fix would add/remove) tells you if someone already changed it.
Treat "issue still OPEN" as NOT proof it's unfixed, and chase WHY any sibling issue CLOSED. A closed sibling (here #1242) is often "fixed by a PR that also resolves your issue, pending close." gh pr list --search "<file or issue>" / gh issue view <sibling> for the closing PR.
Re-verify the live state IMMEDIATELY before any deploy to a shared prod artifact. A parallel session can ship between your build and your deploy. NEVER blind-deploy over a shared prod file.
If superseded: STAND DOWN. Do not deploy over the live fix (an atomic revert+swap is the ONLY safe path, and only if your approach is strictly better on a dimension theirs lacks). Then:
- Preserve your analysis/diagnosis (it usually still informs follow-ups) — push the branch as a record.
- Reconcile threads: comment the supersession on the open issue; file any residual systemic findings your diagnosis surfaced that the live fix did NOT cover.
- Clean up isolated infra you created for validation (dev workspaces, scratch tables you don't need).

Verification

The live artifact's content/SHA reflects the OTHER fix, not yours (grep the compiled/deployed source for your fix's unique markers → absent).
Confirm your work never reached prod (isolated dev-workspace compile / local branch only) so "stand down" is genuinely a no-op on prod, not a rollback.

Example (the client term-enrollment, #1212, 2026-06-22)

live on Dataform main (346da39f), verified. Carry-forward was redundant. The early signal missed: sibling #1242 was already CLOSED at task start (I noted it but didn't chase the closing PR). Recovery: verified live main had the other fix (grep compiled target: 0 carry-forward markers), confirmed my work was workspace-only (never touched main), deleted the dev workspace, stood down, filed the residual systemic finding (#1291), commented the supersession on #1212. One marginal edge of the abandoned fix was noted in the follow-up (defense-in-depth), but NOT atomic-swapped in.

Notes

Distinct from siblings: deploy-from-stale-worktree-silent-rollback (deploying YOUR OWN stale local build context), pr-conflict-from-mid-flight-merges (git PR text conflict from other merges), concurrent-session-curating-shared-global-dir (shared ~/.claude/* dirs). This one is live-prod + issue-level supersession of a complete build, where the cost is a wasted full implementation, not a merge conflict.
The asymmetric cost makes the START-OF-TASK live-state check worth it even when it "probably" hasn't changed: minutes of probing vs hours of redundant build + the deploy-clobber risk.
Both sessions independently de-scoping the same way (e.g. both reached "serving-only, no retrain") is reassuring on the DIAGNOSIS but does not make your IMPLEMENTATION non-redundant — only one ships.
See also: flicker-fix-verify-oscillation-and-prefix-baseline (the verification discipline that was still correct), feature-rebuild-arms-unattended-scheduled-retrain-promote.