Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

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

Étoiles2

Forks0

Mis à jour8 juillet 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

wan-huiyan

wan-huiyan/agent-traffic-control

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.